An example of a user research plan for a B2B product must address two challenges that consumer research plans don't face: you need to recruit participants through gatekeepers, and you need to separate the buyer's perspective from the user's perspective — because the person who bought the software is often not the person who uses it daily.
B2B user research that ignores the buyer-user split produces two common failure modes: features that buyers love but users won't use, or features that users need but buyers won't fund. A research plan that accounts for both perspectives produces more complete signal.
The Research Question: Where Most Plans Go Wrong
The most common B2B research plan failure is starting with a solution hypothesis ("we think users want feature X") rather than a problem question ("what is preventing users from achieving Y?").
Solution-led research produces confirmation bias. Problem-led research produces insight.
Weak research question: "Do users want a Kanban board view for task management?" Strong research question: "How do users currently track work in progress, and where does visibility break down?"
The strong version will surface whether a Kanban view is needed — and also whether it is the right solution, a better solution exists, or the problem is different from what the team assumed.
H3: Research Question Types
| Type | When to use | Example | |------|------------|---------| | Exploratory | Early discovery — you don't know the problem | "What does the weekly planning workflow look like for ops managers?" | | Evaluative | You have a solution — you want to test it | "Can users complete task assignment without instructions?" | | Generative | You know the problem — you want solution ideas | "How have users worked around the current limitation?" | | Validation | Pre-ship — does this work as intended? | "Does the new notification system reduce missed deadlines?" |
Each type requires different methods and different participants.
According to Lenny Rachitsky's writing on B2B user research, the most valuable research in B2B is generative research with power users who have built workarounds to solve the problem you are trying to solve — they have already designed the solution; your job is to find them and understand what they built.
Participant Recruitment for B2B
H3: The Gatekeeper Problem
In B2B, participants are customers. To reach them, you typically go through:
- Customer success managers (for existing customers)
- Sales reps (for prospects or recent churned customers)
- LinkedIn outreach (for cold research recruitment)
Each channel has bias: CS managers send you to happy customers. Sales sends you to prospects who want something. LinkedIn attracts the most engaged or most frustrated users.
A robust recruitment strategy uses all three channels and explicitly recruits from churned customers — they will tell you what the product fails at in a way that retained customers won't.
H3: Participant Segmentation for B2B Research
For most B2B products, recruit across three segments:
- Power users: Heavy product usage, multiple features used, likely to surface advanced workflow needs
- Casual users: Low usage, single feature, likely to surface onboarding and adoption barriers
- Churned users (if applicable): No longer using the product, most candid about failure modes
Minimum viable research: 5 participants per segment. Diminishing returns typically set in after 8–10 participants per segment.
H3: Screening Criteria
Write specific screening criteria:
- Role and seniority (ops manager, not VP ops)
- Company size (50–500 employees, not enterprise)
- Usage frequency (logs in at least 3x per week)
- Feature usage (uses task assignment feature, not just reporting)
Vague screening produces participants whose experiences don't generalize to your target user.
Method Selection
H3: B2B Research Methods by Question Type
| Method | Best for | Duration | Participants | |--------|---------|----------|-------------| | Semi-structured interview | Exploratory, generative | 45–60 min | 5–8 per segment | | Contextual inquiry (observe in their environment) | Exploratory, workflow mapping | 60–90 min | 3–5 | | Usability testing | Evaluative, validation | 30–45 min | 5 per flow | | Diary study | Longitudinal behavior, infrequent events | 1–2 weeks | 8–12 | | Survey | Quantitative validation after qual | Async | 100+ |
For most B2B product research, start with semi-structured interviews. They produce the richest signal per hour invested.
According to Shreyas Doshi on Lenny's Podcast, the most underused B2B research method is contextual inquiry — watching a user actually do their job in their real environment, not in a test scenario. In B2B, work contexts are complex and often surprising, and the most important insights come from seeing what the user does between product interactions, not just during them.
The Research Plan Document
H3: Required Sections
- Research question(s): 2–3 questions in problem-framing format
- Context: Why this research is happening now, what decisions it will inform
- Participant criteria: Segmentation, screening criteria, recruitment channel, target number per segment
- Method: What method, why this method, how sessions will be structured
- Session guide: Discussion guide or task scenarios (not a rigid script)
- Timeline: Recruitment, sessions, synthesis, findings delivery
- Outputs: What will the research produce (insight themes, personas, journey maps, decision recommendation)?
H3: From Findings to Product Decisions
The deliverable from a B2B user research plan is not a summary of what users said. It is a recommendation for what the product team should do differently.
Structure findings as:
- Insight: What we learned (with evidence — quotes, observation notes, frequency counts)
- Implication: What this means for the product
- Recommendation: What we should do, with a confidence level
According to Gibson Biddle on Lenny's Podcast, the most common research waste in B2B product teams is research that produces findings but no decisions — the PM writes a research report, presents it to the team, and the roadmap does not change. Research that does not change a product decision was not worth doing.
FAQ
Q: What is a user research plan for a B2B product? A: A document that defines the research questions, participant criteria, research method, session structure, and timeline — and commits the team to using the findings to make a specific product decision.
Q: How do you recruit B2B research participants? A: Use customer success managers for retained customers, sales reps for prospects, and direct outreach for churned users. Recruit across power users, casual users, and churned users to get complete signal.
Q: How many participants do you need for B2B user research? A: 5 participants per segment for qualitative methods. Diminishing returns set in after 8–10 per segment. Surveys require 100+ for statistical significance.
Q: What research methods work best for B2B products? A: Semi-structured interviews for exploratory and generative research, usability testing for evaluative and validation research, and contextual inquiry for workflow mapping.
Q: How do you translate B2B research findings into product decisions? A: Structure findings as Insight plus Implication plus Recommendation. Every finding should connect to a specific product decision or roadmap change. Research that does not change a decision was not worth running.
HowTo: Create a User Research Plan for a B2B Product
- Frame research questions in problem terms rather than solution terms — ask what prevents users from achieving a goal, not whether they want a specific feature
- Recruit across three segments — power users, casual users, and churned users — using CS managers, sales reps, and direct outreach with specific screening criteria
- Select the method based on the question type — semi-structured interviews for exploratory research, usability testing for evaluative, contextual inquiry for workflow mapping
- Write a discussion guide with open-ended questions that follow the user's story rather than a rigid script, with probes for unexpected answers
- Synthesize findings as Insight plus Implication plus Recommendation with supporting evidence, and tie each recommendation to a specific product decision
- Deliver findings within one week of completing sessions while the data is fresh, and confirm with the product team which decisions will change as a result