Communicate Business Value to Your Stakeholders

I’ll let you in on a secret: I don’t care what letter you put in front of ”DD.” I don’t care so much about how code is written or the ins-and-outs of software development. It’s not because I don’t realize how incredibly important it is – it’s because what I care most about is the value delivered. How can what you do save me time, money and/or frustration? I’m smart enough to know that without you – the incredibly talented member of the development team – my life will go into a tailspin. Nothing will work. I realize and appreciate that what you develop creates value for me.

So why is it then that when an IT team wants to really understand their stakeholders’ needs, improve perceived results, gain greater visibility from the organization,  increase the likelihood of getting more funding, or attract the most talented people to the project, they sometimes feel challenged? Because they have a tough time communicating the value they are delivering– or getting their stakeholders to articulate the real benefits they desire.

Stakeholders in your organization need to understand what it is you will do for them in a language that creates meaning for them.  And you need to help them do that. But how?

What’s in it for my stakeholders?

First, let me define ”stakeholders.” I like Scott Ambler’s definition: ”anyone who is a direct user, indirect user, manager of users, senior manager, operations staff member, the ‘gold owner’ who funds the project, support (help desk) staff member, auditors, your program/portfolio manager, developers working on other systems that integrate or interact with the one under development, or maintenance professionals potentially affected by the development and/or deployment of a software project.”1

So why don’t  your stakeholders always understand the value you deliver? Because often project leaders – even Agile project leaders – talk about their projects or processes in terms of features. It’s not their fault, stakeholders do the same. ”We need faster processes, better user interfaces, more efficient, system-supported workflows.” Yes, but what do these things mean for the stakeholder? What’s in it for them? And what does it mean for your organization as a whole?

You can communicate exactly what’s in it for your stakeholders by communicating in terms of benefits, not features.  Features are what your system or process can do. Benefits are why people care.

The most straight-forward definition of each (which comes out of the marketing world) are:

Feature: a characteristic that is special or important

Benefit: an advantage that is meaningful for your stakeholder

Frederieke Ubels, Scrum Process Coach at bol.com in the Netherlands, commented to me that she thinks of benefits as more universal: “Everybody wants to feel happy and safe, make money, have happy customers, etc. Features help to achieve benefits, but only if and when they are used – not so universal, more of the conditional kind,” she says. “Features can be used, but they can also not be used. It is up to you if you value them or not.”

Sell with the benefit; support with the feature

Marketers have been selling us the benefits since the beginning of time. I don’t really want the wheel, I want something that is easier to roll – or even better, makes transport easier so I save time and energy. I don’t want a new car, I want something that gets me from A to B quickly so I save time, is safe and looks cool so that I feel good driving it.

The same goes for projects. I don’t want to be able to search a certain way in a database. I want to get the information I need, when I need it, to save time and frustration. I don’t want to analyze customer needs. I want to satisfy customers, so they keep buying from us and my company makes more money.

Saving time. Feeling secure. Experiencing little or no frustration. Earning more money. These are the real benefits. These are the things that create business value. It is important that we know how to “sell” (or, as I’d rather say, “communicate”) the benefits to stakeholders.

It’s the benefits that connect with our emotions that create a desire for something. The relatively new field of neuromarketing explores how these connections work. Basically, when we create a tangible connection to something – especially something that connects to an emotion, or one that we can see, touch, hear, smell or taste, a memory is made that is embedded deep in the brain. It is also in this part of the brain where decisions are made. So, if you can find a way to connect on an emotional level with your stakeholder, you are much closer to creating understanding, having them on “your side” when you are looking for more resources or support, and working to reach your own value-adding goals.

But communicating the benefits is not enough. You also need to talk to the “logical” part of people’s brains that want the facts, the data, the research behind things. These are your features. They are all the capabilities that enable you to deliver the benefit – the business value to your stakeholder.

Start by talking about the value you deliver and support your messages with features. As you get better at this, you can steal from marketing experts who tell stories that fit the stakeholder’s world. A story that clearly shows you understand what’s in their heart and mind.

For example, one such story (slightly exaggerated) might be:

“In a time only a few iterations away…our CRM clients will be able to turn on their PCs, and immediately search and find the customer information they need in any form. It could be a shipping address, their very first purchase order, a list of most-often purchased items. They can cross-reference against other orders, including other customers in the same company and with outside companies and see trends.  They will become smarter, more relied-upon CRM representatives and their customers will be ecstatic. Our CRM clients will become rich and fulfilled and, in turn, so will we. Together, we will all live happily ever after.”

Question until you get to the benefit

What if you don’t know the benefit? Or worse yet, what if you’re stakeholder does not know the benefit? Then you need to ask a lot of questions. If you prefer the “5 Whys”2, use it. If you want some ideas to question in a more conversational style, try the following:

“So what?” questions to understand the benefit

(assuming your stakeholder knows what the benefit is)

• What’s in it for my stakeholder?

• What’s the purpose of the (feature stakeholder wants)?

• What do you (the stakeholder) want to be able to do?

• What advantage does this (feature) bring?

  
  

Questions to help your stakeholder discover/understand the real benefit (business value)
(assuming your stakeholder cannot articulate what the benefit is)

• Why would I (stakeholder) want or need this?

• What can I (stakeholder) do with it?

• Why is this (feature) better than others?

• Why should (the stakeholder) care about this (feature)?

To get at the real benefits (business value), ask why each feature is included to begin with. Then, take that answer and ask how does this connect with the stakeholder’s desires? This will help you get to the what’s in it for the stakeholder at an emotional level.

