Finding Your Product & Market · Field Guide
The most expensive software
is the kind nobody wanted.
Before you build anything, the question that decides everything: what to build, and for whom. A guide to falling in love with a problem instead of your idea — discovering what customers actually need, choosing a market you can reach, and validating demand before you write the code, not after.
Introduction & how to use this guide
Purpose & audience
The delivery guide teaches you to build software well. This one asks the harder question it can't: should you build this software at all?
Most of the library is about executing well — building, pricing, selling, running. This guide is about aiming well, because the finest execution on the wrong idea produces something excellent that nobody buys. It covers how to find a problem worth solving, how to discover what customers actually need rather than what you imagine they need, how to choose a market you can reach and that will pay, and how to validate that demand is real before you commit months to building. It is the difference between building a product and building the right product.
It is written both for the developer with an itch to build their own product and for the services firm choosing which kind of work to specialize in — because “what should I build, for whom?” is the same question in both. Everything here is generic and reusable, and it applies whether the answer is a SaaS product, a niche tool, or a focused consulting practice.
The core principle
The pricing guide argues you should price on value. This one names where value comes from: value lives in a problem someone will pay to have solved — so fall in love with the problem, never with your solution.
The natural instinct is backwards: we start with a solution we find clever, then go looking for people who might want it. That path leads, again and again, to beautifully built software with no customers — because the solution was never anchored to a problem anyone urgently had. The reliable path runs the other way: start from a real, painful, common problem, understand it deeply, and let the solution be whatever genuinely relieves it. Ideas are cheap and usually wrong; problems, understood properly, are where durable products come from. Your job at this stage is not to invent — it is to discover.
Two failure modes dominate. The first is building in a vacuum — disappearing to build the thing you're sure people want, and emerging months later to discover they don't. The second is never deciding — researching and second-guessing forever, mistaking endless analysis for the courage to commit. The path between them is to learn cheaply and fast until you have enough evidence to build with conviction — and then to build.
Where this sits in the library
This guide sits at the front of the arc, right after Setting Up Shop and before Build it. It decides what to build; the Delivery Guide then handles how. Its discovery work feeds directly into the requirements the Delivery Guide turns into a specification, and its market and positioning work feed into the pricing and selling of Winning the Work. Do this first, and everything downstream is aimed at something real.
You do not need certainty to proceed — certainty at this stage is an illusion. You need enough evidence: enough understanding of a real problem, enough signal that people will pay, that building becomes a calculated bet rather than a hopeful leap. This guide is about gathering that evidence cheaply, before the expensive commitment of building begins.
Start with a problem, not an idea
Everyone has ideas. Ideas are the cheap part, and usually the wrong part. What's scarce — and valuable — is a clearly understood problem that someone will pay to make go away.
Problem-first, not solution-first
The commonest way software businesses fail before they begin is solution-first thinking: falling for a clever thing you could build, and reasoning forward to who might want it. It feels productive — you're already imagining features — but it inverts the logic of value. A solution is only worth anything to the extent it relieves a problem someone actually has, so a solution invented before the problem is understood is a bet that a matching problem exists, placed blind. Problem-first thinking reverses this: find and understand a real problem first, then let the solution follow from it. The solution designed backward from a genuine problem is far more likely to be something people want, because it was built to fit a need that was already there.
Problems worth solving
Not every problem is worth building a business on. The ones that are share a few traits, and learning to recognize them is most of the skill.
A problem worth solving is real (people genuinely have it, not just in theory), painful (it hurts enough that they want it gone, not merely a mild annoyance), common (enough people share it to make a market), and underserved (existing solutions are absent, bad, or expensive). The best opportunities usually sit where a painful, common problem meets weak existing solutions — a “painkiller,” something people actively seek relief from, rather than a “vitamin,” a nice-to-have they can easily live without. When you find yourself hearing the same painful complaint from many different people, pay attention: that repetition is the sound of a problem worth solving.
Customer discovery
You cannot learn what people need by imagining it at your desk. You learn it by talking to them — carefully, and in a way designed to hear the truth rather than the answer you want.
Talk to people first
Customer discovery is the disciplined practice of talking to the people who have the problem, before and instead of assuming you understand it. It is the single highest-return activity at this stage, and the one most builders skip because it feels slower and less certain than building. But an afternoon of honest conversations with people who have the problem teaches you more than a month of building based on your own assumptions — and it teaches it before you've spent anything. The goal is not to pitch your idea; it is to understand their reality: what they struggle with, what they've tried, what it costs them, and what they'd genuinely change money hands for.
What to actually ask
How you talk to people determines whether you learn anything true. The trap is asking questions that invite polite, useless answers — “would you use a tool that did X?” nearly always gets a friendly “sure,” which tells you nothing. The reliable approach is to ask about their past and present, not their hypothetical future: what they actually do today, what actually went wrong last time, what they've actually spent money or effort trying to fix. Concrete history is honest; imagined futures are flattering and false. Ask what problem they're solving, how they solve it now, what's painful about that, and what they've tried — and then, crucially, listen far more than you talk.
Fighting your own bias
The greatest danger in discovery is that you go looking for confirmation and, being human, you find it. It is painfully easy to lead people toward the answer you want, hear encouragement that isn't really there, and come away falsely reassured.
The purpose of discovery is to find out whether you're wrong while it's still cheap to be wrong — so treat disconfirming evidence as the valuable find, not the threat. Don't pitch and fish for approval; ask neutral questions and welcome the answers that deflate your idea, because hearing “actually, that's not really a problem for me” now saves you months of building the wrong thing. The builder who goes into discovery hoping to be validated learns nothing; the one who goes in genuinely trying to disprove their own idea learns everything they need. Enthusiasm is not evidence — behavior is.
Choosing a market
A problem is not a market until you can name the people who have it, reach them, and confirm they'll pay. Choosing that group — deliberately and narrowly — is one of the highest-leverage decisions you'll make.
Narrow beats broad
The instinct is to aim wide — “anyone could use this” feels like a bigger opportunity. In practice, for a small business, the opposite is true: a narrow, well-defined market is far easier to serve than a broad, vague one. When you focus on a specific kind of customer, you can understand their problem deeply, build something that fits them precisely, speak to them in their own language, and reach them without a fortune in marketing. “Software for everyone” is software aimed at no one — generic, hard to market, and competing with giants. A tool built for a specific, well-understood niche can dominate that niche precisely because a big competitor finds it too small to bother with. Narrow is not a limitation; for a small vendor it is an advantage.
Reachable & willing to pay
Two questions turn a group of people with a problem into an actual market. First, can you reach them? — is there a realistic, affordable way to get your product in front of these specific people, or are they scattered and impossible to target? A great product for an unreachable audience is a business that can't acquire customers. Second, will they pay? — is this a group with both the willingness and the means to pay for a solution, or one that expects everything free? Some painful problems belong to people who simply won't or can't pay to solve them, and building for them, however noble, isn't a business. The best markets are specific, reachable, and clearly willing to pay — and confirming all three is part of the validation the next section covers.
Validating demand
The point of validation is to find out whether people will actually pay — before you build, when being wrong is cheap, rather than after, when it's devastating.
The riskiest assumption
Every product idea rests on a stack of assumptions, and they are not equally dangerous. The skill of validation is finding the riskiest assumption — the one that, if false, sinks the whole thing — and testing that one first, as cheaply as possible. Usually it is not “can I build this?” (you probably can) but “will anyone actually pay for it?” Spending months building because the technical challenge is interesting, while leaving the will-anyone-pay question untested, is building the answer to the wrong question. Identify the assumption whose failure would be fatal, and design the cheapest possible test of it before committing real resources. Test the thing most likely to kill you, first.
Signals of real demand
Not all encouragement is evidence. The signals that actually predict demand are the ones that cost the customer something — because talk is free and commitment is not.
A stranger saying “great idea, I'd definitely use that” is worth almost nothing; people are kind, and imagining is easy. What's worth a great deal is commitment — someone offering to pay, putting down a deposit, signing up to a waitlist, giving you real time, or introducing you to others with the problem. The reliable rule: weigh what people do far above what they say. Every signal that costs the customer something — money, effort, reputation — is worth more than a hundred free compliments. When you're unsure whether demand is real, look for what people are willing to give up to get the solution; that, and only that, is the truth.
Pre-selling
The strongest possible validation is the one that also earns money: pre-selling — getting people to commit to buy, or actually pay, before the product fully exists. If people will pay for something not yet built, on the strength of the problem it solves, you have the clearest evidence demand is real that exists, and you've begun funding the build. This can take many forms — a paid pilot, an early-access commitment, a deposit, a founding-customer deal — but the essence is the same: converting stated interest into real commitment before you've sunk the cost of building. Not every product can be pre-sold, but where it's possible, it turns the riskiest question — will anyone pay? — into a settled fact before the expensive work begins.
Scoping the MVP
Once you're building, the discipline shifts from “what could this be?” to “what is the smallest thing that tests whether this works?” That restraint is harder, and more valuable, than it sounds.
What “minimum viable” means
A minimum viable product is the smallest version of your product that delivers the core value and lets you learn from real users — not a cut-down, half-broken version of the grand vision, but a deliberately focused thing that does the one essential job well. The word that gets forgotten is viable: it must actually solve the core problem for someone, not merely be small. The purpose of an MVP is to get something real into people's hands quickly, so you learn what they actually do with it — which teaches you more, faster, than any amount of planning the full product. You are not trying to build the whole thing small; you are trying to build the core thing first, and let reality guide the rest.
The discipline of less
Scoping an MVP well is an exercise in ruthless subtraction, and it runs against every instinct. Each feature you can imagine feels important; the vision wants all of them; and it is genuinely hard to ship something that does less than you know it could.
The cost of a bloated MVP is not just wasted effort — it's delay in learning whether you're right at all. Every extra feature pushes back the day you get real product into real hands, and it may be a feature nobody wanted, built before you knew whether anybody wanted the core. The discipline is to identify the single essential thing your product must do to relieve the problem, build that, and resist everything else until real users tell you what actually matters. It is far better to ship a small thing that works and learn, than to spend months polishing features around a core value you haven't yet confirmed anyone wants. Less, shipped and learned from, beats more, built on a guess.
Positioning & the wedge
Even a good product for a real market has to answer one more question in the customer's mind: why this, and why you? Positioning is the answer, and a narrow wedge is how a small vendor makes it convincing.
Why you, why this
Positioning is how your product occupies a clear, distinct place in the customer's mind — the crisp answer to “what is this, who is it for, and why choose it over the alternatives?” A product that can't answer this clearly is a product the customer struggles to understand and therefore doesn't buy, however good it is. For a small vendor, the winning position is rarely “better than the big competitor at everything” — that's a fight you'll lose. It's usually “the best for this specific customer with this specific need” — a narrower claim you can actually make true and defend. The market and problem focus from the earlier sections is what makes sharp positioning possible; a product built for a specific customer can say exactly why it's right for them. The Winning the Work guide develops positioning further for the selling stage.
The beachhead
A small vendor cannot take a whole market at once, and trying to spreads them too thin to win anywhere. The wiser strategy is a beachhead — a narrow initial segment you can genuinely dominate, chosen not because it's the whole opportunity but because it's the one you can win first. Establishing yourself completely in a small, specific niche — becoming the obvious choice for that particular kind of customer — gives you a base of happy customers, revenue, and credibility from which to expand, rather than a thin, losing presence everywhere. Start where you can win decisively, then widen from strength. Many large software businesses began as the clear leader of a niche so small their eventual competitors ignored it — which was exactly why they were allowed to take it.
Deciding to build — or not
All of this discovery exists to serve one moment: an honest decision to commit, or to walk away. The courage to make that call — either way — is the point.
Kill criteria
The hardest and most valuable discipline in this whole guide is the willingness to not build — to look honestly at what discovery has told you and, if the evidence isn't there, walk away. This is far harder than it sounds, because by now you've invested time and pride, and abandoning the idea feels like failure. It isn't; it's a cheap, smart failure that saved you an expensive one. A useful practice is to set kill criteria in advance — the specific evidence that, if you don't find it, means you stop. Deciding beforehand what would make you abandon the idea protects you from the very human tendency to rationalize a “yes” you've already emotionally committed to. The goal of discovery was never to justify building; it was to find out whether you should — and a well-earned “no” is a success.
Build, buy, or partner
Even when a problem is real and worth solving, building your own product from scratch is not always the right way to capture it. Sometimes the smarter path is to build on, resell, or partner with something that already exists — extending an existing platform, integrating rather than reinventing, or partnering with someone who has a piece you lack. Building everything yourself is the most expensive and slowest route, and it is worth asking, before committing to it, whether the value you'd add sits better on top of existing tools than in a wholly new one. The question isn't only “is this problem worth solving?” but “is building a new product from scratch the best way for me to solve it?” — and the honest answer is sometimes to build less and combine more.
Templates & checklists
The guide compressed into instruments: a way to run a discovery conversation that tells you the truth, a scorecard for weighing an opportunity honestly, and the vocabulary of finding what to build.
The discovery interview guide
- Don't pitch. You're here to learn, not to sell. Keep your idea out of it as long as you can.
- Ask about the present. “How do you handle this today?” — concrete current behavior, not hypotheticals.
- Ask about the past. “Tell me about the last time this was a problem.” — real stories, not imagined futures.
- Probe the pain. “What does this cost you — time, money, frustration?” — is it a painkiller or a vitamin?
- Ask what they've tried. Effort or money already spent trying to solve it is strong evidence of real pain.
- Listen for repetition. The same complaint across many people is the signal that matters.
- Welcome the “no.” Disconfirming answers are the valuable ones. Don't argue people back to yes.
The opportunity scorecard
- Real problem — do people genuinely have it, confirmed by talking to them?
- Painful — is it a painkiller they seek out, not a vitamin they can skip?
- Common — do enough people share it to make a market?
- Underserved — are existing solutions absent, bad, or overpriced?
- Reachable — can you realistically and affordably get in front of these customers?
- Willing to pay — do they have the means and the will, shown by real commitment?
- Winnable — is there a narrow beachhead you can genuinely dominate first?
- Right for you — is building a new product the best way for you specifically to capture it?
Glossary
| Term | Meaning |
|---|---|
| Problem-first | Starting from a real problem and letting the solution follow, rather than the reverse. |
| Painkiller vs. vitamin | A problem people actively seek to relieve, versus a nice-to-have they can live without. |
| Customer discovery | Talking to people who have the problem to understand it before building. |
| Confirmation bias | The tendency to hear the encouragement you want; the enemy of honest discovery. |
| Niche / narrow market | A specific, well-defined group of customers — easier for a small vendor to serve and win. |
| Riskiest assumption | The belief that, if false, sinks the whole idea; the first thing to test. |
| Validation | Gathering evidence that people will actually pay, before building. |
| Pre-selling | Securing commitment or payment before the product fully exists — the strongest validation. |
| MVP | Minimum viable product — the smallest version that delivers the core value and lets you learn. |
| Positioning | The clear, distinct place your product holds in the customer's mind. |
| Beachhead | A narrow initial segment you can dominate first, then expand from. |
| Kill criteria | Evidence decided in advance that, if absent, means you stop. |
This guide aims the whole library. Its discovery feeds the requirements the Custom Software Delivery Guide turns into a specification; its market and positioning work feed the pricing and selling of Winning the Work; and the demand it validates is what From Project to Product later turns into recurring revenue. Build the right thing, for the right people, confirmed before you commit — and every guide that follows is working on something real.