Discovery Questionnaires and the Mom Test, Questions That Actually Surface Truth

TL;DR — Good discovery questions ask about the past and the concrete, not the future and the hypothetical / opinions are cheap, behaviors are expensive / your job is to make it hard for stakeholders to flatter you into the wrong project.

Last week I wrote about the four-phase structure of a consultative discovery session. This week I want to get specific about the questions themselves. Structure is necessary but not sufficient — you can have the right framework and still walk out with garbage data if your questions invite the wrong kind of answer.

The single best book on this is still Rob Fitzpatrick’s The Mom Test. It’s aimed at startup founders doing customer interviews, but every move in it works for software discovery with internal stakeholders, enterprise clients, or anyone whose life your software is about to land in. I’ve stolen liberally from it for the better part of a decade.

Below is the question playbook I actually use, organized by what you’re trying to learn. None of these are clever — that’s the point. Clever questions get clever answers. Boring, concrete questions get truthful ones.

Why Most Discovery Questions Fail

Three failure modes account for most bad discovery questions, and once you can spot them in your own draft questionnaire, you can fix them.

Hypothetical questions invite fiction. “Would you use a feature that did X?” People are bad at predicting their own future behavior, and worse, they’re polite. They’ll say yes to be encouraging. The answer tells you nothing about whether they’d actually use the thing.

Generic questions invite generic answers. “What are the challenges your team is facing?” produces a generic list of things every team complains about — too many meetings, tech debt, unclear priorities. Nothing actionable. Anchor in specifics.

Solution-framed questions skip the diagnosis. “Should we build A or B?” assumes both A and B are the right shape of solution. You’re asking the stakeholder to validate your idea instead of describe their reality. They’ll usually pick one out of helpfulness, and you’ll learn nothing.

The corrective for all three is the same: ask about the past, ask about the concrete, and ask about behaviors over opinions.

The Question Patterns That Work

Here are the patterns I keep coming back to, grouped by what they’re for.

Anchor in Recent Events

The single highest-leverage move in discovery is to anchor questions in specific recent events rather than general patterns. Memory is more reliable than introspection.

• “Tell me about the last time X happened.”
• “Walk me through what you did yesterday morning when…”
• “When was the most recent example of this being a problem? Pick a date if you can.”
• “Show me the spreadsheet / ticket / email thread, if you have it.”

The last one is unreasonably effective. People will describe a problem abstractly for fifteen minutes and then, when you ask to see the actual artifact, you discover the problem is half what they described and a completely different second half that they forgot to mention.

Probe for Workarounds

What people do today, in the absence of your software, is the most honest signal about what they actually need. Workarounds are silent product specs.

• “What do you do today when this happens?”
• “Who do you ask, what do you look up, what do you copy-paste?”
• “How long does the workaround take? How often?”
• “Have you built anything yourself — a script, a spreadsheet, a macro?”

Internal-tools shadow-IT is a goldmine. A finance analyst with a 4,000-row Excel file full of VLOOKUPs is telling you exactly what your application should do, in exquisite detail.

Quantify the Pain

Pain without quantification is just complaint. You need numbers — even rough ones — to make scoping decisions later.

• “How often does this happen — daily, weekly, monthly?”
• “When it happens, how long does it cost you?”
• “How many people on your team deal with this?”
• “What’s the impact if this isn’t done — does someone wait, does revenue drop, does a deadline slip?”

If the stakeholder can’t quantify, it’s a useful signal in itself. Either the pain isn’t actually that significant, or the organization doesn’t measure the thing — both of which are important to know early.

Surface Past Attempts

Almost every problem worth solving has been attempted before. Understanding why previous attempts failed is the single best protection against repeating them.

• “Has anyone tried to fix this before? What happened?”
• “What was bought, built, or abandoned for this?”
• “Why didn’t the previous approach stick?”
• “Who championed it, and where are they now?”

The “where are they now” question is sneakier than it looks. If the original champion left the company, your project might be a zombie — politically un-killed but organisationally orphaned, with no current sponsor. Better to find out now.

Test Commitment, Not Enthusiasm

Enthusiasm is free. Commitment costs something. The Mom Test’s central move is to ask for things that have a cost — time, money, introductions, calendar — because those reveal real priority.

