Please note that this blog is archived and outdated. For the most current information click here!

Using the Lean UX Canvas to Validate Your Product

Some years ago, the head of the Industrial Engineering Department of Yale University said, "If I had only one hour to solve a problem, I would spend up to two-thirds of that hour in attempting to define what the problem is."*

We love solving problems - it's what gets us up in the morning. There is nothing more significant for us than when we do this for our customers. However, in working as an external vendor, there are several issues which can block the correct definition of what the problem is.

There are two critical reasons for this:

1. Time: A commercial time-based engagement encourages both parties to focus on solution delivery over problem definition.
2. Domain Expertise: As a vendor, we trust you as the domain expert to bring the domain expertise. However, this domain expertise is often confused with user needs. Neither parties can prescribe the user needs; only the end users can.

In 2019, we had great success moving to a problem driven approach to agile software development. The process has gone a long way to ensuring we are solving the right issue. Despite this, we felt we needed to go further in providing initial guidance to our customers.

The Lean UX Canvas

So, we asked ourselves. How can we discover more at an early stage, retain this and get a complete understanding of the situation before we begin to solve the problem? In researching, we discovered the Lean UX Canvas by Jeff Gothelf.

In summary, Jeff developed the canvas for the following purposes:

• A customer-centric cross team facilitation tool.
• Help the team focus on 'Why' they are doing the work.
• A recipe for teams to adopt agile.
• Ensure learning takes place every iteration.
• To expose gaps in teams understanding.
• A first step to shift the conversation from outputs to outcomes.

Here's Jeff's canvas:

In seeing the canvas's alignment with our problem statement discovery, we experimented with filling it out before confirming the problem statement. We found this gave us far better insight into the situation, resulting in better-defined problems and problem statements.

Our adaptation on the lean UX canvas

We have now taken Jeff's canvas and applied it to use with our process. The process is actually straightforward, and following it yourself or with your own team may allow you to discover your own problem statement.

To fill it out yourself, follow the number system on the left side of the page. Once complete, you can then ideate your problem statement on the right.

Here are each of the steps:

1. Business problem: What problem does the business have that you're trying to solve? (Hint: Consider the client's current offerings and how they deliver value. Are they experiencing changes in the market? Delivery channels? Competitive threats? Any customer behaviour changes?
2. Business Outcomes: How will you know you solved the business problem? What will you measure? (Hint: What will your users be doing differently if your solutions work? Consider metrics that indicate customer success like average order value, time on site and retention rate)
3. Users: What types (personas) of users and customers should you focus on first? (Hint: Who buys the product or service? Who uses it? Who configures it?)
4. User Outcomes & Benefits: Why would your users seek out your product or service? What benefit would they gain from using it? What behaviour change can we observe that tells us they've achieved their goal? (Hint: Spend more time with family? Save money? Get a promotion?)
5. Solutions: What can we make that will solve our business problem and meet the needs of our customers at the same time? List any product, feature or enhancement ideas here.
6. Hypotheses: List any assumptions this project is making.
7. What's the most important thing we need to learn first? Identify the current riskiest assumption/hypothesis that will cause the entire idea to fail if incorrect (Hint: Focus on the risk to value rather than feasibility)
8. What's the least amount of work we must do to learn the most important thing? Brainstorm experiments to quickly learn whether your riskiest assumption is true of false. We'll focus more on this during scope...

Focus of the MVP

1. Problem Statement: Use cells 1, 2 and 4 to summarise the first problem to focus on for the MVP.
2. Top 3 Business Outcomes: Select the top 3 business outcomes from cell 2 to focus on for the MVP. These metrics will be measured post-production release
3. Top 3 User Outcomes: Select the top 3 user outcomes from cell 4 to focus on for the MVP. These metrics will be measured post-production release of the solution.

*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.