Are your clients trying to tell you which requirements matter most to them? How can you target the requirements that give you the best value return? The Voice of the Customer process is a great way of balancing your users’ priorities and help you see where to best target your project investment.

I recently spent some time with a small IT Consultancy, helping them understand just how bad they were at listening to their clients. Whilst the team were proud of their “out of the box” IT product, I have to say that when it came to capturing their clients’ requirements, they stunk.

To even the most casual observer, the guys were too inward looking and tech-focused, concentrating more on polishing their product and aligning their clients to it than on understanding how the product could be customised to suit their clients’ needs. Something was definitely missing.

Their deployment approach was led by a handful of influential developers with strong views, without considering the increasingly frustrated feedback from sales representatives who were unable to offer a personal solution to clients. As a result, clients were not being heard clearly and the product had a “one dimensional”, “take it or leave it” feel.

Voice of the Customer – listening to our users

This situation throws up two challenges for Project Managers.

Firstly, how do we harness the voices of different stakeholder groups, blending their competing priorities and conversations into a single, textured narrative?

We undermine the quality of our outcome if we only listen to the loudest voice and ignore different opinions; a far better approach is to consult broadly and view the problem through a wide-angled lens. The best Project Managers understand this and spend time trying to understand their stakeholders – what matters to them, what their priorities are, where they are likely to see the best value return on their investment.

Secondly, how do we manage the product roadmap so that the right features are developed, at the right time, in the right order, so that we get the best market offering?

Whilst product development may not be thought of as a project management function, the Project Manager should sensibly understand what the product roadmap looks like when planning the most effective path to delivering target business outcomes.

My team’s challenge was to find a way to capture thoughts and feedback from a wider range of user groups, explore them in detail and blend them together into a body of substantial, integrated requirements. They had to find a way to understand how the users prioritised these requirements and as a result, where to focus their product development time and resources.

Whilst they knew the product roadmap inside out, they needed to step back and look at it from a different angle to see what was missing. The team was simply not hearing what their clients were asking for and instead, kept releasing features that they themselves felt improved their offering. Being a Six Sigma novice, I decided to take the plunge and play with the Voice of the Customer (VOC) for the first time. I can certainly say that along the way, I was frustrated, engaged, confronted and enlightened but at the end of it all, the clouds parted, the sun shone through the mist and I came to appreciate how important the VOC is in blending these two challenges. Phew.

In short, I am a convert.

So in the lingering glow of my happy VOC adventure, let me call out two lessons that left an impression on me.

  1. There is no standard VOC tool, so be prepared to build your own
  2. The VOC drives conversations, so be prepared to share it widely and talk to it regularly

There is no standard VOC tool (be bold and build your own) Surprisingly, I could not find a single, authoritative VOC model. Although there is plenty of literature, opinions and simple templates freely available, I was unable to point to a definitive version. Most online resources were simple tabular listings of client ideas and feedback that allowed the user to assign an owner and track them through to a unique requirement. That was a good start, but didn’t give me that sense of weighted priority.

This surprised me but in the end, opened up an opportunity to create my own.

We can start by extending the tabular listing into a simple matrix, listing client requirements down the left hand column, and technical/system requirements across the top row.

For each requirement, the users assigned a number (1-5) to represent how important that particular feature was to them, with requirements receiving a higher number to signify higher priority.

This is a better start because it allows the users to (1.) list their requirements, and (2.) prioritise them. Of itself, this is very useful – it gives users an opportunity to call out the things that matter most to them.

But the real business value arises where we can target the development towards the things that provide the best return on investment. To do this, we can mark the points of intersection on the matrix where the requirements align. Does a client requirement for a new product feature align with a system requirement for increased stability? If yes, then mark the intersection by summing the two priorities. If no, then leave the intersection blank. As we work through the matrix, we see a total score for each client requirement (row) and system requirement (column). In this way, we know two important things:

  1. The user tells us which requirements are more important, through a higher number – we can see which user requirements matter the most at any point in time
  2. We can see which requirements provide the best value outcome – the rows and columns with the highest total scores tell us where the best alignment is between user groups.

Interestingly, the two may not produce the same outcome. While the user will have requirements that matter to them, these may have few points of intersection with other users and hence may add little additional value across the firm.

VOC forms a living conversation (keep it close by and share it widely)

The VOC is not a “set and forget” document but rather, it frames a living conversation.

Over time, priorities change and requirements evolve. The VOC allows this by giving us the flexibility to add or remove requirements, change their priorities and reassess whether they add value by aligning with other user groups.

Use it to drive conversations and engage user groups. Call out the differences between high-priority user requirements and high-value product features.

This is gold. We can now use the VOC to (1.) direct product development and (2.) plan solution delivery around an integrated body of features that matter to the users and provide value to the business.

Bringing it all together The VOC is so much more than a dull spreadsheet and offers Project Managers a great way to engage users and shape their delivery framework. It extends the gathering of user requirements by blending requirements analysis, functional design, benefits modelling and implementation planning. Using the VOC process, we can see which features/requirements matter the most to the users, whilst also seeing which add value by aligning across other user groups. A fabulous process and well worth working with. Good luck!