The Goldilocks Effect: Crafting a design challenge that’s just right
As we continue to integrate design challenges into our innovation process here at ReadyTalk, it’s become obvious that the biggest challenge is in selecting the right challenge!
In our first go-around, I let my high falutin’ academic brain take over:
“how might we surface important information that individuals may not be aware they need?”
This is such a nebulous statement with so many assumptions, it’s basically not actionable. Thankfully, the design thinking process we went through had the time and space for us to realize we weren’t going to make much progress with the above statement as our guiding star.
After we reframed our goal, we were able to dig in and have a great sprint. But now we’re onto the next one, and I find myself once again grappling with how to articulate the challenge.
The Sprint book has a bit of guidance on the subject:
Go after [your] most important problem. Running a sprint requires a lot of energy and focus. Don’t go for the small win, or the nice-to-have project, because people won’t bring their best efforts. They probably won’t even clear their schedules in the first place.
So pick an important problem to solve. Got it. Should be obvious, but I think too often we may worry if we can ‘get enough done’ in a week to take on an audacious project. The sprint process is actually fantastic in generating a LOT of insights and momentum in a compressed time-frame.
Another bit of guidance is to start with the surface; “where your product or service meets customers”.
Human beings are complex and fickle, so it’s impossible to predict how they’ll react to a brand-new solution. When our new ideas fail, it’s usually because we were overconfident about how well customers would understand and how much they would care… Focusing on the surface allows you to move fast and answer big questions before you commit to execution, which is why any challenge, no matter how large, can benefit from a sprint.
Given that the final step is “test your concept with customers”, it makes sense to start with something customer-facing. Too often we can get wrapped up in whether we can achieve the solution technically, but design thinking and lean startup AND outcome-driven innovation all advise we first answer “should we” before we answer “can we”?
So where does this leave us? Well, we’re going to be doing a “pre-sprint kickoff” 10 days before the sprint with our Decider. We’ll go through a business model canvas and identify the riskiest assumption. That’s what’ll direct our challenge (and follow-on work).
What about you? Have you used other methodologies or tools to complement your design sprint for innovation?
Would love to hear about it!
