Master the ways of talking business value and stakeholder needs

Andre Muscat -

Why did I choose to read this book?

Business leaders talk in terms of alignment, prioritising business value and de-risking to achieve their business objectives. But what does this even mean to:

Words such as "value", "risk", "ownership", "purpose", "accountability", etc. are often overused, misapplied and misunderstood by the very individuals that need to:

  • Reliably do their job to expectations, on time, repeatedly.
  • Be proactive in detecting and addressing shortfalls.
  • Identify and escalate new opportunities that excite stakeholders and create experiences that wow.
  • Engage stakeholders effectively to enable transparency in progress, continuous feedback, and ongoing project de-risking.
  • Swiftly change their ways of working to achieve more substantial outcomes.
Business value is often a misunderstood concept in the IT world, yet we all agree that delivering it is our goal as technology leaders.


Digital businesses embrace modernised working methods, leveraging Agile manifestos and DevOps practices to enable intentional, swift changes in direction and modernising ways of working. Agile and DevOps approaches all HEAVILY RELY on the organisational leadership to have a clear definition of purpose.

Agile and lean approaches take a particularly strong stance that value delivery is the main objective, trumping the importance of adhering to cost or schedule milestones.

With this purpose set, one can work backwards to identify a collection of priority pieces of work which, when delivered in a particular sequence, enable the business to grow, realise value and access additional levels of investment:

Imagine the various stakeholders in your organisations and how they prioritise work in a backlog. Depending on their role in the business, they will have different perspectives on the relative priority of stories. Using an example:

  • Support thinks addressing bugs and issues should be done first.
  • Innovation teams think UI/UX upgrades should be handled with priority to drive new wow experiences.
  • Compliance thinks risk stories should be done first.
  • Ops chooses automation, maintenance and bug fixes.
  • Delivery picks technical debt.
  • Management says "strategic initiatives" and "New features that sell" trump all else.
A good understanding of business value is critical to Agile practice…To say that we want to deliver business value is to say nothing much except that we want to do the right thing, do lots of it, and do it quickly. But this does not help us understand how to select and prioritise features.


The expectations businesses have from their teams around priorities, accountability, de-risking pro-active work improvement etc., all rely on their ability to rally stakeholders around a common understanding of:

  • What aspects of the business are worth being worked on to improve (and to what level).
  • The drivers behind priorities set.

And here lies the key trigger on why I chose to read this book. I wanted to:

  • Refine my language around understanding how other people identify and talk about business value.
  • Challenge my ways of defining, discussing and prioritising business value.
  • See if there are lessons learned I can pick up to be better at what I do.

The book in 3 sentences

  • Business value is not to be confused with stakeholder value, customer value or stakeholder value.
  • Modern business value is a hypothesis held by leadership to make informed decisions and create a context that drives priorities and enables cross-functional behaviours that teams can use to self-organise and accomplish the organisation's goals.
  • Combining agile, context, experimentation with various metrics, we can continually clarify our understanding of the business value we need to achieve and how to deliver it.

Impressions

The book predominantly explores the difficulties IT departments have implementing scrum/agile in a context where:

  • Technical debt and non-functional requirements don't seem to be adequately prioritised by their Product Owners.
  • Priority decisions tend to perplex the people implementing the necessary updates.
  • Even though developers follow the backlog prioritisation direction, they still get complaints about their outcomes' low value.
Otherwise said, if producing business value is the goal of Agile practices, we ought to know what it is and how to achieve it.


This same narrative can easily extend towards:

  • Product Development teams in charge of developing shippable value to customers globally via on-premise or SaaS offerings.
  • Digital Leadership competing for budget allocations to accelerate their digital transformation initiatives.

The book helped me explore a vocabulary that:

  • Recognises that the definition of Business Value is vague across stakeholders and is difficult (not impossible) to measure objectively.
  • Enables a better analysis and articulation of business impact against desired work outcomes as applied to business assets, customers and stakeholders.
  • Facilitates better communication across various stakeholders across technical and business domains.
  • Identifies how bureaucracy, set practices, workflows and governance are representations of the codified business value of the past and should never be ignored. Instead, it would be best if you understood the underlying intent and value. You can then decide whether there is an alternative way to create that value (process, tooling, automation, etc.) or whether you continue with the established method based on your newfound understanding.
  • Emphasises that teams with rich contexts around the value their work provides, when done within key parameters, what KPIs they will impact (leaving them figure out the how) are much more productive and innovative.

The book does not present/explore a solution for approaching the definition of business value or prioritising work accordingly.

It does solidify the importance for people leading product strategies (Solution Strategists, Digital Leadership, Product Managers, Product Owners etc.) to

  • Tag and define top value themes the business values and is interested in investing in (these vary by business, and I am happy to explore them in a separate post)
  • Share context and knowledge on how they got to the resulting prioritisation with their stakeholders.
  • Be in continuous close contact with customers, business leaders, operators and other stakeholders.
  • Mesh the resulting research and data produced from support organisations and product telemetry to measure take rate and other user behaviours.
  • Marry market directions, take rates, technical debt priorities and growth drivers to prioritise against value themes that matter for the business.

This approach, in turn, helps individuals and teams:

  • Focus on a precise set of goals, even when working on separate projects asynchronously.
  • Prioritise and accelerate informed, and decentralised decision-making
  • Align and communicate.
  • Focus on impact and sustainable capability-led growth.
  • Master the ways of talking about business value and stakeholder needs.

The ability to identify what is valuable (or not) to you, your organisation, your customers, your partners etc., has implications both on your personal and professional life. It impacts the way you measure success, your velocity and your sense of urgency.

