That’s Solutioning!

“Pain-Driven Design” is a great name for the discipline required to build the right thing rather than building the wrong thing the right way. Laura Klein defines this methodology in her book UX For Lean Startups, which you should add to your reading list.  “Pain-Driven Design” captures perfectly the heart of how product innovation needs to proceed when following the principles of the Lean Startup movement. Be forewarned, it is simple to understand but requires enormous discipline.  I have seen it done very poorly or completely disregarded by dozens of companies of all sizes. 

The steps are:

1. Validate the Person – Be specific about the person you are planning to help (as an archetype and anecdote for a sufficiently large audience of people with behavioral patterns in common).
2. Validate the Problem – Understand the pain experienced by the person in step one.  Listen to them.  Watch them.  Learn from them.  If you already have a product, learn what they hate about it.  If they use your competitor’s product, learn what is imperfect about the way it solves pain for the person.
3. Hypothesize the Solution – Now you think up a solution.  Once you have a specific person to empathize with, communicate with, and build a relationship with (as a representative of a group called a “target market”) you can truly understand their pain and address that pain.
4. Validate the Hypothesis

Of course, I entitled this post “That’s Solutioning!” so let’s start over at the problem phase.  The reason most product innovators fail at solving pains is that they are too busy solutioning to notice all the pains in the first place!  While facilitating groups in enterprise software customization, I saw this all the time.  The discipline required to truly analyze the pains and painful inefficiencies locked away in a workflow – physical or virtual, while shopping or at home or on the job – is tremendous when we are all so excited to get our ideas out there!  I had a colleague who could jovially point right at someone and say “That’s Solutioning!” to keep the group on track.

Obviously (in retrospect), when I wrote about my perfect agile process, I glossed over the critical difference it makes to empathize with a real person to understand their pain.  This is the test every “idea” in the Idea Backlog needs to pass prior to validating hypotheses, experimenting, or developing anything. 

It was nice to see I’m not alone in thinking this way:

The vast majority of time I talk to entrepreneurs, they present me with solutions rather than problems.  They say things like, “I want to add comments to my product,” not “My users don’t have any way to communicate with one another, and that’s affecting their engagement with my product.”

By rephrasing the problem from your user’s point of view, you help yourself understand exactly what you are trying to do before you figure out how to do it.

– Via UX for Lean Startups by Laura Klein

This is the part of Product Ownership – more specifically, backlog grooming, prioritization, and decomposition – that ought to happen prior to Sprint Planning.  This is part of the “half her time with stakeholders” that should occur. It should be a significant amount of effort ensuring the market risk of building the wrong thing is overcome prior to mitigating the technical risk of the team’s ability to build the feature or the project risk of aligning resources and timing.

Here’s how to know an idea, an epic, or a user story has failed the Pain-Driven Design process:

• If I say my target user is “women with an iPhone” then I’m not being specific enough.
• If I state my solution without a problem then I’m not empathizing enough.
• If I build a feature without empathizing with a person, my work is meaningless and my solution cannot be properly validated or a source of disciplined learning.

Imagine a bridge.  Everyone else who read this probably imagined a slightly different bridge.  What you most likely did not do is imagine a person who experiences pain crossing a river.  However elaborate your imagined bridge was, however perfect your engineering certainty about its development you may be, however robust your process for ensuring timeline and budget – that bridge is meaningless on its own.  That is the essence of solutioning: a decontextualized answer.

Do this instead.  Imagine a mid-twenties mother of one on the prairie in Kansas during the 1870’s.  Imagine a stream, only two feet wide but ice cold.  She jumps over this stream on her way to town, holding her child, husband by her side, every Sunday.  As the child grows and becomes heavier, jumping over the stream becomes more painful.

Now you have context.  Now you have a User Narrative and a person to empathize with.  There is a real pain that you can solve.  You can write a meaningful user story in-context: “As a mother on the prairie, I want a foot-bridge I can cross on the way to town because I’m starting to experience back pain that might hurt my ability to support my family’s health and well-being.”

Contrast that with an eCommerce executive yelling “We need SOCIAL!”

Don’t be that guy.