In product development, there's a pretty important concept lurking around that sometimes gets lost between an abstract vision and its practical implications. It's called 'business value'. It should be something tangible, objectively measured, but often, this isn’t how it works. The more complex the scenario we’ve envisaged for creating business value gets, the more difficult it becomes to measure it. But business value often provides the impetus for product development initiatives; so we need to step back a bit and see how software development and business value can walk hand in hand.
Business value is about getting to know who will, in the end, benefit from what we are creating, coming up with a hypothesis and gathering the feedback we need to validate our assumptions. That helps us decide on the next, potentially most valuable, functional increment. Whenever we create an infrastructure for software development and adopt Agile methodologies to create things and make them go live quickly, this is done precisely to better deliver business value.
The literature about lean processes focuses on reducing waste, on doing the right thing right, which is something that may confuse a lot of people: the difference between doing the thing right and doing the right thing. It's not just funny wordplay. These must be mutually inclusive concepts, rooted in the synergy between strategic and tactical thinking. Both are necessary, each of them for a different objective: we want to do the right thing because this is the quickest path to add value to the business, and we want to do the thing right so that we’re able to keep a healthy and predictable way of doing the right thing.
There is a common mismatch between having a nice product vision and the day-to-day chores that keep us busy doing the thing right. Whenever we drift away from the actual reason why we are developing functionality A or B, there's a big risk of hurting the value delivery side of the equation.
So how can we know if we're on track? Metrics.
There are two sets of metrics that must be taken into consideration:
As Peter Drucker once said, "there is nothing so useless as doing efficiently that which should not be done at all". That's why both sets are important. And, why are we talking about this, then? Because we sometimes mistake one for the other, often investing our energy in only one of them.
The 'perfect' code isn’t the one that adheres to all the principles of SOLID if it doesn't positively impact the business at the same time. The code we write must be good enough to fulfill a given and timely business objective in a way that allows it to keep evolving, given what we learn with its interaction with the end users. It doesn't mean that quality is negotiable, that we must come up with some quick and dirty, unmaintainable solution. Not at all. The part of doing the thing right still holds true. Balance is key. It's about understanding the limits of how far we want and shall go. For this, there are some metrics that will indicate the health of our code and its underlying development process. Our decisions on where to go and how to go must be taken with this information at hand.
In short, each functional increment — that is, the software we create — should aim to deliver business value, helping the business to move forward while at the same time making sure we have a sane codebase, good enough to keep a steady value-delivery pace.
From a business standpoint, we're talking about problems and opportunities. Not solving a problem in a timely fashion or taking too long to seize an opportunity so that a product or functionality will lose some of its potential impacts.
For example, if we account for the time it takes to develop something versus the way this functionality can pay itself if released too late, it either costs too much or will take longer to break even. It might also happen, in a more catastrophic scenario, that we watch the opportunity window get permanently closed. That means time and money invested for zero return.
During the 'discover' step, we have problem statements and assumptions. We’re dealing with a higher degree of uncertainty. We flesh it out during the 'define' step, creating a plan and hypothesis we want to assess quickly. When it comes to 'deliver' we’re trying to make sure everything that goes live has a reason to be there and to stay there.
We want to measure the performance of the product itself and the performance of the mechanism for product creation. As there's a test pyramid, we can imagine a metrics pyramid where its base makes sure we’re doing the thing right and at the top that we’re doing the right thing. Both parts are in constant feedback and validation flow.
Carrying this discussion to a horizon view, our degree of certainty tends to be higher for those things that are in H1, gradually decreasing in each further horizon, with our vision of scope going from concrete functionalities to future bets. Our biggest investment of time must be in what we know how to do and, from the knowledge we gather, refine our vision of what we intend to do in the future. This way, we make sure we’re executing the product vision or obtaining evidence that we ought to take a different path.
What to do then? From a business vision or a set of assumptions that we want to verify, we shall focus on small value increments. We must, above all, use each functional increment to measure the business and determine if we're still in the right direction. Remember one within several possible 'right' directions, but always some proven to add value to the business. It's not always easy and won’t always be possible, but this has to be like a prime directive: we always seek to add business value in each functional increment, and we want to measure it objectively.
We may start by measuring if we're doing the thing right. Then we ask ourselves how business value can be perceived. There's a very basic question to ask: is this new version of my product or feature equal or better than the previous one? What we can measure to answer this question may be something as increased conversion, better customer satisfaction, improved engagement, anything that makes sense right away.
We don't need to feel oppressed by some esoteric acronym taken out of a trendy business magazine. Not yet. Try to come up with simple ways to get a feel of what "it's better now" means. The more we learn about our product and the impact it generates in each iteration, the better equipped we are to understand if things like ROI, NPS, RPU or LTV are the ones that will help us on our journey.
This translates to being able to measure the health of our product development environment as well as being able to measure the impact each functional increment has on the business. Failing to do so means we’ve no way to tell whether the resources being invested are put to the best use; it means we're blindfolded following a plan just because it guides us to some end. The plan isn’t the objective. It's how we imagine we can possibly attain the goal, while we strive to make sure the objective makes sense at all.
Step back for a moment and think about your current project. Do you know what the goal is? How can you be sure you're getting there? Do you have in place ways to measure the software delivery mechanism and the impact of each functional increment being delivered?
And, most important, always remember that value is a multi-faceted concept: what customers value may not be an exact match to what the business values. Get to know your customer to be able to measure his or her perception of the product.
Business value: the Alpha and the Omega
Business value is not (just) about money. It's about how a positive impact is perceived by end-users, employees, partners or shareholders. It's about doing something in more effective and efficient ways, reducing costs, time, and so on. It's about creating innovative ways to solve problems. Ultimately, business value means the prospects a company has to keep running a healthy business in the long run.Business value is about getting to know who will, in the end, benefit from what we are creating, coming up with a hypothesis and gathering the feedback we need to validate our assumptions. That helps us decide on the next, potentially most valuable, functional increment. Whenever we create an infrastructure for software development and adopt Agile methodologies to create things and make them go live quickly, this is done precisely to better deliver business value.
The literature about lean processes focuses on reducing waste, on doing the right thing right, which is something that may confuse a lot of people: the difference between doing the thing right and doing the right thing. It's not just funny wordplay. These must be mutually inclusive concepts, rooted in the synergy between strategic and tactical thinking. Both are necessary, each of them for a different objective: we want to do the right thing because this is the quickest path to add value to the business, and we want to do the thing right so that we’re able to keep a healthy and predictable way of doing the right thing.
We want to deliver the right product to the right market at the right time with the right process.
There is a common mismatch between having a nice product vision and the day-to-day chores that keep us busy doing the thing right. Whenever we drift away from the actual reason why we are developing functionality A or B, there's a big risk of hurting the value delivery side of the equation.
So how can we know if we're on track? Metrics.
There are two sets of metrics that must be taken into consideration:
- metrics that help us to steer the product throughout its lifecycle and
- metrics that help us measure the health of our value delivery mechanism
As Peter Drucker once said, "there is nothing so useless as doing efficiently that which should not be done at all". That's why both sets are important. And, why are we talking about this, then? Because we sometimes mistake one for the other, often investing our energy in only one of them.
Business value and the software we create
Our enthusiasm and focus on becoming increasingly better technologists should never make us forget the reason why we create any software. This is especially true if one develops software professionally and has clients who are paying to understand their problems and the challenges they face, to identify opportunities, and come up with appropriate solutions. When writing elegant, scalable, robust and secure code, we’re doing a fundamental part of our job, but only a part of it. If this code diverts from its main purpose — which is to provide an increment of value to the business — it ends up not being good.The 'perfect' code isn’t the one that adheres to all the principles of SOLID if it doesn't positively impact the business at the same time. The code we write must be good enough to fulfill a given and timely business objective in a way that allows it to keep evolving, given what we learn with its interaction with the end users. It doesn't mean that quality is negotiable, that we must come up with some quick and dirty, unmaintainable solution. Not at all. The part of doing the thing right still holds true. Balance is key. It's about understanding the limits of how far we want and shall go. For this, there are some metrics that will indicate the health of our code and its underlying development process. Our decisions on where to go and how to go must be taken with this information at hand.
In short, each functional increment — that is, the software we create — should aim to deliver business value, helping the business to move forward while at the same time making sure we have a sane codebase, good enough to keep a steady value-delivery pace.
Problems, opportunities, and results
Using metrics will help us make an informed decision in order to experiment and move forward taking some calculated risks, so we know how far we can go and when to stop. Measuring things means validating ideas and look for those able to yield better results for the business, with the least effort and in the simplest way that works. It means playing a game where the rules are known and where the team can speak the same (business-oriented) language, protecting itself from HIPPO (highest paid person's opinion) decisions and frustrating journeys towards failure.From a business standpoint, we're talking about problems and opportunities. Not solving a problem in a timely fashion or taking too long to seize an opportunity so that a product or functionality will lose some of its potential impacts.
For example, if we account for the time it takes to develop something versus the way this functionality can pay itself if released too late, it either costs too much or will take longer to break even. It might also happen, in a more catastrophic scenario, that we watch the opportunity window get permanently closed. That means time and money invested for zero return.
Product development process
The product development process we usually follow has an iterative life cycle that goes from discovery to delivery:
Figure 1: Process for product development
It's crucial to understand this process because, when we talk about metrics, it's easy to confuse which metric is relevant in each stage of the product lifecycle, and how a given metric provides the necessary evidence so we can move to the next. Each stage has different purposes, and we ‘ll work with metrics that, starting from a high level of uncertainty, lead us into gauging our assertiveness towards the level of attainment of our goals and validating the value delivered by the product.During the 'discover' step, we have problem statements and assumptions. We’re dealing with a higher degree of uncertainty. We flesh it out during the 'define' step, creating a plan and hypothesis we want to assess quickly. When it comes to 'deliver' we’re trying to make sure everything that goes live has a reason to be there and to stay there.
We want to measure the performance of the product itself and the performance of the mechanism for product creation. As there's a test pyramid, we can imagine a metrics pyramid where its base makes sure we’re doing the thing right and at the top that we’re doing the right thing. Both parts are in constant feedback and validation flow.
How do we get there?
Back to the problems and opportunities issue. As we move forward in our comprehension of the business opportunities we're chasing, our capacity to perceive another problems and opportunities will also increase. We’re exploring the unknown and generating evidence that raise our certainty. We’ll find new ways and a few roadblocks on the planned path. It often means finding a higher degree of complexity or more urgent impending problems that must be addressed to execute the vision — or for us to consider an opportunity to calibrate the vision given this gained knowledge.Carrying this discussion to a horizon view, our degree of certainty tends to be higher for those things that are in H1, gradually decreasing in each further horizon, with our vision of scope going from concrete functionalities to future bets. Our biggest investment of time must be in what we know how to do and, from the knowledge we gather, refine our vision of what we intend to do in the future. This way, we make sure we’re executing the product vision or obtaining evidence that we ought to take a different path.
What to do then? From a business vision or a set of assumptions that we want to verify, we shall focus on small value increments. We must, above all, use each functional increment to measure the business and determine if we're still in the right direction. Remember one within several possible 'right' directions, but always some proven to add value to the business. It's not always easy and won’t always be possible, but this has to be like a prime directive: we always seek to add business value in each functional increment, and we want to measure it objectively.
We have to take it as an opportunity to start questioning the product vision and coming up with effective ways to attach our day-to-day tasks to this vision.
We may start by measuring if we're doing the thing right. Then we ask ourselves how business value can be perceived. There's a very basic question to ask: is this new version of my product or feature equal or better than the previous one? What we can measure to answer this question may be something as increased conversion, better customer satisfaction, improved engagement, anything that makes sense right away.
We don't need to feel oppressed by some esoteric acronym taken out of a trendy business magazine. Not yet. Try to come up with simple ways to get a feel of what "it's better now" means. The more we learn about our product and the impact it generates in each iteration, the better equipped we are to understand if things like ROI, NPS, RPU or LTV are the ones that will help us on our journey.
Conclusion
Understanding what business value is, how it can be measured and how this concept translates objectively to each one of our projects must be considered the basic hygiene of a consultant's life, regardless of their role on a team. Uncertainty and possibilities come in the same pack, and we have to make sure we’re adequately equipped to handle them.This translates to being able to measure the health of our product development environment as well as being able to measure the impact each functional increment has on the business. Failing to do so means we’ve no way to tell whether the resources being invested are put to the best use; it means we're blindfolded following a plan just because it guides us to some end. The plan isn’t the objective. It's how we imagine we can possibly attain the goal, while we strive to make sure the objective makes sense at all.
Step back for a moment and think about your current project. Do you know what the goal is? How can you be sure you're getting there? Do you have in place ways to measure the software delivery mechanism and the impact of each functional increment being delivered?
And, most important, always remember that value is a multi-faceted concept: what customers value may not be an exact match to what the business values. Get to know your customer to be able to measure his or her perception of the product.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
