- Growth
- Growth leadership
- ICP and personas
- Buyer persona
Wiki
Buyer persona
On this page
Three personas for a project management tool
Persona 1: 'PM Priya' (Project Manager). Role: Managing 5-10 projects simultaneously. Pain: Stakeholders asking for status updates every day. Goal: Single view of all projects and automatic status reporting. Budget: influences decision but doesn't approve. Persona 2: 'Engineer Eric' (Engineering Manager). Role: Managing team and projects. Pain: Context switching between tools breaks focus. Goal: Minimal tool ecosystem. Budget: Technical influencer, cares about API and integration. Persona 3: 'Finance Felix' (VP Finance). Role: Cost and capacity planning. Pain: No visibility into which projects are over budget. Goal: Financial analytics and capacity forecasting. Budget: approves purchases over £10K. Each persona got different messaging in campaigns.
Using personas to guide product roadmap
A data analytics platform identified three personas: 'analyst Aaron' (wants flexibility), 'executive Eva' (wants dashboards), and 'manager Marcus' (wants simplicity). Quarterly roadmap planning used personas to allocate engineering: 40% of roadmap to improvements Aaron cared about (API, customisation), 30% to Eva's needs (preset reports, presentation mode), 30% to Marcus (templates, one-click setup). This allocation reflected customer revenue distribution, maximising value delivered to the personas that matter most.
Why it matters
Focuses marketing messaging
Without personas, marketing messages try to appeal to everyone and end up persuading no one. With personas, you can create targeted campaigns: one message for CFOs (focused on ROI and risk mitigation), another for engineers (focused on technical capability and integration), another for operations (focused on efficiency and scalability). This focus improves conversion.
Aligns sales and marketing
Sales and marketing often disagree about who the 'real' decision-maker is. Personas settle this by mapping out all the decision-makers and influencers in a typical deal. It clarifies who marketing should target in initial campaigns and who sales needs to engage later in the cycle.
Guides product development
Product teams use personas to prioritise features. If 'VP of operations' is your most important persona and she cares deeply about mobile access, build mobile first. If 'engineering manager' cares most about API reliability, make API robustness a priority. Personas prevent building features no one asked for.
A buyer persona is a short, semi-fictional profile of the specific person you're trying to sell to. It captures their job title, the size of company they work at, what they're measured on, what keeps them up at night, and how they actually decide to buy. One product often has three or four: an 'engineering manager', a 'VP of operations', a 'CFO'. Each one worries about different things and is persuaded by different language, so you write to each one differently.
Personas matter because they line up your whole go-to-market. Marketing writes messages that land. Sales tailors the pitch. Product builds the features these people actually asked for. Skip them and you build a generic thing for a generic person and persuade no one.
The usual mistake is building personas from demographics alone ('mid-market marketing director') without understanding the real problem. A marketing director at a fintech lives under completely different pressure than one at a manufacturer. Good personas come from research: customer interviews, sales feedback, and behaviour data. They describe not just who someone is, but why they buy and what they're trying to get done.
Three ways this shows up in practice
Say you're running a sales team in Folk. Instead of one undifferentiated contact list, you tag each company by the persona who actually signs off, 'engineering manager' versus 'CFO', so your pipeline views and follow-ups already speak to the right person's concerns rather than a generic blast.
Say you're recording every discovery call in Fireflies.ai. This is where personas get built honestly: after ten or fifteen interviews you read back the transcripts and the patterns jump out, the same pains, the same buying triggers, the same objections by role. That's research, not guesswork, and it's what stops a persona being a made-up cartoon.
Say you keep your personas in Notion. A persona only earns its keep if the team uses it, so it lives somewhere everyone reads, linked into the sales playbook and the roadmap doc, and you revise it each quarter as you learn more. An outdated persona nobody opens is worse than none at all.
How to apply
Conduct customer interviews
Talk to 10-15 customers across different segments. Ask about their role, challenges, goals, and how they evaluate solutions. Ask what their typical day looks like. Ask about their budget constraints. Record patterns in responses; people in the same role often share similar concerns.
Segment by job title and company type
Usually, you'll find 3-5 distinct personas based on job title and company size. A director at a 50-person startup has different needs than a director at 1,000-person enterprise. Create separate personas for each segment.
Document decision-making patterns
Personas should describe not just the person but how they buy. Does a 'VP of engineering' typically choose tools alone or with input from the team? Does budget come from operating expense or capital budget? Does purchasing need approval from procurement? These details shape your sales strategy.
Share and refine with your team
Personas are only useful if your team uses them. Share in Slack, print them, put them in the sales playbook, reference them in strategy meetings. Refine them quarterly as you learn more. Outdated personas are worse than no personas.