Succeed with outcome-driven development

And because it’s such a demanding process, it’s easy to lose sight of what really matters – to give real value to the users. Here’s when approaches such as jobs-to-be-done and outcome-driven development come along. It’s about embracing every Agile rule.

How to do it? How to focus on the value the product gives its users?

This article will cover the various approaches to software development, different sides of product roadmaps, and the jobs-to-be-done approach. Lastly, I’ll discuss what outcome-driven development is, in which situations it’s beneficial, how to implement it, and why it’s worth the fuss.

Let’s learn how to succeed with outcome-driven development.

The wrong conversation

In top-down cultures, the senior management and stakeholders hand out feature-driven decisions to teams. Likewise, founders often focus on the ’executive’ layer, so they ask ’how?’ instead of ’why?’. So what’s the solution here? How to fix this approach?

Agile project management

#11 rule of Agile: Self-organizing Teams Generate Most Value. And that’s true.

After all, it’s about teams and their everyday micro-decisions. They build the product from figuring out the strategy and the target audience to beta testing and launching it to the market.

That’s why they have to understand the idea, the business needs, the users, and many more. So autonomy, regular feedback, and conflict management are just a few of the many factors that make sure a team is motivated and successful. There’s no other way to do it. 

To learn more about different Agile project management methodologies take a look at my other article –  Scrum, Kanban, and Scrumban!

The other side of the product roadmap

For most of us, this is the exemplary roadmap for projects. But it’s not that easy. Sometimes, a roadmap is not really a roadmap but a feature release plan. There’s no info about the value the product gives. Plus, sometimes, a single change in the roadmap forces us to plan our tasks all over again. It seems a bit counter-productive, doesn’t it?

So in practice, in projects, the focus is more on the creation rather than on strategy. Instead of fixing the problem, you add more features that don’t really fix anything but hide it. And even though you can use HotJar and Google Analytics to track user’s behavior, you only see half of the truth – you know what’s happening, but you have no idea WHY it’s happening. That’s the problem. 

Jobs-to-be-done approach

But isn’t the point of all our stages is to build a product that will give value to its target audience? Because of that value, the users will want to buy it. To achieve that, we can implement a jobs-to-be-done approach that is especially useful when building new features. What’s that? 

The legend says that nobody ever has asked for a microwave. People just wanted to be able to prepare food faster. So the solution is microwave, while the actual need is the desire to cook food faster. This is what the jobs-to-be-done approach is all about. 

It’s also one of the prioritization tools. It focuses solely on the user, not the product. This method strives to look into the real motivation of the user. 

The pros

• It’ll help you adjust what you create to what your users actually need.
• It’ll help you figure out why they need it.

The cons

• The research & workshop can turn out to be too abstract, too hypothetical.
• Some say it can lead to worse UX (too much focus on user need, rather than intuitiveness and the overall look).

What’s an outcome-driven development

The ultimate answer to all our questions and doubts may be outcome-driven development. This method is based on the roadmap set as series of goals that can be precisely measured. Instead of priorities, there are time horizons. It’s much simpler too. It includes the vision, objectives, and overall strategy of the project. 

So the key to this method is being able to make a relatively small change, check if it makes a positive impact, and double it if it does. In other words, here, the focus shifts from delivering a product to delivering outcomes. And not just any outcome, but a desired one. 

The process

In reality, it looks like this – the team is constantly developing some new code and releasing it on production using “feature flags“. Those allow them to turn the new features on or off and control what users actually see. So they gradually release new features and study how those features influence the target audience as well as how it impacts the process of reaching the goal. This feedback provides us with information about the next steps of our team. 

Plan, develop, deploy, listen to your audience, and iterate. It sounds like Agile, doesn’t it? But in reality, it’s much more than that. 

Why is it so unique?

It requires changing the way we think. So instead of measuring the outcome of our work in hours, Sprints, the number of written user stories in outcome-driven development, we set the goal measured in some outcomes like improved application performance index score, more returning users, and so on. 

This outcome-driven development isn’t only in line with the business value, but also responsible teams can decide what work has to be done to get us closer to the goal. Because sometimes, a new feature may be the solution to a problem, while other times not so much. The point is to look for the best solution to achieve certain set goal with the least amount of money and effort needed. 

Is that really that easy? Well, not really. But if you can’t do it fast enough, especially if the implementation lasts longer than a day (that’s a textbook definition). But the time depends on how many users we have, how big the app is, and how fast we can get this feedback.

Why are outcome-driven roadmaps the way to go?

Result-driven roadmaps offer context for specific items in a plan and their prioritization and ensure communication and consistent product development. Everything is created with a purpose, and it has a clear and measurable objective.

Why is an outcome-based roadmap important?

The roadmap provides visibility while the company aims to prioritize and plan in the context of value; achieving clearness and integration of stakeholders and product teams as well as autonomy and empowerment to help the product team solve a problem rather than implement a solution.

What do you need to implement this method?

• technical evolution (necessary to make it work),
• cultural shift,
• the change of approach.

Those 3 things will help you implement this method successfully. So you have to start by rethinking and redefining your goals in terms of measurable results and not only outputs of effort (hours worked, Sprints completed, user stories written).

Objective and key results framework (OKRs) may come in handy. And then transform them into a plan of work as a series of measurable outcomes. Here, you have to consider clients and their jobs-to-be-done (see? it’s all figured out) as well as find the solution to meet their needs.

Now you’re probably wondering what it looks like from a technical point of view. Well, here it means you constantly invest in a loop – so optimize, implement the feature flags (before we release it to the market), add analyses and usage statistics (to get clients’ feedback) and regularly use this information in our decision-making process. 

Stop building stuff and start solving problems

Result-oriented roadmapping does not change product strategies, but it simply affects how you reach your goal. Because in the end, it’s all about desired outcomes.

But, I’m not going to lie – implementing this method is challenging. There are many edge-cases to consider, but there are also many benefits: the focus on clients, the feeling of actually getting things done in a team, that everything we do has a real impact on users. And lastly, a better understanding of business – this is essential in startups and traditional software houses, just like ours. 

Are you looking for a team for your innovative project? Book a meeting with us! Let’s start the journey together.