The lost value in Product Management

I spent a reasonable portion of time with my team deciding what is valuable. The various people, stakeholders, in this don’t explicitly use the term value, yet, but it is clear to me that is what everyone should be using. I’m asked Why this project? Or what’s the utility of this project? Instead of determining what is valuable we use language and questions that point to its direction or outcomes.?We often ask about prioritisation and what should be the product of our efforts. Instead of a quantitative approach maybe there is something smaller, more fundamental qualitative that we should capture. Value!

You see, in our organisation we have multiple competing priorities – before we reach for our agile project management practices, we triage our prospective work.?In this process we need to decide, collectively, what is the most important piece of work and articulate in a clear plan how we are going to execute. Once we make a commitment, we are all focused, as a development team, on delivery. This quasi-agile practice can create a chasm between the plan and execution, where value can get lost.

Value, I suggest, can get lost over time. Well, that’s my observation at least and a good product owner tries to maintain value by delivering the right outcomes. During a project you can maintain the initial idea, the product vision, a great set of stories and a well-defined backlog – but still drift away from the north star, value.?Imagine you have a product vision to build a single report for the business, you have a set of stories to articulate each part of the report and a set of technical items to build the report.?Yet the value, how many times the report is used, isn’t realised.

In my organisation, Microsoft Commercial Software Engineering,?we have great engineering principles that help us define how to build a quality product. As we get more granular my proposal, for product owners, is we should always reflect on the value we defined up front - our why - and at all future stages, the product owner prioritises and protects value.

Product Junctions

During almost all projects, clarifications are sought when questions are raised. For example, you may find some features technically challenging or contentious in terms of merits. It’s at these “Product Junctions” the product owner needs to be able to make decisions and manage expectations.

Example

We worked with Australian Courts and Tribunals to accommodate their need to manage and moderate hearings online. The project had a clear problem statement and a vision to schedule and moderate online hearings in a familiar manner. There were benefits around efficiency and clarity that would unblock hearings. Due to being a widely applicable Government enabling scenario this project was prioritised and a definite backlog was created. We found that in Microsoft Teams, by design, you couldn’t unmute participants. Unmute was a story in the current sprint backlog and by not having it a question was raised around the impact on the product.

Evaluating decision impact

When presented with key project decisions a good product owner will evaluate delivery impact and make swift decision with great communications to all involved. The impact could be limited to the current backlog item, or its overall story, the product vision or at worse case the business case.

?Typically, in a project we will create artefacts that help us establish clarity and perhaps governance. Below I present 4 key elements – the problem statement, its success criteria, user stories and sprint backlog – all sustained by value.

In our organisation we turn an idea into a problem statement, our vision into measurable success goals, grouped by stories and executes in sprints.

?Example

In our court solution the value was measure of being the ability to bring order to courts. Mute all gives a judge the ability to control the order of the court, therefore has value. Automated unmute has little value for court order. Individuals must be able to elect to be unmuted to maintain their privacy.

Describing value

In this second part of this post, I wanted to emphasise the differences in similar terms and how value is a standout for directional decision making – it gives us a clear path forward.

Problem Statement

A problem statement is useful tool to describe the why – the current reality, the ideal situation, the consequences, and a proposal. Its leads to opportunity and benefits. It combines the business drivers, goals, and product aspirations into a succinct statement. Within this statement we describe the problem (where we are) and perceived value (where we want to be).

Success Criteria

Ensures measurable conditions for the project is to be considered is a success. Success and business value are therefore inextricably linked. Success is the long form description of value and can have multiple perspectives:

• customer
• technology
• training or upskilling
• sharing or learning

A key point – being too precise can limit agility, so use your measures wisely.

Value

Value is the degree of importance given to something. It can be expressed as a “value proposition” - what is being promised to the primary stakeholders/customers.

Example

In our Courts example the value we promised was we would bring back order to an otherwise hard to manage hearing. Order should not be compromised.

The amount of value attainable is related to the work undertaken, the resources you have and the risks you do or don’t manage. Value can be perceived differently by organisation role so to know if the value is captured correctly, it’s important to get feedback from important stakeholder groups.?

The value exchange system

We should associate value with outcomes for the business and the customer. It's not linear and it's not measured by quantity - value is not measured by the number of things produced for either party.

A positive way of looking at value is as an exchange. On one side a customer has problems wants and needs and on the other businesses create products and services. Customers realize value when their problems, needs or wants are met, businesses when they realise to fuel more business.

Benefits

Value is the subjective measure of benefits – the worth of combined outputs. It is:

• what is being realised and the process of realising them is product management.
• what may be realised because of new features – new things the users can achieve.
• what are the quality (positive or negative) that renders something desirable or valuable. ?

Products can therefore have both value and benefits. A products goals/objectives and success criteria can be derived and tested against these values and benefits.

Value and Product Management?

Project leadership?determines why and what work should be undertaken and fiercely protects value. If our success criteria or story moves us away from our value proposition, then it needs to change. Leaders ensure the team focus on the priority of what to build and what the team continue to build according to agreed value outcomes. In a way Product Management applies the necessary governance by continually evaluating value creation (current stage/status) and directing value creation by setting goals.?(e.g., EDM01-EDM05 in COBIT)

Value classification

Value can be created and classified as single or a group effort, for example:

1. Discreet value – separated values from the overall organisation or initiative
2. Synergistic value – coordinated value over multiple teams
3. Co-created value – leveraged value created by an input of stakeholders

Value components

When we think of value, we can attribute the value to a particular component to help us focus on how to describe it. For example:

• Quality - How well should this be done. These impacts time
• Cost – Does this lower/avoid costs or increase/protect revenue. Is the cost of the product overpriced for the market?
• Safety – Does this remove risk
• Features – Can we realise new benefits\productivity
• Schedule – Will this reduce the time required to deliver or allow us to be more productive.

There are multiple ways of looking at value from an organisational perspective which may influence/skew the importance of the value components. Financial value/ Future Value / Internal Value and customer Related Value vs delivery time frame/cost.

Value Metrics

We can address the subjectivity of value by creating metrics and measurables. It’s said “You can’t improve what you can’t measure” so it may be useful to attribute metrics to make sure we are not going in the wrong direction. If this is a worthwhile exercise involve your team in thinking about the definition of the:

1. units of value delivery (e.g., number of subscribers, hours saved in the process).
2. value of the product increment in specific units (e.g., 17 new subscribers once deployed).

Value stages

We can measure value in stages alongside product development, such as:

• Available?- can the product readily be used?
• Useful??- will it work as promised?
• Used?- are the people using it well?
• Valuable?- does it help our customer?

And finally

Bringing it all together – a very long post for a very simple statement – we need to understand the primary value for any project so that we will not be shaken from delivering a better product and delivering well.

Some practical tips:

1. Define your value as a short statement from your product vision.
2. Categorise the value using a value component.
3. Fiercely, continuously, protect value - weigh backlog items against it
4. Understand what stage you are at, consider metrics as a way of gauging value realised.
5. Be mindful if you have multiple stakeholders. Align perspectives on value

References:?

Thanks to CSU IT Masters Project Leadership (Brenton Burchmore 2021) and the following others:

• Kerzner, H. (2015) Project Management 2.0, Wiley. Chapter 4: Value-Drive Project Management
• ?The Real Difference Between Features, Benefits, & Value (linkedin.com)
• Better Software: Agile Governance: Value Metrics That Work
• Perri, M. ?(2018), Escaping the Build Trap, O’Reilly
• COBIT 2019 ISACA

Full post here (Edits and co-authoring thanks to Kristofer Liljeblad and Sonal Patil)