This is a synthesis article. It draws on ideas from Shreyas Doshi, Marty Cagan, Nate Stewart, Tony Fadell, Florin Branici, and Arpit Rai — linked in full at the end — and weaves their frameworks into a single argument about product judgment. It is not a summary of any one source; it is an attempt to answer one question from several angles.
Most product teams ask the wrong question first.
They hear a customer describe a pain point, see a competitor ship something similar, or get pressure to close a deal — and the conversation quickly becomes: Can we build this?
The better question comes earlier and is harder to answer: Should this exist in our product at all?
As Florin Branici puts it, the real gate isn't technical feasibility. It's judgment. And judgment is fragile. Every yes carries a cost — maintenance, cognitive load, a product that becomes harder to explain and harder to evolve. Steve Jobs captured it simply: deciding what not to do is as important as deciding what to do.
Knowing when something is worth building means passing through several filters: problem, priority, payment, clarity, and strategy. Skip any one of them and you risk building something real that nobody cares enough to use.
Start with pain, not solutions
The instinct to build starts with a proposed solution — a feature request, a client ask, a roadmap item someone handed down. Resist that urge. Slow the conversation down.
Florin Branici recommends returning to a single question: What problem are we actually trying to solve? Always challenge a feature request by understanding what issue would truly be solved — not what was asked for on the surface.
Tony Fadell takes a similar start-from-pain approach. He looks for existing pains — often rooted in outdated technology — and then searches for new technology that can revolutionize the solution, not merely improve it incrementally. The Nest thermostat is his go-to example: the pain was high energy bills and thermostats that were painful to program; the enabling technology was AI-driven learning that made the product fundamentally better.
Pain first. Technology second. Solutions last.
Solve THE problem, not A problem
Here's where many B2B products go wrong. Teams talk to customers. Customers describe a problem. The team builds a solution. And when it ships, customers don't prioritize using it — because that problem was never a priority for them in the first place.
Shreyas Doshi makes this distinction sharply: solve the problem of the customer, not a problem. The fix isn't to stop talking to customers. It's to rank their problems and understand what matters to their business first.
That ranking matters because talking about a problem distorts how important it feels. As Shreyas explains in his Customer Problems Stack Rank framework, when someone describes a problem, you focus on it — and that brings disproportionate emphasis to its importance. Something that sounds like a huge fire in conversation might be a minor inconvenience compared to everything else they're trying to solve. CPSR asks customers to rank the problem against all the other problems they're already working on.
Pair that with open-ended discovery: What frustrates them? What annoys them? What are their motivations and incentives? What will make their buying or using decision easier — or harder? For B2B especially, understand at which stage of the company your product becomes a must-buy, not a nice-to-have.
Validate before you build
Arpit Rai offers a practical question set for feature validation:
- What is the use case? — Understand the problem and empathize with it.
- How often do you face the problem? — Discover whether the feature would see real usage.
- When did you last face the problem? — Ground frequency in recency, not hypotheticals.
- How much time and money does the problem cost your business? — Understand the impact your feature could have.
- How do you solve the problem now? What issues do you have with your current solution? — If no solution exists, the problem might not be real. If the current solution works well enough, the problem might not be worth solving.
These questions complement Shreyas's stack-ranking: one tells you where a problem sits in the customer's world; the other tells you how badly it hurts and whether anyone has already found a workaround.
But validation has to go one step further. Marty Cagan observes that teams spend a lot of time confirming that a problem exists — and far too little time validating whether people will pay to solve it. An acknowledged pain point isn't the same as a budget line item or a prioritized initiative.
And discovery can't be outsourced. When executives or customers tell the product team what to build, you don't have a product team — you have a feature factory delivering on someone else's orders. Worth-building ideas should emerge from product discovery owned by the team doing the building.
The one-sentence test
Shreyas runs an exercise that cuts through vague value propositions. Simulate a conversation between a happy customer and a friend. The friend has a problem your product solves and describes it. Your customer should naturally say: Oh, you should try this product — it will certainly help you.
The friend replies: What does it do?
What is the one sentence your customer would use — short, compelling, true? Once you have that sentence, work backwards. Build the product that makes the sentence true.
If you can't articulate that sentence, or if building toward it would require scope you can't execute well, that's a signal — not to polish the pitch, but to question whether you're building the right thing.
Filter through strategy, capacity, and focus
Even a validated, high-priority problem isn't automatically worth building for you.
Nate Stewart, CPO of Cockroach Labs, argues that from the very beginning you need a way to say no — to filter requests and potential use cases. Know where you want to go, and decline what doesn't fit.
Don't build to close a client. One-off commitments make you less agile. Only commit when what the client is asking is already on your roadmap — or when the prospect will become not just a customer, but someone who will immensely benefit from the product.
Don't commit beyond your capacity. Promising what you can't execute well poisons trust and diverts resources from what actually matters.
Invest in core differentiators. Build what sets you apart from competitors — not what makes your roadmap look busy.
Branici adds another filter: if the strongest justification for a feature is that someone asked for it or a competitor has it, you've outsourced the judgment part. When your mission is explicit, a surprising number of requests filter themselves out.
The bar for worth building
Before something earns a place on your roadmap, run it through a few honest checks.
Is the pain real — recurring, costly, and something people are already trying to work around? Where does it rank against everything else the customer is trying to solve? Will they pay for this, or only acknowledge it hurts? Can a happy customer describe the value in one compelling sentence? Did your team discover and validate this, or were you handed a build list? Does it fit where you're going, or dilute your focus? Can you execute it well without sacrificing what already matters? And does it strengthen what sets you apart?
A no at any of these gates is useful. It saves you from building something customers mention but never prioritize, something they'd use but not pay for, or something you can ship but can't maintain.
Something is worth building when it clears all of them: a real, ranked priority for the customer — not just a problem that sounded urgent in a conversation. Pain that is frequent and costly enough that people will pay to make it go away. A value proposition you can describe in one sentence a happy customer would actually say. And a fit with your mission, your capacity, and your differentiation — not your competitor's roadmap or a single deal on the table.
Everything else is a feature request waiting for a filter.
The best product teams aren't distinguished by how much they ship. They're distinguished by how rigorously they decide what deserves to exist at all.
Sources
Shreyas Doshi — Minimum Lovable Product (PrimeVP): https://www.primevp.in/content/podcast/shreyas-doshi-minimum-lovable-product-why-strategy-misunderstood-word-benefits-being-clueless
Shreyas Doshi — Customer Problems Stack Rank (OpinionX): https://www.opinionx.co/blog/shreyas-doshi-cpsr
Marty Cagan — Getting in front of the customer (Dovetail): https://dovetail.com/outlier/getting-in-front-of-the-customer-with-marty-cagan/
Nate Stewart — How product strategy fails (First Round Review): https://review.firstround.com/how-product-strategy-fails-in-the-real-world-what-to-avoid-when-building-highly-technical-products/
Tony Fadell — Lenny's Newsletter: https://www.lennysnewsletter.com/p/father-of-the-ipod-and-iphone-on
Florin Branici — Deciding what not to build: https://branici.ro/2026/02/01/deciding-what-not-to-build/
Arpit Rai — Validating new features with customers (Medium): https://arpitrai.medium.com/validating-new-features-with-customers-before-you-build-them-5902557e6c4d
