Insights

Failure – an inevitable part of innovation!

Our Design Thinking team recently held a Twilight Session sharing valuable first-hand insights and lessons learnt.

Simon Holbrook

Simon Holbrook Head of Design & Innovation

simon.holbrook@assurity.co.nz Follow me: Linkedin

Failure – an inevitable part of innovation!

Date: 23 June 2017

Our Design Thinking team recently held a Twilight Session sharing valuable first-hand insights and lessons learnt.

Our Design Thinking team recently held a Twilight Session sharing valuable first-hand insights and lessons learned through applying design processes in business, providing links between Design Thinking and Agile, along with a hands-on activity to take home practical steps to make a meaningful impact on the business. Here, we recap the session for those who couldn’t make it. You can see the full session here.

Before getting to the crux of the session, let’s explore what Design Thinking is

Design thinking is a repeatable problem-solving process that focuses on discovering desirable solutions for our customers.

It is action-oriented and can be applied to any manner of business problems, from designing organisational strategy through to tactical solutions.

It will allow you to routinely innovate and continue to unlock opportunities once all of your greatest ideas have been exhausted.

Design Thinking always begins with empathy, seeing your problems from the point of view of the intended user. The user or customer is not bound by the same constraints as you, often bringing clarity and a fresh perspective to problems, inspiring new directions and pathways.

The real needs and challenges of your user are then defined, before many options, and potential solutions are created within ideation. This is done purposefully to prevent teams from falling into familiar traps of solving problems the same way every time.

Finally, our best-bet concepts are prototyped or built in some way so that the user might interact with them. In effect, we are building to think and learn, moving far beyond perceptual debate and opinion towards hard results and customer feedback to direct our efforts.

Lessons learned #1: Minimum Viable Empathy

How much empathy research is enough? It depends on the scale of the challenge.

Be mindful of just getting enough data to move forward in the design thinking process. Don’t get bogged down trying to be too exhaustive. You don’t want empathy to become the new bureaucracy.

It’s what you choose to do with the data that is more important than collecting it. We usually find within eight interviews we start getting ‘redundancy’, meaning we can pre-empt the answer before hearing it. At this moment – move on and forwards.

Lessons learned #2: Minimum Viable Product (MVP) vs. Minimum Desirable Product (MDP)

One of Assurity’s secrets is unlocking the Minimum Desirable Product and seeing this play out into development cycles.

Avoid MVP capitulation, where user insight is rejected for what is a minimally viable technology solution. What is minimally viable might be very different from what is actually desired by your customer.

Minimum desirability will ‘get you in the game’. Minimum viability might well result in a product that has no relevance for your customer.

Prototyping presents an opportunity to circumvent any fragility of a smaller sample size of users. The concepts developed in design thinking cycles will provide further access to customers for feedback and allow you to pivot. Also, you will have already built something and will be on your journey to solving a problem.

You need to be bold and hold true to the vision unlocked with design thinking. You will be rewarded in the long run.

Lessons learned #3: Design Thinking and Agile

How might we fuse Design Thinking and Agile methodologies into one cohesive framework for both problem solving and fluid delivery?

  1. Debrief design sprints into a backlog. Capture the most compelling user story once you have prototyped and tested concepts. This will help carry the intent and lessons learned from the design cycle output into Agile delivery
  2. Spend time to understand and transfer vision from DT to Agile teams. The full extent of what your designers are imagining may not easily transfer to another team, even if both processes share the same team members. Take time to build alignment and explore the full vision for your concept. It will ultimately save you time and energy
  3. As Scrum teams start delivering increments, they will inevitably discover new questions and opportunities to explore. Aggregate these questions and use them to reprioritise the backlog. When knowledge starts to impede Scrum delivery, it might be time to run another design thinking cycle to gain clarity and direction
  4. If you can remember one thing… Use DT to learn and Agile to deliver

We’ve given you an example as a starter.

If our problem is customer churn, what is the worst that can happen?

Fail fast and learn | Fail slow and burn

Slow failure is insidious. By the time it’s recognised and acknowledged, it’s often too late to act. You need to reframe your failure to the point where it becomes predictable.

Attributes of predicted failure are:

  • You are empowered to fail and learn
  • You are testing a binary variable; for ‘x’ to be true ‘y’ must happen
  • It is a low fidelity and low-stress outcome
  • It can be time-boxed and treated as an experiment

05. Design your experiment (p19)

A problem shared is a problem halved. Find somebody and share your experiment.

Use those listening skills to get feedback and suggestions on how you approached the experiment. Also listen out for tips on how your colleague approached a similar situation differently.

Gain valuable feedback and form an action pact. Commit to action and test your experiment. Share your results with us on Facebook.

Share Article

Want to know more?

Want to be inspired?

Want to learn?

Want to get in touch?

Share on Facebook
Share on LinkedIn
Share on Twitter
Share on Instagram
Follow on YouTube