Hi, Tamer and Ben here! 👋 

Every now and then, we share actionable advice for product builders in startups and scale-ups.

The following post is about transitioning into outcome-driven work. It should bring you an idea of what is required, from you and your company.

It can be read in 6 minutes.

If you are not a subscriber, here are a few posts you might have missed:

• Guide: Coaching Product People

• Skill Evaluation Matrix for Product Managers (Free Template)

• Frameless Work

Consider subscribing here, if you haven’t already

What's needed to work outcome-driven?

Introduction

Product thought leaders are challenging the common approach companies take to building products. They fight against treating product development like a feature factory. Instead of rushing to ship whatever is feasible, they prefer a different approach.: Assign problems to product teams. M and make them responsible for finding impactful solutions. This is how the principle of outcome over output is born.

Many non-product leaders think that fast delivery is the key. They think it solves business problems. To some extent, it's true.

However, a team's ability to execute is not the same as delivering value. The reality is more nuanced.

Outcome-driven work is not about having full autonomy to work on problems in isolation. It's about keeping the result in mind. Delivering business and customer value.

Whether it's a small feature, a big initiative, or a new product line, the size doesn't matter as much as the impact.

Sounds great, but "With great power comes great responsibility."

Most product teams aren't equipped to work in an outcome-driven manner. Would you entrust your product team with crucial product decisions right now? Teams and organizations need specific skills to work this way. This post explores the approach it takes. It covers the skills you need to work towards outcomes.

"Working outcome-driven is more than just a mindset."

The Quick Journey of Outcome-Driven Work

We can assess the need for outcome-driven work by walking through the major steps.

In essence, we want to answer these questions:

• How does (a streamlined) outcome-driven work look like in practice?

• What are the key ingredients needed to make it work?

We can break this down into 5 Phases:

* Phase 1: Identifying the Right Opportunity

* Phase 2: Normalizing Opportunities

* Phase 3: Assessing Options

* Phase 4: Generating Solutions

* Phase 5: Executing the Solution

Phase 1: Identifying the Right Opportunity

You need an idea of which outcome you want to achieve. Regardless of how focused on results you are now, the journey starts with finding a problem to solve. This involves leveraging domain expertise, research, and primarily customer insights. Insights in these fields help you see the real issue. They encompass: Business Model, Product, Operations, Customer, User, Market, Technology, Acquisition, Competition, Regulations/Compliance, Legal, Partners, Suppliers, and Vendors. Each of these fields may unfold significant opportunities.

You need to be able to find the right opportunities in the vast field of options. Without a decent level of insight, your suggestions become pure guesswork.

Also, you need to measure the outcomes you create. This way, you can see how far you've come. It's nice to say "Increase user-generated content by 30%," but if you can't measure it, the goal is pointless.

To get the first phase right, your product team needs fresh, unbiased, and thorough data. This data includes customer information, financial data, business plans, product analytics, and many more. Not every company can do this due to a lack of data or the rush for delivery. Or, they are unwilling due to information hiding. Without the buildup or access to data, working outcome-driven may not generate the needed impact. It's true for both creating options and tracking your results.

Having data is one thing, but it also needs data literacy. Your company culture needs to rank data over opinions. Stakeholders must not perceive this as overhead and instead contribute to the discussion.

This phase has more requirements for product people. With more insights and knowledge, you gain more data to act upon. Getting comfortable in the messy middle is difficult. Keeping a mindset of continuous learning can be a challenge. Product teams must be capable of interpreting data and building mental models of the company's mechanisms.

Imagine you have an ambitious revenue growth target in your company. Ideally, you get a feeling of the potential in each area. So e.g. if the marketing team is mainly focussing on 2-3 channels to acquire customers, an extension towards additional channels might be vital to drive growth. If that is already covered on a highly professional level an extension of the product to add a new revenue stream or increasing conversion rates might be a better opportunity.

Phase 2: Normalizing Opportunities

In daily business, feature ideas, requests, and business needs flood the process. The key is to normalize these by identifying the underlying opportunity (or problem). Fixing a payment bug is more than solving a technical issue. It's about ending customer frustration and revenue loss. This nuance is crucial. It fosters a mindset that puts customers and business at the forefront.

