How to ship your way to product market fit through small, stable, high-impact releases

There’s always more to build than we have time, money, or people for. Always. That’s just who we are. We see an idea and we are tempted to build it out to the end. We see the entire grandiose thing — mapping out scenarios, planning strategies for execution, and sometimes even getting lost in the process.

But our customers often have different expectations than we do. Years of start-up success and failure have led to hard-earned lessons from previous builders. One of them is how to calibrate our bets when building software.

And the first step in calibrating these bets is understanding what exactly you’re trying to build. The cardinal rule has always been: identify a problem, preferably something no one has thought of before — Peter Thiel calls them secrets. Then you speak to the people experiencing the problem — your customers to be — to understand what they need desperately. Then provide a solution that solves their problem so well that they’re willing to pay for it.

Yet, this is easier said than done. The deeper you dig into your customer’s needs, you’re likely to find a myriad of problems you could solve for them. All are dependent on one another, and it’s not possible to solve them all at once. So we arrive at the second rule: that we must ruthlessly prioritize what to build first.

Building a shared understanding through story mapping.

All happy product teams are alike; every unhappy product team is unhappy in its own way.

No idea lives without great execution. In software, product teams mostly default to using agile development methodologies to design and develop software. But agile development is not a very useful design tool. It is a way of thinking about product development that is design-friendly, which is a very good thing, but by itself, it won’t get you to a product users love.

We have seen good designs, well documented, given to devs who manage to kill the design in the implementation process. Yes, the functions are implemented, but the patient dies on the operating room table.

Story-mapping helps bridge this chasm.

Story mapping is a way to keep us focused on users and their experience, resulting in a better conversation, and ultimately a better product. It’s a simple map to help us work together with others and imagine the experience of using a product.

As you will see, it’s a handy way to dig deep into our customer’s needs. It also helps us prioritize small, strategic, high-impact product releases that provide value to our customers.

Why use story maps?

Good engineering or design is as much about framing a problem as solving it.

When people read written instructions, they interpret them differently.

Reading a shared document, as teams often do, doesn’t lead to shared understanding.

Shared understanding is when we both imagine what the other person is imagining and why.

If you’ve been involved in software development for a while, you don’t have to reach back far in your memory to recall a situation where two people believed they were in agreement on a feature they wanted to add to the software, but later found out that the way one imagined it was wildly different from the other.

I might have a feature idea in my head, and describe it to you in writing. But when you read the document you might imagine something different.

However, if we got together and talked, you can tell me what you think and I can ask questions. The talking goes better if we can externalize our thinking by drawing pictures or organizing our ideas using sticky notes.

If we give each other time to explain our thoughts with words and pictures, we get to see loopholes in our thinking. If one of our customers or users happens to be present, they are likely to introduce detail that we might have entirely missed or dismissed. It’s at this point that we realize we understood things differently.

It’s not that one person is right or wrong, but that we all see different and important aspects.
Through combining and refining our ideas, we end up with a common understanding that includes our best ideas. Externalizing ideas is important because we get to move them around. We evolve our shared understanding.

Example: A Short Story About My Morning Routine

Let’s illustrate the concept of a story map with something as simple as my morning routine on days when I have to go to an office.

First, I’ll wake up to turn off the alarm. Then I’ll sit for a bit to gather my senses. Sometimes I regrettably hop into Twitter to get a glimpse of what’s going on. Sometimes I download a playlist or podcast that I’ll listen to on my commute. Then I make my bed. Then I take a shower. After the shower, I dress up and proceed to have breakfast. Then I journal as I drink my coffee. Once I’m all set, I leave the house.

Each of the steps I take — from the time I wake up to when I leave the house has tiny details embedded into it.

For instance, taking a shower involves me stumbling into the bathroom, turning on the shower and adjusting it till the heat is just right, washing my hair, washing my body, and thinking of the day ahead of me as I rinse, dry off…you get the drift.

Now, with that in mind, here’s a better picture of my morning routine represented in a story map.

The cards in green represent my goals. I want to get cleaned up, have breakfast, journal, then get to work.

Then below that, in purple, are the tasks Imust complete to achieve those goals. They are the ‘backbone’ of my goals. I must get out of bed, take a shower, and get dressed to achieve my first goal, that is, to get cleaned up. Breakfast and journaling take a lesser number of steps. Leaving the house is even simpler.

