From SaaS Idea to Product-Market Fit

The Fundamental Mistake

A software engineer has an idea for a SaaS product. It feels obviously useful. She spends three months of evenings and weekends building it: clean architecture, tests, billing, a polished landing page. She launches.

Nobody buys it.

Not because the code is bad. The code is excellent. The product works exactly as designed. It fails because of something the code cannot fix:

Engineers make this mistake for a specific reason: building is the part we are good at. When you are uncertain, you retreat to the activity where you feel competent. Writing code feels like progress. But the risky question was never "can I build this?" — for an experienced engineer the answer is almost always yes. The risky questions are: does anyone have this problem, do they care enough to pay, and can you reach them?

Four words you must keep separate

The three-month failure happens when you start at solution and never verify the other three. This guide teaches you to move in the opposite direction: market → customer → problem → evidence → and only then, solution.

What Is a Market?

A market is a group of people or companies who share a problem and spend money (or could spend money) on solving it. That's it. Not a report, not a chart — a group of real buyers.

Inside a market, three roles matter. Sometimes one person plays all three. Often they don't.

B2B vs B2C

• B2C (business-to-consumer): you sell to individuals. User and buyer are usually the same person. Prices are low, so you need many customers, which means you need cheap distribution.
• B2B (business-to-business): you sell to companies. Prices are higher, customer counts are lower, and buying decisions are more rational: "does this save us money or make us money?" For a solo technical founder, B2B SaaS is usually the more forgiving path — 100 customers paying $200/month is a real business.

Why the user/buyer split matters

In B2B, the person who loves your product often cannot pay for it. A recruiter may adore your tool, but if the agency owner doesn't see the value, no sale happens. The reverse also occurs: a manager buys software the team hates and never uses — which kills you later at renewal time.

What Is a Niche?

A niche is a narrow, specific slice of a market that you deliberately choose to serve first. Narrowing feels like giving up customers. In practice it's the opposite: it's the only way a small founder can win any customers at all.

Watch a market narrow

Each step down does three things:

• Customer discovery gets easier. "Businesses" can't be interviewed. "Shopify fashion brands with high return rates" can be listed by name, found in specific communities, and emailed this week.
• Product design gets easier. A tool for "businesses" must be generic. A tool for fashion returns can ship with the exact workflow, integrations (Shopify, the major return carriers), and vocabulary the customer already uses.
• Marketing writes itself. "Cut return losses for your fashion brand" beats "optimize your business operations" every time.

The tradeoff

• Too broad: you can't name your customers, every prospect needs different features, and you compete with everyone.
• Too narrow: there are only 40 possible customers on Earth, or they have no money, or the problem occurs once a year.
• Useful niche: hundreds-to-thousands of similar customers with a shared painful problem, money to spend, and a place where you can find them.

How to evaluate a niche

Score a candidate niche against these questions. You don't need every answer to be perfect. You do need to notice which answers you don't know.

Finding Problems

Once you have a niche, resist the urge to invent a solution. Your job now is to hunt for problems that already exist — visible in what people do, not just in what they say.

The vocabulary of pain

• Pain — something that costs real money, time, or stress. "We lose placements because paperwork is late."
• Inconvenience — mildly annoying but tolerable. "The export button is in a weird place." Inconveniences rarely support a paid product.
• Desire — something people want more of (revenue, leads, speed). Desires sell well when tied to money.
• Workflow — the sequence of steps someone follows to get a job done. Problems live inside workflows, so learn the workflow first.
• Workaround — the duct-tape solution people built because no good tool exists. Workarounds are treasure: each one marks a problem someone cared enough to hack around.
• Recurring problem — happens weekly or daily. Recurring pain supports recurring revenue.
• Expensive problem — costs measurable money (lost deals, staff hours, fines).
• Urgent problem — must be solved now, not someday. Urgency is what makes buyers actually move.

Where problems leave footprints

Don't ask "what problems do you have?" — people can't answer that well. Instead, look for these footprints:

