Moving towards products and outcomes
How the product mindset with an outcome-based focus makes for better products and happier customers
In today’s market, we often work with fixed teams that have been working together for a long time and know each other inside out. The various clients we help often have diverse needs and requirements specific to their sector or market segment. In everything we do, we always try to prioritise the value for the customer: how can we ensure that the applications we build for them contribute as much as possible to better, faster, and more sustainable service to end customers and users.
Like in many other sectors, we often still work on a project basis: we define a project plan that indicates what we are going to build and execute, with a clear delineated scope of functionalities. In doing so, we try to make a budget estimate and a timeline beforehand: we start around date X and try to deliver everything by date Y.
However, in recent years, we have noticed a clear shift from projects to products, particularly due to influences and insights from product development and product management. This shift also means that the focus is shifting more from output (what have we built) to outcome (what results have we helped achieve). In this blog post, we try to delve into both aspects and see how we can combine these concepts in our daily operations.
From projects to products
When we talk about projects or products, both actually have the same goal: to help a customer solve problems and work better, faster, and more efficiently. It is the way we approach it that differs: the mindset is completely different when we talk about a project versus a product. And consequently, the result is often completely different.
With a project mindset, we usually start with a fixed scope: "This is what we absolutely need to have. We have thought about this for a long time, done many studies and analyses, and this scope is set." If we then look at the project management triangle, we see that the other aspects, time and cost, are filled in a little more flexibly.
Fixed scope but flexible budgets and timelines, sounds good, right? However, the reality is that costs and timelines often cannot be flexible: we still want relatively quick results (because the competition is not standing still), and the budget also has its limits (we still have to pay for many other things).
So what happens? Both scope, budget, and timing are actually "fixed," and therefore we try to deliver the agreed-upon scope faster and cheaper. Result: the quality drops drastically, and we end up with an unwanted result: dissatisfied customers or end-users, little or no delivered value, a "failed" software project. Conclusion: we focus on output without really delivering value (or quality). More on this later in this post.
Most organisations have moved away from this mindset for quite some time. Their proposals explicitly state that the scope is flexible: with the available time and budget, we try to build the most quality product possible, without deciding in advance what we will deliver: we respond to changes in the market and evolving insights during development.
In fact, we are increasingly working less according to the project mindset. Partly because scrum and agile are increasingly being applied, and we realise that delivering small pieces of value regularly makes it much easier to get feedback and base our decisions on it. Another reason is the ever-increasing complexity and uncertainty in our modern world: there are fewer certainties, and we can no longer rely solely on assumptions. Instead, we must regularly validate them in the market and with end-users.
Enter the product mindset: flexible scope, focus on real value for the customer, based on validated assumptions, and constantly adjusted by feedback and evolving insights. We build products that will hopefully be used for a long time and move away from projects that are often doomed to fail in advance.
However, we see that the product mindset is not yet fully ingrained. We work with a flexible scope, but we still do not make enough use of the opportunities that arise from this. If we do not yet know exactly what we are going to build, it gives us the opportunity to think critically about what the customer or end user really needs.
It allows us to develop a product vision or a "product goal" together with the customer and/or end user, which we continuously refine. That product goal keeps us sharp, tells us why we are working on certain things and, above all, on which things we are not going to work. Thanks to the product goal, we focus on delivering real value, which we regularly validate with the end user through scrum, and based on the feedback, we can further refine our product goal and focus.
In short, a product mindset has a stronger focus on outcome, not just output. Delivering value for a customer is no longer just about building features, but also and especially about bringing about valuable changes in the way of working and thinking about the customer, what they need, and how we can achieve it.
From output to outcome
In the scrum and agile community, everyone talks about outcome in favor of (only) focussing on output. But what is the difference? Let's start with a very simple, non-IT related example.
Our boy Finn is turning 5 and for his birthday party, we ordered a Spiderman cake that we picked up from the local bakery. If we were to ask what the outcome of this transaction is, many people would say it's the cake itself. That's not correct.
The outcome is actually a happy and excited Finn and a group of happy friends with full stomachs thanks to the Spiderman cake. The output is the cake itself provided by the baker. If it wasn't a delicious cake, or if it was an Elsa cake, then the desired outcome - happy kids - would probably not have been achieved.
When we think in business terms, we can describe it as follows:
Outcomes are what the customer/business needs or wants to achieve
Outputs are the actions and decisions that lead to the desired outcomes
Outcomes are therefore the benefits that a customer experiences thanks to the technological solutions we deliver. The goal is the outcomes, the means to get there is the output. To identify the desired outcomes, we need to know the real needs of the customer: what challenges do they face, what issues, limitations and priorities are there? Where does it really hurt the customer? Trying to understand the discomfort they have, what takes more time and money than it yields.
With that information, we can determine which output (activities) can lead to positive changes in the identified problem areas. Output remains important to achieve decent outcomes, but the focus should not only be on output metrics. This is still often the case, and it is somewhat understandable.
Output is easy to quantify: there is data available to demonstrate what was delivered and that makes it easy to report and validate: it was delivered or it wasn't. Outcomes are both quantitative and qualitative, and strongly dependent on the customer's perception of the delivered value. Consequently, not easy to report on, but it is important that we find a way to do so.
Because if we continue to focus solely on output metrics, such as velocity (=quantitative), there is little room left to focus on the outcome (=qualitative added value). In practice, you then see, for example, little or no contact with end-users, which is an important benchmark for measuring the right outcomes.
The glue (aka “Product Owner”)
If we want to combine the product mindset and the extra focus on outcomes, we need a strong Product Owner, in addition to a self-managing team (with the support of a Scrum Master). This role has an almost obsessive focus on the product that needs to be built, a vision and product goal about where that product should go and what problems we want to solve with it. Ideally, the PO has sufficient decision-making authority and a strong mandate to make informed decisions about the product goal and budget.
As we mentioned earlier, a product mindset assumes a flexible scope that takes shape over time based on advancing insights. Because the Product Owner can and should regularly say "No" to certain feature requests or requirements that do not fit into the product goal. The PO tries to define the "what" and the "why" as sharply as possible, and the team itself determines how that outcome can be achieved.
In a consultancy environment, almost everyone today works or wants to work in an agile and Scrum environment, where team autonomy and the true role of the Scrum Master is beginning to take shape. But the Product Owner role is often still seen as a glorified Project Manager, or even worse: someone on the customer side who is forced to take up the PO role without paying attention to the mindset shift required for it. Stakeholders are also often wrongly considered as POs.
That is why I believe that, in a consultancy environment, the best Product Owner is often not the customer themselves. If we want a strong ownership of the product, where you dare to say "No" to features or requests, you must be willing to go against the client to shape your product goal. This is often easier as an external person because you are less susceptible to internal politics, hierarchy, or career advancement opportunities that often make it more difficult to question decisions from "management."
Conclusion
A mindset focused on products with a flexible scope, an autonomous and self-managing team that produces output but focuses on the actual outcome and behavioural changes at the customer side, and a mandated Product Owner who guards the product vision with his life: these are the ingredients for delivering a successful product that adds real value.
Every day we should strive to get a step closer towards this goal, while continuing to learn, discover, experiment, inspect and adapt. Because the only certainty we have is that the environments in which we operate will continue to be Volatile, Uncertain, Complex and Ambiguous (VUCA). Agile and scrum, completed with other proven practices, are still the best way to deal with this, for now…