How I decide if a product is even worth building

Not every idea deserves a roadmap. Before I help build, I run a filter that protects founders from expensive curiosity. Interesting is not the same as urgent, and urgency is what pays invoices. I have watched talented teams spend a year polishing a product nobody needed this month. The work was admirable. The market was busy elsewhere.

This filter is how I decide whether a product-or a major bet inside a product-is worth building with nau. It is related to why great products fail before product-market fit and to feature-level restraint in the hidden cost of unused features. Use it before you hire, before you raise, and before you open Figma-why I start without Figma.

Why founders greenlight the wrong things

Ideas feel cheap. Building feels like progress. Competitors announce adjacent features. Investors ask about TAM. A cousin says they would use it. None of those are demand. Demand is a customer who already feels the cost of not having the thing-and will pay to remove that cost on a timeline that matches your runway.

Y Combinator’s library is blunt about talking to users and building what they need now-Y Combinator Library. First Round’s archives show how focus compounds when founders refuse polite maybes-First Round Review. Harvard Business Review’s strategy-as-choice framing still helps boards accept “no”-HBR.

My build filter

1. Is the pain frequent and urgent-or merely interesting?
2. Will a defined segment pay to remove it?
3. Is there a believable reason you win versus alternatives?
4. Can we deliver a meaningful first outcome quickly?
5. Do we know what evidence would kill the idea early?

1. Frequency and urgency

Ask how often the pain hits and what they do today when it does. Daily spreadsheet pain beats annual mild inconvenience. If buyers can delay forever without consequence, your sales cycle will inherit that delay. Jobs-to-be-done language helps-see the Interaction Design Foundation for accessible JTBD primers-but you do not need jargon. You need a calendar: when does this hurt, and what breaks if they wait?

2. Willingness to pay in a defined segment

“Everyone could use this” is a red flag. Name the segment narrowly enough to find them. Listen for existing spend: agencies, tools, overtime, error costs. If nobody pays for a workaround today, you may be creating a category and a charity simultaneously. Category creation is possible; it is not a default early-stage plan. Clarity about who pays connects to clarity vs marketing problems.

3. A believable reason you win

Alternatives include incumbents, spreadsheets, agencies, and doing nothing. Your wedge must be explainable in one breath: workflow fit, speed, distribution, data, regulation, audience trust. “We will be more AI” is not a wedge. Stripe’s early API delight, Linear’s speed, Figma’s multiplayer clarity-each was a reason to switch that customers could feel quickly.

4. Meaningful first outcome, quickly

If value requires six integrations, a data science team, and a quarter of configuration, activation will punish you. Can a motivated user in the ICP reach a real outcome fast? If not, you may still build-but budget for concierge onboarding or a thinner first product. Time-to-value is part of worthiness, not a later UX polish item. Performance and accessibility shape that outcome too (web.dev vitals, WCAG).

5. Kill criteria

What evidence would make you stop? No paid pilots after N conversations. No retention after first-month cohorts. Switching costs higher than reported. Write the kill criteria before optimism edits them. Teams that refuse to pre-commit to stopping criteria tend to “learn” indefinitely on the same dead horse.

A product worth building has a customer who already feels the cost of not having it.

Applying the filter: two fictional ideas

Idea a: shelfsync for indie retailers

Pain: stockouts and over-orders weekly; owners live in three spreadsheets. Segment: UK indie retailers with 2-5 shops, already paying for a basic POS. Wedge: syncs to their specific POS in under a day with reorder suggestions in plain language. First outcome: one accurate reorder list in the first session. Kill criteria: fewer than three paid pilots after twenty qualified demos in sixty days. Verdict: worth a thin build.

Idea b: “AI mentor for everyone”

Pain: vague desire for self-improvement. Segment: undefined. Wedge: “friendlier GPT.” First outcome: chat that feels nice. Kill criteria: none. Verdict: interesting podcast topic, not a product plan. Curiosity can continue as content experiments without a multi-year platform bet.

Airbnb’s early wedge-better than a hotel for a specific trip context, with trust mechanisms-was urgent for hosts and guests in a way “community platform” never was. Learn from the wedge, not the later empire. Related teardown energy: Airbnb homepage.

What the filter is not

• Not a substitute for taste or craft once you greenlight.
• Not a claim that only small ideas win-sequencing still allows ambition.
• Not an excuse to ignore distribution forever-only to delay it until the path works (dig deeper than marketing).
• Not anti-innovation-anti-unexamined inventory on the roadmap.