Each of the tasks in purple is an activity I have to complete before you move on to something else. For instance, taking a shower. I don’t get halfway through the shower and think, “Man, this shower is taking too long. I’ll just grab a cup of coffee and finish this shower later.” I have to complete it before I move on to something else.

The major tasks, like taking a shower, are like a rock. If you take a big rock and hit it with a hammer, it’ll break down into a bunch of smaller ones.

The subtasks. The little rocks: These vary in many ways. You’ll often see subtle behavioral differences in the way people approach tasks. I know a person who sometimes makes whole meals for breakfast. I know a person who meditates or does yoga. I know a person who starts their day with a prayer. I know a person who doesn’t take anything at first but takes breakfast around 10 am. I know a person who’ll prepare everything the night before so they can as much sleep as they can.

Behaviour is our medium

If we’re to design a product that offers great value to our users, we have to understand what influences their thoughts and shapes their behavior.

Therefore, once we have the breadth of a story map in place, we have to dig deeper. We have to think, in detail, of how our users would accomplish a task. We stop at each user’s story and look for:

• Pains — The things that don’t work, parts people hate. What happens when things go wrong?
• Joy or rewards — Fun things, the things that make it worth doing. What would make it cool?
• Questions — Why do people do this? What are the specific things they’d do here? What alternatives do they have?
• Ideas — Things people could do, or that we could build that would take away the pain.

If we fill in those details, the result will be rich enough to create a vivid picture of a day in the life of our user.

Our understanding of the user’s behavior becomes the primary medium for the kind of interactions we add to our product. Sometimes even to the extreme, like the bottomless feed on Twitter or Facebook, designed to keep you locked in.

Or TikTok’s highly engaging and addictive design, which is backed by powerful artificial intelligence along with a seamless UI that bleeds screens into one another. The content plays through without the user having to do anything but swipe. But so much for that.

The same applies to the morning routine. For instance, there are people who start their day with some exercise, such as a morning run. So if we’re to automate a morning routine that prioritizes a fitness habit, then we have to consider exercise as one of the focal points we have to design for. That may range from simple features like a fitness habit tracker, to a complex Strava-like application.

Planning to build less

Every time you create a story map, it’s likely you’ll end up with way too much scope.

As you fill in details in your story map, you end up finding holes in your narrative that you have to address. This is the stuff that you’d have missed, and it’d have come to bite you later on. For instance, morning routines sometimes involve some kind of medical routine, such as checking your BP for people with hypertension.

Consider what would happen if you didn’t unearth these loopholes early. You’d find new stuff later on — after you’d already estimated delivery time and committed to your delivery date. You’ll call that stuff scope creep. But when you build a story map, the scope doesn’t creep, there’s little ‘technical debt’ and you get to grow your understanding of the problem you’re trying to solve.

Once you have mapped everything, you can then prioritize what to build by slicing out a release roadmap.

Minimize output, and maximize outcome and impact.

“There is no higher and simpler law of strategy than that of keeping one’s forces concentrated.” — On War, Carl von Clausewitz.

The best way to decide what to build or design first is to concentrate on what brings superior strategic outcomes.

We don’t measure an outcome by the number of features delivered or what people have the capability to do at the moment. We measure what people actually do differently to reach their goals as a consequence of what we’ve built, and most importantly, whether we’ve made their lives better.

Outcomes are what happens when the ‘thing’ you’re working on gets out of the door. A series of good outcomes lead to the long-term stuff that people call ‘impact’.

Your business has lots of possible users and customers it could focus on, based on your business strategy. The trick is that you’ve got to pay close attention to the people whose problems you are trying to solve.

When you have conversations about a feature, you’ll talk about who it’s for, what they do now, and how things will change for them later. That positive change later is really why they’d want it.
We slice out tasks that help you reach a specific outcome — Imagine a line slicing through the middle of the story map from left to right — like a belt. We move all the tasks below that line if we wouldn’t do them to reach a predefined outcome.

For instance, in our morning routine. Suppose I wanted to get out of the door as soon as possible. So I have to slice to identify the most essential tasks that need to happen for me to get out of the doors in a few minutes, as pictured below.

