Product Discovery Frameworks: Which One Your SE Team Needs

Hypothetical scenario: You're the Solution Engineer (SE) on an opening call with a B2B SaaS buyer. They ask to see the reporting module, your AE wants to keep momentum, and nobody has agreed what business result the reporting needs to change. You can start screen sharing, but you can't yet say what would count as a technical win.

That's where product discovery frameworks earn their place in PreSales. Use them to identify the evidence missing from the deal, not to turn a buyer conversation into a product-management workshop.

Why Discovery Frameworks Exist and Which One Fits

An SE can reach a demo with a buyer before anyone has agreed on the business outcome the software should support. A polished walkthrough may still test the wrong need, consume evaluation time, and leave technical fit or qualification unresolved.

Product teams use discovery methods to check customer problems before committing effort to solutions. In PreSales, the same discipline helps determine whether a request reflects a real business need, whether the proposed solution fits, and what evidence is still missing. Discovery takes time from the demo or evaluation, so use it to answer a specific deal question.

A discovery framework is a repeatable set of questions, artifacts, and decision rules for turning a vague request into a testable need or assumption. For an SE, its value is the evidence it produces about customer need, solution fit, evaluation risk, and qualification.

Five Discovery Frameworks at a Glance

Choose by the missing evidence, not by framework loyalty. Each method addresses a different gap.

On a hypothetical reporting call, ask which decision the report supports, who makes it, and what happens when information arrives late. This is a focused first check, not a full investigation. The cost is spending meeting time on questions instead of showing the software, and the answers may still require follow-up with other stakeholders.

Make that trade-off clear to the buyer. A narrower demonstration can then address the decision they need to make, rather than showcasing features without a defined purpose.

Practical rule: No discovery, no demo. Discovery quality, not demo polish, determines whether you are testing something that matters.

The PreSales role across the sales cycle puts this work in context. You own the technical win, but technical fit alone does not qualify an opportunity without a confirmed business need. Use the framework that closes the evidence gap in front of you.

Jobs-to-Be-Done and the Switch Interview

Hypothetical example: A mid-market finance lead asks for CSV export. Their real job is closing month-end without re-keying data, so an export button might preserve the manual work they're trying to remove.

A scheduled transfer or an existing integration could be more relevant. You won't know until you understand the situation, the desired progress, and the constraints around it.

Jobs-to-Be-Done (JTBD) shifts attention from requested capabilities to the progress a buyer wants in a specific circumstance. Tony Ulwick developed Outcome-Driven Innovation in 1990, and Clayton Christensen popularized Jobs-to-Be-Done through his 2003 book The Innovator's Solution, as documented in this history of Jobs-to-Be-Done.

Write the Job Before Choosing the Capability

Use this working format:

When a situation occurs, I want to make progress, so I can reach an outcome.

Capture the functional, social, and emotional dimensions. In the hypothetical finance example, those might be completing reconciliation, defending the close to leadership, and feeling confident that a hidden error won't surface afterward.

Don't turn those dimensions into invented buyer motivations. Treat them as hypotheses until the buyer supplies evidence. The cost is deeper questioning and access to the person doing the work, rather than relying entirely on the champion.

A need-based selling approach connects that understanding to a relevant recommendation. It doesn't mean agreeing that the buyer's requested feature is the right answer.

Reconstruct a Real Switching Decision

The JTBD switch interview works backward from an actual purchase or replacement. Surveys and focus groups alone don't reconstruct the circumstances behind that decision.

1. Find someone who changed tools recently. A completed decision gives you actions to investigate rather than intentions to interpret.
2. Start at the trigger event. Ask what happened that made the existing approach unacceptable.
3. Walk from first thought to signed contract. Capture pauses, stakeholders, evaluation events, and changes in urgency.
4. Ask what they tried first and why it fell short. Include internal fixes and doing nothing, not only competing products.
5. Name the forces. Separate push from dissatisfaction, pull toward a better outcome, anxiety about the unfamiliar, and habit around the existing workflow.
6. Check the balance. Test whether push and pull outweighed anxiety and habit. Don't mistake attraction to your product for readiness to change.

The shorthand is Push + Pull > Anxiety + Habit. It's a way to organize the decision, not a numerical scoring model.

For an SE, the timeline helps anticipate evaluation objections and identify what the buyer needs to see before switching feels safe. Its limit is equally important: someone else's past switch doesn't prove this buyer's current readiness.

If no switcher is reachable, interview a recent adopter of the workaround the buyer uses today. That costs less access effort, but you'll have weaker evidence about purchasing and procurement.

Opportunity Solution Trees and Continuous Discovery

An Opportunity Solution Tree (OST) makes your reasoning visible. Start with the business outcome, branch into unmet customer needs, branch again into candidate solutions, and attach assumption tests beneath those solutions.

That order matters. A feature list starts with what you sell; a tree starts with what the buyer needs to change. Teresa Torres's Opportunity Solution Tree resource introduces the structure.

