Letting product strategy drive your roadmap

We had the opportunity to sit down with Steve Klein of Launch Awesome to discuss roadmaps, product strategy, setting outcomes, discovery, and more.

Launch Awesome is a community where Product and Marketing leaders go to learn, discuss, and connect with their peers to improve how their companies launch new products and features. If that's you, request an invite here!

How teams land themselves in the Build Trap

‍Question: How did we get here? So many teams are in the same position, and a lot of designers, developers, and product managers are feeling like they're not really empowered. Why is that such a common failure mode of product teams?

There are several reasons you can end up focusing exclusively on features, and I think many of them start off well-intentioned. Many people understand the problem well enough and want to jump into solution mode immediately.

Saying things like "This is going to solve that problem." or "maybe this will."

And you start to get into this game of – "All right... well, if we start building several things, the first ideas that come to mind, we can throw all of them into a backlog and move faster. Then we'll systematically try to prioritize them and start knocking each one off the list.

You quickly end up in this space where you're just shipping features, and then you'll begin to create efficiencies around shipping features faster, but you have to ask whether you are solving your customer's problems or are you creating business value.

Lots of output ≠ value.

Doctors, not Waiters

Question: You mentioned listening to the customers. That doesn't sound so bad. What's so bad about just listening to your customers?

Often I think you'd be surprised when you come up with solutions – how far off you will be when it comes time to test them out and see how they work.

Your ideas might be wrong, and your customer's ideas may be wrong. However, they're rooted in truths that, if worked through properly, can start to help you work backward, little by to uncover the root cause of the problem. Now, you will build a clear picture of what you need to do.

If you listen directly to customers and take what they say at face value, you will run into this problem where you are building for that specific customer. So you want to look across the board at more than just small little pockets of your user base and try to identify solutions that are going to solve more problems for more of your customers.

We need to be Doctors and uncover the problems to prescribe the right solutions, not take orders with blind execution.

Outcomes > Outputs

Question: What does good look like? What are the best companies doing?

Let's focus on the change we're trying to create, the change in either human behavior or the positive change for the business you're trying to make. And by starting there, you can pragmatically walk your way closer to solutions that will work for you (instead of starting with the end state).

You can begin to uncover the outcomes that will make a difference by pulling your data and studying it to understand user behavior and usage patterns. You can find outcomes you want to improve by talking to your customers and asking questions that will have them describe their pain points. All of this will help build a mental model around your users that you can work with to define better outcomes.

Be careful not to fall into the proxy trap. A proxy metric is any metric that, if moved, is assumed to have a dissociated but correlated impact on something of value.

For example: "We shipped 32 features this month!"

Okay, great. But how much value was created by that work and effort? Can it be measured? Celebrate hard work – it took a lot to get there, but you're still in the race. The finish line is still in the distance.

Focusing on the truly valuable end state highlights another value add of shifting focus to outcomes. Focusing solely on delivery will discourage iteration. Instead, iteration will help you achieve that much coveted "10x better than the alternative" you want.

Let a little time pass, talk to our users about what you shipped, and monitor the data. If you're continuously moving on to the next feature without reflecting on the one you just shipped, you may not have created enough value for that feature even to be valuable.

Shifting Mindset (To Outcomes)

Question: So we're going to move from this output-driven approach to this outcome-driven approach. Talk to me about outcomes. Like, what are the different kinds of outcomes? Like, what does it even mean to think about starting from an outcome perspective?

OKRs (Objectives & Key Results) are popular frameworks for setting and communicating outcomes. First, we'll look at the outcome part. That's the Key Result, and they are the quantitative measurement of change.

Often you'll see business style Key Results. Those are the – "increase acquisitions," "increase conversions," "increased retention," or "increase revenue." Those are the significant outcomes you want to see for your business, demonstrating that you have traction and your customers are engaging with your product, they want it, and it's providing value to them.

But the question then becomes, "Well, now what?"

Answering it well requires solution discovery. You need to figure out, "how do we move from this business outcome to something more actionable?"

Enter "product outcomes." Teresa Torres talks a lot about this, and I highly recommend checking out her work at producttalk.org.

Breaking down your business outcomes into product outcomes will help create focus and provide a method for measuring outcomes using leading indicators of success.

Take conversion rates, for example. You want to increase conversion, but first, you need to go out there and do the work to figure out why users are not converting. What are their pain points? It will take a bit of investigative time to determine the barriers to conversion. For example, you may find out that there's a very critical workflow causing users to fall off when they start to engage with the product. In this case, you may set a product outcome that answers the question, "How do we reduce the time it takes to complete the onboarding workflow?" Now, that's something that a product team can work to achieve.

They can start to interview their customers to figure out how they are importing data, why they are importing data, what kind of data they are importing, etc.

Once that average onboarding time decreases (product outcome), you can start to measure its impact on the overall business outcome it ladders up to (increased conversion rates).

Who Sets Outcomes?

Question: Do you think about it like, oh, executives talk about what the important business outcomes are for the year, and product teams think about, okay, what are the product outcomes that are certainly there's probably some amount of a leap of faith you need to take that these product outcomes will affect that business outcome. But do product teams determine what the right product outcomes are?

Fantastic question! We see this playing out very differently across companies.