• Spreadsheets — every hairy shared spreadsheet is a database and app someone needed but nobody built.
• Manual processes — copy-paste between systems, printed checklists, "then I email it to Carol."
• Agencies and consultants — companies paying outsiders $3,000/month for a service are announcing a budget.
• Virtual assistants and repetitive staff work — a human doing the same steps daily is a process waiting for software.
• Multiple SaaS tools stitched together — Zapier chains and duct-taped integrations mark a gap between products.
• Complaints about existing tools — 1–3 star reviews on G2/Capterra, "does anyone know an alternative to X?" threads.
• Internal tools — when several companies each build the same internal tool, a product is missing from the market.
• Repeated community discussions — the same question appearing monthly in a subreddit or Slack group.
• Feature requests — public roadmaps and forums of competitors show what customers beg for.
• Switching — people migrating between competitors are unhappy people; find out why.

Problem Quality: Ranking What You Found

Problem-hunting usually produces several candidates. They are not equal. Rank them with a simple framework — not because the numbers are truth, but because scoring forces you to confront what you don't know.

Rate each criterion Weak / Unknown / Promising / Strong. Treat "Unknown" as a to-do item, not a zero. The score is a decision aid — a way to compare candidates and expose blind spots — never a mathematical prediction of success.

Three examples

Problem vs Idea vs Product

Engineers blur these four things constantly, and the blur causes bad decisions. Keep them separate:

Why the separation matters:

• You can validate the problem without any solution in mind. (Do agencies really lose placements this way? How often? What does it cost?)
• You can test the solution hypothesis without a product. (If documents were chased automatically, would that actually prevent the losses — or is the real bottleneck the licensing boards?)
• You can be right about the problem and wrong about the solution — or right about both and wrong about the business model. Each layer is a separate assumption, and each gets its own evidence.

What Does "Validate an Idea" Actually Mean?

Validation is not a binary stamp. There is no moment when an idea becomes "validated." There is only evidence — and evidence has grades. Your job is to climb from weak evidence to strong evidence while spending as little time and money as possible.

The Evidence Ladder

// click any rung to expand it

Everything in the rest of this guide is a technique for climbing this ladder cheaply. Interviews get you to rungs 4–6. Experiments get you to 7–10. A product is only required for rungs 11–13.

Customer Interviews

Interviews are the cheapest way to move from rung 2 to rung 6. But most first-time interviews collect garbage, because of one mistake: asking people to predict their future behavior.

A reusable 25-minute interview structure

Practical notes: 5 interviews reveal the obvious patterns; 10–15 in one niche is usually enough to rank problems confidently. Take verbatim notes — the customer's exact words become your landing-page copy later. And listen for what they didn't mention: if you have to introduce the problem yourself, that's evidence against it.

Market Research for Technical Founders

Desk research runs in parallel with interviews. You're not writing a report — you're hunting for specific pieces of evidence. Here's what each source is actually for:

How to inspect a competitor

"Research competitors" is vague. Inspect these specifics and write them down:

• Customer segment — who is the site talking to? Enterprise? SMB? Which industry words do they use?
• Positioning — what is the one-line promise on the homepage?
• Pricing — plans, price points, per-seat or flat, free tier? This calibrates what the market will pay.
• Reviews & complaints — what do customers love and hate? Hates are your opportunity list.
• Missing functionality — public roadmaps, forum requests, "coming soon" pages.
• Acquisition channels — do they rank on SEO, run ads, sell outbound, live in a marketplace? Their channels hint at what works.
• Integrations — which systems they connect to reveals the tool stack of the niche.
• Switching complaints — "we left X because…" posts are the most honest competitor teardown available.

Competition

Beginner instinct: "someone already built it, so I shouldn't." That instinct is wrong often enough to be dangerous. Competition is evidence that customers pay for solutions to this problem. A market with zero competitors demands an uncomfortable question: is it undiscovered — or is there no money in it? Usually it's the second.

Worked examples

