Ask Teresa: Do Product Teams Really Ship Value Weekly?

A good continuous discovery team is interviewing customers, mapping opportunities, and testing assumptions every week.

But for teams new to discovery, it can be hard to find time for all of these new activities. Part of that is because they are still thinking about discovery as a phase that happens before delivery. And since they are always delivering, it’s hard to see where this discovery phase fits in.

This is why it’s important to adopt a continuous mindset for both discovery and delivery. Instead of trying to find time for a new phase, we want to integrate small discovery activities into our weekly cadence. We also need to shift our delivery efforts to be more bite-sized as well.

It can be hard to understand what this looks like in practice until you’ve experienced it yourself. And that’s what today’s Ask Teresa is all about.

Michael Greig, a Principal Product Designer at Veygo and member of the Continuous Discovery Habits community, asked about how often product teams should ship value to their customers.

Question: What does best practice look like in terms of the cadence of shipping value to customers? How long should it take to solve a given small sub-opportunity?

To provide a little more context, Michael said he’d read various articles by people like me and Marty Cagan that say a product team should aspire to ship customer value (e.g. solving a small opportunity or making the customer’s life easier in some way) at least every other week, if not multiple times a week.

Michael asked, “Is this really saying that—assuming we have mapped the opportunity space well and truly broken down big opportunities into much smaller opportunities—we should be able to ‘solve’ (to an extent that the customer feels a benefit) an opportunity every two weeks/week? And if we’re not doing that, then we probably haven’t broken down the opportunity space enough/our target opportunity is too big? I am just trying to crystallize that vision in my head.”

Short Answer: Ideally Yes, We Want to Ship Value Every Week

My short answer is: Ideally, yes, a team should be shipping value to customers on a weekly or biweekly basis.

But like a lot of things, the longer answer is more complicated. That’s because there are a number of factors that will determine if this is possible.

For example:

• Is the team supported by a continuous deployment environment? If not, even if a team can identify and build value, they may not be able to ship it on this timeframe.
• Does the team work in a regulatory environment that requires that every release be screened or gated? This might make it impossible to ship on such a frequent cadence.
• Does the organizational culture support small iterations, or are they still focused on big solutions?
• Has the team adequately identified small enough opportunities?

How frequently a team ships value to a customer is not always in the team’s control. The rest of the organizational context needs to support this cadence as well.

Like all things in discovery, I encourage teams to think about this cadence as a benchmark to aspire to. You don’t need to get there overnight.

The Longer Answer: How You Might Get There in Practice

Instead, you want to consider how you might increase your cadence. For most teams, the answer is going to involve reducing your work in progress or reducing your batch size. That means working on smaller and smaller opportunities.

But don’t confuse this with only working on low-hanging fruit or easy opportunities. We don’t want to ignore the hard problems that matter most to our customers. The key to reducing our batch size while still working on the most important opportunities is twofold: opportunity mapping and story mapping. We have to learn to deconstruct hard opportunities into their component parts and we have to learn to start with ruthlessly simple solutions.

Deconstructing Big Opportunities Into Their Component Parts

When you are choosing a target opportunity, the goal isn’t to choose the opportunity that you think you can deliver the fastest. You still want to consider which opportunities can have the most impact. But if the most important opportunity feels big, you might have some more work to do to break it down into its component parts.

As you continue to interview customers (remember, we never stop interviewing), you’ll want to explore your target opportunity in further detail. When you get to the part of the customer’s story where the target opportunity occurs, slow down. Dive deep. You want to start to unpack how they think about that moment. You are listening for the component parts.

Here’s a simple example: A minor pain point that my husband and I experience on a daily basis is deciding what to eat for dinner. Suppose we start with a target opportunity of “I can’t decide what to eat for dinner.” If you were interviewing me about last night’s decision, you would want to capture as much detail as possible. Here’s a quick narrative of what actually happened last night:

It was 6:30pm. My husband and I had just wrapped up work calls and we were hungry. We started our daily discussion about what to do for dinner. We always start with, “Are we eating in or going out?” Last night, we decided to go out since it was already late. Next, we have to decide if it’s warm enough to eat outside, as we like to take our dog with us. It was windy and a little chilly outside, so we decided to eat inside. The dog had to stay home. Next, we started to explore where to go. We live in a small-ish town and we eat out a lot. So it’s easy to get tired of our usual places. I started to scroll Google Maps hoping to find some inspiration. I asked my husband if he wanted pub food or something nicer. He said either. I threw out one option and then realized it had stairs. I’m on crutches, so we ruled that out. My husband threw out two more options. We had been to one recently, so I said “Let’s go to the other one.”

This is a simple story that unfolded over five to ten minutes. But we can still learn quite a bit about our target opportunity from it. I can deconstruct it as follows:

Notice how I can use each key decision in the story to deconstruct my target opportunity. If I collect a couple more stories, you can see how I can keep deconstructing the target opportunity into smaller and smaller opportunities.

Now if I was building an app to help me decide what to eat for dinner, you can imagine I might want a lot of features to address each of these sub-opportunities. That might turn into a big project. But if I work on one small opportunity at a time, I can ship value week over week.

Teams often don’t do this because it’s hard to escape a project mindset. You might think: Can’t we just build one solution that addresses many of these opportunities? For example, doesn’t Google Maps already address many of these? Not really.

Let’s look at the difference between “I want a nice meal” and “I want a casual meal.” A nice restaurant typically requires a reservation. Most of our casual places don’t take reservations. So we can further deconstruct these:

• I want a nice meal.
  • Where can we get a reservation?
• I want a casual meal.
  • Where won’t be crowded?

OpenTable is good at helping with the nice meal, but Google Maps’ busy now feature is better at helping with the casual meal. If you were building a new app to address all of these opportunities, you could turn it into a big project and release everything at once. Or you could release one opportunity at a time and deliver value quicker.

Using Story Maps to Find Ruthlessly Simple Solutions

Finding a small opportunity to start with is only part of our strategy. We also need to make sure that as we move into the solution space, we don’t get pulled back into a big project.

Once we have a target opportunity, we need to brainstorm solutions and choose a few to explore with assumption testing. During these two steps, I don’t want to worry about effort or project size.

When brainstorming, I want to generate as many ideas as I can—big and small. When I’m choosing which ideas to move forward with, I still don’t want to worry about effort. I want to choose the ideas that I believe have the most potential to address the target opportunity.

But once I move into story mapping my ideas, now I want to focus on ruthlessly designing the smallest solution that still has the potential to address the target opportunity. And this is exactly the opposite of what most teams do.

Most teams at this stage start to design the best solution they can imagine. They want to add all the bells and whistles. But this pulls us back into a project world.

Instead, we want to start with the smallest amount of value we can identify and trust that we’ll add more value over time. This is what allows us to ship value quickly.

So if I’m story mapping a solution that allows me to quickly find the restaurants that have reservations for tonight, I might want to add all the bells and whistles like filtering by genre or location, including some information on pricing, customer ratings, and so on. But I don’t need all of this right now. To address the target opportunity, I merely need to list the restaurants that have open reservations for tonight. That’s the minimum required to address the need. That’s value that I can ship. I can always add more later.

TL;DR: Let’s Recap

In an ideal world, we are shipping value to customers on a weekly basis. But none of us live in the ideal world.

Instead, think of this as a benchmark to aspire to. Focus on increasing your velocity or reducing your cycle time. To do that:

• Deconstruct your target opportunity into smaller and smaller opportunities.
• Ruthlessly story map the simplest solution that has the potential to address your target opportunity.
• Iterate from there.

It takes some time to build this muscle. But with time, you’ll learn to balance building the least possible to address the most important thing.

Want more support translating continuous discovery concepts into your real-life work? Come join us in the Continuous Discovery Habits community!

The post Ask Teresa: Do Product Teams Really Ship Value Weekly? appeared first on Product Talk.