I'll share my take on this. I want to see product teams develop and own the product outcomes. I think business teams prioritize the business ones. So product teams, engineers, designers, and product managers, the people out there in the weeds, innovating day to day on the product, are going to be able not only to identify and come up with better product outcomes but also will be the ones delivering on them.

So if business and product can come together on product outcomes and the product teams can own the product outcomes, I think that's an effective way to deliver on them.

Talking to Customers

Question: It's hard to talk to users that often. Can't I just survey people? Or why do I have to spend time lining up customer calls, getting the whole team to be there for them?

Getting everybody together (engineering lead, designer, product) all on a call with a customer helps them;

1. Sympathize with your customer and the pain points
2. Hear it directly from them. You're hearing how they're talking about their challenges and pain points, and once you get off the call, you're just really excited to take steps to try and solve them.

Every time we get off a call with potential or existing customers, my co-founders and I get excited and start going back and forth -

"Did you hear this?!" "What about that!" "That lines directly up with what this other customer said."

Not only do some of our best ideas start flowing after these, but it helps inform "what do we want to learn next?" You start thinking collaboratively through what tests can be quickly run – this is being agile, and it's fun.

Steve: "Yeah. Another thing, and I think the Mom Test book by Rob Fitzpatrick, which I haven't read, which is probably a cardinal sin for someone who works in Product, I think there's this idea that you know, when you ask people about their behavior or what they find important, they'll often answer in a way that reinforces their identity or this or that. But it's easy for people when you're not talking to them about a specific time they did something that they don't give you a truthful answer or give you the answer that they think sounds good or something they aspire to."

Automating Customers Interviews (Recruitment)

Question: It truly is a lot of time and effort coordinating customer interviews. Do you have any tips on just ways to make it easier?

I certainly think there are ways that you can make talking to customers easier. But, also, this is our job, and we need to go out there and understand our customers. So we need to find ways to create space to do that within our businesses and our teams to learn more about what will solve THEIR problems.

Interview automation is one of the hot topics in the CDH (Continuous Discovery Habits) space.

"How do we automate our interviews?"

Some teams embed links in their applications for calendars that say things like, "hey, sign up if you want to help us improve the experience." And you can set those up to dynamically show up based on availability.

That's a pretty automated workflow, right? So you may say, "Okay, well, we want three in one week, and that's our max." So, once you get those three, it closes.

One quick tip on automating recruiting - do not allow them to schedule far out in advance. You'll get more no-shows. So try to keep it tight, like in the next few days, if you can. This is a straightforward way to get users to re-engage with you who want to provide feedback and sets up a more natural cadence.

Steve: "Yeah, love that it's one of those "it's tough" answers, but if you want to be a bodybuilder, you got to lift heavy weights every day. And this is the same thing. If you want to be a PM and do a good job of really knowing your customers, you just got to put in the reps. And there are some things you can do and some processes that can make it easier. But it's the job. It's the job."

Prioritizing OSTs (Opportunity Solution Trees)

Question: It kind of begs the question, we go through this process, we've come up with this big tree of opportunities that all funnel up to our outcomes. How do we then go about deciding which ones we do next? Which ones are most important? How do I think about where to start once I have that whole thing?

Prioritizing opportunities is a topic that comes up a lot. Some of these trees get big, like 500, 600, opportunities. So it's not uncommon to hear, "whoa, what do we do now?"

We approach it by focusing on your most significant opportunities, starting at the highest level in the tree. Don't jump down far into your tree if you have it mapped. Instead, start up high and focus on prioritizing at each level as you go.

Each opportunity brings you one step closer to solutions. So keep walking your way down until it makes sense to start ideating solutions.

Now you have opportunities mapped out in a tree. After solving one opportunity, you can jump right back into your tree and see what's next. You don't have to go back to the team and constantly say, "Ok, what's next?" It's all mapped out. You know what the next most important opportunity is.

Do more than “set it and forget it” with your OKRs

Question: So this is from Teddy. I've seen endless discussions to set yearly OKRs, only to have everyone forget about them during the year until it's time to evaluate how close the team came to hitting them. How are the best teams staying aligned and focused on OKRs throughout the year?‍

"Setting and forgetting" is a funny thing you'll often hear. We end up going through this long process of setting our OKRs for the sake of doing it and never leveraging them throughout the quarter or year.

It can be challenging, though. There are always fires, and operational work always comes up. So teams tend to get distracted.

This leads to another reason for "setting and forgetting" if you have too many OKRs, it could cause you to drop most because you just don't have the time and need to focus on the most important thing.

Try narrowing the OKRs to create focus by determining what matters for your business. Ask:

Which metrics really matter? What do we end up working on every week? What are we looking at improving next week? What are we planning in the near term? How does the team feel about delivering on the outcomes?

Reflecting on OKRs needs to be part of the process, keeping it all continuous.

Steve: "Yeah. I think Execs should be talking about this on a quarterly basis. But this isn't something that should be forced on product teams. It's something that product teams should embrace. And when product teams demo things weekly, they should be talking about, "Here's what we're building. And remember, here's how it layers back up to our OKRs." And I think by doing that and getting that weekly repetition reference to the overall goals, you can build that muscle as an organization around keeping those things top of mind."

---

That's all. Thanks to Steve over at Launch Awesome for a great conversation. And if you're looking to find a passionate group of Product folk, this is one community you want to be a part of!