• Basecamp existed; project management looked "done." Then Trello won with boards, Asana with teams, Linear with software engineers specifically. Crowded market, repeated wins through segment + angle.
• Mailchimp dominated email; ConvertKit still built a business by serving one segment — creators — better.
• Countless "Uber for X" ideas had zero competitors. Most died: no competitors because no demand.

Distribution: Can You Reach Anyone?

Engineers systematically underestimate distribution. Here is the uncomfortable truth: if you cannot reach potential customers, you cannot validate the idea — and you certainly cannot sell the product. A brilliant product with no path to customers is a hobby.

That's why distribution appears here, before the chapters on building anything. Reachability is a validation question, not a marketing afterthought.

Founder–channel fit

Channels are not interchangeable. Each rewards different skills, and you should pick the one that fits you and your niche:

For a solo technical founder in B2B, the honest default is: outbound email + LinkedIn + one community, later reinforced by a marketplace or integration listing. Pick one primary channel and get good at it before adding another.

Validation Experiments, Cheapest First

You now have a ranked problem, a defined customer, and a channel. Time to test the solution side. The tools below are ordered by cost. At each step ask: what is my riskiest remaining assumption, and what is the cheapest experiment that could kill it? Then run that experiment — not a more expensive one.

When Should I Start Coding?

The question every engineer actually cares about. The answer is not "never build before validation" — that advice overcorrects and ignores that for you, building is cheap. The real principle:

What you ideally know before serious building

• Who has the problem — a customer you can describe in one sentence
• What the problem is — in the customer's own words, without mentioning your solution
• How they solve it now — the workaround, tool, or staff currently doing the job
• How painful it is — a cost in money or hours, from real examples
• How often it happens — frequency supports subscription revenue
• Who pays — the budget-holder, and why they'd approve it
• How you reach them — a channel you have personally tested
• Why existing solutions are insufficient — from reviews and interviews, not your guess
• Meaningful commitment — at least one person on rung 8+ (time, data, LOI, or money)

You will rarely have all nine. Treat missing ones as labeled risks you're consciously accepting — not as details to discover after launch.

Legitimate reasons to code early

• The riskiest assumption is technical feasibility ("can an LLM actually extract expiry dates from scanned licenses at 99% accuracy?"). Then a throwaway spike is validation.
• A rough working demo will unlock conversations that slides can't — common when selling to skeptical technical buyers.
• The prototype takes days, not weeks, and you commit to throwing it away if evidence says so.

MVP: The Minimum Viable Product

An MVP is not "version 1 with fewer features." It is:

Engineers overbuild MVPs in predictable ways: infrastructure for scale that hasn't arrived, settings pages nobody asked for, edge-case handling for users who don't exist, three integrations when the niche uses one, and a rewrite in a "better" framework halfway through. Every one of these delays the only thing that matters: contact with reality.

Bad MVP vs good MVP — same idea

Idea: credential expiry tracking for healthcare staffing agencies.

Two rules of thumb: your MVP should embarrass you a little (Reid Hoffman's line — if it doesn't, you shipped late), and it should be usable for the core job without you in the room by roughly week two of a customer's life. "Minimum" is not an excuse for broken — it means narrow, not shoddy: one workflow, done reliably.

First Customers

With an MVP live, the game changes from validating to selling — and the two feel different. Validation conversations ask "is this real?"; sales conversations ask "will you buy this, this month?" Many founders stall here, endlessly "validating" to avoid the discomfort of asking for money. Once you have rung-8+ evidence, start asking.

What this stage looks like in practice

• Founder-led sales. You, personally, emailing and demoing. Nobody can sell an unproven product but the founder, and every objection you hear is product research.
• Manual onboarding. Set up each customer yourself, on a call. You'll watch where they get confused — that's your real bug list.
• Watching customers use the product. Screen-share sessions beat analytics at this scale. Where do they hesitate? What do they ignore?
• Support as research. Answer everything personally. Support tickets are interviews that customers initiate.
• Usage observation. Instrument the 3–5 events that define "the product did its job," and check them per-customer weekly, by name — not as aggregate charts.