When someone successfully realises value from a relationship, knowledge, business engagements, product features etc., they are swift to renew and extend agreements beyond the initial periods.

Who should read it?

There's no limit to who should read The Art of Business Value. We're all interacting with people who are engaged on a personal or business growth journey. This book is inherently about how we look at problems presented to us and engage in decision-making.

You will enjoy this book if:

  • You are a product owner, or product manager focused on delivering works agreed to while managing your customer engagements and business expectations.
  • You are a consultant helping customers understand the realm of opportunities available to them as part of a Digital Transformation journey.
  • You are operating in a business development role, managing opportunities.
  • You care about how IT can effectively support you to improve and accelerate organisational desired outcomes.
  • You are diagnosing support tickets and providing a narrative/context to an escalation.
  • You are part of a team in charge of delivering a scope of work as an outsourced provider to achieve a desired set of outcomes.
  • You want to strengthen your influence and ability to support your arguments with data aligned to business purposes.

How the book changed me?

In its delivery, I found the book engaging and easy to follow. It solidified my beliefs and sharpened my vocabulary and mental model to engage in business discussions around value with delivery teams and extended stakeholders.

I particularly liked the way it differentiated between business, customer and stakeholder value. If the company only focuses on what users consider to be valuable now (generally captured as a backlog of feature requests), agile teams could be:

  • Rehashing the old ways of doing things
  • Making the product more complex to use
  • Increasing the code footprint to bug fix and maintain
  • Increasing complexity to address technical debt

This approach limits the business's ability to innovate and stay relevant in the market and transform its business truly needs to compete and grow.

I also highlighted the following as personal reminders:

  • Determining/Demonstrating business value from initiatives is the most critical and challenging issue modern leadership faces.
  • Agile and DevOps practices are here to stay supported by the need to change direction quickly while remaining in control.
  • Waste has no value to the customer

Key Notes

Setting the stage

Agile and Lean practices are all about maximising the delivery of business value.

  • While they tell us that business value is essential, none of them tells us what business value is or how one goes about articulating it.
  • Business value, customer value, user/stakeholder value are used interchangeably, but they are distinct.
  • High-level business goals like "maximising shareholder value" is challenging for stakeholders who are not investors to translate into concrete measures of Business value.
  • Interpretations of business value are not always explicit and often need discovery.
  • Traditional financial measures provide limited use and context in the prioritisation process. Using an example, ROI does not consider the timing of profits, risk of expected returns, or accounting of profits.
  • Some areas are also near-impossible to quantify, such as work designed to reduce technical debt, meet compliance requirements, freshen user interfaces etc.
  • To understand the business value a piece of work returns, we need to expand our understanding of the organisation's goals and its key stakeholders and use data collected from the organisational systems as indicators of value. For you, this means we need to talk to many more experts and stakeholders to reduce uncertainty in our decisions.
  • Talk with as many stakeholders as you can across as many demographics as you can. Include C-Level, Management & Leadership, Individual Contributors, Partners, Customers, Reporters, Bloggers. Ask, what is essential to the business' functioning? Prioritise a list. Ask, what KPIs and metrics indicate success to the business?
  • Not all data is quantifiable. Some of which may not be or not be of value to make it.
  • It is unreasonable for the business, its leadership or the product leader to have all the information required to prioritise stories effectively. Instead, the team is more enabled by having cross-functional representation and together own the discovery of value and Cost to realise.
  • The organisational culture and rules must embrace agile approaches to hypothesise, test, modify, deploy broadly, measure outcomes and repeat.
  • Be mindful of culture, its impact on the velocity at which you can accommodate agile practices.
  • Legacy architectures are often considered negatives and obstacles to progressive, competitive relevance.
  • Set processes and architectures enable businesses to operate in a manner that allows them to de-risk from repeating past failures and achieve repeatable, scalable outcomes.
  • Culture and set processes contain clues to what the organisation values.
  • Processes allow organisations to operate fairly, free of emotion and within the compliance requirements of their industry.
  • Existing processes act as "muscle memory" of past business value and should be considered in any transformation project or work that can impact such established procedures.

Business value in terms of cost of delay

Business value in terms of scenario planning

  • Developed by Pierre Wack - https://www.sciencedirect.com/science/article/abs/pii/S001632871530015X
  • Examining the drivers that will impact the organisation in the future
  • Based on those drivers, create plausible scenarios related to that decision at hand (e.g. against the probability of scenario happening and evaluating against parameters such as complexity, likelihood, impact).

Business value in terms of options thinking

Land and expand

  • Embrace Experimentation
  • Shorten feedback loops through a continuous delivery pipeline.
  • Assemble cross-functional teams.
  • Assign the product owner as a member of the team
  • Let the team self-organise and select its leadership, and advocate for the work to be done.
  • Move towards smaller, continuous batches of work against which to measure outcomes and value to stakeholders.
  • Capture data and metrics produced from internal systems as people do their daily work.
  • Examine culture, compliance and accounting with a critical eye to identify opportunities to eliminate waste without impacting the businesses ability to deliver value.
  • Use Impact Mapping to find things that affect value but are not features.
  • Consider Cost of Delay when prioritising.
  • Recognise the economic value of the Enterprise Architectures.
  • Approach IT as a business asset rather than a specific cost against which to measure project returns.
  • Approach work in terms of the value they add to your business assets (Core product, Value Chain, Organisation value)
  • Consider the value of data and knowledge encoded within your existing systems. Develop ways to extract knowledge to create dynamic views for your teams.
  • Drive change by pushing outcomes rather than requirements.
  • Incentivise teams to fail productively.
  • Shorten the investment review cycle through continuous transparency.