Moving From Output To Outcome Is A Monstrous Challenge

Lack of Courage and Fear of Failure Keep the Feature Factory Immortal.

I hear a lot about empowerment. Everyone, including me, shouts out loud that top management should trust teams to solve meaningful problems and let them figure out how to reach goals— yet, only a few people say how teams could move from a feature-factory mindset to a value-driven one.

Outcome accountability is one thing, but delivering predefined features is an entirely different beast. I believe most scrum teams aren’t ready to move from output to outcome because they’ve never experienced how to take such massive responsibility.

I won’t lie to you. It’s much harder to be accountable for outcomes than outputs. You’ve got much more uncertainty and risks ahead of you when your goal is to create meaningful outcomes. However, this road is much more interesting and exciting.

Every day is an opportunity to learn something new and uncover hidden opportunities.

Let me give you some ideas on moving from output to outcome and defeating the feature factory once and for all.

Mindset Differences Between Output and Outcome

For many years, I perceived success as delivering features on time and within scope. I mastered the art of meeting stakeholders’ wants. They were happy with our results, and the team felt comfortable with our working mode.

Everyone had clarity on what to do and when to deliver. I spent most of my time talking to stakeholders to gather their requirements. Then, I’d write well-defined backlog items. The team would estimate the tasks and get them done as written. 

Every Sprint was similar: Features. features, features, maybe a bug fix here, a refactor there, but nothing beyond that. Our work was predictable, and our responsibilities were quite clear. Of course, we had the stress of balancing our capacity with tons of requests. But that was the only stressful aspect we had to deal with.

We were responsible for outputs. Our mindset focused solely on delivery, which we knew very well how to master. But something was about to happen. The leadership team was restructured and wanted us to reach business goals. They stopped telling us what to do and started telling us where to land.

We panicked. 

We were clueless as to where to start. We asked ourselves: 

• Where do we start? 
• What if we make a bad call? Will they blame us?
• What’s success now?

It was a stressful situation and a bit embarrassing. For months we’ve complained that we were lacking direction and that our Sprints were confusing. We longed for more responsibility and autonomy. Suddenly, our wish came true, but we didn’t know how to deal with it.

We were empowered to reach goals, but we were ill-equipped for that.

Output vs. Outcome

Back then, our focus went solely to features. We invested all of our time in delivering predefined requirements; the sad truth is that we didn’t know the meaning of outcomes.

Maybe you’re also confused about that, so I’ll try to clarify: An output is something you create, and your customers can use. For example, in the e-commerce world, product recommendations are an output. Customers see similar products based on products they are interested in.

Product recommendations exist to create value for end-users and businesses. Outputs are solutions and hopefully do something good for end-users. The success of outputs would be outcomes. Continuing the previous example, customers adding recommended products to the cart resulting in more sales, would be the outcome. 

Warning! Outputs do not guarantee outcomes. You must measure and learn from the results.

Now comes the exciting part: You can deliver outcomes with different outputs. It’s like a problem, you’ve got different alternatives to solve it. In the previous example, product recommendations are one way of helping customers find products they want. You could achieve that by more precise search, newsletter, influencer list, and many other alternatives.

When you start with the outcome in mind, you open up different possibilities and have better chances of creating value.

Start Small

To get where you’ve never been, you need help from someone who’s been there. Trust me, get someone experienced with that, and your life will be easier. 

The first moment I faced true empowerment, I froze, and everyone else did too. We tried our best to focus on outcomes but had no experience with it. You can guess what happened. We screwed it up.

• As a Product Manager, I didn’t know how to conduct discovery experiments
• Developers looked at me and wanted precise requirements as I once wrote them
• Stakeholders wanted feature predictability

Things started changing once an experienced person joined the team. Instead of moving everything at once, we moved gradually from output to outcome.

“You can, you should, and if you’re brave enough to start, you will” - Stephen King

Our Sprints had most of the items output-focused, but some items outcome-oriented. This approach helped us slowly get familiar with a totally different way of working. An example of a Sprint was investing around 70% of our capacity concluding a pre-defined integration with partners, and 20% figuring out how to reduce our churn rate. We learned what held us back from truly embracing the unknown:

• We were reluctant to give estimates to “poor requirements” because, in the past, we were blamed whenever we didn’t meet our estimates
• We didn’t want to explore different solutions because we feared failing and being judged for that
• We were uncomfortable with the unknown because that removed the security we were used to

Things got clearer, and slowly we transformed how we worked.

Mindset Transformation Is Required

Outcome accountability is daunting. With an output mindset, you cannot succeed in delivering outcomes. I need to break something tough to you: This change is demanding and exhaustive because it turns everything you used to do upside down. 

With an output mindset, you don’t need to make decisions beyond how to deliver the predefined features. You provide what’s written and ignore what’s not. Once you put the feature live, you jump to the next one and have nothing else to worry about. Maybe a bug will pop up, and you have to solve it, but that’s it.

When it comes to a value-driven mindset, the story is different. You need to make at least 10x as many decisions. You have to choose which problems to solve to drive the desired outcome. Then, you need to define a potential solution and test it with your end users. You must verify whether your solution solves your end-users problems, then inspect and adapt. 

Your job is finished when the outcome is delivered, not when a feature goes live.

Let me summarize a set of principles that can help you with this transformation:

• Questions over answers: Aim for understanding instead of giving fast answers. I like saying a value-driven person asks ten times more questions than provides answers.
• Problems over solutions: Strive to understand the problem, its scenario, how relevant that is, how many people face it, and how that can drive business and user value. Only after you have such an understanding should you talk about solutions, not before.
• Learning over predictability: Embracing the unknown means setting frequent small experiments and learning as quickly as possible from end-users. You accept that you don’t have all the answers and then put your energy into learning instead of being predictable. Learning what not to build is as valuable as learning what to build. You want to create value while avoiding waste.
• Evidence over opinions: Real evidence from experiments should drive your decisions, not opinions. This is about having a data-driven mindset. You may not have the data all the time, but you will make decisions based on the evidence you’ve got and keep moving forward to learn from your target audience.

Once you’ve adapted your mindset, outcome orientation will be motivating and inspiring. Your Sprints will never be the same again. Every Sprint becomes a different story.

Final Thoughts

Moving from output to outcome is stressful. I cannot deny how stressed I was during my first contact with outcome accountability. The unknown frightened me, and I felt the burden on my shoulders. Yet, I’ve never learned so much in my life.

Scrum teams long for empowerment, but they may be unprepared for it. When it happens, they may freeze. It’s a massive responsibility to deal appropriately with empowerment. 

My tip is to get someone on board who has done it before to support the team on this journey. Otherwise, the team will struggle to determine how to benefit from empowerment and deliver outcomes. Beyond that, take the transition gradually. It’s a marathon, not a sprint. Don’t worry about time. Worry about progressing in the right direction.

“Do not follow where the path may lead. Go instead where there is no path and leave a trail.” - Ralph Waldo Emerson

‍