THE PROBLEM WITH PRODUCT STRATEGY AND HOW YOU CAN FIX IT?

For most of our life, we strive to achieve some goals. If we want to look at our best physically, we go to the gym and start eating healthier. If we climb the proverbial ladder in our career, we start educating ourselves, enroll in a course, or find a mentor. These goals consist of small and tangible milestones. But they are not our ultimate purpose and what we want to achieve in the end.

Buying a bicycle is not an outcome. A bicycle is just a means of transportation, an opportunity to spend more time outdoors and keep yourself in better physical shape. But these are all examples from everyday life. Getting back to our topic, what does it have to do with product development?

When you need to decide on the digital product strategy and the roadmap, it’s getting hard to outline the desired outcomes. In this way, it’s more tempting to make features the core of the product strategy as they are much easier to measure and deliver. But what if we shift our focus and make our strategy document more than just a set of “nice to have elements”?

Have you read a book by Joshua Seiden, “Outcomes over outputs”? If not yet, I highly recommend it. This page-turner will take about an hour of your time but give you a couple of useful insights.

The author explains why and how to move from “making stuff” to creating outcomes by changing customer behavior in this book. Seiden defines an outcome as “a change in human behavior that drives business results.”

Let’s take an example of an analytics dashboard for company CEOs. Imagine that there’s no need for a product team to regularly create reports for a company’s CEOs so that they can see the most important business data at a glance.

Output – analytics dashboard for company CEO.

Outcome – product managers, spend less time collecting data to report to the CEO; the CEO has access to analytics at any time.

Impact – the company doesn’t waste time and resources to perform routine tasks like creating data reports for the company CEO; the entire organization works more efficiently.

Inspired by this book, I’ve decided to take it as a basis for this article and explain how we perceive and practice outcome-based software development when creating a product strategy.

The feature-based roadmap consists of a number of features to be delivered within a specific period (weeks or months). In other words, it gives the product team and stakeholders visibility into how long it will take to develop certain product functionality.

It looks nice, neat, and very structured. Like this:

But the main problem with a feature-based roadmap is that it rarely works in practice in terms of product outcomes.

It’s true. Have you ever met a product team that created a feature-laden product development strategy and stuck to it without any overtime, meeting all the deadlines, and, most importantly, delivering everything as it should be? If yes, please share your secret sauce.

A recent research project turned out that 80% of features in the cloud software product are rarely or never used. The result: about $29.5 billion is wasted. And we’re talking only about cloud software. Imagine a more large-scale impact.

Before developing another feature, ask yourself: “What will people be doing differently as a result of this feature?” Unfortunately, the product teams ship a feature without analyzing its performance and value.

The main reason why a  feature-based roadmap fails is that it lacks the answer to one simple but crucial question: Why?

Why did your company decide to create this product?

Why should people care about your product?

Why should your customer pay for the product?

As a rule, this approach is not much like predicting whether these features deliver any impact.

You can create a beautiful app in terms of interface design, convenience, and intuition in terms of good user experience, develop it using the latest and most trendy technologies and still not deliver any value to your customers. And if the product (hence the features) doesn’t provide any value, then it follows that we shouldn’t consider features the center of our strategy.

The goal of an effective product development team is to create an impact and work on outcomes. It requires us to shift focus from thinking about high-level tasks and work on smaller and more manageable targets. It leads us to a different approach to product development, which is an outcome-based roadmap.

Outcomes should be the reason you decided to develop a product strategy. Let’s imagine you’re thinking of redesigning your website. You set a task, “redesign a home webpage.” But why did you decide to allocate resources and time working on that? Maybe, you’ve received feedback that it’s hard to navigate the page or discovered that visitors don’t scroll down the page. In this way, the real reason you want to redesign your home webpage is to increase customer retention rates.

Now, let’s suppose if a redesign operation failed? I mean, what if your visitors still abandon the website and don’t fill in the contact form? What is the design that wasn’t the problem at all? But the main reason why the visitors leave is poor content, product pricing, or a confusing registration form? Would you continue with the redesign as the best solution for this issue, hoping for the best? I guess not.

You’ll continue to test assumptions, gather feedback, and analyze the multiple scenarios. Outline the business problem (outcomes) and then decide on the features’ details (your outputs).

Schematically, the difference between feature-based and outcome-based roadmaps looks like this:

If you face the fact that you cannot accurately answer the question “What’s the outcome for my product?” don’t panic. Think about why you initially wanted to create this product? What do you want to build? Why should customers use the product? In other words, develop your product around how to help people.

An outcome-based strategy acts as a link between your product vision and the problems you will solve to achieve this vision.

This roadmap shows what we are doing and why and what results we will achieve for company stakeholders.

For your potential users, this is a so-called specification, where you explain that you know that there’s a kind of gap (problem) in the market and how your product will help solve it.

The outcome is less measurable and quantifiable than the output. It’s easier to say, “We wanted to build a gas station, and now we have a gas station.” But when your desired outcome is like “deliver technology that solves complex problems in a beautifully uncomplicated way.”, how would you start measuring it?

The answer is the Objectives and Key Results (OKR). This method was invented and first used by Intel. Google, Oracle, LinkedIn, and Twitter picked up this method later. OKR helps to focus on goals, increases initiative and stimulates work between different teams in the company.

Consider the Objective as a mission statement but for a shorter period. The Objective should be qualitative, time-bound, and actionable.

Key Results help you to quantify your motivational Objective, make it measurable and possible to achieve. In other words, Key Results help you to know whether you met your Objective.

In a nutshell, an objective answers the question “Where do we want to go?” while a critical result gives an understanding of how we will know we’re getting there.

Let me give you an example:

Objective: Increase the efficiency of all processes.

Key Result 1: Introduce new tools and techniques by Q3 FY 2019-20.

Key Result 2: Conduct training sessions about new tools and techniques by Q2 FY 2019-20.

Key Result 3: Organizational productivity increased by 45% by Q4 FY 2019-20.

The primary purpose of OKRs for agile product teams lies in their promise to improve the way we work.

Now that the product has target outcomes, the product manager can decide which features will help them achieve their goals. Start with defining the priority of each feature so that to form the right backlog.

For starters, answer these questions:

• Will the feature help us attract new customers?
• Will this feature help attract new paying customers?

Then, divide features according to their importance: critical, high, medium, low.

In this way, you will see a bigger and more precise picture of what you want to be global, up to the product functionality that will help you with it.

An outcome-based roadmap won’t drastically change your product development strategy. But it will help your team become more organized and get a clearer understanding of what your company wants to achieve within a specific project.

When you focus on final results and not deliverables, you get:

• Better visibility of your target goals.
• Ability to plan and prioritize based on your value.
• Clarity among project stakeholders and product team.
• Space for continuously receiving user feedback and an opportunity to adjust the product accordingly.

As a product manager, your main focus should be on the outcome of a product, not the output. That is to say; you may conduct 10 user interviews, collect all possible feedback, and assemble a team of great designers. But it won’t matter until your final product solves the problem.

Let’s talk about how your company can benefit from an outcome-based product roadmap.