Use the hierarchy to separate the buyer's result from your proposed response.

Keep the Branches Tied to Customer Evidence

Hypothetical deal: An operations director wants to reduce new-site onboarding from six weeks to three, with manual data mapping, unclear approval ownership, and training gaps as possible opportunities. The sponsor supplies the outcome, users validate those opportunities, demo scope represents candidate solutions, and proof-of-concept success criteria become assumption tests.

Those branches imply different work. Data mapping may require an import test; approval ownership may require a process decision; training gaps may require a usability check rather than another integration.

The cost of the tree is maintenance and stakeholder access. If you draw it once and never revisit it, you've created another deal document that can drift away from reality.

Use Continuous Discovery as a Working Cadence

Continuous discovery keeps the tree current through recurring customer contact rather than treating research as a completed phase. The continuous-discovery operating guidance describes a weekly customer touchpoint involving a product manager, designer, and engineer, supported by a living OST.

PreSales shouldn't copy that staffing model mechanically. For a live deal, update your working tree after customer calls and bring the relevant specialist into the next conversation when an assumption needs their judgment. That consumes coordination time, so make the unresolved question explicit before requesting another meeting.

My operating recommendation is to cap a deal tree at three opportunities. You sacrifice breadth, but you retain a decision-focused evaluation instead of creating a survey of everything wrong with the buyer's operation.

Recurring contact keeps those branches honest. If a user contradicts the sponsor's explanation, preserve the disagreement and investigate it rather than editing it away. The numbered live-deal procedure below turns that evidence into demo scope and qualification records.

Design Thinking, Lean Tests and Design Sprints Compared

These approaches optimize different work. Design Thinking broadens your understanding of people and their problems; Lean experiments test a risky belief; a Design Sprint puts a bounded business question through a compressed design-and-validation sequence.

Reach for the smallest approach that can resolve the uncertainty. A workshop is expensive when a scoped import test would answer the question, while an import test won't resolve disagreement about whose workflow matters.

Compare the Work Before Booking the Calendar

The Stanford d.school provides the Design Thinking grounding: empathize, define, ideate, prototype, and test. For PreSales, an empathy map is useful only if it changes the problem statement or the evaluation you propose.

A Lean experiment needs a written belief and a result that could disprove it. A clickable prototype, concierge workflow, or scoped data import can test different assumptions; none proves more than the question it was designed to answer.

Hypothetical example: A manually operated concierge workflow might test whether users adopt a proposed handoff. It won't establish that your production integration can handle their operating conditions, so record that limitation before the result reaches a proposal.

Borrow the Sprint's Boundaries for a Proof of Concept

The Google Ventures Design Sprint uses a five-day sequence to answer a critical business question:

1. Understand the problem through research and shared context.
2. Diverge on solution options before selecting one.
3. Decide and write a user story that makes the scenario concrete.
4. Build a quick prototype with enough detail to test.
5. Test with people outside the company rather than relying on internal approval.

For PreSales, borrow the discipline, not the ceremony. Name the business question, consider alternatives, and build only enough to test the critical assumption. A sprint-shaped proof of concept shouldn't become a disguised implementation project.

The trade-offs need to be visible before anyone commits:

• Design Thinking takes time and stakeholder access. Budget for facilitation and conflicting accounts of the problem.
• Lean tests need a written hypothesis. The cost is agreeing beforehand what result would make you change direction.
• Sprints need a decision-maker in the room for the full week. Without protected availability, choose a smaller test.

Skip the sprint when the buyer's question is a known integration. Use Design Thinking when two user groups disagree about the problem. In either case, the access and preparation cost should match the uncertainty you're resolving.

How Much Evidence a Problem Needs Before You Build

A buyer praises the demo, then declines to share sample data or name a budget owner. That gap matters: enthusiasm helps frame a conversation, but it is weak evidence for a technical win or a qualified deal. Judge what the buyer has done, shared, changed, or committed. The ladder below is a decision aid, not a universal scoring system.

Evidence Ladder from Weakest to Strongest

Praise and internal opinions are easy to give. Shared artifacts, customer effort, and budget commitments are harder to produce. Even a paid pilot, however, does not establish production value. Repeated usage, renewal, or expansion provides evidence after the pilot begins.

Treat stated willingness to pay cautiously. Startupbook's product discovery guidance discusses how stated intent can differ from actual behavior. A positive budget conversation can support further qualification, but it is not a purchase forecast or proof that funding is approved.

Watch for confirmation bias when evidence matches your preferred answer, friendliness bias from a supportive champion, and loud-customer bias when one vocal stakeholder stands in for the buying group. Internal pressure to close can distort the same judgment. Ask who supplied each signal, what action followed, and which stakeholder still needs to confirm it.

A champion's confidence is a reason to investigate, not permission to stop investigating.

Put Human Approval Between AI Synthesis and Decisions

