How do you debate how to build something you’ve been asked to build? There are several constraints which affect choices – non-functional requirements (NFRs), cost, capacity, and capability are easy ones to discuss. And while all of those are relevant, an altogether different factor has dramatically more impact on your results.
“Can We Do It?” vs. “Will It Work?”
There’s a pattern in most organizations, where people are told what to build, so they build it. They are given some latitude to decide the best way to build it. I’ve written before to make the point that when people ask for things, they tend to ask for the wrong things. But that’s not directly what I want to emphasize here – I want to dig into what happens on the receiving end of the request. These are the two sides of how things play out when the pattern of orientation towards creating value in the organization anchors on creating outputs. People ask for things, assuming they are valuable. People then receive the request and deliver those things, assuming they are valuable.
Yes, the assumption of being valuable causes problems, because the value is often not sufficient to justify the expense. Even if the thing being requested could result in value creation, it may not. Value escapes the team because of how they treat the request. More specifically, because they are unable to treat the request the way they should.
When asked to build something in this way, these are the questions which unfortunately are the common core of the negotiation which unfolds. These are output questions.
- Can you build it?
- Who will build it?
- When can you deliver it?
- What will it cost?
Those output questions should be peripheral questions. These outcome questions need to be at the center of the collaboration.
- How is value created?
- How will we measure success?
- How much will we benefit from having it?
- When do you need to have it?
- What are we willing to spend to build it?
For too many people, the output questions are familiar, and the outcome questions are foreign.
In the output-focused scenario, the questions are asked by the speaker. In the outcome-oriented scenario, the questions are asked by the listener.
The answers to the outcome questions are the ones which matter for making good decisions and ultimately creating great products.
A Semantic Sidebar on How
There’s a semantic debate I think we can avoid about how we describe what we create. Arguing about the difference between “the thing we are building” or “the way we are building the thing” is – for this article – only semantic. People often talk about “what, why, and how” and this sidebar is digging into what “how” really means, so we can avoid doing that through the rest of the article.
Here’s an example – think about enabling on-the-go order-status checking for your customer.
You could build a mobile app which provides order status information to the customer. Is the mobile app “the thing you build” or is it “the way you build it”? An architect would probably say that an order-status-sharing capability is “the thing” and the mobile app is “the way.” This architect would suggest that you could enable order status updates via text message, or a mobile app, or a website, or a call center, etc. Each of those implementation choices, to the architect, is “the way.” Others on the team would likely describe the mobile app as “the thing.”
You could look at the mobile app solution-approach and declare that you will build a native app unique to iOS or Android, or a progressive web app which works on both, or a hybrid app which forces different compromises than either of the other approaches. Is the cross-platform app “the thing you build” or “the way you build the thing”? You can keep going – does the app include authentication features? Does the app provide a view of order history? Are you building C++ code or React functions?
All of these descriptions of how to build are both “the way” and “the thing”, depending on where you are anchored.
I’m referring to this generally as “the way” in the rest of the article to simplify the narrative, because we need to focus instead on “the why.” It is “the why” which needs to drive “the way.”
Deciding the Best Way to Build
To decide what the best way to build would be, you have bring the right information into the decision. Yes, all of the information from the output questions is relevant, but it is secondary. You should be focusing on the more important questions.
How Is Value Created?
The mechanism for value creation is what you need to understand to have a sense for the right way to build something which creates value. This is about cause and effect. You need to know the effect you’re trying to create to choose the right way to cause it. Use a solution hypothesis to describe your belief. We believe if we solve a customer’s problem, by building some thing, it will result in a change in behavior. Take a look at the Assumption of Causality section in this earlier article (link).
Let’s look at a concrete example for this abstract concept. Imagine we believe a customer has a better shopping experience when they know the status of their order, because it eliminates anxiety. This is what Indi Young might classify as a serious harm (link). Different people in different situations may experience different versions of this. Someone living in an apartment may worry about a package being delivered in a public area where it could get stolen. Someone away from home when placing an order may worry about the package being delivered before they get home and being damaged by bad weather or wildlife. Someone ordering medication may worry about exposure to the elements ruining their shipment.
That is the situation of the example – now imagine we also believe that improving the customer’s experience results in an increase in customer loyalty – they will be more likely to purchase from us in the future. There’s a value proposition to the customer (reduce anxiety about delivery) which drives a value proposition for the company (do this and increase loyalty to increase revenue).
Instead of “build a mobile app which provides order-status information” now we have “reduce customer anxiety about order status, to increase customer loyalty.”
The first declaration forces you to build a mobile app and makes it impossible to answer the next question. The second objective gives you choices and the context you need to measure the success of your product. This is a big deal. If you stop reading the article at this point, and just do this, your products will be better. But don’t stop, there’s more you can do.
How Will We Measure Success?
With a directive to build a thing, all you can measure is if you finished building what you planned to build. The definition of success is absent. It does not exist.
With a customer goal of reducing anxiety about order status, we can now explore – how much must we reduce anxiety? With a desired outcome of increased loyalty, we can explore – for how many people must we reduce anxiety?
In Discussing Design, by Adam Connor and Aaron Irizarry, a key concept for critique is suitability. A colleague of mine, Dennis Stevens referred to this as fitness function – how well the capability you’re building fits the need you are addressing. The choices you make about the way you build something influence the effectiveness of what you build. With an objective like “reducing anxiety for this many of these people in this situation by this much” you can critique solution approaches. You have a framework for deciding if “the way” is a good one, and you can compare different approaches and choose the best one. You also have the opportunity to say “we cannot imagine a solution approach which reduces anxiety enough for enough people to warrant building anything.”
How Much Will We Benefit from Having It?
When accepting direction to only build what is requested, you are absolving yourself from responsibility for delivering outcomes. Just build it. If it doesn’t generate value, that’s someone else’s problem.
I’m writing this because it is your problem, even when you don’t acknowledge it. Here’s a little thought experiment. If all the requests were valuable, where the ROI was 2x or 5x or 10x for every feature being requested, how would things play out? As my friend Rich Mironov famously says “there’s never a shortage of good ideas” (one of several links). If every idea has high ROI, and we’re capacity constrained, what will leadership do? Increase capacity. Like scaling up the GPUs in a server farm, bigger is better. Micro-economics tells us we should keep scaling until the marginal cost of increasing scale equals the marginal benefit of the additional deliverables. This is definitely not happening.
What if every idea isn’t valuable? Then there would be downward pressure on costs and headcount. Looking to sustain business as usual, to “make do” with fewer people and keep the lights on. Sound familiar? I believe the pressures on budgets and team sizes and increased throughput exist because only some of the requests generate returns. I also believe the way most companies try and solve it is misaligned with the root cause. Instead of making it cheaper to deliver the wrong things, I believe we should make it more likely we deliver the right (valuable) things.
Increase the size of the top line instead of decreasing the size of a line item.
When subjected to this level of thinking, many requests to build something get cancelled. Because it becomes clear they aren’t worth building. This came up twice last week with two different product managers I’m helping. Both of them offered examples of work which just evaporated when value was explored.
You cannot assert or assess the value of the request, but you can assess the value of the objective.
With an objective like “reducing anxiety for this many people by this much” you can critique solution approaches. You can develop an outcome hypothesis before you begin exploring solution approaches. “If we reduce anxiety by this much for this many this often, we will see a revenue increase of $X…” You now have some guidance for imagining a solution – it must reduce anxiety by “this much” for “this many people” with “this regularity.” You can develop solution approaches to meet those observable, measurable changes. Fitness of the design to the job at hand requires criteria. And these are the criteria. You also have the opportunity to say “we cannot imagine a solution which reduces anxiety enough for enough people to warrant building anything.” Explore cost-effectiveness of the solution by defining effectiveness.
When Do You Need to Have It?
We’ve been trained to ask and answer this question the wrong way. Every organization I’ve worked in or with in the past 35 years has done it, and still does it. We answer this question in terms of scheduling and planning. Imagining the effort required to deliver the solution, thinking about who is available to build it, and the logistics and dependencies which are part of our operational reality.
The problem is, none of that stuff is actually answering the question – all of that stuff is answering a different question “when can we do it?” Again, useful info, but the wrong focus.
When someone needs the solution is an entirely outside-in consideration. There are market rhythms, like launching before a trade show, or back-to-school shopping season. There are milestones in our customer’s or supplier’s timelines, like a key piece of infrastructure being turned off (sunsetted or EOL’d are common jargon terms for this). There are often compelling events which have an impact on the value of solving a particular problem. Delivering a solution after the deadline is sometimes pointless. We should know that as a constraint on how we would approach solving the underlying problem.
Even in the absence of deadlines or cliffs, there is the time-value of money. Once you identify and quantify a problem, you can now identify the cost-per-month of not solving the problem. The faster you can deliver a solution, the more value it has. In agile, the ‘focus on finishing, not on starting’ principle increases the value of whatever is being built by doing this. Assuming the work is valuable, which it often is not.
Understanding the influence of time on value is also an important factor in deciding “the way” you build a solution. An approach could be 50% as effective but launch in 1/10th of the time. Is that a good thing to do? The economic analysis of value (for your customers and for your business) is how you can explore.
What Are We Willing to Spend to Build It?
In theory, this is a redundant question. By knowing how much we benefit, our willingness to spend is a foregone conclusion. Companies have rules of thumb – establish a particular payback period, ROI, NPV, internal hurdle rate, etc. And at times those rules of thumb are ignored to make exceptions for strategic initiatives, like an acquisition or a race to “do AI.” You simply do the math for what qualifies as an acceptable investment, except when a leader says we can ignore the math.
In practice, I have found this question to drive better decisions. I think it happens because people bundle together a bunch of different emotional approaches to operating in uncertainty. Every investment is a gamble. Prospect theory tells us that losing hurts more than winning feels good. Different people get different levels of satisfaction from placing sure thing bets vs. long-shot bets. What I want to do is activate those pathways (whatever they are, for whichever team or leader), because it improves the thinking about the value proposition.
When asked “what is it worth?” people tend to estimate a number. With training, they develop an estimation range. Knowing the range, however, doesn’t tell us everything we need to know to decide to make the investment. Cost estimates have uncertainty just as value estimates do. Just as with value, people tend to estimate with a number, and with training, a range.
If the high end of the cost range and the low end of the value range overlap, what do you do?
When asked why it is so hard to create a bear-proof trash can, as the joke goes, it is because there is a significant overlap between the smartest bears and the dumbest people.
How should you deal with the situation where the cost estimate range for “the way” you chose to build something overlaps with the value estimate range for solving the problem? Ultimately, the choice about how to build something is part of the decision to build it or not. When the highest costs overlap the lowest values in your estimation range, you should explore different ways to build.
When you start with a definition of your objective, you can ask the question – will an alternative solution approach, while lowering costs, also lower the expected value? This is every bit as hard as designing a bear-proof trash can. But it is a necessary consideration when trying to create value for your company through creating value for your customer. A different approach may undermine the realization of value.
Conclusion
Focusing on “the way” must be done in conjunction with a focus on “the why” if you want to create value for your customers and your company.
If we don’t agree on the problem we are solving, we cannot agree on the solution.
