On my journey to value pricing, I’ve regularly seen and heard the term value conversation mentioned when describing early interactions with the customer.

To begin with, I thought this was just another name for the initial call or meet with a potential new customer. The usual meet-and-greet over coffee, getting a broad overview of their idea, listening to their requirements, and trying to formulate in my head (as quickly as possible) some solutions.

After a while, though, I began to see that these initial consultations were, at their worst, actually limiting my work and the value I delivered by solving only surface-level concerns — which often aren’t even a problem!

As I’ve had more and more of these initial conversations over the weeks and months, I’ve come to realise how different they are from a true value conversation.

Digging into the Problem

Let’s start by defining the value conversation as I’ve come to understand it: a true value conversation is far more exploratory, and goes into far more depth than a typical initial consultation — even though it may still be called as such.

By way of an example, I’ll summarise the typical traditional initial discussion I was using:

A potential customer would get in touch via phone or email with a brief outline of task they want to achieve. This may be a cold enquiry, or a referral. The potential customer may have idea for a new app; need some help with a specific technical issue; or even need some new work carrying out on an existing project.

After answering some initial qualifying questions via email, a phone call or meeting is booked to find out more about the project. What generally happened, though, is that “finding out more” is almost entirely focussed on the technical details of the initial enquiry.

The customer says they need a mobile app, so we start discussing what platforms would be best suited, what sort of infrastructure we might need , third-party API integrations, and so on. In some cases, we’d even start napkin-sketching some design and layout ideas (giving away value!)

As I gained more experience, I began to introduce questions to find out a little more about the problem (e.g. what made you think about this idea?, or what is the problem with the current app?), but invariably, any attempts to discover what’s driven the project were either limited to surface level problems — glossed over as a necessary evil, or even entirely brushed aside to get to the excitement of the solution.

At the end of all this, the potential customer asks for some “ballpark” idea of costs and timescales, and numbers are carefully considered plucked from the air and proffered. Even though they requested a ballpark, always know that the customer hears a final price.

After pleasantries are exchanged, some written communication and formalisation of the discussion takes place, and the project is either won or lost. Then we get to dive into the fun stuff (writing code, designing screens, pushing releases). Within a few weeks — once code has begun to generate results, and things are “real” — that initial discussion and the initial “problem” we set out to solve become a long-forgotten memory.

The real problem — lurking in the shadows all the time, but buried under layers of really great features — may never get solved. I’ve seen enough projects that start with such great intention, but go on to solve little or even nothing at all.

Clearly, this approach is damaging for everyone involved.

Focus on the Problem…

So let’s take a step back, and try to explain how a value conversation can help. The difference is in how the relationship starts. A real value conversation establishes a level of partnership between the customer and the consultant. It is in the consultant’s interest to dive as deep into the root cause(s) of the project — the real pain that it is trying to solve. Similarly, it is in the customer’s best interest to realise this themselves, and be able to talk with the consultant about it.

In this way, both parties are working towards a common goal rather than being at odds, and both parties can see the true value in what is being built. In the future, when questions arise about why something is being done, it can always be measured against that initial root problem, and approved or rejected. A bonus of this — for both consultant and customer — is that it can help to contain scope creep / scope seep.

So, in practice, a value conversation is far more exploratory than a traditional initial consult. The goal (as a consultant) is simply to listen, and keep questioning the reasons behind a customer’s problem. Solutions should be avoided at this stage, or kept minimal.

…but allow ideas to flow

However, in my experience, once some root problems have been uncovered, it’s inevitable that my mind starts thinking of solutions. These will usually be small ideas that may solve the customer’s problem.

For example, if the customer is looking to integrate some email marketing solution into their app, then one relatively simple idea is to use an off-the-shelf product or service, rather than writing their own, and having to deal with all the problems and ongoing maintenance that entails.

There are two possible outcomes here. One is that it’s something the customer hadn’t considered, and after some more exploration, it might be that that is enough to solve their need. Except for some short-term integration work, this would be a fairly trivial solution that gets the job done. The customer has received value from the conversation, and that might be as far as the project goes (for now).

Alternatively, they might put up a barrier to the solution — perhaps their IT department refuses to allow third-party systems to be integrated, etc. — and thus reveal a deeper problem to the consultant.

All of this is valuable feedback for the consultant, helping them to build a picture of the true value of the project and what they can deliver.

Actions

For a while now, with all of this in mind, I’ve been trying to move my initial discussions towards a value conversation model. Basically trying to shut my mind up (it tends to start hunting for solutions immediately) and take a lot more time getting an understanding of a customer’s real requirements.

An interesting outcome of this is that I’ve found myself actively trying to put off new customers — finding ways to talk them out of hiring us. If it wasn’t for Jonathan Stark talking about exactly this, then I would be very concerned that something is going wrong…after all, actively discouraging work is generally not good business!

But in my experience, doing exactly that has actually helped to refine the work I’ve taken on. It seems to help customers justify their requirements to themselves, and in doing so better ensures they are getting genuine value from working with me, rather than work for work’s sake.

My work has evolved to spending more time helping customers to understand their true need at these early stages of a project’s inception. The code is just an outcome of that understanding.

By obtaining a much deeper understanding of the problems behind their project, everyone is on the same page. We’re no longer jumping to solutions and chasing false hopes dreams. We’re consistently working towards a common goal and delivering real value, all from simply changing how we frame those initial discussions.

Have you changed your initial discussions to value conversations? How have you found the experience? Do you actively try to discourage new leads from working with you? Let me know by getting in touch.