There can also be situations where you have more than one stakeholder – and they may not necessarily agree on what the real benefit is, for instance, a customer service manager may say “having satisfied customers who make repeat business” is the benefit. While his director may say the benefit is the revenue earned (and not the happy customers). In this case, you could argue that you need happy customers in order to make money. Question until you understand what the main benefit is. And if you need to, you might create a ‘hierarchy of benefits’ that can then be supported with specific features.

User Story format as a starting point

Coming from the non-IT world, I know nothing, really, about software development. But having worked for more than 20 years in marketing and leadership and change communications, I do know the value of communicating in terms of benefits. “Start with the benefit message,” I always advise my clients. “You need to get people to care about what it is you are doing for them!”

Clever minds like Chris Matts3 and Andy Pols3, Dan North4, Liz Keogh5 and others talk about Behavior-Driven Development and Stakeholder Stories (rather than User Stories) in order to understand the business value a stakeholder is looking for.  The common User Story format is a good starting point. Teams are trying to get to the benefit.

As a (role, persona),

I want (goal, what will the feature do, why is it useful),

so that (benefit/business value).

However, from a pure communications perspective, it is not surprising that looking at the common User Story format one would quickly suggest turning it upside down – (and is what I now know Chris Matts suggested in 2008). Here’s my version:

We will (benefit/business value)

for our (role, persona),

because we have (what will the feature do, why is it useful).

Or simply skip the “I want” part of the common User Story format to focus solely on the end-user and the benefit. This puts the least constraints on the team, since no features are even mentioned.

And, here is a simplified example that some Siri developers at Apple could have worked with:

As an end-user consumer,

I want to be able to make changes to my calendar and search without having to type on my iPhone, because it saves me time and hassle. (It’s also safer if I happen to be driving.)

A stickier way of communicating this, so that the benefit comes first, is:

We will save time and hassle, and increase safety

for our end-user consumers,

because we have an “intelligent personal assistant” that can make changes to calendars and search using a natural language user interface.

I’m not proposing that using the benefit-first is necessarily the “right” way when it comes to software development. What I am saying is: starting with the benefit message is the way to effectively get to and communicate the business value.

Making the benefit message stick

When I’m working with teams who are having difficulties getting their stakeholders to understand the value of their projects, it is usually because the team does not know how to communicate in terms of the value they are delivering. Understanding what the value is and then starting with the benefit message are first steps. But how then, do you make the message top of mind for your stakeholder, so that your stakeholder can also communicate the business value of your project to others inside and outside of the organization? You do that by increasing the stickiness of your message.

After working as a journalist and then as an executive communications coach, I’ve seen the effectiveness of using simple, easy-to-understand messages that convey significance and motivate to action. However, in Made to Stick6 by Chip Heath and Dan Heath, they outline succinctly what I have been teaching for years.  Here are their “Six Elements of Stickiness” to make messages memorable:

1. Simple – what’s the most important thing to remember?

2. Unexpected – how can we grab the stakeholder’s attention?

3. Concrete – what is the context that makes the benefit relevant?

4. Credible – why should stakeholders believe this?

5. Care – what’s in it for me the stakeholder?

6. Act – what should I do now?

   
   

The idea is to incorporate these elements into your benefit message in order to make a real imprint in your stakeholder’s mind. Even the best messages do not have all of the elements, but they usually have three or four.

I worked with an IT team responsible for developing a patient tracking system for a large group of hospitals.  They were not getting the support they needed from their stakeholders, and they were not communicating the value they were delivering. After getting to the benefit and thinking about the value they delivered in a ’sticky’ way, the team came up with the following:

Our system saves lives. Doctors and nurses anywhere in the country have quick access to patient records. With a single sign-on, they can get an immediate overview of each patient’s conditions and medications. They can feel secure in knowing they are giving their patients the best medical care possible.

This message contains the following elements:

• SIMPLE, CONCRETE, UNEXPECTED (”Our system saves lives.”),

• CARE (”They can feel secure in knowing they are giving their patients the best medical care possible.”)

• ACT  (”With a single sign-on…”)

  
  

The advantage is that the benefit message is powerful and easy for the team and stakeholders to remember and articulate. It serves as the basis for every communication that is made about the value the team is delivering with this system.

Enhanced communications builds trust

So what is the benefit for you to improve your communications about the benefits of your project with your stakeholder? The biggest benefit is around building trust. In order to figure out the value for the stakeholder, you need to have (or at least start building) a relationship with them. This happens through the benefit communications process. And when you talk about the benefits of your project in a language that resonates with stakeholders, it helps them to trust you – especially when you deliver that value. It becomes a self-perpetuating cycle, the more you talk about the benefits (or business value) of your project and when you deliver those benefits,  the stronger your relationships with stakeholders become, and the more value you are able to create.

Practical tools to increase understanding

The next time you are working with your stakeholders to gather requirements, start by talking about the benefit or business value. Make sure the benefits are real. Making a visual representation is an excellent and very Agile way to create a common understanding of these benefits. (Effect Mapping7, other types of mindmaps, and vision boxes can help the process.)

Here’s an example of a vision box for a large company in Denmark. They have the project’s brand and logo on one side, the other has benefits, the sides you can’t see have the features.

Some last advice, increase communication effectiveness between teams and stakeholders by:

• Understanding the real benefit

• Supporting with features

• Asking questions

• Creating your benefit-first user story

• Profiting from making your benefit messages stick

• Focusing on building trust through the process

  
  

See for yourself the difference communicating business value will make in creating better understanding, achieving goals together and working in relationships of trust.

References:

1. Active Stakeholder Participation: An Agile Best Practice

2. 5 Whys

3. Business Value Driven Software Development

4. Introducing BDD

5. They’re not User Stories

6. Made to Stick 

7. Agile product management using Effect Maps