What This Template Is For
A buyer persona is a research-based profile of the person who decides whether to purchase your product. In B2B, the buyer is often not the same person who uses the product daily. A VP of Engineering evaluates and signs off on developer tools that individual engineers use. A Head of Marketing purchases analytics platforms that marketing analysts operate. Conflating the buyer with the user leads to products that win evaluations but fail at adoption, or products loved by users that never get purchased.
This template captures everything your sales, marketing, and product teams need to understand about the buyer: their role, goals, decision process, objections, information sources, and the messaging that resonates with them. It is distinct from a user persona, which profiles the daily user. For B2B products, you need both.
Buyer personas should be built from actual conversations with buyers, not from assumptions or demographic stereotypes. Interview 5-10 people who recently made a purchase decision in your category. Include both buyers who chose your product and those who chose a competitor. The contrast between the two groups reveals what actually drives the decision. This template pairs well with the customer interview template for structuring those conversations and with product discovery practices for synthesizing the findings into product and go-to-market decisions.
How to Use This Template
- Identify 5-10 recent buyers in your category. Include customers, lost deals, and prospects who evaluated but chose a competitor or chose to do nothing.
- Conduct 30-45 minute interviews focused on the buying process, not the product. Ask about the timeline, who was involved, what information they sought, and what nearly killed the deal.
- Fill in each section of the template from interview data. Do not use a single interview to fill the entire template. Synthesize across multiple conversations.
- Validate with your sales team. They interact with buyers daily and can confirm or challenge the patterns you found.
- Share the completed persona with marketing (for messaging and content), sales (for objection handling), and product (for positioning and packaging decisions).
- Review and update quarterly. Buyer behavior shifts as markets evolve, competitors change, and your product matures.
The Template
Persona Overview
| Field | Details |
|---|---|
| Persona name | [Give them a memorable name, e.g., "VP Victoria" or "Director Dave"] |
| Job title(s) | [2-3 titles this persona might hold] |
| Company size | [Employee count and revenue range] |
| Industry | [Primary industries where this buyer type exists] |
| Reports to | [Who is their boss? This is often the final approver.] |
| Team size | [How many people report to them?] |
| Budget authority | [Typical annual budget they control without additional approval] |
| Tech savviness | [Low / Medium / High. How comfortable are they evaluating technical products?] |
Goals and Priorities
Primary goals (what gets them promoted).
- [Goal 1: The business outcome their boss measures them on]
- [Goal 2: The operational metric they track weekly]
- [Goal 3: The strategic initiative they champion]
Current priorities this quarter.
- [Priority 1: What is taking most of their attention right now?]
- [Priority 2: What deadline or initiative is creating urgency?]
- [Priority 3: What problem has been festering that they want to fix?]
What success looks like to them.
- [Outcome 1: Specific, measurable result they want in 6-12 months]
- [Outcome 2: How they will demonstrate ROI to their leadership]
Buying Behavior
Typical buying process.
| Stage | Duration | Activities | People Involved |
|---|---|---|---|
| Problem recognition | [Timeframe] | [What triggers the search?] | [Just the buyer? Their team?] |
| Research | [Timeframe] | [Where do they look? What do they read?] | [Who helps evaluate?] |
| Shortlisting | [Timeframe] | [How many vendors? What criteria for the shortlist?] | [Who gets added?] |
| Evaluation | [Timeframe] | [Demos, trials, reference calls?] | [Who must sign off?] |
| Decision | [Timeframe] | [What is the final approval process?] | [Who has veto power?] |
Average deal cycle. [Total weeks/months from first touch to signed contract.]
Budget source. [Is this a new budget line, a reallocation, or a replacement of an existing tool?]
Purchase trigger. [What specific event moves them from "we should look into this" to "we need to buy this now"?]
Decision Criteria
Rank the criteria this buyer uses to evaluate solutions.
| Criterion | Weight (1-5) | What they look for | How they verify |
|---|---|---|---|
| [Criterion 1: e.g., Security/compliance] | [1-5] | [Specific evidence] | [SOC 2 report, security questionnaire] |
| [Criterion 2: e.g., Integration with existing stack] | [1-5] | [Specific evidence] | [Integration docs, technical demo] |
| [Criterion 3: e.g., Time to value] | [1-5] | [Specific evidence] | [Customer references, trial experience] |
| [Criterion 4: e.g., Pricing/TCO] | [1-5] | [Specific evidence] | [ROI calculator, pricing comparison] |
| [Criterion 5: e.g., Vendor stability] | [1-5] | [Specific evidence] | [Funding, customer count, Gartner] |
Table-stakes requirements. [What must be true for you to even make the shortlist? These are not differentiators. They are eliminators.]
- ☐ [Requirement 1]
- ☐ [Requirement 2]
- ☐ [Requirement 3]
Objections and Concerns
| Objection | Frequency | Root Cause | Effective Response |
|---|---|---|---|
| [Objection 1: e.g., "Too expensive"] | [Always / Often / Sometimes] | [What is really behind this?] | [What evidence or framing resolves it?] |
| [Objection 2: e.g., "We already have a tool for this"] | [Frequency] | [Root cause] | [Response] |
| [Objection 3: e.g., "My team won't adopt it"] | [Frequency] | [Root cause] | [Response] |
| [Objection 4: e.g., "We don't have bandwidth to implement"] | [Frequency] | [Root cause] | [Response] |
| [Objection 5: e.g., "I need to get buy-in from [other stakeholder]"] | [Frequency] | [Root cause] | [Response] |
The objection they think vs the objection they say. [Buyers often state a rational objection ("too expensive") when the real blocker is emotional ("I'm afraid this will fail and I'll look bad"). Note both.]
Information Sources
Where they research solutions.
- [Source 1: e.g., Peer recommendations, Slack communities]
- [Source 2: e.g., G2/Capterra reviews]
- [Source 3: e.g., Analyst reports (Gartner, Forrester)]
- [Source 4: e.g., Vendor websites and blog content]
- [Source 5: e.g., Conference talks and demos]
Who influences their decision.
| Influencer | Role | Type of Influence |
|---|---|---|
| [Person 1] | [Title/relationship] | [Technical validation / Budget approval / Daily user advocacy] |
| [Person 2] | [Title/relationship] | [Type of influence] |
| [Person 3] | [Title/relationship] | [Type of influence] |
Content they consume.
- [Newsletter/podcast 1]
- [Community/forum 1]
- [Publication/blog 1]
Messaging Framework
Positioning statement. [For [persona], who [key problem], [your product] is a [category] that [key benefit]. Unlike [alternatives], [your product] [primary differentiator].]
Value proposition (their language). [How would this persona describe the value to their boss in one sentence?]
Elevator pitch (30 seconds). [What would you say to this persona in an elevator?]
Email subject lines that work.
- [Subject 1: Problem-focused]
- [Subject 2: Outcome-focused]
- [Subject 3: Peer proof-focused]
Words and phrases that resonate.
- [Phrase 1]
- [Phrase 2]
- [Phrase 3]
Words and phrases to avoid.
- [Phrase 1: Why it does not work with this persona]
- [Phrase 2: Why it does not work]
Filled Example: VP of Engineering Evaluating an Observability Platform
Persona Overview (Filled)
| Field | Details |
|---|---|
| Persona name | VP Vanessa |
| Job title(s) | VP of Engineering, SVP of Engineering, Head of Engineering |
| Company size | 200-1000 employees, $20M-$200M ARR |
| Industry | B2B SaaS, FinTech, HealthTech |
| Reports to | CTO or CEO |
| Team size | 30-80 engineers across 6-12 squads |
| Budget authority | $200K-$500K annually for tooling without board approval |
| Tech savviness | High. Former senior engineer, still reads technical RFCs. |
Goals and Priorities (Filled)
Primary goals.
- Ship product roadmap on time with high quality (measured by sprint velocity and incident rate)
- Reduce mean time to resolution (MTTR) for production incidents from 45 minutes to under 15 minutes
- Retain senior engineers by reducing on-call burnout and improving developer experience
Current priorities this quarter.
- Migrating from a legacy monolith to microservices, which tripled the number of services to monitor
- Reducing cloud infrastructure costs by 20% per CTO mandate
- Hiring 12 engineers across 3 new squads
What success looks like.
- MTTR under 15 minutes, with 80% of incidents auto-detected before customer impact
- Engineering team rates observability tooling satisfaction at 4+ out of 5 in the quarterly developer experience survey
Buying Behavior (Filled)
| Stage | Duration | Activities | People Involved |
|---|---|---|---|
| Problem recognition | 1-2 months | Incident post-mortems reveal tooling gaps. MTTR trend is flat or worsening. | VP Eng, SRE Lead |
| Research | 2-3 weeks | Reads peer reviews on G2, asks in CTO Slack communities, reviews Gartner MQ | VP Eng, SRE Lead, 1-2 Staff Engineers |
| Shortlisting | 1-2 weeks | Narrows to 3 vendors based on integration support, pricing model, and peer references | VP Eng, SRE Lead |
| Evaluation | 3-4 weeks | 2-week POC with one squad, technical deep-dive with SRE team, security review | VP Eng, SRE Lead, InfoSec, 1 Squad |
| Decision | 2-3 weeks | ROI business case for CTO, contract negotiation, annual commitment | VP Eng, CTO, Finance |
Average deal cycle. 8-12 weeks.
Budget source. Reallocation from existing Datadog/New Relic budget plus incremental for microservices monitoring needs.
Purchase trigger. A P1 incident that took over 2 hours to resolve because the team could not trace requests across 4 microservices. The post-mortem explicitly called out tooling gaps.
Decision Criteria (Filled)
| Criterion | Weight | What they look for | How they verify |
|---|---|---|---|
| Distributed tracing quality | 5 | Auto-instrumentation, trace-to-log correlation | 2-week POC with production traffic |
| Cost predictability | 5 | Per-host or flat pricing, not per-GB ingestion | Pricing calculator with their actual data volume |
| Integration with existing stack | 4 | Kubernetes, Terraform, PagerDuty, Slack | Integration docs + POC validation |
| Time to value | 4 | Under 2 hours to first useful dashboard | POC experience |
| SOC 2 Type II | 3 | Current certification | Audit report review |
Objections (Filled)
| Objection | Frequency | Root Cause | Effective Response |
|---|---|---|---|
| "Datadog works fine for most things" | Always | Habit + switching cost anxiety | "We integrate with Datadog. Start with distributed tracing gaps only. No rip-and-replace needed." |
| "My engineers will push back on another tool" | Often | Fear of adoption failure | Customer reference: "Stripe's SRE team adopted in 3 days with zero training." |
| "I can't justify the cost to my CTO" | Often | Needs ROI ammunition | "MTTR reduction from 45 to 12 min = $380K/year saved in engineering time. Here's the model." |
| "What if you get acquired or change pricing?" | Sometimes | Vendor risk, burned by past experience | "3-year pricing lock. Open-standard data export. You own your data." |
Common Mistakes to Avoid
- Confusing the buyer with the user. The VP who signs the contract and the engineer who uses the tool daily have different goals, objections, and decision criteria. Create separate personas for each. Use this template for the buyer and the user persona template for the daily user.
- Building personas from demographics alone. Job title, company size, and industry are starting points, not the persona. Two VPs of Engineering at similar companies can have completely different buying behaviors. Focus on goals, decision criteria, and objections rather than demographic attributes.
- Creating personas without talking to actual buyers. A buyer persona built on assumptions is fiction. Interview 5-10 recent buyers, including both wins and losses. Your sales team can introduce you to buyers who did not choose your product. Those conversations are the most valuable.
- Making the persona too generic. "Decision maker at a mid-market SaaS company" is not a persona. A useful persona is specific enough that your sales team says "I talked to exactly this person yesterday." Add details until recognition clicks.
- Never updating the persona. Buyer behavior changes. New competitors enter the market. Economic conditions shift priorities. Review and update quarterly, or whenever your win rate changes by more than 10 points.
When to Use a Buyer Persona vs Other Templates
This template focuses on the purchasing decision. Use it alongside other discovery templates for a complete picture:
- Buyer persona (this template). Who decides to purchase? What criteria, objections, and process do they follow?
- User persona. Who uses the product daily? What are their workflows, pain points, and satisfaction drivers?
- Empathy map. What does a specific user type say, think, do, and feel? Best for grounding a team in real user observations.
- Jobs-to-Be-Done canvas. What job is the user hiring the product to do? What forces drive or resist switching?
- Customer journey map. What is the end-to-end experience from awareness through renewal?
For B2B products, the minimum set is one buyer persona and one user persona. Add empathy maps and JTBD canvases as your research depth increases. Use the NPS Calculator to track whether your product is meeting both buyer and user expectations over time.
Key Takeaways
- Buyer personas profile the person who makes the purchase decision, not the daily user
- Build from real conversations with 5-10 recent buyers, including lost deals
- Focus on decision criteria, objections, and buying process rather than demographics alone
- Most B2B products need 1-3 buyer personas plus separate user personas
- Review and update quarterly, or whenever your win/loss patterns change
About This Template
Created by: Tim Adair
Last Updated: 3/5/2026
Version: 1.0.0
License: Free for personal and commercial use