This piece sits in Polymorph’s series on the seven fundamentals of great products. We’re on the first one: know your customer well enough that the roadmap points at a real human context.
I first wrote this as a short LinkedIn post. That version starts a conversation. This one is for teams who need something they can run next week.
Most product failures we’ve seen don’t look dramatic. Nobody’s pager goes off. The assumptions were wrong: that users will care, that the pain is big enough to fund change, that a polished deck somehow equals adoption. Your first job is to replace those guesses with evidence you can point at in a roadmap review.
Most teams believe they already “know the customer.” They have slides. They have quotes from last quarter’s calls. Then they ship, and discovery debt shows up as churn, stalled pilots, or people who never really use the thing. That’s usually a missing evidence base.
TL;DR: Atlassian’s State of Product 2026 reports 80% of teams still do not involve engineers early in discovery, so the build starts without shared context. CB Insights ties 43% of analysed startup failures to poor product–market fit. First-pass customer discovery is how you buy down that risk before capital turns into code.
Why does “know your customer” fail so often?
Poor product–market fit showed up in 43% of analysed shutdowns in CB Insights’ review of VC-backed startups that shut down since 2023. Two-thirds of those PMF failures were early-stage companies that never found a market. We’ve rarely seen that story start with bad code. It starts when “the customer” lives only in product and sales slides, while engineering optimises for a spec nobody has stress-tested against a real Tuesday.
McKinsey’s December 2024 analysis looked at more than 1,700 teams across 75 organisations. The teams that performed (delivery, value, engagement) weren’t the ones with the slickest process posters. Strategy, structure, people, process, and tech had to reinforce each other. Customer discovery is where you plant strategy in something you can observe.
Skip a clear answer to “who suffers, where, and under what constraints,” and the later fundamentals get shaky: behavioural validation, value proof, competitive mapping, differentiation, scope.
What goes wrong first, from what we’ve seen:
- Demographics dressed up as insight. Titles and firmographics, no day-in-the-life.
- The loudest voice wins. One buyer’s opinion treated as universal truth.
- Handoff thinking. Research happens “before the build,” then nobody opens the notes again.
- Interview theatre. Plenty of conversations. Almost nothing you can reuse next sprint.
Sanity check: if your “customer” sounds like “tech-savvy professionals aged 25–40,” you have a label. Build from what people have shown you in real workflows. Logic that never left the meeting room is still guessing.
What should you capture in first-pass customer discovery?
You’re after minimum viable understanding: enough to point at one coherent context and say, “we’re building for this reality.” Not a PhD thesis. Evidence your roadmap can trace back to.
Daily reality
Where does time disappear? Which tools, handoffs, meetings, and approvals make the job painful? What does “busy” look like on a Tuesday on an actual calendar, not in a persona workshop?
Emotional drivers
What creates stress, fear of looking incompetent, or urgency to change? In B2B, professional risk often beats feature lists. People protect their reputation harder than they chase a 10% efficiency claim.
Decision context
Who influences budget, security, procurement, and rollout? Who can veto a purchase after your champion has already said yes? Map that early, or you’ll “win” a demo and lose the buying cycle.
A test we use a lot: if your team can’t describe the customer’s last bad week in concrete steps, you don’t have first-pass clarity yet. You have a hypothesis with a headshot.
Nielsen Norman Group treats user interviews as a discovery tool for experiences, pain points, mental models, and motivations. They also warn that interviews alone collect reported behaviour. Memory is messy. People leave things out. They tidy the story for the room. So treat talk as the start of the picture, and plan to watch where the job actually happens.
Seven artefacts that prove you actually know the customer
Slides fade. Artefacts travel. After a first-pass discovery sprint, we want the team walking out with something concrete: documents and maps other people can argue with.
- Beachhead description: one segment, one job context, one environment. Not five ICPs on a slide.
- Day-in-the-life sketch: tools, handoffs, meetings, and where hours vanish. Rough is fine. Vague isn’t.
- Last-bad-week narrative: a specific week (or close cycle, shift, campaign) told in steps, with what broke and who got blamed.
- Workflow / journey map of the current way: including spreadsheets, side chats, and “we just email Jane.”
- Stakeholder and veto map: champion, budget owner, security, ops risk-bearer, and anyone who can kill the deal without owning the slide deck.
- Constraint list: compliance, devices, connectivity, literacy, integration points, training capacity.
- Open assumptions log: what you still don’t know, ranked by how expensive it would be to be wrong.
If you only leave with quotes and a persona poster, you have raw material. You don’t yet have a shared customer picture engineers can build against.
How do you build the picture without boiling the ocean?
You don’t need a six-month research programme. You need a short, disciplined pass that produces the artefacts above.
Interviews with concrete prompts
NN/g’s interview guidance is blunt: jog memory with specific events. Ask about the last time something happened. “Your challenges in general” invites speeches. Speeches are rarely useful.
Five interview prompts that force specificity
- Walk me through last Tuesday from the moment this problem showed up.
- Tell me about the last time you tried to fix it. What did you open? Who did you message? What broke?
- Show me the workaround you actually use (screen share if you can).
- Who else has to say yes before a new tool survives more than a pilot?
- If you could fund one fix this quarter, what would it be, and what would you stop doing?
Contextual observation
Watch people use today’s tools. Note workarounds, hacks, and the moments they apologise for the process. Those apologies are gold.
Diary or lightweight logging
If you can, capture frequency and triggers over several days. What people remember in a meeting and what they repeat every week are different animals.
Shadowing
Follow the job through the environment (warehouse floor, clinic, home office) where software meets operational reality.
Empathy mapping (for alignment, not decoration)
Get the team aligned on what users say, think, feel, and do. Shared understanding matters. A poster on the wall is optional.
Teresa Torres defines continuous discovery as, at minimum, weekly touchpoints with customers by the team building the product (Product Talk). First-pass clarity is the foundation. The habit that keeps it honest is staying close after the first sprint. Her product discovery basics piece puts it simply: if you’re continuously deciding what to build, you need to stay connected to customers. Good teams interview together as a product trio (product, design, engineering). Handing discovery to a research silo and waiting for a report slows the learning.
Why should engineers be in the room early?
Atlassian notes that 80% of teams still don’t involve engineers early. That gap often starts here. When engineering meets customers late, you get brittle estimates, misread constraints, and “just build it” pressure that skips feasibility.
Bring them in early and you cut expensive rework. You learn what’s hard to integrate, what security will block, and what has to stay manual for now. You also get a shared vocabulary for the artefacts above, so the roadmap isn’t a translation exercise three weeks later.
How many conversations are enough?
Teams love a magic number. Qualitative research rarely grants one.
Nielsen Norman Group suggests starting with a small representative sample (about 5–6 interviews) and analysing as you go. Add people until you hit saturation: new conversations stop changing your themes in ways that matter. Broad goals and diverse populations need more sessions. Narrow goals with a fairly similar group can saturate faster. Five interviews are often too few for wide exploratory work. They can be enough when the scope is tight and you synthesise properly.
We’ve seen the same pattern in B2B discovery. Five deep conversations that produce artefacts beat twenty shallow ones that produce only quotes. Stop when the story stabilises. Keep going when every session still rewrites the beachhead.
What failure modes show up even when you “did interviews”?
- Research theatre: lots of meetings, few artefacts.
- Single-threaded discovery: one champion, no operational voices.
- No decision map: you understand pain, but not procurement.
- Past-tense avoidance: people talk about ideals; nobody walks a real incident.
- Shelf life of one week: insights never make it into the backlog or the sprint brief.
Short scenario A B2B SaaS team ships a workflow for “finance teams.” Interviews surfaced “reporting is painful.” Nobody shadowed month-end close. The first release missed the spreadsheet handoffs that actually ate people’s nights. First-pass discovery never touched the environment where the work happens. The rebuild cost more than the interviews would have.
When executives ask “can’t we move faster?”
Speed without a grounded customer picture is directional risk. You’re choosing cheap learning now or an expensive rebuild later.
You can still move fast. Time-box discovery. Limit the beachhead. Produce the seven artefacts in days, not quarters. Bring an engineer to the first three conversations. Share interview snapshots the same week. Torres’s habit of making learning visible beats a 40-page research deck nobody reads.
What you can’t shortcut is contact with reality. Guessing dressed as velocity still shows up on the P&L.
Atlassian’s State of Product 2026 reports 80% of product teams do not involve engineers early in discovery, which weakens shared context before the build. CB Insights attributes 43% of studied startup failures to poor product–market fit, often preceded by a fuzzy customer picture. NN/g advises starting with roughly 5–6 interviews and analysing toward saturation. Put together, those figures argue for first-pass discovery that produces artefacts the whole team can reference, and a cadence of customer contact that doesn’t stop after kickoff.
Where does this fundamental lead next?
First-pass clarity sets up second-pass behavioural rigour in behavioural customer research. When you’re ready to prove value before you scale the build, read product validation before build. The full loop is in the seven fundamentals overview.
Want to pressure-test your discovery before you commit capital? Talk to Polymorph — we work with founders, product leads, and executive teams to validate, build, and improve software that earns its place in the business.
FAQ
How is customer discovery different from a persona?
A persona is a summary. Discovery is evidence: tasks, constraints, and decision paths you can challenge. NN/g notes interview data can feed personas, and that interviews alone are attitudinal. Trace the persona to artefacts, or treat it as fiction.
How many interviews are enough for first-pass clarity?
NN/g suggests starting with about 5–6 people and analysing toward saturation. Five deep conversations that produce artefacts beat twenty shallow quote-hunts. Stop when themes stabilise. Keep going when each session still rewrites the beachhead.
What if we sell to many segments?
Pick one beachhead context to understand first. Breadth without depth is how roadmaps go generic. You can widen later once the seven artefacts exist for one real environment.
Should we include customer success and sales in discovery?
Yes, when they bring customer reality, not internal politics. Triangulation helps. A product trio still owns synthesis so the roadmap doesn’t become a sales wishlist.
How does this connect to the rest of the fundamentals?
Discovery sets context. Next, stress-test behaviour (behavioural customer research), then prove value (product validation before build). Overview: seven fundamentals.
Sources
- CB Insights — Why startups fail: Top reasons
- Atlassian — State of Product 2026
- McKinsey — What makes product teams effective?
- Nielsen Norman Group — How many participants for a UX interview?
- Nielsen Norman Group — User interviews 101
- Product Talk — Everyone can do continuous discovery
- Product Talk — Product discovery basics
