In this presentation we explore what personas are, why we build them, and the importance of identifying the right personas to build. We then take you through a real life example of how we used primary market research techniques to build a persona for an enterprise software product.

1. Building Personas
Elaine Chen
January 2015
© 2015 ConceptSpring

2. Before we begin

3. 2 classes of research
• Problem Research
– To understand who the buyers and users are
– To understand the problem statement
– To understand the context in which the product will be
used
– To understand use cases
• Solution Research
– To understand the usability and utility of the product
– To help prioritize the feature set
– To understand pricing elasticity
– To understand customer satisfaction

4. Common Methodologies
• Contextural interview
• Observation / shadowing
• Immersion
• Longitudinal diary study
• Photo essay
• Usability benchmark
• Focus groups
• … etc
• Qualitative (<30 samples) • Quantitative (>1000 samples)
• Surveys
– General interest
– Conjoint analysis
– Pricing studies
• Monadic
• Multiple monadic
• Van Westendorp
• … etc
– Customer satisfaction: NPS, P/M
fit
• Web testing
– A/B split, Multivariate
– Web analytics
– … etcPersonas

5. What is a persona?

6. Image credit: http://www.slideshare.net/LeanStartupConf/jon-irwin-rocktheinterview-slides

8. Why make personas?

12. 12

13. A persona helps align your team
“Personas are the personification of what
you learn by truly and deeply listening to
your market.”
– Jennifer Doctor, Managing Partner, Harborlight
Partners; Author, “Flat Stanley Doesn’t Live Here”

14. Sausage making Step 1:
Enumerate personas

15. Who is in your Decision Making
Unit (DMU)?
• Economic Buyer
• Champion
• Influencers
• Veto powers
• Users

16. Who is in your Decision Making
Unit (DMU)?
• Economic Buyer
• Champion
• Influencers
• Veto powers
• Users

17. Who is in your Decision Making
Unit (DMU)?
• Economic Buyer
• Champion
• Influencers
• Veto powers
• Users

18. Sausage making 2: Making
each persona

19. Get out of the building

20. Example: Enterprise Source
Code Management
• Company X:
– Startup providing enterprise grade source code
management and collaboration tools
• Product:
– Secure, open, productive, integrated source code
management system that supports Git, Mercurial,
SVN and integrates with standard tools
• Target market:
– Enterprise software companies at scale (1000+
employees, $500M+ annual revenue)

21. Product positioningEaseofmigration
LowHigh
Low High
Enterprise readiness: Comprehensive SCM management tools + ALM coverage
Awesome product
from Company X

