The user you're building for doesn't exist

???? Hey there and thanks for reading. Each week I share tips and tactics that help software developers and teams create more successful software projects. Get the latest issue of the Build It Better newsletter in your inbox by subscribing today.

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.

What do the best software developers and teams have in common?

They know how to make the right choices so they can ship successful software.

Right now you're reading a past issue of the?Build It Better?newsletter.

I release a NEW issue like this every Wednesday.

Join other developers from companies like Dropbox, Spotify, MongoDb, Capital One, and Automattic who read Build It Better weekly.

Subscribe today to get the latest issue first.

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...

To be continued...

You can find the rest of this issue on the Build It Better website.

Want the latest issues delivered to your inbox every Wednesday? Subscribe to the Build It Better newsletter.?