Visualizing Strategic Objectives across Multiple Clients

For the past year or so, I have found myself in a situation that many Product Managers could probably associate to; our team’s main responsibility has been to look after a Web CMS platform – a platform that is being used by a number of different clients under the same roof (the company I work for in this case).

Even though the overall Technology Strategy is set at a company-wide level, the fact that most of our clients come from various market sectors means that all of them have their own unique requirements and roadmaps that need to be handled by a single team looking after a single product. On top of this, this platform  should remain as “global” and re-usable as possible, i.e. we cannot start introducing client-specific features without evaluating its impact to other clients.

As with most development teams around the globe, we also face the challenge of delivering maximum value at a minimal cost – in our case this means that we need to identify the features that are common across the majority of the clients and deliver top value. By addressing those items as a matter of priority, we manage to “kill two birds (or ten) with one stone”.

Even though the above statement seems quite straight forward and simple, I have struggled to find a quick framework that allows us to apply non-complex heuristics in order to reach a self-explanatory visual representation of all the information mentioned above. After quite a bit of thinking and failed trials, I’ve managed to produce the following (click on the image to enlarge or click here to view the high resolution PDF)

In a nutshell, the item with the longest bar is the one that is considered to deliver the best value across the majority of the clients – with value and benefits decreased as we go down the list. But how do we get the numbers to generate the above graph?

The Use Case

Consider the following Use Case:

1. We have a number of client. (9 in this example – don’t ask why!)
2. All clients are using our product and they all have features that they want to see implemented.
3. All clients their own priorities and roadmaps.

The Methodology

Please note that the methodology described below is empirical and is not derived from any established scientific approach. It’s a method that has been proven valuable for my team and I share it as an aid to other individuals that might be experiencing the same issues.

Step 1: Requirements Workshops (x9)

The first step would be to meet each client individually and get a high-level list of their strategic priorities. We shouldn’t delve into details at this stage – simple User Story statements should be enough:

“As a Web Admin I want to be able to serve personalized content to my Site Visitors based on their browser so that I can optimize my site for mobile devices. “

Allow your clients to present as many requirements/user stories as they want, but aim to keep these sessions time-boxed; anything up to 2hrs is acceptable in my opinion. Following this, you should have a nice a nice “bank” of user stories for all the clients.

Ultimately, those user stories are the ones that will end up in the left hand side of the bar on the graph, but we’ll get back on that:

Step 2: Spending Points on User Stories

The next step is to get your clients to assign points to their User Stories. This is a very simple but effective step and can be achieved as follows:

“Give” each client 10 units of currency – you can call that whatever you want! Those units represent the fact that technology budgets are always finite and have to be used wisely. I have personally found that many clients tend to treat Requirements Sessions as a “Fire Sale” where they can ask for whatever they want, regardless of its value. By using this method however, we force the client to evaluate the real value of an item

Ask your clients to “spent” as much as they want on each of their user stories – but the total amount spent should always be 10. Some User Stories can be left with zero points (“now that I’m thinking about it, that’s not so important”), or even a single User Story can be assigned 10 points (“I don’t care about anything else, I just want this feature done”).

This approach has the added benefit of being able to indicate the importance of each of your clients. If for one reason or another, one of your clients is more important than the others, you can give them more points to spend – just to mention it to everyone else!

Step 3: Time for some analysis

This next step is probably the most BA-intensive. Purpose of this step is to identify common patterns and themes across the overall requirements backlog. For example, let’s assume that client ABC stated the following:

As a Site User I want to be able to sign in using my Facebook credentials so that I don’t have to register with another party.

At the same time, client DEF has stated that:

“As a Site User I want to be able to sign in using my Google credentials so that I don’t have to provide my information to yet another site. “

As a Product Manager of a Development Team, you would probably treat the User Stories above as part of the same Epic User Story, titled something like “Sign In Using OpenID”.

At the same time, we can identify higher-level themes for each one of the user stories – for example, anything that has to do with User Profiles and Sign In could be under an “Access & Entitlement” Theme. After some effort you should have a fully categorised and grouped backlog:

Once again, this information is also captured in the graph as follows:

The colour of the bar indicates the “Theme” as indicated by the accompanying functional areas legend:

Having gone through this process, you will be surprised to find out how many “touching points” there are between clients that are seemingly very different.

Step 4: The Maths Part

The next step consists of some simple calculations that can be easily automated using an Excel Spreadsheet – in this post I’ll try to provide an overview of the different values we need to calculate:

Count of each Epic in the Backlog (Variable A)

The first number to calculate is how many times each epic appears in your “unified backlog”. This could be easily calculated using the COUNTIF Excel Formula:

Total Number of Points Assigned to each Epic User Story (Variable B)

The second number to calculate is the total number of points assigned to the Epic User Story (i.e. the sum of points assigned by all clients to user stories under each epic) . In this case, the SUMIF Excel Formula would be more appropriate:

On the graph, this is displayed as follows:

The “Overall Priority” Value

This is the last part of our calculations and it involves calculating a number the takes into account the points assigned to an epic as well as the number of clients that have requested features under the epic. The calculation of this value is straight forward and it uses values already calculated:
$x = \frac{A}{Z}(B)$
where
• A is the  Count of the Epic in the Unified Backlog
• Z is the total number of clients
• B is the Total Number of Points Assigned to each Epic User Story
On the graph, this is indicated by the length of the bar and the value appearing at its side:

The Summary

So there you have it – a visual representation displaying a wealth of information around user stories, epics, values and priorities – all using (very simple) maths and a few colorful bars:
What we did find is that such graph can spark some very interesting conversations between Business and Technology. It’s definitely not an artifact that can can replace roadmaps and backlogs however it allows the team to get some perspective and focus on what’s important for the business.