The ultimate proof of Investment value is the willingness of a customer to pay for it, or by what internal stakeholders are willing to commit to in terms of expense reductions. There must be a clear link between what the Investment provides and the value stakeholders perceive.

This chapter starts with a definition of great products. What is it about a product that makes them “great”? Can we find something in common that will allow us to create great Investments? I'll share a definition of great products that I learned from a very wise person. Then we'll discuss what they have in common.

We'll then discuss three different business models that will affect how customers obtain value from your product.

The bulk of the chapter describes stakeholder value analysis, a method to maximize the value product stakeholders obtain from Investments. It is followed by a description of how user scenarios can be the common language for the business and engineering sides to facilitate collaboration and innovation.

6.1 Great Products

I often start a seminar with the question, “Who wants to build great products?” Everyone raises their hands. I then ask them how they would know if they built a great product. Typical answers are “It sells well” or “People like the product.” Nobody has a good definition for something we all aspire to in software development.

Another epiphany from a Construx summit. We had Fred Brooks, the famous author of The Mythical Man‐Month [1], as a keynote speaker at the Construx leadership summit. His book showed the industry that adding engineers to a late project makes it later. Software could not be estimated as if programmers were brick layers, where doubling resources halves cycle time. Brooks is also famous as “The father of the IBM 360,” the ground‐breaking general‐purpose computer developed in the 1960s.

Brooks' topic was great design. He included a simple definition of “great products”:

Great products have fans.

I give this definition to seminar attendees and ask them how they would know if their products had fans. That was easy.

• People become evangelists for your product – “You've got to try this.”
• Communities of users form around your product in social media.
• You can't tear the product out of their hands.

We then do an exercise where they can evangelize their favorite products. The only rule is that they need to state a specific product, not a product class like “digital cameras.” It is a fun exercise where everyone starts writing down the product names so they can try them themselves. The examples of Amazon and Google always come up. The iPhone is often included.

Take the iPhone as an example. Many of you will recall the days of the menu‐driven phones from the 1980s. Leading manufacturers were Research in Motion (RIM) with the Blackberry, Nokia, and Motorola. Even Microsoft had their hat in the ring with the Windows phone. I used many of them. I recall having to go through a series of illogical menus on a Blackberry to turn the phone off. Or I would have to use the Windows phone start button browser and type into the browser to get information I wanted, like how my stocks were doing, or the local weather forecast.

The iPhone changed everything. Steve Jobs challenged his engineers to come up with a single button and no menus. He did more than that. He had them focus on quick access to what users valued. With the iPhone, I can quickly access my stocks and the weather, which I do multiple times during a day. I can pull up my e‐mail and calendar without having to walk through menus that I can barely read. I can roll through my contacts with a flick of my finger. Achieving value quickly and easily set the standard for the iPhone apps to follow. Unfortunately, the younger generation was never exposed to these old phone interfaces so will never truly appreciate the iPhone breakthrough.

I always ask how many people in the seminar believe that the iPhone could have been defined in a Marketing Requirements Document (MRD). Of course not. It required a value perspective instead of the obsession with features and functionality in software development. Product definition would likely have started with menu layouts.

I love how the value provided by Amazon can be expressed in such a simple statement:

I want to minimize the time to buy and receive something I want.

This simple value statement drives Amazon. They help you find something you want with quick search capabilities that present options in a fraction of a second. Have you ever experienced a significant delay? Amazon shows similar products that customers have purchased and their reviews. You can use the famous patented “one‐click checkout” to buy it. It arrives in a day or two, and sometimes even the same day. Amazon isn't stopping there. The value statement includes delivery time. They are working on drones.

I then ask the class why their companies are so focused on features when nobody lists the number of features as the reason for being fans. They get the point.

It's unlikely that this book is going to turn you into a Steve Jobs or Jeff Bezos that will change your industry forever, and I'm pretty sure that neither Jobs nor Bezos started out by writing stakeholder value statements. These insights come naturally for some people and are coupled with tenacious drive and outstanding leadership that keeps the organization focused on value.

The common trait of “great products” per Brooks' definition is they focus on something their stakeholders' value, and move it a mile rather than moving everything an inch at a time with small features and small enhancements. Companies that build great products can innovate because engineering understands the problems to solve.

Imagine your customers telling other customers they really need to buy your latest release because it's so great. Or imagine a trade show where customers love to get up and evangelize your software. Now you know the secret, and it's not about filling releases with features. It's about stakeholder value.

6.2 Business Model Value Considerations

A business model defines the products or services that a company can sell into a target market to achieve financial objectives. They are often supported by a “value proposition” that describes what customers will receive in return for purchase of your product.

There are three major classifications:

Business to Business (B–B)

• Transactions are conducted with other businesses. For example, hospital information systems fall under a Business to Business (B–B) model. The hospitals buy your software to increase revenue or reduce costs. This aligns with our Investment definition. At the highest level, we can assume that the “value” delivered by an Investment in the B–B case is based on the positive contribution to the customer's financial statement.

  For B–B business models, someone in the customer organization needs to demonstrate to their CFO that a software purchase can generate a positive return on their Investment.

