How We Decide What to Build Next

When you are a small studio, the decision of what to build next is not one decision among many. It is the decision. Pick wrong and you spend three months and most of your runway on something nobody wanted. Pick right and a single feature pulls the whole product forward. Big companies can afford to spread bets across a dozen initiatives. We get a few shots a year, and each one has to count.

People assume there must be a clean framework behind a focused product. There is not. There is a messy, opinionated, deliberately uncomfortable process, and I would rather describe it honestly than pretend we have a tidy scoring spreadsheet.

We start from pain, not from ideas

Ideas are cheap and infinite. Everyone has them, including us, and most are seductive nonsense. We do not start a build from an idea. We start from a pain we have seen repeatedly, in our own usage or in how people talk about the product.

The discipline is to keep asking what hurts, not what would be cool. Cool features are how studios go broke feeling busy. Painful problems are where the actual willingness to pay lives. If I cannot name the specific moment of frustration a feature relieves, it is not ready to be on the roadmap.

We do not ship features. We retire pains.

The signal we trust most is repeated, unprompted

Not all feedback is equal. A feature someone requests in a survey is weak signal. A frustration that the same kind of user keeps raising, unprompted, in their own words, is strong signal. We weight the spontaneous over the solicited every time.

• Unprompted beats prompted. If we had to ask, the pain is probably mild.
• Repeated beats loud. One furious user is a data point. Five calm mentions of the same gap is a pattern.
• Behavior beats words. Where people drop off, what they retry, what they screenshot, all of it says more than what they tell us.

We size by the cost of being wrong

Once we have a candidate, the question is not only how big the upside is, but how expensive the mistake would be. Some bets are cheap to test and cheap to undo. Others quietly commit us for months. We strongly prefer the reversible kind.

This is where being small is an advantage. We can ship a rough version of a feature to a slice of users, watch what happens, and kill it without ceremony if it flops. A larger team would need a launch plan and a stakeholder meeting to do the same thing. We just try it and read the data.

We weigh it against the one thing rule

Every candidate gets held up against the core promise of the app. MyoScore promises an honest muscle score. PrettyType promises an honest read of how you present. If a feature does not sharpen that promise, it has to clear a much higher bar, because adding off-promise features is how focused apps slowly turn into bloated ones.

Most of the best decisions we have made were decisions not to build. The roadmap is as much a list of refusals as a list of plans. Saying no to a good idea so a great one has room is the whole job.

We protect time for the non-obvious

If you only ever build what users ask for, you will make an incrementally better version of what already exists, and you will never make the leap that users could not have imagined. Henry Ford's faster horse is a cliché because it is true.

So we deliberately reserve a slice of our effort for bets that come from our own conviction rather than from explicit demand. The honest scoring approach in MyoScore came from this kind of bet, not from a feature request. Those swings are riskier, and they are also the only way a small studio builds something genuinely new instead of merely competent.

The decision is never finished

The last thing I will say is that what to build next is not a question you answer once a quarter in a planning ritual. It is a question you hold continuously, sharpened by every conversation, every drop-off in the funnel, every moment you catch yourself frustrated with your own product. The studios that win are not the ones with the best framework. They are the ones paying the closest attention.