Using the lean UX can­vas to val­i­date your prod­uct

SOFTWARE DEVELOPMENT

Some years ago, the head of the Industrial Engineering Department of Yale University said, “If I had only one hour to solve a prob­lem, I would spend up to two-thirds of that hour in at­tempt­ing to de­fine what the prob­lem is.“*

We love solv­ing prob­lems - it’s what gets us up in the morn­ing. There is noth­ing more sig­nif­i­cant for us than when we do this for our cus­tomers. However, in work­ing as an ex­ter­nal ven­dor, there are sev­eral is­sues which can block the cor­rect de­f­i­n­i­tion of what the prob­lem is.

There are two crit­i­cal rea­sons for this:

  1. Time: A com­mer­cial time-based en­gage­ment en­cour­ages both par­ties to fo­cus on so­lu­tion de­liv­ery over prob­lem de­f­i­n­i­tion.
  2. Domain Expertise: As a ven­dor, we trust you as the do­main ex­pert to bring the do­main ex­per­tise. However, this do­main ex­per­tise is of­ten con­fused with user needs. Neither par­ties can pre­scribe the user needs; only the end users can.

In 2019, we had great suc­cess mov­ing to a prob­lem dri­ven ap­proach to ag­ile soft­ware de­vel­op­ment. The process has gone a long way to en­sur­ing we are solv­ing the right is­sue. Despite this, we felt we needed to go fur­ther in pro­vid­ing ini­tial guid­ance to our cus­tomers.

The Lean UX Canvas

So, we asked our­selves. How can we dis­cover more at an early stage, re­tain this and get a com­plete un­der­stand­ing of the sit­u­a­tion be­fore we be­gin to solve the prob­lem? In re­search­ing, we dis­cov­ered the Lean UX Canvas by Jeff Gothelf.

In sum­mary, Jeff de­vel­oped the can­vas for the fol­low­ing pur­poses:

  • A cus­tomer-cen­tric cross team fa­cil­i­ta­tion tool.
  • Help the team fo­cus on ‘Why’ they are do­ing the work.
  • A recipe for teams to adopt ag­ile.
  • Ensure learn­ing takes place every it­er­a­tion.
  • To ex­pose gaps in teams un­der­stand­ing.
  • A first step to shift the con­ver­sa­tion from out­puts to out­comes.

Here’s Jeff’s can­vas:

Image

In see­ing the can­vas’s align­ment with our prob­lem state­ment dis­cov­ery, we ex­per­i­mented with fill­ing it out be­fore con­firm­ing the prob­lem state­ment. We found this gave us far bet­ter in­sight into the sit­u­a­tion, re­sult­ing in bet­ter-de­fined prob­lems and prob­lem state­ments.

Our adap­ta­tion on the lean UX can­vas

We have now taken Jeff’s can­vas and ap­plied it to use with our process. The process is ac­tu­ally straight­for­ward, and fol­low­ing it your­self or with your own team may al­low you to dis­cover your own prob­lem state­ment.

Image

You can down­load your own copy of our can­vas here. For the flow of this ar­ti­cle, we’ll in­clude a low-res ver­sion of the can­vas with a brief ex­pla­na­tion on how to use it.

Image

To fill it out your­self, fol­low the num­ber sys­tem on the left side of the page. Once com­plete, you can then ideate your prob­lem state­ment on the right.

Here are each of the steps:

  1. Business prob­lem: What prob­lem does the busi­ness have that you’re try­ing to solve? (Hint: Consider the clien­t’s cur­rent of­fer­ings and how they de­liver value. Are they ex­pe­ri­enc­ing changes in the mar­ket? Delivery chan­nels? Competitive threats? Any cus­tomer be­hav­iour changes?
  2. Business Outcomes: How will you know you solved the busi­ness prob­lem? What will you mea­sure? (Hint: What will your users be do­ing dif­fer­ently if your so­lu­tions work? Consider met­rics that in­di­cate cus­tomer suc­cess like av­er­age or­der value, time on site and re­ten­tion rate)
  3. Users: What types (personas) of users and cus­tomers should you fo­cus on first? (Hint: Who buys the prod­uct or ser­vice? Who uses it? Who con­fig­ures it?)
  4. User Outcomes & Benefits: Why would your users seek out your prod­uct or ser­vice? What ben­e­fit would they gain from us­ing it? What be­hav­iour change can we ob­serve that tells us they’ve achieved their goal? (Hint: Spend more time with fam­ily? Save money? Get a pro­mo­tion?)
  5. Solutions: What can we make that will solve our busi­ness prob­lem and meet the needs of our cus­tomers at the same time? List any prod­uct, fea­ture or en­hance­ment ideas here.
  6. Hypotheses: List any as­sump­tions this pro­ject is mak­ing.
  7. What’s the most im­por­tant thing we need to learn first? Identify the cur­rent riski­est as­sump­tion/​hy­poth­e­sis that will cause the en­tire idea to fail if in­cor­rect (Hint: Focus on the risk to value rather than fea­si­bil­ity)
  8. What’s the least amount of work we must do to learn the most im­por­tant thing? Brainstorm ex­per­i­ments to quickly learn whether your riski­est as­sump­tion is true of false. We’ll fo­cus more on this dur­ing scope…

Focus of the MVP

  1. Problem Statement: Use cells 1, 2 and 4 to sum­marise the first prob­lem to fo­cus on for the MVP.
  2. Top 3 Business Outcomes: Select the top 3 busi­ness out­comes from cell 2 to fo­cus on for the MVP. These met­rics will be mea­sured post-pro­duc­tion re­lease
  3. Top 3 User Outcomes: Select the top 3 user out­comes from cell 4 to fo­cus on for the MVP. These met­rics will be mea­sured post-pro­duc­tion re­lease of the so­lu­tion.

*1966, The Manufacturing Man and His Job by Robert E. Finley and Henry R. Ziobro, “The Manufacturing Manager’s Skills” by William H. Markle (Vice President, Stainless Processing Company, Chicago, Illinois), Start Page 15, Quote Page 18, Published by American Management Association, Inc., New York.

Discover Software
Secrets

ABOUT THE AUTHOR

David Burkett

Growth en­thu­si­ast and res­i­dent pom

Get cu­rated con­tent on soft­ware de­vel­op­ment, straight to your in­box.

How Leading Edge Software Can Help You Scale Your Business

09 October 2018

How did Tanda achieve their ini­tial prod­uct/​mar­ket fit

26 March 2020

What are user in­ter­views and why are they im­por­tant?

29 May 2020

Your vi­sion,

our ex­per­tise

Book a con­sul­ta­tion