Why prioritize value backed by measurable data over sheer product features?

Understanding value becomes clear when measured in terms of income, revenue, and direct costs. But is value solely monetary? Metrics like growth rate, market share, and customer satisfaction are equally vital. Similarly, a product's ease of use and adoption are crucial optimization factors.

And what about the effects of engineering work?

These, too, are easily measured, for example, by the amount of functionality delivered. But it is only of secondary importance, why? Because the number of features delivered is irrelevant if none of them contribute to improving the customer's existence or capabilities.

Now, let's examine the results of the 2002 Standish Group study (an independent international IT research advisory firm):

According to Jim Johnson, Chairman of The Standish Group – “The 2002 pie chart was based on 100 mission-critical applications that we were researching for a total cost of ownership (TCO) study. Since then, they have conducted several TCO studies annually. They try to incorporate this into their engagements. Based on these casual observations, their current estimate of features used for mission-critical applications is 20% often and always, 35% infrequently, and almost half hardly ever.”

According to a publication in the Harvard Business Review, 'The vast majority [of new ideas] fail in experiments, and even experts often misjudge which ones pay off. At Google and Bing, only 10-20% of experiments yield positive results. At Microsoft, one-third prove successful, one-third yield neutral results, one-third negative."

Does this mean that new software products should not be developed?

Of course not. What it does mean, however, is that you should pay close attention to the goal you want to achieve. It should NOT be "Let's do all the functionality, then our application will be perfect". The assumption that everything on the 'wish list' is important and valuable is wrong - as the research described above proves. Instead of worrying about whether everything will work, focus on how you can test value assumptions more quickly to reduce waste (and therefore cost) and increase the value delivered.

Therefore, when working with a Product Owner or Product Manager, I ask the following questions of stakeholders:

From a product scientist's point of view, what to focus on when building a software solution can be defined in the following points:

1. Develop the product based on new information. The initial product vision is a starting point, based on assumptions and guesses, many of which will be correct, but some of which will turn out to be wrong. You will need to check, adjust, and develop the product vision based on new information. I think this is most accurately stated by Peter Drucker, the management guru: If you can't measure something, you won't be able to improve it.
2. Stay focused. Successful products have a clarified purpose. The teams creating them know who they serve and how they serve them. Poor-quality products try to serve a little bit of everyone but will not fully satisfy anyone.
3. Constantly improve the product. To use the words of professional coach Don McGreal, 'be annoyed.' Product owners should look for opportunities to reinforce the product vision, as well as validate compliance with the product vision.

Below is a list of indicators that can be your starting point for measuring:

1. Satisfaction of customers using your app:

2. Achieving business goals:

3. Customer-related performance indicators:

How do you organize all this?

Scrum was not created to help you build and release more 'stuff.' Instead, Scrum is designed to help you maximize the value you create for your customers and therefore your organization - by delivering the product frequently, measuring the results, and then learning and adapting to squeeze even more value out of the product. Hence, a product review with your team should be an important event on your meeting calendar.

The outcome of a sprint review is to:

When you plan for a short Sprint period (1-month max) and then actually do the work, you have the opportunity to quickly check the results by asking:

Based on the new information, you can adjust your plan accordingly. By modifying your plans based on new, measurable information, you minimize the risk of complex work in an unpredictable and changing world. If, on the other hand, the team is forced to adhere to a schedule, this is often at the expense of quality. Ultimately, this kind of activity generates costs in the long run because it destroys your ability to deliver future value. This traditional approach to project management suggests that making more detailed plans reduces risk, but more detailed planning actually only delays confronting risk by making more assumptions. And the further into the future the forecast goes, the wider the range of unknowns, complexity, and likelihood of change. This is why so many traditional projects fail. So, in practice, the empirical assumptions of the Scrum approach reduce uncertainty by taking action rather than planning more action.

If you are interested in this topic, I encourage you to read the book by Stephanie Ockerman: "Mastering Professional Scrum: A Practitioner's Guide to Overcoming Challenges and Maximizing the Benefits of Agility".

Source of graphics: www.pexels.com.