Software development is a complex process. From idea validation through product design, development, testing, and features deployment to releasing the product to the market, getting yet another users’ feedback, and iterating. It’s a lot.
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.
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?
#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!
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.
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 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.
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.
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.
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.
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.
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.
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.
Have a project in mind?
Let’s meet - book a free consultation and we’ll get back to you within 24 hrs.
Other worthy reads