Example of a product discovery process for enterprise SaaS must account for something consumer product discovery does not: the buyer is not always the user. In enterprise SaaS, the person who approves the purchase (economic buyer) often differs from the person who uses the product daily (end user), and both differ from the person who integrates it (IT/security).
A discovery process that ignores this triangle produces features that win deals but don't drive adoption — or features that users love but can't get approved.
The Enterprise Discovery Triangle
Economic Buyer (VP/Director)
/ \
/ \
End User (IC) ---- Technical Buyer (IT/Security)
All three vertices must be interviewed. Their needs frequently conflict. Your discovery process must surface those conflicts before development begins.
H3: The Five-Stage Enterprise Discovery Process
- Problem framing — What business problem are we trying to solve and for whom?
- Stakeholder interviews — Validate the problem across all three buyer types
- Solution prototyping — Test the solution approach before writing a spec
- Decision gate review — Explicit go/no-go before engineering starts
- Pilot validation — Test with 1–3 enterprise customers before general availability
Stage 1: Problem Framing
Before any customer interview, write a one-page problem brief:
- Observation: What signal (support tickets, sales feedback, churn data) triggered this discovery?
- Hypothesis: What is the underlying problem we believe customers have?
- Business case: Why is solving this worth engineering investment?
- Out of scope: What related problems are we explicitly NOT solving?
According to Lenny Rachitsky on his newsletter, the most common enterprise product failure is building a solution before the problem is clearly defined — teams that skip the problem brief almost always end up in scope creep because the problem boundary was never drawn.
Stage 2: Stakeholder Interviews
H3: Interview Guide by Buyer Type
Economic Buyer interview (30 min):
- What business outcome are you trying to achieve in the next 6 months?
- How are you currently measuring success in this area?
- What does a bad outcome look like, and what is the cost to your business?
- What has prevented you from solving this already?
End User interview (45 min):
- Walk me through the last time you had to do [target workflow]
- Where do you get stuck? What takes the longest?
- What tools do you currently use for this? What do you like/dislike?
- If you had a magic wand, what would the ideal solution look like?
Technical Buyer interview (30 min):
- What are your data residency and security requirements?
- What integrations are required for adoption in your environment?
- What is the approval process for adding a new tool to your stack?
- What are the dealbreakers that would prevent you from approving this?
According to Shreyas Doshi on Lenny's Podcast, the enterprise PMs who build the most successful products are the ones who genuinely respect the technical buyer's constraints — not as obstacles but as design inputs that often produce more durable solutions than what the end user asked for.
Stage 3: Solution Prototyping
Before writing a full PRD, prototype the solution at the lowest possible fidelity:
- Wireframes for UI-heavy features
- API contract sketches for integration-heavy features
- Process diagrams for workflow features
Test prototypes with 3–5 end users. The goal is not validation — it is learning. You expect to change the approach based on feedback.
Stage 4: Decision Gate Review
Before engineering begins, hold a 60-minute decision gate review with:
- PM presenting the problem definition and proposed solution
- Engineering estimating complexity and identifying technical risks
- Design reviewing UX decisions
- Sales or CS validating that the solution would have changed recent deals or retention outcomes
The review produces one of three outcomes: Build, Revise (go back to prototyping), or Kill (problem not worth solving at this time).
According to Annie Pearl on Lenny's Podcast, the enterprise teams that ship the highest percentage of features that actually get adopted are the ones that treat the decision gate as a genuine checkpoint — not a rubber stamp — with explicit power to kill or revise a project.
FAQ
Q: What is product discovery in enterprise SaaS? A: A structured process for validating that a problem is worth solving, that the proposed solution addresses the right stakeholders, and that the solution can survive enterprise security and integration requirements before engineering investment begins.
Q: How do you run customer interviews for enterprise product discovery? A: Interview economic buyers, end users, and technical buyers separately — they have different problems and different success criteria. Use structured but open-ended interview guides tailored to each buyer type.
Q: How long should enterprise product discovery take? A: 3–6 weeks for a new feature area. Faster for incremental improvements to existing workflows. The decision gate review should happen before any engineering sprint begins.
Q: What is a decision gate in product discovery? A: A formal 60-minute review with PM, engineering, design, and sales/CS that produces an explicit Build, Revise, or Kill decision before engineering starts. Prevents investment in poorly validated solutions.
Q: How do you validate an enterprise product hypothesis without building it? A: Prototype at the lowest fidelity that communicates the core interaction — wireframes, API contract sketches, or process diagrams — and test with 3–5 end users before writing a full spec.
HowTo: Run a Product Discovery Process for Enterprise SaaS
- Write a one-page problem brief covering the triggering observation, problem hypothesis, business case, and explicit scope exclusions before any customer interviews
- Interview all three buyer types separately — economic buyer, end user, and technical buyer — using tailored guides for each
- Synthesize interview findings to identify conflicts between buyer types and define the solution space that serves all three
- Prototype at the lowest viable fidelity — wireframes, API sketches, or process diagrams — and test with 3 to 5 end users
- Hold a 60-minute decision gate review with PM, engineering, design, and sales or CS that produces an explicit Build, Revise, or Kill decision
- Run a pilot with 1 to 3 enterprise customers before general availability to validate adoption in a real enterprise environment