Starting from Users? Wrong. Start with a problem. Here’s why.

If you ask any developer, marketer, or designer today where to start from developing a product, 90% of them will tell you to define your target audience and user persona first.

This is somewhat a traditional approach. While it’s not (completely) wrong, in the era of the ever-growing importance of UX and product-market fit, we can’t rely anymore on documents about fictional people and assumptions made behind closed doors.

The landscape of human interactions is constantly changing and evolving. That ideal user, Jane Doe, whose imagined characteristics you’ve documented during a whiteboard session might not be valid tomorrow.

Perhaps that Jane Doe is just our perfect representation (and strong generalization) of a user, while the reality proves to be different.

So what do we do? We say – Stop relying too much on users and start with problems. This article will tell you exactly why and help you implement the same thinking into your company.

What are user personas and why are they important in the first place

User personas have been used since the 90s. They are a holy grail of human-centered business. 

Many companies started products & services development with only their business perspective in mind… and then went bust after a year trying to persuade someone to even try a product or a service.

User personas have changed that. They represent a description of people for who we are making our product. 

A good user persona document outlines your ideal user’s motivations, beliefs, values, but also characteristics like demographics, age, income, gender… Which in the end helps you understand the people who should be using the product and the overall market.

With that one ideal user in mind – you can streamline your production and adapt. Without it, you’re shooting in the dark.

However, having a user persona is not a silver bullet for your efforts.

User personas can fail

Even though they’ve been refined many times over and even though you’ve had multiple sessions to define them and did your homework. 

There are multiple reasons why personas fail.

• First of all, conventional user profiles (personas) are made in silos, then forwarded to other departments – so they don’t reflect reality.

• Second, vaguely defined target users become generalized, so that in the end, you know there’s a target somewhere, but don’t know where to point the arrow.

• Third, they tend to leave out the problem people hire you for and focus too much on the psychological and demographic characteristics.

When it comes to problems, that’s where the Jobs to Be Done framework steps in.

Personas vs. Jobs-to-Be-Done (JTBD)

User personas were always the core of the user-centric design. But as we’ve shown, vague characteristics about our users often aren’t enough. That’s not the case with JTBD.

Here’s how Tomy Ulwick, a pioneer of JTBD, defines it:

In his, now famous, article on Medium, he says – 

“When using this framework, a complete set of need statements can be captured in days — rather than months — and the statements themselves are valid for years — rather than quickly becoming obsolete.”

The statements that you define in your User Persona document, like “She likes to run at 6 AM and reads The Economist.” truly limit your thinking.

This is not to say that knowing users’ habits will hurt your product development. No, it will actually improve it, but it’s not enough.

Maybe we should start asking more questions about the needs of our users. 

What’s that one job for that one problem people hired us for?

Starting from problems allows you to look at things from many perspectives, anchored in reality

When we start with personas, we start from our perspective and our perceptions. Starting from problems requires that we start from people directly.

Starting from problems requires that you actually ask people what they need.

When you ask people something along the lines of:

What was happening in your life/business that led you to consider using this product/service?

You start with the problem. You get to hear that struggle and analyze it from many perspectives.

• How the problem started
• When did the user start considering us
• How do we really make their lives better

You’re not confined to the limits of a document that describes a perfect John Doe. You’re sketching a real person.

Walk a mile in my shoes: Investigating a problem first puts you in your users’ position

With user representations made behind closed doors, you can’t build empathy with real people. You have to go out there and ask questions.

You have to write down the answers. Analyze them. Try to emulate that problem and feel for yourself.

• Are they struggling because of hectic circumstances?
• Will this really solve that security issue they’ve been having for years?
• Can we impact their daily habits (and should we)?

You can’t know that unless you talk with people.

How to find the core problem of your users

We must agree on the fact that finding the core problem isn’t an easy task. It requires empathy, but also keen users that would be happy to share opinions with us.

Whether you’re making a new product or improving the old one, here are the evergreen methods to find the problem:

• Start with surveys and provide incentives for filling them in (like discounts, coupons, vouchers)
• Host live webinars and demos, engage with people in the chat
• Do traditional market research with focus groups
• Connect with communities and have meetings with potential users
• Collect regular feedback during sprints, implement – then collect feedback again

Combine your problem investigation with your user persona

In the end, all it matters is that you make your version of a successful problem-mining process. Don’t throw your user persona in a trash bin now. Use JTBD to enhance it.

Next to demographics and habits – add a few statements on core problems. Eventually, you’ll see how your development & design process becomes clear. 

The only ultimate tactic for making products people love is to ask. A lot.