Most product waste starts with one sentence: "Users will probably want…"
"Probably" isn't a requirement. It's a guess with a deadline attached.
You've heard a version of this in almost every kickoff. Sometimes it's dressed up as a persona. Sometimes it arrives as a competitor screenshot. Sometimes a founder thinks out loud, and the room treats it as a decision.
The feature goes on the board. A designer makes screens. An engineer estimates a week, then spends three. Launch day comes, and the thing sits there, half-used, because nobody can point to a person who actually asked for it.
The expensive part isn't the code. It's the attention. A small team only has so many weeks in a quarter, and every "probably" spends one of them.
Three questions before anything hits the board
Before a feature goes on our board, we ask three questions:
- Who asked for this, in their own words?
- What are they doing today instead?
- What's the smallest version that would tell us we're right?
If we can't answer the first two, the feature waits. It's not a rule we always enjoy, but it's the cheapest one we know.
The first question kills a surprising amount of work. "Users" is not a who. "The market" is not a who. "I would want this if I were them" is not a who. We want a sentence a real person said, even if it was messy: "I keep pasting this into a spreadsheet every Friday." That is a requirement. "They'll probably want a dashboard" is not.
The second question is about the workaround. People already have a way to get the job done — a spreadsheet, a WhatsApp group, a messy export, a teammate who just remembers. If you can't describe that workaround, you don't understand the job yet. The first version of the product should usually replace one workaround, not invent a new ritual.
The third question is how we keep the first version small. The goal is not "the complete feature." The goal is a version that would embarrass us if we were wrong, quickly and cheaply. A manual email instead of an automation. A single template instead of a builder. A concierge version you run yourself for five customers. If that sounds unimpressive, good. Impressive is often late.
What a one-sentence spec actually looks like
We like a one-sentence spec before anything more elaborate:
For [who], when [situation], they can [action], so that [outcome]. We will know this is working when [observable signal].
Not a novel. Not a twelve-page PRD. One sentence you can argue with.
"For freelance accountants, when a client sends a messy folder of receipts, they can upload the folder and get a categorized list, so that they stop spending Sunday night in a spreadsheet. We'll know it's working when a real accountant uses it for a real client week without exporting to Excel."
That sentence is specific enough to say no to things. A "smart insights" tab doesn't fit. A mobile app doesn't fit yet. A team admin panel doesn't fit. You can feel the edges.
Compare that to: "An AI-powered receipt platform for modern finance teams." That sentence can justify anything, which means it justifies nothing. It will produce a lot of product, and very little learning.
A one-sentence spec is also a filter for design. If the situation is "a messy folder of receipts," the first screen is an upload, not a marketing carousel. If the outcome is "stop spending Sunday night in a spreadsheet," the success state is a list they can trust, not a confetti animation.
Write it at the top of the ticket. If two people read it and imagine two different products, it isn't done.
"But the investor / competitor / sales team said…"
There are always reasons to skip the questions.
A competitor shipped a feature, so it feels unsafe not to have one. A sales conversation mentioned a request, so it feels like a promise. A slide in a deck already showed a screen. None of these are useless signals. None of them are a substitute for a who, a workaround, and a smallest test.
Competitor features are especially slippery. You don't see the ones they regret. You don't see the ones that ship and sit unused. You only see the screenshot. Copying a screenshot is a way to inherit someone else's guess.
Sales requests need a little translation. "Can it also do X?" often means "I'm not sure this is for me yet." Sometimes the right response is a clearer offer, not a new module. Ask what they do today, and what they would stop doing if you built it. If they can't answer, you're being asked to decorate the product, not to solve a job.
Internal requests have the same problem with better access. A teammate can be the "who," but only if they are describing their own work, in their own words, not a theory about the user.
And timelines don't excuse the questions. If you have two weeks, you need a smaller test, not a fuzzier spec. "We don't have time to talk to users" usually means "we will spend the time later, cleaning up the thing we built."
A practical way to run this in a small team
You don't need a process consultant. You need a habit at the start of the work.
When a feature is proposed, write the three answers in the ticket or the brief, in plain language. If the first answer is a role ("product managers") and not a sentence someone said, go get the sentence. A short call is enough. A support email is enough. A founder using their own product every day is enough, as long as they write it as a user, not as a visionary.
Then cut the first version until the third question is honest. If the only way to know you're right is a six-week build, you haven't found the smallest version. Ask: what could we put in front of one person next week?
Keep the answers visible. A one-sentence spec that lives in a forgotten doc will not protect you in the mid-sprint meeting where someone says "while we're in here, we should also…" The sentence has to be in the room.
We still get this wrong. The "probably" sneaks in. Everyone nods, and a week disappears. The questions are how we catch it — not always in time, but often enough that the board stays smaller than our ambition.
The same habit is useful whether you write the ticket yourself or you work with a partner. The point is not the process. The point is not building the wrong thing for a month.
Takeaways
- Treat "users will probably want…" as a guess, not a requirement.
- Don't put a feature on the board until you can answer: who asked, in their own words; what they do today instead; and the smallest version that would tell you you're right.
- Write a one-sentence spec you can argue with: who, situation, action, outcome, and an observable signal.
- Competitor screenshots, sales "can it also," and deck mockups are signals. They are not a substitute for the three questions.
- If you only have two weeks, shrink the test. Don't blur the spec.
- Put the sentence at the top of the ticket, and keep it in the room when scope starts to grow.
What's the question you ask before building anything?
We're nothink, a small team that designs and builds products for startups — more at nothink.site.
