Love the elegance of this. One build I wanted to add (that I find useful) on box 7 - 'Risk' ; think about the optics of how this will be perceived by your users (and stakeholders for that matter). Sometimes we may have all the best intentions on something but our users have some misconceptions about our intentions. TL;DR - box 7, think about optics and perception risk. Also.. the risk of resistance to change or adoption risk.
Hi Jeff , Great video indeed and I bought your third version recently and started reading it ❤ 1-I noticed that outcome (a measurable change in human behavior that creates value whether for business or user and or both ) is something that is part of the conversations in box 1 2 and 4. I am wondering how do we keep the focus on each box when talking about outcomes I.e what when we talk about a measurable moving change in behaviors metric at the box 1 ,how is that different from box 2 or even box 4 . Could you possible give an example that could help see the difference . In a nutshell , My confusion is mostly between box 1 and 2 and 4 in addressing the outcome question for each box without redundancy between them . 2-We often talk also about leading and lagging outcomes when the conversation hits human behavior change as we could probably have a fractal way of looking at it ,outcome A leads to outcome B (lagging ) then on higher level leads to outcome c(lagging ) .. Does the leading /lagging outcome happen at all in the canvas ?at which stage precisely ? 3-Josh’s book (impact ,outcome ,output ) and the logic frameworks model also talks about impact as the as of the tunnel destination (usually what corporations want ?) is it part of the conversation here (box 2) ,is it mapped somewhere or is it a outside layer before hitting the canvas ?if it is in box 2 than what would be the difference between business outcome and impact ? Thank you 🙏🏼 again for all the great contributions and insights you had provided us
Hi - thanks for your questions. 1. The outcome in the business problem statement (box 1) is typically higher level. It's often something like revenue, sales, etc. In box 2 (business outcomes) we're looking for a more detailed behavior that drives the metrics in Box 1. For example, this could be "50% increase in products added to cart in first visit." In Box 4 (user outcomes) we're looking for the goal the user is trying to achieve. this doesn't always have to be a measure. in fact it's more often than not an end state the user is trying to achieve, "never miss my kid's soccer practice." 2. More often than not we talk about this in Box 2. We work with our teams to map the relationships between the behaviours they see in their systems. (leading/lagging). As you point out, this can get messy. There is an example of this in the 3rd edition of Lean UX. 3. Box 1 often focused on the impact you're trying to achieve. It's often the net result of solving the problem. I hope that helps. Jeff
Hey, thanks a lot for this video! I read your linkedin article too! Would you not think it better to have the prompts that you are going through on the post-its within the canvas?
Great video Jeff, just got a copy of the third edition and it's pack full of useful info I know this is old but gonna take the shot and ask a couple questions anyways: 1- Would it make sense to add client requested features/designs (if any) at step 5 to check if they point at the right direction? 2- I'm thinking the process to complete the full canvas takes it's time, in your experience did you had to change the process in any way for shorter projects?
Absolutely. Best case scenario is you're doing this WITH your clients. and on #2, always. i adjust based on needs of the project, client, timeline, scope, etc. Sometimes I don't do all of it. Sometimes I get through it in a half a day. Sometimes in a week. adjust as necessary.
Hi Jeff, thanks for the video! I had some follow-up questions: 1. Is the canvas meant to be used for larger projects or new products where the team is looking to determine product market fit? If so, how does this process compare to Jake Knapp's design sprint? 2. Can the canvas be used for smaller projects where your team is thinking about adding or improving a feature to a product? Would the team move through the canvas differently for these type of cases? If so, how? 3. For the 5th solutions box, is the solution usually expressed as a feature? Or is it expressed as a user outcome? Exp: "user can achieve a,b,c goal"? Or even sketches? Do you have specific exercises that you use to generate solutions for box 5? Sorry for all the questions! Any help would be appreciated :) Thank you!!
HI Harleen - 1. It's meant to be used for both scenarios. It can help you refine an existing system and it can help you get your assumptions out about a new product or service idea. Jake and I talked about how to reconcile this with Design Sprints and we decided that once you get to Box 6 in the canvas, Solution Hypotheses, you can use the output of the canvas at that point as the input for your design sprints. 2. For smaller initiatives it depends on the risk the new feature idea represents. If it's a fairly small feature and not particularly risky you're probably better off just building it and shipping it. If the feature is risky (even if it's small) the canvas will help you get to good experiments quickly. You'll likely move through it faster than for a bigger initiative. 3. It's expressed as a feature, product, service, initiative, campaign, etc. In other words, it's expressed as specific output. You can do it in words or in sketches. You can run design charetes for that or just brainstorm on post-it notes -- whatever gets the team's creativity flowing. There are specific exercises in the Lean UX book that address this box in detail. In short though, design sprints, design "studios", brainstorming on post-its are all ways to get ideas generated here. I hope this helps.
Hi Jeff, if you run this Lean Canvas workshop with 4 participants for a completely new service or product, how much time do we need? 2 hours or more? And is it okay to fill in the boxes based on assumptions first then validate later? Cheers.
I'd carve out at least half a day. Ultimately it depends on the complexity of the product you're building but give yourself a half day at least. And yes, the canvas is designed to be an assumptions declarations exercise that you then test/validate with experiments.
@@gothelfco good to know. Half a day might be hard to schedule for the time-sensitive participants. What if it’s broken into shorter 2-3 sessions of 1.5-2hrs? What should I watch out for if that is the case?
Great question Heather. When we practice Lean UX we bias for action. What that means is that base our work off of assumptions -- our best educated guesses of what we know at the moment. The porto-persona is designed to visualise those assumptions from all the team members and build a shared understanding of who we *believe* our target user is. This can certainly be augmented and solidified with existing research. Once we have that shared understanding (which is often neither 100% right nor 100% wrong) we can start testing some of those assumptions through short customer interviews and experiments like the ones described in Boxes 7 and 8. As we gather more information we iterate on our porto-personas. They evolve over time to reflect both where we were initially wrong AND where the target audience is evolving towards. Research based personas are certainly going to be far more accurate. However they take a long time to create. What should the team do in the mean time? They are often outsourced to a research team or agency forcing handoffs between team members and missing the opportunity to build a shared understanding across the whole team. Finally, because of the level of investment put into research based personas they feel fixed to the team, untouchable. The team reads the persona document once, codifies the users and then is reluctant to update them as new information emerges (which it will inevitably do). The team ignores this new information in favour of the existing personas OR they discard the research based persona entirely creating waste. This is all to say that by making a few assumptions we can align the team, get enough of a direction to keep the team moving forward and with regular learning activities we continuously sharpen our assumptions about the users and their needs. Hope that helps.
Thanks so much for your explanation Jeff. I have a book of Lean UX and it’s always one of my reference Books. I have 2 question: 1. Should have to apply the Lean Canvas to solve bigger problems in terms of business or it is for specific problems in web development like usually product designer do? Or should we can use in the both ways: General and specific problems? 2. The stage 7 and 8 of the canvas we have to identify Risks in our hypothesis to make an previous experiment to discover if we have a valid hypothesis to work on and begin to work in MVP and later to mesure or solutions. My question is stage 8 is a pre experiment to validate hypothesis and then we can build MVP to create another Experiment to Validate Our solution? Thanks so much in advance.
1. I think it can work in both situations however if you’re taking on business unit or brand new business level challenges the Business Model Canvas from Strategyzer is likely a better fit. 2. The way we structure the language experiment = MVP (i.e., the smallest thing you can make or do to test your hypothesis). At some point the only way to test your hypothesis will be working code but it’s rarely the first thing you should do.
Love the elegance of this. One build I wanted to add (that I find useful) on box 7 - 'Risk' ; think about the optics of how this will be perceived by your users (and stakeholders for that matter). Sometimes we may have all the best intentions on something but our users have some misconceptions about our intentions. TL;DR - box 7, think about optics and perception risk. Also.. the risk of resistance to change or adoption risk.
Incredibly helpful huge thank you for this
Hi Jeff ,
Great video indeed and I bought your third version recently and started reading it ❤
1-I noticed that outcome (a measurable change in human behavior that creates value whether for business or user and or both ) is something that is part of the conversations in box 1 2 and 4.
I am wondering how do we keep the focus on each box when talking about outcomes I.e what when we talk about a measurable moving change in behaviors metric at the box 1 ,how is that different from box 2 or even box 4 .
Could you possible give an example that could help see the difference .
In a nutshell , My confusion is mostly between box 1 and 2 and 4 in addressing the outcome question for each box without redundancy between them .
2-We often talk also about leading and lagging outcomes when the conversation hits human behavior change as we could probably have a fractal way of looking at it ,outcome A leads to outcome B (lagging ) then on higher level leads to outcome c(lagging ) ..
Does the leading /lagging outcome happen at all in the canvas ?at which stage precisely ?
3-Josh’s book (impact ,outcome ,output ) and the logic frameworks model also talks about impact as the as of the tunnel destination (usually what corporations want ?) is it part of the conversation here (box 2) ,is it mapped somewhere or is it a outside layer before hitting the canvas ?if it is in box 2 than what would be the difference between business outcome and impact ?
Thank you 🙏🏼 again for all the great contributions and insights you had provided us
Hi - thanks for your questions.
1. The outcome in the business problem statement (box 1) is typically higher level. It's often something like revenue, sales, etc. In box 2 (business outcomes) we're looking for a more detailed behavior that drives the metrics in Box 1. For example, this could be "50% increase in products added to cart in first visit." In Box 4 (user outcomes) we're looking for the goal the user is trying to achieve. this doesn't always have to be a measure. in fact it's more often than not an end state the user is trying to achieve, "never miss my kid's soccer practice."
2. More often than not we talk about this in Box 2. We work with our teams to map the relationships between the behaviours they see in their systems. (leading/lagging). As you point out, this can get messy. There is an example of this in the 3rd edition of Lean UX.
3. Box 1 often focused on the impact you're trying to achieve. It's often the net result of solving the problem.
I hope that helps.
Jeff
Hey, thanks a lot for this video! I read your linkedin article too! Would you not think it better to have the prompts that you are going through on the post-its within the canvas?
Great video Jeff, just got a copy of the third edition and it's pack full of useful info
I know this is old but gonna take the shot and ask a couple questions anyways:
1- Would it make sense to add client requested features/designs (if any) at step 5 to check if they point at the right direction?
2- I'm thinking the process to complete the full canvas takes it's time, in your experience did you had to change the process in any way for shorter projects?
Absolutely. Best case scenario is you're doing this WITH your clients. and on #2, always. i adjust based on needs of the project, client, timeline, scope, etc. Sometimes I don't do all of it. Sometimes I get through it in a half a day. Sometimes in a week. adjust as necessary.
What software are you using to open the canvas? Great video.
Mural. (mural.co)
Hi Jeff, thanks for the video! I had some follow-up questions:
1. Is the canvas meant to be used for larger projects or new products where the team is looking to determine product market fit? If so, how does this process compare to Jake Knapp's design sprint?
2. Can the canvas be used for smaller projects where your team is thinking about adding or improving a feature to a product? Would the team move through the canvas differently for these type of cases? If so, how?
3. For the 5th solutions box, is the solution usually expressed as a feature? Or is it expressed as a user outcome? Exp: "user can achieve a,b,c goal"? Or even sketches? Do you have specific exercises that you use to generate solutions for box 5?
Sorry for all the questions! Any help would be appreciated :) Thank you!!
HI Harleen -
1. It's meant to be used for both scenarios. It can help you refine an existing system and it can help you get your assumptions out about a new product or service idea. Jake and I talked about how to reconcile this with Design Sprints and we decided that once you get to Box 6 in the canvas, Solution Hypotheses, you can use the output of the canvas at that point as the input for your design sprints.
2. For smaller initiatives it depends on the risk the new feature idea represents. If it's a fairly small feature and not particularly risky you're probably better off just building it and shipping it. If the feature is risky (even if it's small) the canvas will help you get to good experiments quickly. You'll likely move through it faster than for a bigger initiative.
3. It's expressed as a feature, product, service, initiative, campaign, etc. In other words, it's expressed as specific output. You can do it in words or in sketches. You can run design charetes for that or just brainstorm on post-it notes -- whatever gets the team's creativity flowing. There are specific exercises in the Lean UX book that address this box in detail. In short though, design sprints, design "studios", brainstorming on post-its are all ways to get ideas generated here.
I hope this helps.
thanks so much for your explain!
Hi Jeff, if you run this Lean Canvas workshop with 4 participants for a completely new service or product, how much time do we need? 2 hours or more? And is it okay to fill in the boxes based on assumptions first then validate later? Cheers.
I'd carve out at least half a day. Ultimately it depends on the complexity of the product you're building but give yourself a half day at least. And yes, the canvas is designed to be an assumptions declarations exercise that you then test/validate with experiments.
@@gothelfco good to know. Half a day might be hard to schedule for the time-sensitive participants. What if it’s broken into shorter 2-3 sessions of 1.5-2hrs? What should I watch out for if that is the case?
@@gothelfco Is it good to have a break every 45-60min? And is Box 8 shld be done together or just by the UX Designer?
Hi Jeff I am a little confused on 7 and 8. Wouldn’t user research come first before building a persona? Thank you.
Great question Heather. When we practice Lean UX we bias for action. What that means is that base our work off of assumptions -- our best educated guesses of what we know at the moment. The porto-persona is designed to visualise those assumptions from all the team members and build a shared understanding of who we *believe* our target user is. This can certainly be augmented and solidified with existing research.
Once we have that shared understanding (which is often neither 100% right nor 100% wrong) we can start testing some of those assumptions through short customer interviews and experiments like the ones described in Boxes 7 and 8. As we gather more information we iterate on our porto-personas. They evolve over time to reflect both where we were initially wrong AND where the target audience is evolving towards.
Research based personas are certainly going to be far more accurate. However they take a long time to create. What should the team do in the mean time? They are often outsourced to a research team or agency forcing handoffs between team members and missing the opportunity to build a shared understanding across the whole team. Finally, because of the level of investment put into research based personas they feel fixed to the team, untouchable. The team reads the persona document once, codifies the users and then is reluctant to update them as new information emerges (which it will inevitably do). The team ignores this new information in favour of the existing personas OR they discard the research based persona entirely creating waste.
This is all to say that by making a few assumptions we can align the team, get enough of a direction to keep the team moving forward and with regular learning activities we continuously sharpen our assumptions about the users and their needs. Hope that helps.
Thanks for the question and the answer in detailed. Learned a lot from this!!
Thanks so much for your explanation Jeff.
I have a book of Lean UX and it’s always one of my reference Books.
I have 2 question:
1. Should have to apply the Lean Canvas to solve bigger problems in terms of business or it is for specific problems in web development like usually product designer do? Or should we can use in the both ways: General and specific problems?
2. The stage 7 and 8 of the canvas we have to identify Risks in our hypothesis to make an previous experiment to discover if we have a valid hypothesis to work on and begin to work in MVP and later to mesure or solutions. My question is stage 8 is a pre experiment to validate hypothesis and then we can build MVP to create another Experiment to Validate Our solution?
Thanks so much in advance.
1. I think it can work in both situations however if you’re taking on business unit or brand new business level challenges the Business Model Canvas from Strategyzer is likely a better fit.
2. The way we structure the language experiment = MVP (i.e., the smallest thing you can make or do to test your hypothesis). At some point the only way to test your hypothesis will be working code but it’s rarely the first thing you should do.
@@gothelfco Thanks Jeff to be so kind to answer my questions.
Congrats. Very helpful
Hi Jeff! what is the program do you use to write the yellow post its? thanks!
Mural.co
Yep, it’s Mural.
Are you going to add that template to Mural? I can only find version one on there.
It’s up to them rather than me.
FYI: just thought i would let you know that there is a spelling error on box one of the powerpoint slide 2
It 's hard to follow without a real world scenario example...