A Practical Guide to Problem Interviews for B2B SaaS

This is the pillar guide for B2B SaaS teams running problem interviews. The framing is intentionally tilted toward the B2B-specific patterns: user-buyer split, procurement, champion profiles, and existing tool politics. Read through and you have everything you need to start the round this week.

Step One: Define the Buying System, Not Just the User

Before outreach, define four roles. The user (feels the pain). The buyer (signs the contract). The gatekeeper (security, IT, legal - veto power). The champion (internal advocate). The product has to serve all four. The interview round needs to surface all four.

Step Two: Define the Audience by Two Filters

For each role, two filters: a job-or-role and a recent behavior. Examples: ops managers at SaaS companies between 50 and 500 employees who shipped at least one new internal process last quarter. CFOs at companies between 100 and 1000 employees who approved at least one new vendor in the last six months. Be specific.

Step Three: Reach Fifteen of Them, Split Across Roles

Roughly seven users, five buyers, three gatekeepers. Plan to send 50-80 messages total. Reply rates are lower for buyers and gatekeepers - plan accordingly.

Three-sentence message. Why specifically them, what you are researching, ask for thirty minutes. Do not pitch.

Step Four: Build a Three-Question Spine

Question one: walk me through the last time your team did X.

Question two: where did things get slow, who fixed it, what did it cost?

Question three (B2B-specific): if you wanted to bring a tool in for this, who has to approve and what would they ask?

For buyer interviews, swap question three for: "walk me through the last vendor approval you managed." For gatekeepers: "what would your team ask before approving a vendor for this kind of workflow?"

Step Five: Run the Call

Open with a low-stakes intro. State you are researching, not selling. Ask question one and listen. Use silence after answers - the second sentence after a pause is usually the most useful one.

If they ask what you are building, deflect to the end. Most B2B operators will accept the deflection.

Step Six: Capture Vocabulary, Procurement, and Champions

Three things B2B-specific you must capture in notes. The exact phrases operators use about their workflow. The procurement constraints they describe. The internal champion profile - who, on this team, would actually push for the purchase if they saw a good demo.

The third is your launch playbook. Skipping it is the most common cause of B2B SaaS launches that produce demos and no buyers.

Step Seven: Synthesize Every Five Calls

Reread the previous five sets of notes. Look for repeats. Same workflow shape. Same handoff pain. Same procurement constraint. Same champion profile. Same buyer objection.

By interview fifteen you should be able to write one paragraph that names the user pain, the buyer's ROI argument, the gatekeeper's compliance bar, and the champion's motivation. That paragraph is your spec.

Step Eight: Decide What You Have

Four questions. Is the user pain real and recurring? Is there a coherent ROI story for the buyer? Can you meet the gatekeeper's baseline? Is there a champion profile you can reach with a launch motion?

If yes to all four, build the smallest version and design the launch motion. If any is no, you have learned something equally valuable.

Common Failure Modes

Only interviewing users. Skipping procurement questions. Trusting your old network. Asking pricing hypothetically. Stopping at three. Not capturing champion profiles. Each is covered in detail in other posts.

When You Should Skip This

You have built and sold several products in this exact category. Your gut already encodes the buying system. You are the user, the buyer, and live in the gatekeeper's shoes. Otherwise, do the round.

The Trade

Twenty-five to thirty hours over three to five weeks (B2B reply rates are slower than B2C). At the end you have a workflow map, a buying-system map, a champion profile, procurement constraints, vocabulary, and a list of fifteen people to launch to.

The build that follows is narrower, more focused, and aimed at a system that exists - not just at a user pain you remember from your last job.