The Messy Process Of Building Things People Want

When deciding what to make, most people overemphasize delivery and underemphasize discovery. The goals of delivery is to get things out the door as fast as possible. What is the goal of discovery?

The goal of discovery is to avoid spending years working on a product, only to learn at the end that nobody wants it.

A lot of the frustration around this culminated in 2001 with the release of The Agile Manifesto. Agile encourages us to do two things.

  1. Develop in smaller batch sizes. Write code for weeks, not months.
  2. Show it to people and see if you are on the right track.

This was a good step forward.

Around the same time, we started seeing the rise of user experience design and design thinking. We started talking about building empathy for our customers.

Then came the Lean Startup, informed by Steve Blank’s work, and we shifted from asking “Are we building something that customers can use?”, and started to ask “Are we building solutions that our customers want?”

Enter the Jobs-to-be-Done framework. Thank you Clayton Christensen and Anthony Ulwick. And so we moved from focusing on solutions to starting to ask, “Are we solving important problems?”

This evolution is not stopping. We keep asking better and better questions. Now design Sprints and OKRs have joined the party. We started getting too obsessed with features, and OKRs help us stay focused on what outcomes we are creating for our customers and for our businesses.

We have all these tools and frameworks because all of us are pushing to get better. The question is how do we know what to use when?

Well, if the point is to avoid spending years working on a product, only to learn at the end that nobody wants it, then our goal is to learn fast.

As we answer better and better questions earlier in our product discovery process, we are better able to answer the ultimate question, “Are we driving toward the desired outcome?”

As product teams, our goal is to increase engagement, to reduce churn, to increase revenue, to increase customer satisfaction, to make my NPS score go up. It’s not to just build feature A, B, and C.

Our product discovery practices are shifting from a focus on output to a focus on outcomes.

To navigate through the messy land of product discovery, start by defining a clear desired outcome. How are we supposed to build a product that drives an outcome if we don’t know what that outcome is?

Don’t say things like, we are just trying to make the user experience better. How are you measuring that, how are we going to know when we’ve done that? OKRs are a qualitative objective, they force you to say how you will know if you’re making progress towards that objective, and they make you come up with a quantitative measure.

You need a quantitative measure because when we’re running experiments, we are going to evaluate our experiments based on that quantitative measure.

Okay, so first, step one. Define a really clear desired outcome. Next, discover opportunities that drive that desired outcome. How we frame the problem has a really big influence on the types and quality of solutions we can generate.

As product teams, “Our goal is to go increase engagement” and we start brainstorming solutions. We start generating solutions but have no way of evaluating solutions if we don’t know what problem we’re trying to solve.

Calling them “problems” encourages us to fix things, and sometimes things aren’t broken. “Opportunity” is a bit more inclusive.

So if my desired outcome is to increase engagement, I want to know two things. One, what stops people from engaging today? On the other side, what are my most engaged customers doing that everyone else isn’t?

This opportunity space is where product strategy happens. Two companies in the exact same space are going to pick different opportunities. The opportunities they pick are what differentiates them.

Finally, we run experiments to discover solutions that deliver on those opportunities in a way that drives your desired outcome.

We need to make sure that we discover solutions that deliver on those opportunities. It’s the links between the two which help us evaluate our thinking, it’s how this tool acts as a critical thinking aid. Does this solution deliver on the opportunity?

We also have to ask, does the solution deliver on the opportunity in a way that drives our desired outcome? Because even if we solved the problem for the customer, but it doesn’t increase their engagement, we didn’t actually create value for our business.

So what this structure does, is it helps teams remember, what is our goal, what is the outcome we are driving, and as they do all these research activities, they can track it.

I have no idea if I’m going to increase engagement, but here are the opportunities that I see, these are the solutions that I’m exploring. if they will deliver on those opportunities, and these are the sets of experiments that I am running that will tell me if I am going to reach my desired outcome.

OKRs help us set clear defined outcomes. Jobs-to-be-Done and design thinking help us discover opportunities. The Lean Startup and User Experience Design helps us discover solutions.

These are tools. We tend to get dogmatic about them. At the end of the day, all they are helping us do is discover opportunities that will drive our desired outcomes. The tools might change, but what we’re trying to do won’t change.

Start with an outcome, explore the problem space, use the problem space as a way to expand the solution space. And as you explore solutions, it feeds back into your understanding of the problem. This is the heart of problem-solving and decision making.

When you read that next article about whatever comes next, take a step back and you say okay, does it help me learn something faster? If the answer is yes, you want to adopt it. Second, what does it help me learn faster? Does it help me set the desired outcome? Does it help me discover opportunities, or does it help me discover solutions? And that helps you understand what to use when.

Full credit to Teresa Torres for this lovely little history on product discovery. She talks about it in this wicked little talk from back in 2016


Now read this

Rules For Great Microcopy

Be specific. “Save” is not the same as “submit.” Front-load meaning. Say “Continue,” not “Click to continue.” As few words as possible. Never more than 1 sentence. Microcopy is contextual. That’s why it’s so valuable. It answers very... Continue →