All of this is deliberately unscalable, and that's fine. As Paul Graham argues in "Do Things That Don't Scale," early startups are hand-cranked; the recruiting of the first users is almost always manual. You're not building a machine yet — you're learning what machine to build.

Idea Validation Is NOT Product-Market Fit

This is the distinction founders most often blur, so let's make it sharp.

Between validation and PMF sit several stages, each requiring its own evidence:

Why this matters practically: pre-sales, LOIs, and waitlists live in "demand validation." They justify building. They do not justify scaling, hiring, or spending on growth — decisions that should wait for retention evidence. Skipping stages is how funded startups die with beautiful demand metrics and empty week-8 dashboards.

Measuring Product-Market Fit

PMF isn't a single number, but it leaves measurable fingerprints. Watch these:

• Activation — the share of new customers who reach the product's first moment of real value (e.g., first automated document chase sent). Low activation means the product promises value it doesn't deliver, or delivers it too slowly.
• Repeated use — do customers return at the natural frequency of the problem? A daily-pain product should see weekly-or-better use.
• Retention — the share still active after 1, 3, 6 months. The core PMF metric.
• Churn — the share who cancel each month. Early-stage B2B churn above ~5%/month is a flashing warning; low single digits or better is healthy.
• Expansion — existing customers adding seats, usage, or upgrades. Expansion means the product spreads inside accounts.
• Organic referrals — new customers who arrive saying "X told me about you," without you asking.
• Willingness to pay — price resistance dropping; customers accepting renewals and increases without drama.
• Customer pull — inbound demos, feature demands phrased as "when can we have," people chasing you.
• Sales getting easier — shorter cycles, higher close rates, less convincing.
• Complaints during downtime — when your product breaks and customers are angry within minutes, congratulations: you're load-bearing.

Cohort retention, simply

Group customers by start month (each group is a cohort). For each cohort, plot the % still active (or still paying) after month 1, 2, 3… The shape tells you everything:

The Sean Ellis question

Ask active users: «How would you feel if you could no longer use this product?» with options Very disappointed / Somewhat disappointed / Not disappointed. Sean Ellis, after studying many startups, observed that companies where ≥40% answered "very disappointed" generally went on to grow well, and those far below struggled. Rahul Vohra's team at Superhuman famously turned this into an operating system: measure the score, segment for the users who love you, and split the roadmap between doubling down on what they love and fixing what blocks the fence-sitters — moving their score from 22% to 58% in about a year.

What PMF Feels Like

Three honest caveats, because PMF is romanticized:

• It's rarely a single magical moment. More often it's a gradual shift: sales calls stop feeling like begging, churn quiets down, the inbox changes tone. You notice it in hindsight.
• PMF has strength. Weak PMF (a retention floor at 40%, lukewarm pull) and strong PMF (customers evangelizing, waitlists) are different worlds. You can operate at weak PMF while working to deepen it.
• PMF can be lost. Markets shift, competitors improve, platforms change rules. PMF is a state you maintain, not a trophy you keep.

Continue, Narrow, Pivot, or Kill

Every experiment ends in a decision. There are exactly four, and choosing consciously — on a schedule, against pre-written criteria — is what separates systematic founders from drifters.

Practical guardrails: decide in advance what result would change your mind ("if fewer than 2 of 10 interviews reveal existing spend, I stop"); timebox each stage; and beware the two failure modes — quitting after one awkward interview, and "just one more feature" for a year. Evidence, not mood, makes the call.

The Complete Validation System

Everything above compresses into one reusable pipeline. This is the mental model to keep:

At every arrow, the same loop runs: Assumption → Experiment → Evidence → Decision (continue / narrow / pivot / kill). The pipeline is linear on paper and loopy in real life — you'll revisit stages. That's normal. What must never happen is skipping from stage 8 to stage 12 on vibes.

Case Study: Dana and ShiftDocs

Dana's story has run through every level. Here it is end to end — roughly nine months, one engineer, no funding.

