"Does this advance our ability to get the customer to their desired state?"
Products don’t match people; they match problems.
If you want to build a great software product, making crucial decisions based around a series of personality traits won’t get you there. That’s because products don’t match people; they match problems.
Personas are a tool for sharing a common vision of a target user with everyone on a project. When everyone knows the sort of end users being targeted, it helps cut out some unnecessary debates.
A persona depicts what you need to know about a typical end user of your product to make informed design decisions.
Every sentence in a persona should have a design implication.
Personas work well when the user base can be broken down into different types of users with different needs.
So bad personas happen because: Insufficient or poor research has been done. Personas are the wrong tool for the job.
So when you’re thinking about competitors, it’s best to ignore product categories and instead ask yourself who else is fighting for that same job.
The attractiveness of the outcome of your product vs the other product. Your marketing should work to make the alternative outcome less attractive, or reposition your product so the outcome is no longer in conflict.
The point is, customers don’t experience your product in a vacuum. They experience it alongside every other product, service, and idea fighting for their attention. Some of these will compete with your brand and some will contradict it. Understanding all these forces helps you counter them with your marketing efforts.
What tool were you using before you bought <software>? Were you also involved in buying that?
What was is it like working in <department> for <company> back then?
Can you remember if anyone else was involved in the decision? What was their role in the company at that time?
Tell me about the <old solution>. Can you remember how well that was working? Was it just your department using it?
The push of what is happening currently:
The pull of a new solution:
The anxiety of what could happen:
The attachment to what you currently have:
Active looking usually stems from a moment of particular frustration the person has been through with the product.
Passive looking can be ongoing for weeks/months while the person is uncertain if the product is doing its job well enough.
Consideration set involves the time in which a person (or company) is looking at all the possible solutions for a job they want to fulfill through a product.
For software businesses, asking questions around the consideration set can help you uncover if there were situations where multiple people affected the purchasing decision:
Where did you first hear about the tool you picked?
Can you recall how you came to purchase the specific tool you did?
Once you figured out you wanted to buy a new solution, did you do much research to figure out which tool was right for your company?
Were you the only one who was looking for something else at that time?
When you were looking around, did you (or anyone else) try out any other tools? What were they?
How long did you look around before you clicked “buy” on the <tool's> website?
Creating a timeline of events helps bring the interviewee back through their purchase journey. We’ve discovered for software purchases, there are often multiple timelines at work.
Knowing who the other decision makers are will give you a broader picture of where you need to innovate, and how you can support jobs your product is getting dropped for.
Jobs-to-be-Done can be great for understanding why companies hire and fire products, and unearthing areas where you can innovate.
Emphasize why the existing way does not make sense, why it's safe to switch to your product, and why they don't need to worry about leaving the existing way behind. If you can solve all those things, you'll get customers to switch.
Marketing increases familiarity, reminds consumers your product exists, and spreads product news. But marketing also does another job: it defeats inertia.
Advertising lets you manipulate these four forces. Specifically you can:
Increase the push away: Show how bad their existing product really is.
Increase your product magnetism: Promote how well your product solves their problems.
Decrease the fear and uncertainty of change: Assure consumers switching is quick and easy.
Decrease their attachment to the status quo: Remove consumers irrational attachment to their current situation.
A large budget should define how well a problem is solved, never how many problems are tackled.
Your budget, whether time or money, should restrict but never define your scope.
Your product should stop when the next step: has well defined market leaders looking after it (e.g. Apple, Netflix, Expedia), and you don’t intend to compete. is done in lots of different ways by lots of different types of users (e.g. trying to process salaries in a time-tracking app would be difficult). involves different end-users than the previous steps (e.g. managers, accountants, etc). is an area you can’t deliver any value.
Making a product simple emphasizes removing all unnecessary complexity so every user can solve their problems as efficiently as possible. Making a simple product, however, is about scoping down and choosing the smallest subset of the workflow where your product delivers value. This minimum viable product approach runs the risk of being labelled a point solution, or worse, “a feature but not a product”.
While best in class personas focus on goals (what drive people’s behavior) as well as attributes, the reality is that most personas focus on attributes alone, even when goal driven.
Designing for motivation is far better than designing for attributes. It’s the key difference between personas and Jobs-to-be-Done. Personas look at roles and attributes. Jobs-to-be-Done looks at situations and motivations. Personas explain who people are and what people do. But they never fully explain why people do something. And why people do things is far more important.
People are experts in their problem, not the solution. However, it is more natural to suggest a solution in the form of a feature request. Describing a suggested solution is easier than describing a problem, but you need to go back to them with questions to really understand their problem.
When _____ ] [ I want to _____ ] [so I can _____ ]
‘When ____’ focuses on the situation
‘I want to ____’ focuses on the motivation
‘so I can ____’ focuses on the outcome.
Start with the high level job
Identify a smaller job which helps resolve the high level job
Observe how people solve the problem now (i.e what job they currently use)
Come up with a Job Story that investigates the causality, anxieties, and motivations of what they do now
Create a solution which resolves that Job Story
Designing successful products means observing how real people solve problems now, exploring the context of the situation they are in, and then understanding causality, anxieties, and motivations.
Layers to understanding the value of a product
The immediate layer relates to usefulness. What do you actually do with the thing?
The secondary layer relates to usability. What result comes from using it?
The tertiary layer relates to desirability. What’s different now that I’ve accomplished my goal?