When the Struggle Is Real
There’s one time it makes me happy to hear about people struggling: when I come upon a new product designed to help those people. Most teams launch their product by telling you about the awesome, shiny features it offers. But without enough organic demand from real people, a shiny new product is not long for this world.
Those familiar with Lean Startup, Customer Development or Jobs to be Done already know entrepreneurs need a very clear sense of the problem their product solves. In our work, we’ve found it useful to co-opt that struggle and use it as a framing device to structure conversations about the product’s feature set. That may sound obvious, but it’s far from common.
Opening on the Struggling Moment
Instead of discussing customer problems in a broad sense, we’ve learned to target a specific struggling moment. You want to be able to call out a point in time when an actual human being experienced a problem while trying to accomplish some goal.
When it comes time to demo what we’ve built — whether we’re seeking feedback or recapping what we’ve accomplished — this is literally where our story begins. We select a single persona (e.g. an inside sales representative), briefly describe the scenario they’re in at this (fictitious) moment, and show step-by-step how they dig themselves out of that hole using the tools we’ve built.
Depending on how many features there are to cover, you may need to repeat this process a number of times. In that case, you’ll want to put some thought into which scenarios you discuss first.
Why This Method Is Better
Most teams fall into the trap of driving the discussion from a flat list of features:
- Here’s Feature A
- Here’s Feature B
- Here’s Feature C
Our outline is more like this:
- Here’s Scenario 1, in which you need Feature A
- Here’s Scenario 2, in which you need Feature A configured differently
- Here’s Scenario 3, in which you need Feature B
- Here’s Scenario 4, in which you need Feature B configured differently
- Here’s Scenario 5, in which you need Feature C
- Here’s Scenario 6, in which you need Feature C configured differently
Since our teams build enterprise apps, we usually deliver software with some room to be customized or configured. It’s not uncommon for these configurations to have a major effect on the outcomes created by our tools.
This additional factor really put a fine point on the need to sharpen our narratives: why (or when) is the configurability needed? Who wants that? How many options are needed? There’s no way to answer those questions without a meaningful discussion of the demand side of the product.
Evaluating the Solutions
Products often include many design choices (beyond configuration) that only seem relevant when you consider the context of usage. Amazon’s Alexa-powered Dash Wand is a recent example; it’s a device that lets you reorder household items the minute you realize you’re “running low.”
Once you see it’s meant to be used in the kitchen, it makes perfect sense that it’s magnetic — you keep it right on the fridge. But if I tried to tell you about a bar code scanner for your home, and mentioned it was also magnetic, neither of those points would make much sense out of context.
Amazon regularly uses videos showing struggling moments to explain why you should buy their newest gadgets. Stripe does the same. LinkedIn used a storyboard to literally illustrate the key use case for their Lookup app.
Follow their lead and focus on the struggling moment both in your marketing collateral and in your internal discussions of your product’s feature set. You’ll make smarter, more grounded design decisions and buyers will better understand how you can help them.
Show them when it hurts. What’s the moment?