Business to Consumer (B–C)

• Consumers don't have to justify your software based on income improvement. They may buy your software because it makes them feel good, like a video game, or saves them time, like TurboTax. In this case, value is based on providing or improving something users value. Investment income is based on the willingness of the customer to pay, and market penetration.

Information Technology (IT)

• Although IT departments don't build products in the traditional sense of the word, they encounter the same work prioritization challenges as product companies. IT departments are tasked with increasing productivity through Business Process Automation (BPA). This may involve purchase and customization of software obtained in a B–B model, or by internal software development projects. In either case, the IT department will need to justify an Investment by reducing operational expenses.

Investment Cost of Delay is based on income generation. The first question to ask for any Investment proposal is, “How would that Investment provide value to our customers based on our business model?” Here are some examples for the different business models:

B–B

• “How will your product increase income for our customers to justify a purchase? Does it increase their revenue or decrease their operational expenses?”

B–C

• “What value would be provided to users to make them want to spend money on our product versus options they have today? Why would they evangelize the product on social media?”

IT

• “How will this software reduce operational expenses?”

These questions will start you thinking in terms of value. Section 6.3 explains how you can maximize the value that your customers perceive.

6.3 Stakeholder Value Analysis

This was another gem from a Construx leadership summit that enabled me to connect another dot to create the Investment model. The speaker was Tom Gilb, another major contributor to software engineering since the 1960s. Tom provided a seminar for Construx on work he had been doing on stakeholder value. Tom's son, Kai, has followed in his footsteps and is also a contributor to the software industry.

I first recognized the power of Tom's stakeholder value model to focus innovation. Technical innovation requires that engineers understand the problem they are solving, rather than just implementing requirements handed down from product management. I saw stakeholder value as a way to identify the problem to solve for engineering.

Agile was supposed to increase innovation by defining stories that represented need rather than specific functionality. However, epics and stories tend to be user‐focused. Innovation requires a broader view. Value may be provided by eliminating the users who are providing input for your user stories. For example, why make a user more efficient by solving their problems when you could automate the entire process?

I developed seminars around innovating with stakeholder value. When the Investment model was conceived, I realized that it is the perfect starting point prior to any discussions on features or functionality.

6.3.4 Five Whys

The Five Whys is a good technique for getting down to stakeholder value. It was introduced in the automotive industry to determine the root causes of quality issues. A group starts with the problem and then asks why it occurred. This usually produces a superficial response with narrow impact on the problem. Questioning continues until the root cause is determined.

For example, there may be multiple customer reports of clutches failing. The first “Why” may result in, “Because a clutch spring failed.” Another “Why” reveals that the clutch springs were not tensioned correctly. The next “Why” determines that the manufacturing machine was not correctly calibrated the week on which the clutches were assembled. The final “Why” might result in “There are no process controls to ensure that the machine is calibrated before each shift.” That reveals the opportunity for a broader solution.

The analysis is not bound to exactly Five Whys. The team goes as far as they can to determine a root cause that they can address. In the above example, a team could go further to reveal that the company does not invest enough in quality control. However, this is likely out of the control of the group. They may make a recommendation to increase Investment in quality control, but machine calibration is within their scope.

In stakeholder value analysis, the first “Why” is applied when functionality appears in a value statement. I use an example of radio control buttons found on most car steering wheels.

Initial customer request:

• I want two buttons to change the station on my car radio.

In most cases, this statement would just become a requirement:

• There shall be two buttons located on the steering wheel to search for available radio stations. The first button results in a search toward stations higher in the frequency band. The other searches toward lower frequencies.

Or a typical Agile user story:

• As a driver, I want to change the radio station with two buttons on my steering wheel.

Yes, this isn't a well‐formed user story. It should be something like:

• As a driver, I want to change my radio station to find a channel I want to listen to.

However, I usually see the user stories stated in terms of functionality that a user wants. The Agile team is just happy to get a user story defined so they can try to meet their fixed schedule!

This still includes the functionality of the two buttons. Ask “Why?”.

Response:

• I want to change my radio station without taking my eyes off the road.

Let's go deeper with another “Why?”.

Response:

• Because I like to listen to music I enjoy in my car.

Restatement:

• “So, let's say that you want to minimize the time to hear pleasing music after getting in your car.”

Response:

• Yes!

Two value statements emerge:

1. I want to minimize the time from when I enter my car until music I like is playing.
   • Minimum: 3 minute
   • Target: 2 minutes
   • Stretch: 30 seconds
2. I want to minimize the time to safely choose music I like while I'm driving my car.
   • Minimum: 1 minute
   • Target: 30 seconds
   • Stretch: 5 seconds

I first wrote, “I want to minimize the time to locate and play music I like while I'm driving my car without distraction,” then realized that this is imposing an unnecessary constraint. It would be fine for the stakeholder to be distracted in a self‐driving car. They just want to do it safely.

Also note that the value statements do not limit scope to just the radio. The radio is just one technology to fulfill the value. The music source could be an iPhone or a USB drive. This is a lesson in making sure you have removed as many constraints as possible in the value statement. Constraints limit the ability to maximize value and preclude opportunities for innovation.