• “Would you be willing to spend an hour walking me through this workflow?”
• “Can you introduce me to two people on your team who’d be affected?”
• “If we built this, when could you start using it — what would you have to clear from your calendar?”
• “What would you not do, to make room for this?”

When someone says “this is critical, top priority,” and then can’t commit two hours of their time to a follow-up session, you’ve learned something important about how critical it actually is.

A Reusable Questionnaire Template

Here’s the questionnaire I send ahead of a discovery session. The phrasing is intentional — every question is anchored in past behavior or concrete artifacts.

# Pre-Discovery Questionnaire — <Project Name>

> Please answer based on real, recent events rather than general impressions.
> Rough numbers and dates are better than precise ones you have to guess.

## Section A — The Current Workflow

1. Walk through, step by step, what happens today from <starting event>
   to <ending event>. Include people, tools, and handoffs.

2. When did this workflow last run end-to-end? Pick a recent example.

3. What systems are involved? List them, even informal ones (Slack channels,
   spreadsheets, sticky notes).

## Section B — The Pain

4. The last time this caused a problem, what happened? When was it?

5. How often does this kind of problem occur — daily, weekly, monthly?

6. When it happens, what's your current workaround?

7. Roughly, how long does the workaround take, per occurrence?

8. Who is most affected by the pain, beyond yourself?

## Section C — Previous Attempts

9. Has this been worked on before? What was tried?

10. Why didn't the previous attempt stick? Be candid — funding, scope,
    politics, technical issue, key person leaving?

11. Is anything currently in flight that overlaps with this?

## Section D — Outcomes

12. If this were solved well, what would a good day look like in concrete
    terms?

13. What would you stop having to do?

14. What would you be able to start doing that you can't today?

15. What's the simplest signal — a number, a behavior — that would tell
    you this is working?

## Section E — Constraints

16. Are there systems, regulations, or integrations that absolutely must
    keep working as they do today?

17. Who needs to bless this project for it to ship? Names, please.

18. What would make any of those people block this?

19. What's your honest sense of the budget and timeline?

I send this two to three days before the session. People who fill it in carefully are the ones who’ll be useful collaborators throughout the project. People who don’t are giving you a signal too — about engagement, priority, or both.

What to Do With Bad Answers

You’ll get bad answers. Vague, hypothetical, solution-shaped. The trick is to redirect without lecturing.

• If they answer hypothetically: “Got it — can you tie that to a recent example? When did that actually happen?”
• If they answer with a solution: “Interesting. Before we get into how to solve it, can you describe the problem itself, separate from any solution?”
• If they answer generically: “Help me get specific — which team, which week, which incident?”

You don’t have to be heavy-handed. A gentle “can you give me a concrete example” works ninety percent of the time. The other ten percent, the person genuinely doesn’t have a concrete example — which means the problem might be less defined than the project pretends it is.

Common Pitfalls

Asking your idea, not their reality. “Would a dashboard help here?” is a fishing expedition for validation. Replace with “How do you currently get this information when you need it?”

Accepting compliments as data. “This sounds like a great project” tells you nothing useful. The Mom Test calls this “fluff” — strip it out, restate your question, get specifics.

Confusing politeness with agreement. Especially in cultures that value harmony in meetings, you’ll get agreement that evaporates the moment people leave the room. Follow up in writing, one-on-one, and look for what people actually do, not what they said.

Discovery sessions with too many people. Six stakeholders in one room produces consensus theater. Three is usually the max for a single session. Run multiple sessions if you need broader input.

No artifact at the end. Discovery without writeup is unstructured conversation. Always close with a written summary, sent back within a week, asking for explicit confirmation of the problem statement.

Wrapping Up

The best discovery isn’t done by the most articulate person in the room — it’s done by the person willing to ask boring, concrete, slightly awkward questions about specific past events. The framework above is mostly a collection of those questions, refined over time and many failed projects. Use the template, adapt it to your context, and pay close attention to the questions that make stakeholders pause. The pause is where the real information lives.

Next post: managing multidisciplinary teams, and why most cross-functional friction is structural rather than interpersonal.