First, normalize opportunities. Then, give all options the same assessment. This way, you can find and suggest better solutions. This can be frustrating for many stakeholders. It feels like taking a step backward.

Open communication in that phase has two major benefits. You get buy-in from the people around you, and extra data. Sharing learnings and engaging in discussions around interesting observations adds traceability. It becomes clear that it's not about creating high-impact features, but also about discarding costly ones.

Identifying the essence of an issue should become a habit for the product team. What sounds logical at first is hard when you face many opportunities to normalize. Divide complex problems into manageable parts and deduce sound judgments. Understanding the "why" of a request gets easier when you have a solid data foundation (from domain expertise) so you can assume certain implications.

Phase 3: Assessing Options

Next, you need to evaluate opportunities from multiple angles. You should understand the value you might create for users, its impact on KPIs, and compliance. Also, how it will stand out in the market, and so on. This process helps you understand the real impact of solving a certain problem. But this doesn't stop here.

Questions here might be:

• What is the user value?

• What is the business value?

• How can we measure it?

• Is it compliant?

• Can we build it?

• Can we advertise?

• What will it cost?

• What enables this?

• Who can build it?

• …

You won't have the same certainty over all aspects of your assessment. So, you need to reduce uncertainties by conducting further research or testing assumptions. Finding a balance between gaining more insights and moving forward is an art. When you find the option worth solving, you might be able to feel it.

This part is about being fast. You can use decision-making tools like strategies, roadmaps, KPIs, and goals. They help you filter out unimportant ones.

Problem assessment also needs cognitive flexibility when switching stakeholders' viewpoints. Being able to adapt your thinking is key. It allows you to foresee certain constraints for the solution design.

Phase 4: Generating Solutions

Once you identify the best option, brainstorm diverse solution ideas in teams. This process often leads to better ideas instead of the most obvious initial ones. Selecting the best solution needs more insights, assessments, and tests. They determine whether the problem is worth solving and if the solution can deliver on its promise.

Skipping further analysis is tempting in this phase. A solid testing environment encompasses tools, habits, and processes to reduce uncertainties. It will increase the likelihood of success. The investment in the testing environment pays off soon.

When ideating solutions, creativity, and technical understanding lead to feasible and unconventional solutions. Innovation in this sense is not an end in itself. It's required to gain a competitive advantage. The initiative advances when viability and feasibility align.

Working outcome-driven feels like freedom at first. It's comfortable to talk about the outcome, staying in the problem space, ideating innovation, and not getting real. Balancing the need for research with action is key. Avoid getting lost in reducing uncertainty and know when it's time to move forward. Developing the ability to make timely decisions with imperfect information..

Phase 5: Executing the Solution

Finally, execute the chosen solution with high quality. Once we launch the solution, we will see its impact.

Just Do It

Working towards outcomes may seem daunting. Especially when the company is not used to outcome-driven work. But, taking the first steps is easy. Begin with initial experiences and gradually build layers of skills and capabilities. As a product person, focus on what you can do rather than what the company needs to do to make this happen.

Talking to a few of your ideal customer profiles, setting aside a 2h block to browse competitors' homepages, scheduling a call with the sales team, and listening to their issues can ignite further activities. Sooner or later, you'll see patterns repeating. Your confidence in certain problems to solve will grow.

Finding the underlying opportunity can be relatively simple. Gather some team members to decompose the insights you've generated and examine them from all angles. This will identify weak, strong, and promising options. If you think, "That makes so much sense to address this problem", you're on the right track to further testing assumptions.

This is already enough to turn problems into solutions, talk to stakeholders about your learnings, and slowly start to infiltrate the common way of working. Showcasing the KPIs closes the loop.

Conclusion

Moving from an output-driven to an outcome-oriented product team is tough but rewarding. It requires a fundamental shift in mindset, organizational structure, and individual skills. Focus on outcomes, not outputs. This helps your product teams create solutions that truly address user needs and drive business value.

Once you're there and feel confident in this way of working, anything else will feel like work from the Stone Age. Every choice, feature, and product should be guided by one simple question: "What outcome do we want?"

Learn more about the Essentials of Product Management

We’re offering a hands-on, 6-week, live & digital course on the most important yet hardest skills of a product manager. Learn from 25+ years with over 70 companies. The next batch starts on September 3rd, 2024