The user you’re building for doesn’t exist

In this week’s email we’ll be covering:

• The user you’re building for doesn’t exist: When creating user stories we tend to rely on flawed assumptions that lead to worse software.
• If you build it they won’t come: How to leverage a little-known advertising hack to reverse engineer software people will want to use.

The user you’re building for doesn’t exist

Most of us are familiar with user stories that follow this format:

As a commenter (persona), I want to see all the comments on a post (action), so that I can reply to them (outcome).

Despite how much we rely on them, it’s easy to forget that user stories are imaginary. They’re based on assumptions about a hypothetical user persona and set of actions and don’t usually give any context.

If we look at the previous story closely we’ll notice that:

• It isn’t clear what makes a user a commenter. Anyone reading the story will have a different idea of what a commenter is.
• Whether someone is a commenter doesn’t impact the action (seeing all the comments) they take.
• We assume that the action (seeing all the comments) will lead to the outcome we want (replying). Is that the best solution though?

Stories like this force us to build a specific set of functionality for an imaginary user that no one agrees on.

Then late in the project we usually realize we’re building the wrong thing or for the wrong user.

This leads to wasted product and engineering effort and eventually worse software that no one uses.

Instead of taking user stories at face value along with all their assumptions, we can shift to a better format that focuses on the situation, motivation, and context we’re trying to solve.

Here’s a user story template that does that:

When <situation happens>, I want to <motivation>, so I can <outcome with context>.

To implement it use the following process:

1. Remove the persona and see if you lose anything: I want to see all the comments on a post so that I can reply to them.
2. Focus on the situation (when) that led to the action: When I’ve finished reading a post I like, I want to see all the comments on a post so that I can reply to them.
3. Include the motivation (why) that drives the action: When I’ve finished reading a post I like, I want to engage with the most relevant comments, so that I can reply to them.
4. Add context instead of implementation details to the outcome: When I’ve finished reading a post I like, I want to engage with the most relevant comments, so that I can join the conversation.

Compare the original version of the story with the final revised version.

The revised version is more useful because it gives context, gives shared understanding, yet isn’t prescriptive on what to build.

If you build it they will not come

Thanks to modern tech culture we often take it for granted that once we build something it will be a hit and “change the world”.

But if you build it they will not come.

How do we end up building something no one uses?

• By only getting user feedback that validates our current assumptions.
• By overestimating how much of our user’s pain our software solves.
• By forgetting that the pain we solve is experienced only by a small portion of our potential users at any given time.
• By pretending that our solution is the only one that exists and the obvious choice for users.

More often than not, we deal with it by adding more features in the hopes it’ll be enough, we pivot to building something completely different, or we give up altogether.

In the end, we’re left with little to no traction, a meandering product roadmap, unused code paths, piles of unnecessary tech debt, and a lack of confidence.

Building something is the easy part. Getting someone to use it is much harder.

Instead of expecting users to come to us, we can meet them at their current awareness level.

Enter the 5 Levels of Customer Awareness.  It’s usually used in marketing but it can help you reverse engineer what to build for your users.

The 5 levels are:

• Unaware: They don’t know the problem even exists. Create something to help them discover the problem and understand how painful it is.
• Problem Aware: They know the problem is an issue but don’t know to solve it. Create something that provides information on how they could solve the problem.
• Solution Aware: They know that the solutions exist to a problem but not about your specific solution. Create something that shows how your solution compares to the alternative.
• Product Aware: They know your solution can solve their problem but don’t yet trust you. Create something that shows the results your solution will provide.
• Most Aware: They want to use your solution but don’t know how it compares to the alternative (effort/cost). Create something that shows how valuable your solution is.

I say “create” instead of “build software or a feature” on purpose. Don’t rush to build something new when clearer onboarding, a how-to guide, an example, a walkthrough video, or a conversation will help you meet your users where they are.

If you look at most software that’s failed, there’s a good chance the people that built it assumed their users were at the “Most aware” level. Don’t make that same mistake – meet your users where they are.