How to create a successful product using business outcomes and product outcomes

?? Hey,?It’s Alessandro!?Welcome to my newsletter.

Each month I tackle topics around building products, driving outcomes, setup organization, defining Product strategy &/or vision and globally anything else that will help you find what you need to use it and grow your business.

I'm sharing this specifically for product teams (product managers, product designers, UX researchers, UX/UI designers, developers....), Product leaders, Investors and anyone who wants to work around outcomes and use them in a better way to run, follow and grow their business.

Creating a successful product is not only about the product, the sale, or the design but also about the mindset and organization.

In this article, I will share my 10+ years of experience in product management and how to create a successful product using business outcomes and product outcomes.

My commitment?

After reading this article, you will know ??

• ?? What an outcome is,
• ?? The two types of outcomes,
• ?? How they are created and managed daily between the Product leader and the Product Team.

Let's get started!

?? What is the outcome?

Photo by Markus Winkler on Unsplash

First, we must clarify the Output Organization, the one more famous among both.

The shift from an Outputs organization that initially requires building features, like a "to do" list, to an Outcome organization that lets autonomy and broader scope for a Product Team is a different mindset to understand before starting the shift.

The Output organization opens the discussion directly around the features, a list of "topics" to build with many target dates to follow. Keeping the mindset that we must always build, build and build because the output is something you do.

For example, “shipping a new feature” is an output. It is something very specific, not showing the goal to reach but the action you will do to achieve it.

I'm not going to explain all the impacts of this kind of organization. You already have a lot of excellent resources on this subject. I recommend Melissa Perri's book,?"Escaping the Build trap".

In comparison, the outcomes-oriented organization lets the product team make decisions from a tactical perspective.

The team will be able to discover in a broader scope and work around the product opportunities linked to the business opportunities to ensure that the decisions are the most relevant for the business and the customers.

For example, “Increasing your PMF Metric from 70% to 80%” is an outcome.?It is the end of the situation you want to achieve.

Easy, right? Not really. We have two kinds of outcomes. Let's figure out each of them.

?? Business outcomes & Product outcomes

The business outcome is a metric that moves the business forward, what we want to achieve from a business point of view, generally defined by Company Leadership. The Product team has a non-direct Influence on it (low).

As a Product Team, you can impact a Business Outcome through a Product Outcome.

The Product outcome is a result we want to achieve that drives the evolution of the product to change the customer behaviour to improve the product experience. These changes help to reach the business outcome.

Product outcomes usually come from business outcomes. Product Teams manage them. The Product Team has a direct influence on it.

An Outcome is focused on business Impact, letting the Product team deep dive into a tactical point of view. Giving them the ability to draw the overall landscape of opportunities related to a product outcome and, of course, allowing them to better understand the "why" to reach the "how” correctly.

This way of doing things?prevents the Product team from being narrow on too little scope and risking missing a more significant opportunity. Remember, the product team is staffed by/with experts and, as Steve Jobs said:

“It doesn't make sense to hire smart people and tell them what to do. We hire smart people so they can tell us what to do.”

?? Who should define the outcomes?

Outcomes must be set through discussion between Product Leaders & the product team.

If they are defined exclusively by the Product Leader, it will bring a macro view on the strategic direction, which is s an excellent point. However, using this method,?we lose much important information related to our customers and our tactical view.

The product team is very close to our customers and our capacity to build something or not, how and the different related costs.

That is why it is so “critical” to define outcomes using both.

The power of an outcome is unleashed through a centralized and healthy discussion between both, Product Team & Product Leader.

Let's clarify the main characteristics of an outcome.

• Enough "high level" to let the Product team deep dive?and define themself from a tactical point of view.
• Narrow enough to ensure good focuses.
• The end of the situation you want to reach.
• A clear desired outcome drives good Discovery and serves as the focus of the Discovery effort.
• Related to the company’s mission.
• Related to the Product vision.
• Measurable. Team & Leadership have to be able to determine impactful metrics.
• An outcome has no specific time. It varies according to the business, the need, the resources and many other factors.

How to manage outcomes on a day-to-day basis between Product Leader & Product Team

Photo by Jason Goodman on Unsplash

The product Leader has now defined the desired outcome through a discussion with the product team but currently, how he/she will be involved? How/When he/she will be present?

Throughout the Discovery/roadmap process, the Product Leader should provide input, guide the team, and, apart from unusual cases, avoid giving directives that will reduce the Product Team's scope.

He/she must let the product team define how to move forward.

Letting them move forward doesn’t mean letting them alone, without monitoring.

As Product Leaders, we must monitor progress with the team and be the guardrail.

One of the common mistakes I saw as a Product Leader is that the product team would naturally want to rush to a solution. My point here is to assess the opportunities first.

Don't try to rush into solutions.

As humans, we want/need to see progress along the way. We need to build confidence over time.

In the end, he/she has to Validate & assess the work done by the Product Team around the desired outcome.

As we move?from an output-driven organization to an outcome-driven one, empowering the product team?to ensure high-quality Discovery becomes mandatory.

The product team is in charge of identifying, defining and building around this desired outcome but also of being able to argue with the Product Leader to have a healthy discussion about what to do next.

As in choosing the desired outcome, here again, a?discussion between both sides will define the best way to achieve the goal.

As a Product Leader, I expect from the Product Team a clear Discovery, but I also need a tactical roadmap to help us reach our goal.

• In a nutshell, I lead discussions with the business leadership, stakeholders and the product team to identify the product outcomes (here, the business outcomes are already defined).
• When I have my Product Outcomes Roadmap, I present it to the Product team & after to the whole company.
• After the presentation and the "why", we define which product team will work on which product outcome.
• They work on a?Discovery for four weeks?with a bunch of?touch points with me, although I let them be?autonomous?until they?have a broader, more mature vision and a wide range of opportunities around that product outcome. They work using opportunities mapping, opportunities assessment rules (we'll talk about that later) and a presentation of their tactical roadmap.

How do they think we should move forward from a tactical point of view to help the company reach the Product outcome?

??Assessing outcomes

We know what outcomes (Business & Product) are, who can define them and how to manage them daily.

The point now is how to assess Product Outcomes?

On a day-to-day basis, after starting the Discovery around the desired outcome, it becomes complicated to decide which opportunity to address first and why? And so on.

Every new "card" you find can provide many opportunities, so a Product Team needs to be organized and learn how to assess.

I have often observed what I like to call the "superhero syndrome" within the product team. It's a good feeling but rarely appropriate for what we want to achieve.

This syndrome is a point in the Product team's life cycle where the team wants to solve every problem they hear about from their customer (and internal teams).

As a product team,?getting overwhelmed?at this stage is easy. I will not explain today in detail how to do it. Another article will explain my vision on this point in more detail in a few weeks

In the following articles, I will share with you about mapping opportunities, the Key Points to assess by opportunities, the question to answer by opportunities, Breaking Macro opportunities into “sub-opportunities” (with benefits) & the particular mindset to have”.

Stay tuned.

If you’re finding this newsletter valuable, consider?sharing it with friends or subscribing if you haven’t already.

Best

Alessandro ??