Notice how the routine changed when I had to get out as soon as possible. I just turned off my alarm. Got out of bed. Took a quick shower. Got dressed. Skipped breakfast, and left the house. I have sliced out a ‘release’ and moved the tasks that I thought weren’t essential to a later phase.
Sometimes you might even skip the shower, depending on what’s at stake. Or you may not have turned off the alarm, because maybe you didn’t even set one.

This might not be as complex as building software, but you can easily use the same model to create small, strategic product releases that still deliver more value to your customers, that don’t take much time to build.

If you get the game right, you will realize that your job is not to build more, it’s to build less. You do that using the right techniques. We want to build something small, get it in the hands of our users, learn from it, and repeat. We want to get out of the door in as little time as possible — to use our morning routine analogy. That’s how we build value over time.

As with the time value of money, the time value of shipping is a simple idea: delivering customer value now is worth more than delivering value later.

If you choose to deliver value later, you need to account for inflation in user expectations, and your eventual product needs to be much better to compensate.

Brandon Chu, On The Time Value of Shipping.

We use story mapping so that our design retains its narrative structure. So it doesn’t die on the operating table. This structure can also be deconstructed for effective implementation — but the designer’s story, which is a formalized version of the user’s story, remains intact throughout the development.

Example: Life at a tea collection center

I worked on a product that helps automate the logistics of tea production, from harvest to processing, to auctioning the tea, and eventually remitting payments to farmers.

There are several major stages in the tea production chain in Kenya, as shown below:

All happen sequentially, from left to right.

If you were to automate the entire chain, there’s a lot you could do. It’s foolhardy to think you could do it all at once.

So, our first release was one of the most sensitive parts in the chain — the delivery of green leaf, i.e the moment it changes hands from the farmer to the tea company.

A farmer usually picks the green leaf, then delivers it in baskets to designated tea buying centers located across their region. At the collection center, the green leaf is then collected then transported to the factory by the use of trucks specifically designed for the task.

The farmer is received by a collection clerk once they arrive at the center. The green leaf is placed on a weighing scale and recorded to the farmer’s account by the clerk. Remember a farmer may have even as many as five loads at a time since tea has to be transported in the well-aerated sisal baskets to prevent fermentation.

The farmer then receives a receipt for the proceeds they’ve delivered. The clerk serves several farmers this way until all deliveries are handled.

So at every center, the field clerk collects the amount of tea their truck can hold, then makes a trip to the factory, empties the truck, and goes back to the collection center to serve more farmers, or to the next collection center in their route.

In collaboration with the company, we thought there were several problems we could solve to create a more efficient delivery process:

• The manual process for recording tea proceeds in tea buying centers creates delay and causes errors of omission. Sometimes eroding trust between the company and the farmers.
• Rigid processes that only allow a farmer to sell green leaves through only one collection center.
• Lack of transparency in recording farmer proceeds. Farmers have no way of checking the field clerk’s forwarded record, versus the manual records at their disposal.

Personas

From further interviews with customers and clerks, we profiled their needs and behavior under two personas, as follows:

Based on our understanding of their behavior, and of the inefficiencies in the current process, we came up with the following solution for automating delivery at collection centers:

• A BlueTooth-enabled weighing device that would be paired to an android mobile application used by the collection clerk. This would eliminate the need for paper-based recording, as the weighing device would transmit weights directly to the mobile application (see prototype below). Farmers would also receive a transaction message as confirmation for deliveries they’ve made.
• A USSD shortcode, or web portal where farmers can routinely request for statements, either about the auction rates, or their amounts owed.
• A web application for managers to get a real-time view of incoming collection data, from all centers on a given day. And a dashboard to generate performance insights, based on the collected data.

The delivery story map

We mapped the user journey for an MVP as follows:

The mobile UI would be something like this:

Here’s a link to the interactive prototype.

Notice how we split the storyboard into MVP and a later release at the bottom. Our goal was to first build as little as possible, get it working, and learn from it.

At Adept, we believe a constant stream of smaller releases provides a much more stable solution for our users.

Notes:

1. User story Mapping: Discover the Whole Story, Build the right product.
2. Case Study: Kiriti (useadept.com)
3. The Time Value of Shipping.

Originally published at https://useadept.com.