FounderA founder whose product has no steady paying customers yet

When customers ask for different things, I want to know which are worth building, so the product does not become a collection of features for individuals.

Khi khách hàng yêu cầu những thứ khác nhau, tôi muốn biết cái nào đáng làm, để sản phẩm không biến thành một tập hợp tính năng cho từng người một.

Job context

Who: A founder who is also the person deciding what gets built
When: Each week when choosing the team's work
Trigger: Two large customers asking for opposite things
Situation: Requests come from paying customers, which makes refusal costly
Constraints: A small team, and every feature added must be maintained forever

The biggest payer has the loudest voice
High
The roadmap slowly becomes one customer's roadmap.
Root cause: Revenue is the clearest signal the company has
Cannot tell if a request is common
High
One loud voice sounds exactly like many quiet ones.
Root cause: Only people who speak appear in the request data
Every feature must be fed forever
High
The real cost of a feature is in the years after, not the week of building.
Root cause: Build cost is visible; maintenance cost is not
Refusing a paying customer is hard
Medium
The cost of refusing is immediate; the cost of agreeing arrives months later.
Root cause: The two costs never appear at the same time, so they cannot be compared
Does not know if a shipped feature is used
Medium
Unmeasured, every feature is presumed successful.
Root cause: Nobody returns to check after shipping

A solution is not the same thing as a product — a customer can hire a behaviour or a workaround too.

A feature request tracker
Product
Counts those who spoke, not those who did not.
Public feature voting
Product
Democratises voice and still counts only the participating minority.
Measure usage after shipping
Behaviour
The only feedback loop that actually closes, and few teams run it.
Ask what they would pay for it
Behaviour
Turns a request into a test — the cheapest filter available.
Say no by deferring indefinitely
Workaround
The commonest refusal, leaving a backlog nobody ever cleans.

Request data contains only those who spoke; people with the same need who stayed quiet exist in no table.
Why existing solutions fail: Every request tool is a push channel — it records what was sent and has no way to record what nobody sent.
Potential opportunity: Actively sampling at random instead of waiting for volunteers, so the quiet majority appears in the data.
Decisions are made on build cost because it is estimable, while the real cost is years of maintenance.
Why existing solutions fail: Maintenance cost is spread across the future and cannot be attributed to one feature, so it never enters the deciding conversation.
Potential opportunity: Recording an estimated maintenance cost beside each feature and accumulating it into one visible number.