On user needs and listening to customers.

I've discussed a number of topics recently from the terms I use in mapping, to the importance of position and movement and the difference between context specific play and universal doctrine. Now, I'd like to turn my focus to one of the most important parts of mapping - the anchor.

A map contains a chain of needs described with the concept of movement (i.e. evolution) but the most important question of all is where does this chain of needs start from? To begin with, lets looks at that strategy cycle again but this time focus on purpose.

The Strategy Cycle

One thing to note is your purpose is not fixed but transient. It is altered by your actions along with the actions of competitors e.g. Nokia was a paper mill but at some point, someone decided it would become a plastics manufacturer. There is no such thing as "core" in business, it's just some things are more transient than others. The willingness to accept this, to identify and exploit new opportunities and abandon (or at least diminish) past focus is known as the Pivot. Ask Twitter (from the famous MP3 sharing site by Odeo) or Flickr (from the gaming company Ludicorp that failed to produce the game).

Secondly, your value chain (which I describe using maps) is not isolated but part of a sea of value chains. The outputs from your value chain maybe used as inputs into one or many other different value chains. Naturally, others outputs will be your inputs.

Hence a couple of things. Since your user need is normally the input into someone else's value chain then your user need is a component. This means it can be of any type (e.g. activity, practice, data or knowledge) or combination thereof. This also means it evolves as with all other components.

Those inputs can be to value chains of companies or end consumers (the public) or even your own staff. Therefore the position of pieces on the map will often change according to which user perspective you are looking at. In order to simplify I examine the customer of what we provide and then add onto the map the needs of other types of users. I also ask the question "Do they need us or do we need them?"

Hence, in Fotango, we needed engineering staff to provide the components of our services. Those engineers had their own needs (e.g. a positive working environment, good pay etc). As CEO, I had a duty to not only meet the needs of our customers but also the needs of our employees. 

For illustration, I've taken a very simple map, added engineering and one specific need. Yes, you can argue about the position of pieces but that's the point of a map - it exposes assumptions and enables collaboration & challenge.

Now, the thing of "a positive working environment" can be an entire map. In other words, components in high level maps can be decomposed into multiple components underneath. Therefore maps are recursive and high level maps are like an atlas of the world whereas a low level map can be viewed as the equivalent of a street map or a building map.

In some cases a component will simply hide complexity (i.e. there are many components underneath this), in other cases a single component can be an aggregate of many. In the following illustration then accounting system is an aggregate of many components.

So :-

• what we consider "core" is transient.
• the focus of the anchor is user need.
• the user is primarily our customer (whether a company or public) that we are trying to serve the need of.
• the needs evolve.
• there are other users and needs which can be mapped (usually we need them).
• the needs are components consisting of type.
• maps have granularity and the concept is recursive.