Note what Dana never did: she never built the scheduling tool, never bought ads, never wrote a business plan, and never spent more than three weeks building before the next contact with reality. Her only unusual skill was willingness to run the loop: assumption → experiment → evidence → decision, about fifteen times.

A Failure Story: Validation Theater

Now watch Marco, a talented full-stack developer, do every step in a way that feels like validation but isn't.

SaaS Idea Validation Scorecard

Use this every time you evaluate an idea. Click a rating for each factor; be brutally honest, and remember that Unknown is the most useful rating — it's your research to-do list. The score is a decision aid, not a prediction.

Before I Spend a Month Building This

Answer these in writing. Unanswered questions aren't blockers — they're your next experiments.

1. Can I describe the customer in one sentence? "Healthcare staffing agencies placing 50+ workers/year" — not "businesses."
2. Can I describe the problem without mentioning my solution? If the problem only exists as "they lack my product," it isn't a problem.
3. Have I seen evidence this problem exists independent of me? Complaints, reviews, job posts, communities.
4. Have I spoken to at least 10 people who experienced it recently?
5. Did they tell me specific, recent stories without prompting?
6. What do they do about it today? Name the tool, spreadsheet, staff member, or "nothing."
7. What does the current approach cost them, in money or hours?
8. How often does the problem occur? Daily/weekly supports subscriptions; yearly rarely does.
9. What happens to them if they do nothing? If the honest answer is "not much," urgency is missing.
10. Who is the user, and who is the buyer? Are they different people?
11. Who controls the budget, and roughly how big is it?
12. Why are existing solutions insufficient — in customers' words, not mine?
13. Can I list 20 potential customers by name today?
14. Which channel reaches them, and have I personally tested it?
15. Have I asked anyone for a meaningful commitment? Time, data, an LOI, a pilot, money.
16. Did anyone give one? Rung 8+ on the Evidence Ladder.
17. What price am I hypothesizing, and what existing spend anchors it?
18. Will this product deliver value repeatedly, month after month? Retention potential — or is it a one-and-done tool?
19. What is the single riskiest assumption right now?
20. What is the cheapest experiment that could prove it false?
21. Is coding actually required to run that experiment? If no: don't code yet. If yes: build the smallest thing that runs it.
22. What result would make me narrow, pivot, or kill — decided in advance?
23. What did the last experiment teach me, and what decision did I take from it?

The Software Engineer's SaaS Validation Playbook

The whole guide, condensed. Eight stages: Find → Verify → Test → Sell → Build → Observe → Retain → Scale. Print this section; it's your permanent reference.

Misconceptions, Corrected

Sources / Further Reading

The ideas here stand on well-known shoulders. Where the frameworks disagree, it's mostly about emphasis: Blank and Fitzpatrick push discovery-before-building hardest; Ries emphasizes build-measure-learn loops with minimal products; Andreessen emphasizes market quality over everything; Ellis and Vohra focus on measuring fit once a product exists. This guide sequences them: Blank/Fitzpatrick first, Ries in the middle, Ellis/Vohra at the end.

• Marc Andreessen — "The Only Thing That Matters" (the origin of PMF as a concept): pmarchive.com/guide_to_startups_part4.html
• Rahul Vohra — "How Superhuman Built an Engine to Find Product/Market Fit" (First Round Review): review.firstround.com
• Sean Ellis — the "very disappointed" survey and the 40% heuristic; see Hacking Growth and pmfsurvey.com
• Rob Fitzpatrick — The Mom Test (how to ask questions that produce facts): momtestbook.com
• Steve Blank — The Four Steps to the Epiphany and customer development: steveblank.com
• Eric Ries — The Lean Startup (MVPs, build-measure-learn, validated learning)
• Paul Graham — "How to Get Startup Ideas": paulgraham.com/startupideas.html and "Do Things That Don't Scale": paulgraham.com/ds.html
• Y Combinator — Startup School (free course; see especially the lectures on talking to users and finding product-market fit): startupschool.org
• First Round Review — deep founder case studies: review.firstround.com