Nielsen Norman Group’s emphasis on observing real behaviour over hypothetical enthusiasm is useful when you validate urgency-NN/g. Baymard’s evidence-led culture is another external nudge against building from opinions alone-Baymard. Google’s people-first guidance rewards products and pages that help a real audience-Google Search Central.

Evidence quality: what counts and what flatters

Not all validation is equal. A LinkedIn poll is entertainment. A waitlist without payment intent is a soft maybe. Stronger evidence looks like: paid pilots, deposit pre-orders, repeated unpaid workarounds with named costs, and users who recruit colleagues without prompting. Weak evidence looks like: “I would use that,” advisor enthusiasm, and competitor feature checklists treated as demand.

When evidence conflicts, prefer behaviour over compliments. Watch what people already do on Fridays when the pain hits. That observation habit is classic UX research discipline-NN/g and the Interaction Design Foundation both teach versions of it. I borrow the humility without borrowing the bureaucracy.

Runway math belongs in the filter

A product can pass qualitatively and still be unwise on your timeline. If first value requires six months of platform work and you have four months of runway, the idea is not “validated”-it is mismatched to constraints. Either thin the outcome, fund the gap, or choose a different wedge. Strategy includes arithmetic. Ignoring runway while celebrating interview quotes is how thoughtful people still ship themselves into a corner. Related: what founders get wrong about PMF.

Similarly, if distribution to the ICP is structurally blocked-no affordable channel, no partners, no SEO path, no sales motion you can execute-revisit worthiness. Building a beloved product nobody can discover is a museum with a Slack channel. Sequence discovery constraints into the filter, not as a post-launch surprise.

Team dynamics that break the filter

Filters fail socially before they fail logically. A co-founder falls in love with the demo. An investor attaches identity to the category story. An engineer has already built half the platform “because we would need it anyway.” In those rooms, the filter must be a shared artefact-answers written, kill criteria dated-not a vibe check in a hallway. If someone wants to override a red signal, make the override explicit and temporary, with a review date. Silent overrides are how dead products stay “strategic priorities.”

I also separate build decisions from identity. Killing an idea is not killing the company’s ambition. It is protecting ambition for a job the market will fund. Teams that equate stopping with failure keep burning runway to avoid an awkward conversation. Awkward is cheaper. For sequencing once something does pass, if I joined tomorrow and thirty-day changes describe how I operationalise the green light without instantly returning to fog.

Thin builds versus platform fantasies

Even after a green light, the first ship should be embarrassingly focused. Platform fantasies-“we will need multi-tenant everything eventually”-are how first outcomes slip into next year. Build the spine that delivers the job; leave the cathedral for later. Linear and early Stripe energy beats enterprise architecture cosplay. If engineers worry about rework, budget intentional rework as the price of learning-cheaper than building the final form of the wrong product.

Marketing for a thin build should also stay thin: one offer, one proof set, one CTA path. Do not announce a platform while shipping a wedge. The mismatch trains distrust. Why beautiful websites don’t always convert applies equally to launch pages that over-promise scope the product cannot yet keep.

If the thin build still cannot find urgency after honest exposure to the ICP, honour the kill criteria. Parking an idea is a strategic act. It frees attention for a job that already hurts. Curiosity can continue in notebooks; runway should not.

From filter to first build

If the filter passes, I still do not leap to a kitchen-sink MVP. I define the smallest experience that delivers the first outcome, align the public story to that outcome, and instrument learning metrics. That is the spirit of strategy before screens and from strategy to launch. If the filter fails, I recommend a cheaper probe: concierge service, waitlist with interviews, manual workflow-learning without permanent UI tax.

Try this: a 90-minute build filter workshop

1. Write the idea in one sentence without buzzwords.
2. Answer the five filter questions with evidence (quotes, spend, metrics)-blank answers count as fails.
3. List real alternatives, including doing nothing.
4. Design the thinnest first outcome experience on paper.
5. Write kill criteria and a review date. Put both in the project brief.
6. Decide: build thin, probe manually, or park the idea without guilt.

For day-one company diagnosis after you have something shipping, use if I joined tomorrow. For spend discipline once you have a path, use five questions before £10k marketing.

What to do before your next build decision

• Run the five questions in writing with evidence attached.
• Name alternatives honestly, including status quo.
• Define first outcome and kill criteria before sprint planning.
• Choose thin build, manual probe, or park-no vague “exploratory roadmap.”
• Revisit the filter on a dated cadence after any greenlight.

If we cannot name the cost of not having it, we are not ready to ship. We are ready to keep talking-and talking is cheaper than building the wrong thing. Use the filter. Protect the runway. Build when the customer’s pain is already doing half the selling.