One of the most challenging questions we answer as product managers is “What are we going to build next?”. As if answering this question isn’t challenging enough, it can be equally as challenging to get all of your team members and business stakeholders bought into your vision. When I came across the LeanUX framework, I was instantly intrigued by the realistic, yet empathetic approach that this method takes to understanding your business and users. It encourages us to collaborate with all of the right minds to be able to best align on all areas of a product, and ultimately answer that looming question.
The Lean UX framework is defined in the LeanUX book, authored by Jeff Gothelf and Josh Seiden, as “A design approach that brings the true nature of a product to light faster, in a collaborative, cross functional and user centered way.” It encourages us to “...build a shared understanding of the user, their needs, our proposed solutions and our definition of success.” LeanUX was created with a focus on design thinking, but it also highlights the value of bringing together important minds from all areas of your team. This framework combines waste reducing and continuous iteration principles from the lean and agile methodologies and applies those to enable teams to collaborate on their own destiny, encourages them to understand and empathize with their customers, and eliminates the fear of failure in order to foster innovation.
So, who should participate in filling out the LeanUX Canvas? It’s important to gather a good, well rounded group of team members. These will likely come from product, design, engineering, and maybe some additional business stakeholders if their input is going to be helpful to the conversation. To paraphrase from the book, “No one position/role (devs, design, product, etc.) has all of the answers, the more diverse your team is the more innovative and broad-reaching the solutions the team generates”.
Identifying a problem to solve is necessary to creating a great product, but often I find that this metric gets lost as products get built, or isn’t clearly communicated across a team at the beginning.For younger products, this may be relatively easy to answer, but may also encourage additional conversations between your team members to align on what your organization intends to achieve. If you are using the LeanUX canvas on a more mature product, your product and organization may have many problems it wants to solve, but aligning on one area will allow you to fire all of your weapons at a single problem, rather than spreading out that impact to multiple problems and therefore not accomplishing any of them. The business problem should answer questions about the current state of the product, why we created it/want to create it in the first place, and why it’s not meeting expectations.
Business outcomes are measurable changes in human behavior and are the goals or key results you want to focus on achieving. Knowing these metrics upfront help you align on how you will define success, and can potentially impact your decision making during the solutions & hypothesis steps. These could be things like improving conversion rate by 10% or improving retention by 20%, something quantifiable that we can use to measure success later on.
Next, you will shift to a more customer empathetic mindset. Your product may serve more than one user type, but in order to limit your focus, it’s important to choose one user type as a group that we are focusing on improving the experience for. This is where you would re-visit or create user personas if you do not already have them defined. For your chosen persona you should also document the challenges they are having with the product or what’s preventing them from achieving the most optimal experience. Once you have clearly understood your users in step 3, you will also need to align on the outcomes & benefits you hope to deliver for these customers in step 4. An example of a user with a corresponding outcome could be that an office manager “Stacy” who is moderately tech savvy wants to be able to more easily schedule lunches for their office employees and Stacy’s current solution is preventing them from doing this efficiently. Our outcome for the office manager would be to allow her more time back so she doesn't have to stay late that day to catch up on work and ultimately miss out on time with her family.
The solutions category is the largest on the canvas for a reason, you should be encouraging your team to actively ideate during this phase, since ultimately that is how to best foster innovative ideas and solutions. It’s important to keep your business and user problems and outcomes in mind when brainstorming solution ideas, since ultimately they will be how you measure success. Your solutions can be as small as features or as large as new products, depending on the scope of your problems.
In the next section, you will take categories 2-5, and formulate a hypothesis statement with them. You will likely have multiple hypotheses, but you will need to pick the most important one to move forward with. The Hypothesis Canvas is a great tool that will help you visualize which of your hypothesis statements will make the biggest impact. Using my previous example, I would create a hypothesis statement that’s something like:“We believe we can improve conversation rate by 10% if Stacy the office manager was able to order lunch for her team members more quickly rather than opt to stay late at work on days she orders lunch, with the ability to repeat a previous order.”
Once you have identified the hypothesis you will be testing, the last 2 categories (What’s the most important thing to learn first? And what’s the least amount of work you can do to learn the next important thing?) are presented as questions to help you figure out how to get started without being wasteful with your capacity. Any risks and assumptions you identify are things we will want to test first, as their outcomes could greatly impact our overall hypothesis and cause us to want to steer in another direction (fail fast) or continue to push further into our experimentation. Continuing with my hypothesis statement from above, maybe I would need to validate my assumption that users build recurring orders manually by digging into the data, or maybe I need to watch a user walk through the application to validate my assumption of where they get slowed down the most. If any of these assumptions were disproven, then I wouldn't need to spend my time building that solution and would have saved myself a ton of time and frustration.
Ultimately, the LeanUX framework is here as a tool to help you make more educated decisions, and to inspire passion for the product vision along the way, to quote LeanUX one last time, remember “The deployment of code is not the measure of success, it's the positive impact you have on your customers”