What is Your Pain? And other Intelligent Questions (Part 1)

0
41 views

Share on LinkedIn

Rethinking the Business Requirement


Hypothesis:
Traditional approaches to capturing customer needs and/or business requirements do not produce repeatable results; which is why interventions to capture them must be constantly repeated over time.

We are all innovators and are continually forced to solve problems in our daily lives. We may not come up with breakthrough changes that transform the world, but we try to improve our lives; make things easier or better. I’m constantly trying to figure out more efficient ways to get the dishes cleaned or into the dishwasher, to no avail. They just keep piling up!

While we are often focused on our personal lives, where we tend to be consumers of innovation, we also need to consider our work lives where we may be tasked with making a process or procedure work better. Sometimes we hire consultants to intervene and solve problems. They are innovators too.

Everyone is an innovator; but everyone speaks a different innovation language; which is exactly why there has been no formula for either repeated innovation success, consulting success, or simply to target the right problems to solve on a daily basis. To change this, we need to change our impulsive behavior to solve long term problems with approaches that can’t see beyond the short term

The Enemy we call the “Short Run”

“But this long run is a misleading guide to current affairs. In the long run we are all dead.” ~ John Maynard Keynes

Customer needs are not variables like solutions are. They are the constants we input into the formula we use to assess value when we try to get something done. The perceived value will change over time as solutions change or emerge. If we treat needs as variables, as many product designers, service designers and even CRM consultants do, we end up seeing what looks like short term success; but more often than not we are doomed to repeat our failures a few years down the road.

History is ripe with excuses for not seeking a more quantitative approach to mapping the future. Constantly dealing with a limited set of short term needs is what leads overly educated folks to ask simple questions; such as “What is your pain?” How effective has this been for you? Your customer wants to help you with your solution, so they often answer in the context of a handful of things that are bugging them as they consume your solution, or a competing solution. They are also inconsistent in their language; with some being more technical and others dreaming of being delighted by Tinker Bell – or simply telling you they want a better experience.

This has all led to the ultimate in short-term fads called Failing Fast. While there is a process behind this, there is no control over the triggering event and as such, founders’ ideas are fed into the machine and the result is usually failure. Repeated failure. Lots and lots of failure. Just once I’d like to see a study on how a founder systematically and repeatedly created innovations that didn’t end up withering on the vine just a few years later. Go ahead and cherry pick a few and tell me exactly how I can use their approach to guarantee my long term future success. I’d even take short term!

Capabilities and Processes (the “Order to Cash” trap)

We spend an awful lot of time thinking about ourselves, don’t we? Certainly, we need to make sure we are efficient at what we do, and sometimes we even make assumptions about extra features that our customers might like (especially if it makes our lives easier!). We often present these as hierarchical capability maps in PowerPoint or Excel. They are very pretty.

While these maps typically reference standard industry domains and processes (L1, L2, L3, Letc.) the thing that happens when you attempt to identify requirements somewhere in the chain such as “Create Order”, what you get is current pain in language that a particular stakeholder uses to communicate. Much effort must then be exerted in order to translate and prioritize the various stakeholder outputs into a meaningful business requirement and scenario-based acceptance criteria (for you Agile folks).

“Our purpose here is to introduce a set of timeless standards that define the purpose, structure, content and format of a customer need statement and thereby to transform the art of requirements gathering, and hence innovation, into a rules-based discipline.”
Giving Customers a Fair Hearing – Ulwick and Bettencourt 2008

How many times do we need to go through the exercise of defining a requirement for creating and storing a record? It’s kind of a trick question; because what we’re really doing here is beginning to design a solution. I’m going to suggest, as others have, that requirements are actually a catalog of customer needs. Not just pain that we are focused on today; all of the needs. We need to understand overserved needs, satisfied needs and underserved needs. Why?

That’s simple, because what we really want to see is what describes how we define success over the long haul; not just today. Don’t fool yourself, you didn’t really tell yourself how much value you got when you closed on your first mortgage. You’ve got 20-30 years of opportunities to evaluate your experience as you continue your string of related jobs that started when you decided to purchase a home. (h/t to @GrahamHill for that thought).

We say we want to create long-term growth or long-term success (for ourselves, our companies, our clients); but our behavior often suggests otherwise. Once we begin thinking long-term, we must be able to map the part of the journey that doesn’t change over the long-term. Shall we?

LEAVE A REPLY

Please enter your comment!
Please enter your name here