AI-assisted synthesis can sort feedback quickly. It cannot strengthen the evidence behind it. It may invent themes, make repeated weak signals look like consensus, or leave out contradictions, risks also discussed in this discussion of AI's role in product work. Human review costs time, so reserve it for conclusions that will shape a demo, pilot, or qualification decision.

• Approve every theme. A named person checks whether the interpretation fits the source material.
• Preserve provenance. Link each theme to a source quote and its context.
• Check contradictions. Review disconfirming cases before relying on a conclusion in a proposal.

Set the evidence gate to the decision at hand. Demo scope needs at least an observed workaround, because the demo should address behavior the buyer already uses to manage the problem. A pilot needs a paid-pilot commitment before it starts, or equivalent named evidence from the ladder, such as a confirmed budget and customer commitment to supply the required data and time. Repeated usage, renewal, and expansion are post-pilot signals, not pre-pilot entry criteria.

This gate can slow an evaluation when procurement will not authorize payment. Record the exception and why the buyer is still committing resources. Use written proof-of-concept success criteria to define the test, decision owner, and limits on the capacity you put at risk.

How to Run Discovery Frameworks on a Live Deal

Run discovery across the first two or three calls, then decide what to demo. Treat that as a proposed operating sequence, not a benchmark: an established account may already have the evidence, while a new buying group may need more access.

The cost is coordinated AE and SE preparation plus a short evidence review after each conversation. Don't add meetings just to complete a template.

Use this process overview to agree on the sequence with your account team.

Move from Buyer Claims to a Testable Evaluation

JTBD belongs inside this process as a problem-framing layer, not a feature-prioritization formula, a distinction supported by Harvard Business Publishing's Jobs-to-Be-Done material. Use the methods together without making the buyer learn their names.

1. Confirm the business outcome. Capture the economic buyer's own words and a number they already track. If you only have a champion's account, mark economic-buyer confirmation as pending.
2. Capture the trigger and current workaround. Use the switch timeline to establish why the buyer is considering change now.
3. Map two or three opportunities beneath the outcome. Attach a user role to each so you know whose evidence to seek.
4. List the assumptions behind each candidate solution. At this AI checkpoint, a tool may draft the synthesis, but a person must compare it with source quotes and preserve contradictions.
5. Rank assumptions by uncertainty and consequence. Pick the cheapest credible test for the riskiest belief, not the easiest belief to validate.
6. Scope the demo or proof of concept around that assumption. Write success criteria and the boundaries of what the result can establish.
7. Grade each claim on the evidence ladder. Do this before it enters a proposal, where an unsupported inference can become an apparent commitment.
8. Record proceed, revise, or stop. Update the technical win criteria in the CRM and give the next action an owner.

Use the discovery call guide for question sets and the discovery call framework to structure preparation. The cost of standardization is some administrative work; the benefit is a record that another SE can inspect without reconstructing the deal from memory.

Translate the Evidence into Qualification

Don't maintain a separate framework document that never reaches the opportunity record. Map the evidence into the fields your team already uses, with the MEDDPICC guide for Solution Engineers as the qualification reference.

Use your CRM's actual field labels if they differ. Keep the distinction between a buyer-confirmed fact and an SE hypothesis visible, even if that requires a separate evidence-status note.

For team practice, use the video alongside a recorded-call review, then check the resulting notes against the procedure.

Watch the video on YouTube

Common failures are easy to recognize:

• Demoing before the outcome is confirmed. You spend preparation time without an agreed reason for the buyer to care.
• Opportunities with no user role attached. You can't identify who should validate the problem.
• Proof-of-concept plans without success criteria. You commit technical capacity without an exit decision.
• Framework vocabulary spoken in front of the buyer. You spend their attention explaining your method rather than understanding their work.

Pick the Framework Your Next Deal Calls For

A live deal can have a clear pain but no agreed outcome, or an enthusiastic champion without evidence that the proposed solution works. Choose a framework for the missing evidence, then use the call to close that gap.

The framework earns its place when its output supports both the technical win and qualification. For example, a proof of concept without a buyer-defined decision may use engineering time without advancing either. Each method also has a cost: interviews take buyer time, experiments need a clear assumption and success criteria, and workshops require preparation and review.

The first question should target what the deal still needs to establish. If you leave the call without an answer, the evidence gap remains, even if the conversation felt productive.

Choose one live opportunity this week, match its gap to a row, and ask that question on your next discovery call. Set aside time to prepare and review the evidence, rather than adding a standing workshop.

For practice on active deals, explore the Trusted Advisor Academy. Teams seeking feedback on a recorded conversation can use the discovery call page.

PreSales Unleashed GmbH offers PreSales training and enablement through structured learning, live practice, and feedback tied to active deals. Explore the Trusted Advisor Academy to practice turning discovery evidence into focused demos, bounded evaluations, and explicit technical win criteria.