Often we can find opportunities in not only unmet needs (things which should be provided but aren't) or in newly discovered needs (the uncharted space) but also within our value chains there are components that can be usefully provided to others but aren't. It should also be obvious that failing to meet the needs of your consumers when competitors do meet those needs is usually a bad idea.

But how do we work out those user needs? This is extremely tricky because we bring our own biases to the table. The first thing to do is to understand that you're talking about user needs not your needs i.e. you might need to make revenue and profit but that is NOT your user need. By meeting the needs of your consumers then you hope to make revenue and profit, not the other way around.

The best way I've found for determining user needs is to start by looking at the transactions an organisation makes with the outside world. This will tend to give you an idea of what it provides and what is important. The next step is to examine the customer journey when interacting with those transactions. By questioning this journey and talking with customers then you will often find what is really important e.g. the need to get from A to B plus the need for some social status from the thing.

You'll usually find pointless steps or unmet needs or unnecessary needs being catered for. It's really important however to distinguish between "What consumers say they want" and "What they need". This last part is a mix of data collection, art form, collaboration and discussion. I've yet to find a really good and consistent mechanism for breaking this out.

One mechanism I've found to be exceptionally useful, especially when dealing with corporations as customers, is to go and map out their landscape. In most cases I find companies have no idea what their user needs actually are and hence if you're a supplier to these companies then in discussions they are mainly talking about things they want and they think are necessary but with no real clue as to what is. You can often find entire new opportunities for business by mapping out their landscape if you're so inclined.

Discussion and data collection is a key part of this, so talk with your consumers, talk with experts in the field and try to refine the map from there.  However, here's the gotcha - in many cases they're all wrong! Gasp? What do you mean they're wrong! There are two important areas where invariably the consumers and the experts are usually wrong, they also happen to be two of most crucial for economic gameplay and survival. 

The first area is in stage transition e.g. when something shifts from custom built to product or more importantly from product to commodity (+utility). The problem is that the pre-existing installed base will have inertia to the change (more on the types of inertia here). Invariably they'll tell you they need a whole bunch of stuff they don't need because they're fixated on a legacy world of products. To see through this then you need to get to grips with co-evolution (more on this here) and realise that what they actually NEED is volume operations of good enough in the case of product to utility shifts. This is different from what they'll tell you. Be vary wary of the legacy mindset.

The shift from product to commodity (+utility) is an extremely large and profound change due to the number of value chains it can impact. Companies often get disrupted by this despite the fact that it can be anticipated and defended against. The problem is that companies have such poor situational awareness that they can't distinguish between the two most basic forms of disruption - unpredictable product vs product substitution and anticipatable product to utility substitution. For most, it's all the same. Failing to get to grips with this can break the company and this failure happens regularly at a very grand scale.

The second area to note is that of the uncharted space. These needs are defined (on the evolution curve) as being both rare and highly uncertain. Which means unless you're using an ecosystem play as some form of future sensing engine then you're going to have to gamble and there is no consistent way of determining what the user ACTUALLY needs. It's the same with any component in the uncharted space - you have to gamble and experiment whether than component is something you are building or a user need that you're trying to meet.

So lets think about those user needs. When it comes to dealing with them then there are three different approaches according to the domains of uncharted, transitional and industrialised (more on the terms I use here). These three approaches are :-

• In the uncharted space you have to gamble. Users and experts don't actually know what is needed.
• In the transitional space you have to listen. Users and experts can guide you to how to improve the thing.
• In the industrialised space, you have to be mindful of users and experts bias caused by the inertia of past success. You already know what is needed but it has to be provided on a volume operations and good enough basis.

If we go back to 2005 and when I started implementing the pioneer, settler and town planner structure (for details, this post from 2012 is good enough) then you'll note that under the "Happy with" section it says :-

• Pioneers should ignore existing customers. They don't have a clue. We're exploring the uncharted space.  No-one has a clue. You don't know what you'll find and what might turn out to be useful. Gambling and gut feel should rule your world.
• Settlers should listen to customers. Feedback, learning, constant improvement are your watchwords. Building what is useful is your motto.
• Town Planners should build what is needed, which often means overriding existing customers inertia to change. Volume operations of good enough, empires of scale are your creed.

There has always been method to my madness. Oh, and it should by now be obvious why building a customer journey is nowhere near enough to determine what you should be doing. It's certainly way better than not even knowing the customer journey but ignore evolution at your peril.

Customer journeys are a bit like value stream mapping - a great tool but highly dangerous as you can easily make ineffective flows more efficient or in the case of customer journey build for unnecessary or biased needs. Ditto with business model canvas, an excellent tool which should be used at the end of a journey for confirmation & checking and not the beginning. I cannot emphasise enough how important a bit of situational awareness is. This requires position and movement!

But also remember that maps won't give you the "answer". They are primarily a means of communication and learning, for highlighting assumptions and common patterns. There are no "perfect" maps (even in geography) and maps must always be challenged.

Lastly, as a reminder - all the mapping stuff is creative commons share alike. The only people who can truly effectively map an environment are those who are immersed within it. Which means YOU have to map YOUR environment. Don't try and get a consultancy to do this for you. Learn yourself.