Consider the classic tree‐swing example below that has been used to convey the challenges of requirements definition (Figure 6.1).

Of course, we've come a long way with Agile development. We can involve a product owner who has a clear vision of what the tree swing should look like. The swing is built in small increments, starting with getting the tire right. However, consider what your competitor introduced to the market (Figure 6.2).

How did they come up with this? They conveyed the stakeholder value to their engineering department without including unnecessary constraints, such as the tree and the tire. They realized that the stakeholder value was, “I want to relax outside.” This was translated into Investment stakeholder value:

Build a device that customers rate 8 out of 10 or better in terms of relaxation.

Stakeholder value is a key for innovation. Chapter 14 further explores the relationship of stakeholder value and innovation, and provides practical ways to increase innovation at your company.

6.4 User Scenarios

I recommend an additional step before defining features and functionality. User scenarios can provide the focus for brainstorming product stakeholder value. User scenarios can be proposed and improved by either the business or technical side. They are at a higher level than user stories. And they don't need the formality of requirement statements. User scenarios can provide a fun and collaborative way to spur innovation.

A user scenario is a description of how a product stakeholder could interact with a system to obtain a product value. The brainstorming team should include people from the business and technical sides and may even include product stakeholders. The technical side can contribute solutions that leverage new technology. The business side clarifies value and illuminates any constraints.

User scenarios are a verbal playback of what would be seen by an observer during one system interaction to produce a desired result. They are not to be confused with user stories, which are statements of need that can be implemented in software within a sprint. You may also have heard the term “use cases.” They are elements of a formal requirements modeling process to define every possible system stimulus and response. They can be a good requirements analysis technique, but the level of detail is not conducive to brainstorming.

Consider a user scenario for the car entertainment system:

John unlocks his car. The entertainment system recognizes John from his key code. The system searches through the media and music that John has listened to previously. An algorithm selects music he will most likely enjoy based on his previous selections and replay frequencies. Music starts to play.

This is the “camera‐eye” view of what would be observed for this one scenario. Participants can brainstorm other ideas.

Sounds great. What if we add this? The system starts the playlist at the volume he prefers while the car is stationary. The system detects ambient road noise and employs noise cancelation, and modifies the volume to give John the best entertainment system experience.

Note that the scenarios include some level of functionality assumptions, like “recognizes John from his key code” and “employs noise cancelation.” That is why engineering must participate in the brainstorming. They can contribute technologies that the business side may not be aware of.

Another example:

It turns out that we already use facial recognition for our self‐driving capability, so we know who the driver is. We don't need to rely on the key code. And this is a better solution in case someone else uses John's key.

This has come a long way from the requirement for two buttons on the steering wheel!

Some creative ideas have come out of the truck fleet management example. For example, rerouting a truck around stop‐and‐go traffic to minimize wear and tear to reduce maintenance costs. Or tracking truck speeds and stops to lengthen maintenance intervals to reduce cost. The safety director may get immediate notification on their phone of any driver approaching their weekly time limit with a list of available drivers who could take over. Ideas abound when the team understands the value they are trying to achieve. Engineering job satisfaction increases because they are solving problems instead of just implementing prescribed functionality.

Any decomposition technique can be applied after the user scenario brainstorming. The team may derive features or epics or go directly to user stories (remember, though, that too many features lower WSJF and may preclude the Investment).

You may be thinking that stakeholder value analysis will take more time from product managers who are already overworked. Firstly, product managers gain time by eliminating wasted planning time with the one‐year Investment planning Work in Process (WIP) limit. Secondly, this is exactly what product managers should be doing. Leave the functionality details to the product owners. Product managers should be focused on value.

If you want to go deeper into stakeholder value, Tom Gilb published a more recent book [3] on the subject. I still think stakeholder value analysis is one of the most underused gems of software engineering. I've made it part of the Investment model to enable product managers to focus on value rather than functionality.

6.5 Summary

• Great products have fans that will evangelize your products – it's not about the number of features.
• Great products make quantum leaps in product stakeholder value.
• The value perceived by customers depends on your business model.
• Stakeholder value analysis drills down to what customers value rather than what they think they want.
• Product stakeholders receive benefit from a product and influence purchases.
• Constrainers impose specific requirements on your product to make it viable.
• Stakeholder value can be measured with a scale.
• Stakeholder value should not impose implementation constraints.
• Investment goals can be established by ranges on product stakeholder value scales.
• Many product failures could have been avoided by establishing and testing goals based on stakeholder value.
• The “Five Whys” root cause analysis technique can reveal the product stakeholder value behind a functionality request.
• User scenarios are a valuable tool for brainstorming innovative ways to maximize a product stakeholder value.

References

1. 1 Brooks, F. (1982). The Mythical Man‐Month. Addison‐Wesley.
2. 2 Jayne O'Donnell (2012). Some Ford owners to get touch‐screen software fix soon. USA Today (8 February).
3. 3 Gilb, Tom, Stakeholder Engineering, Leanpubcom, 2021.