22. Decision making unit hypothesis
The Economic
buyer:
Jim, 48, the
software exec
The Champion /
Key Influencer:
Bob, 34, the
DevOps guru
The Influencer /
User 1:
Dan, 23, the cool
kid
The Influencer /
User 2:
Vince, 52, the
veteran
Jim manages about
300 people. At his level
he isn’t close to the
technical details
anymore. He controls
the budget and relies
on Bob to recommend
the right tools for the
team to use.
Bob is head of a small
DevOps team with 6
engineers servicing
300 SCM users. He
does the due diligence
and recommends
solutions to Jim for
approval.
Dan is a 23 year old
computer science
major who just
graduated from a top
school. He is an open
source nut and
strongly believes all
dev tools should be
free and open source.
Vince has 30+ years of
experience working for
companies from
startup to IBM in scale.
He believes there’s no
free lunch – you must
pay for the best tools
(i.e. the one he used
before

23. First focus: Jim, the economic buyer
The Economic
buyer:
Jim, 48, the
software exec
The Champion /
Key Influencer:
Bob, 34, the
DevOps guru
The Influencer /
User 1:
Dan, 23, the cool
kid
The Influencer /
User 2:
Vince, 52, the
veteran
Jim manages about
300 people. At his level
he isn’t close to the
technical details
anymore. He controls
the budget and relies
on Bob to recommend
the right tools for the
team to use.
Bob is head of a small
DevOps team with 6
engineers servicing
300 SCM users. He
does the due diligence
and recommends
solutions to Jim for
approval.
Dan is a 23 year old
computer science
major who just
graduated from a top
school. He is an open
source nut and
strongly believes all
dev tools should be
free and open source.
Vince has 30+ years of
experience working for
companies from
startup to IBM in scale.
He believes there’s no
free lunch – you must
pay for the best tools
(i.e. the one he used
before

24. Step 1: Develop the research protocol
• Goals / objectives
• Methodology
• Recruitment questionnaire
• Recruitment strategy
• Paperwork / incentives (NDA? Photo/Video release
form? Check?)
• Equipment required (AV, laptop, etc)
• Researchers name list and roles
• Discussion guide

25. Step 2: Develop a hypothetical persona
2013 Revenue:
$4.2B
Headcount:
362,000
BU Headcount:
700
Jim’s team
300
Behaviors
• Reports to the BU General Manager
• Manages the software organization
(all aspects) and the associated
budget
• Technically the best guy on staff
• Makes all key decisions on tools and
systems for developers in his
business unit
Demographics
• 48 years old
• Ph.D. in Computer Science from MIT
• Has been managing teams for 15
years. Hands on. Still writes code
every day.
• Married with high school children
• Drives a Toyota Prius
• Carries a Samsung Note
Needs and goals
• He wants his team to turn out the very
best code and is willing to pay a
premium price for the best tools to
support himself and his people

26. Step 3. Develop Recruitment Guidelines
• Company characteristics:
– Fortune 500 or similar scale companies with 450+ employees
– At least 100 employees in engineering organizations
– Prefer US or Europe based companies (ok to have satellite offices
elsewhere as long as HQ is in the US or Europe)
• Subject characteristics:
– Must have: Full time employee working as a software developer,
software development manager, or a devOps / tools and release
engineer or engineering manager within a software organization
– Nice to have: Prefer managers who are well versed in the politics and
process of decision making within the large organization

27. Step 4: Develop a discussion guide

28. Step 5: Recruit subjects
• Free
– Your personal network
– MIT alumni network
– Your prospects
– Your current customers
– … etc
• Paid
– Research agencies e.g. Fieldwork Boston
– Lists e.g. momcentral
– … etc

29. Step 6. Run the actual interviews

30. Interview do’s and don’ts
Do use these phrases:
• Tell me the story of…
• Tell me about the last
time…
• Why?
• Why not?
• Say more about…
• Tell me more…
Do talk much, much less
than your interviewee
Don’t ever do this:
• Ask yes/no or multiple
choice q’s (e.g. “on a
scale of 1-5”…)
• Read the DG to the
interviewee
The DG helps
organize your
thoughts.
Internalize it,
then go in
with open
ended q’s.

31. Step 7: Crunch the data

32. If things go well, convergence is rapid
In 5 interviews:
subjects started self-
organizing
In 10 interviews:
Top persona
hypotheses emerge
In 20 interviews:
personas fully
validated

33. Step 8: Find patterns, build personas
2013 Revenue:
$514M
Headcount:
1000-2000
BU Headcount:
N/A – 1 BU
Jim’s team
200
Behaviors
• Reports to the BU General Manager
• Manages the software organization (all
aspects) and the associated budget
• Primarily concerned with strategy, leadership,
management – high level
• Relies on direct reports (dev, devOps, SQA
managers) to recommend the right technical
decisions
Demographics
• 48 years old
• Bachelor’s in Electrical Engineering
degree from UNY Stony Brooks
• Has been managing teams for 25 years;
last wrote production code 10 years ago
• Married with high school children
• Drives a Mercedes SUV
• Mac, iPhone 5, iPad Mini, W8 for work
Needs and goals
• Above all: his goal is to meet or exceed revenue
goals for his business unit by releasing software
on time and as planned with marketing and sales
• He wants to keep the staff happy and to attract
hot new talent to join his team
• He needs to conserve budget – fixed $/y to spend
on tools, R&D – zero sums game

34. Be open minded! (Orange = new news)
2013 Revenue:
$514M
Headcount:
1000-2000
BU Headcount:
N/A – 1 BU
Jim’s team
200
Behaviors
• Reports to the BU General Manager
• Manages the software organization (all
aspects) and the associated budget
• Primarily concerned with strategy, leadership,
management – high level
• Relies on direct reports (dev, devOps, SQA
managers) to recommend the right technical
decisions
Demographics
• 48 years old
• Bachelor’s in Electrical Engineering
degree from UNY Stony Brooks
• Has been managing teams for 25 years;
last wrote production code 10 years ago
• Married with high school children
• Drives a Mercedes SUV
• Mac, iPhone 5, iPad Mini, W8 for work
Needs and goals
• Above all: his goal is to meet or exceed revenue
goals for his business unit by releasing software
on time and as planned with marketing and sales
• He wants to keep the staff happy and to attract
hot new talent to join his team
• He needs to conserve budget – fixed $/y to spend
on tools, R&D – zero sums game

35. Hypotheses that were invalidated
• Internal team structure – who’s who
• Who decides what
• Who does the core homework
• Whether it is possible to do 1 sale to a 100,000 people
company
• Core pain points
• Calls to action / timing for action
• Awareness of / readiness to adopt industry best
practices
• Magnitude of internal friction
• … etc

36. Taking Action

37. Refine Positioning Statement
• For [target customer]
• Who wants/needs [a compelling reason to buy]
• The [product name] is a [product category]
• That provides [these key benefits].
• Unlike [the main competitor],
• The [product name] [provides these key differentiation
points].

38. Drive Product Strategy
• Redefine Unique Value Proposition (UVP) to meet
needs/wants of economic buyer.
• For Company X:
– Before: UVP is product centric and misses the biggest
pain: migration friction.
• “Manage your source code in the most secure and
productive way in Git or Mercurial”
– After: 2 UVPs tailored to needs of identified economic
buyer and their team
• “Painless Migration to Git”
• “Multiple System Support”
• Redefine product roadmap / priorities

39. Building Personas - reprise
• B2C is simple: user = buyer (except in gifting
scenarios)
• Many more personas for B2B. Make sure you cover
them all.
• Use qualitative techniques
• Recruit carefully
• Ask open ended questions
• Be a good listener
• Not a sales call – talk about them, not you
• 20 interviews to a good persona
• B2B is complicated – do what you can with what
access you have

40. Get out of the building!

41. Thank you
@chenelaine blog.conceptspring.com