2026-07-20
2 min readHow I decide if a product idea is worth building
On this page
Most write-ups on product strategy start after the decision to build has already been made — how to run a sprint, how to prioritize a backlog. The more consequential decision happens earlier: whether the idea deserves engineering time at all. That's the part I spend the most time on before opening an editor.
The loop, applied before any code exists
The process I use for every venture on this site — Languence, the ICPK's editorial systems, Smart AI Library — starts with the same loop: analyze, architect, validate, build. Applied to a new idea specifically, "analyze" and "validate" do almost all the killing. By the time architecture and build start, the idea has already survived the questions that would have made it a waste of engineering time.
Validate the model, not the mockup
A clickable prototype tells you if people like the idea of a product. It tells you almost nothing about whether the business model behind it holds up. Those are different questions, and conflating them is how teams spend six months building something nobody was ever going to pay for.
The questions that actually filter ideas
In rough order:
- Who is this painful enough for that they'd pay before it's polished? Not "who would use this if it were free."
- What are they using instead right now? Every real problem already has a workaround, even a bad one. If there's no current workaround, there's usually no real problem yet either.
- What does this cost to keep running, not just to launch? An AI feature or a content platform that's expensive to operate needs a business model that accounts for that from day one, not a growth plan that assumes costs will "figure themselves out."
- What breaks first if this succeeds? The failure mode of success — support load, infrastructure cost, content moderation — is usually more informative than the failure mode of failure.
Why this is a strategist's job, not a separate research phase
Strategy and engineering aren't sequential here
I don't hand a validated idea off to "the engineering team" — I am the engineering team, so the validation has to be honest about what's actually buildable, not just what sounds good in a pitch. That constraint makes for a shorter, more useful validation phase than most.
Being both the product strategist and the one who builds the thing removes a failure mode that shows up constantly on split teams: strategy validating an idea that engineering later discovers is unbuildable at the cost the business model assumed. When the same person carries both, the idea either survives contact with reality early, or it doesn't survive at all — which is exactly the point.
Questions readers ask
What's the first question you ask about a new idea?+
Who is this painful enough for that they'd pay before it's polished? Not 'who would use this if it were free' — that list is almost everyone and tells you nothing. The paying-before-polished list is short and honest.
How long does validation take before you start building?+
It varies, but I treat it as a phase with an end date, not an open-ended process. Long enough to pressure-test the business model and talk to real potential users, short enough that it doesn't become a way to avoid the harder work of actually building.
What kills an idea outright, in your process?+
No plausible answer to who pays, and why now instead of with whatever they use today. Interesting technology or a personally compelling problem isn't enough on its own — I've killed ideas I found genuinely fascinating because neither of those had a real answer.