a few points to clarify on this: anything before or after the lean framework is considered design thinking. In terms of a timeline, lean is used to prototype products in the present whereas design thinking is used to ideate & define products in the future. Example: we use a design thinking framework to figure out that a segment of drivers actually would like to purchase electric cars. Once what we are building is established, we then use a lean framework to create our MVP. So zooming out, here is what it looks like. Design ThinkingUse Lean to create MVPLaunch MVPUse Design Thinking + Lean + Agile to finalize PMF (Product Market Fit)
Big budget, big team, long timeline, access to resource => design thinking or ucd Tight budget, short timeline, less resource => lean Uncertain requirements, short timeline => agile Based on experience, any approach will work as long as you hit the desired outcomes.
What I take away is that, there is a context for application of each approach. One needs to know that. Also, the question for the industry is how better to provide customer value. Then comes the discussion on tools/approaches. Thanks for tacking this subject in the video.
good review & summary, it's good to hear that in general it's all about communication and being on the same page with the team ;) no matter what approach we use, cheers!
Great delineations. Bought the audio book immediately under your advice. I have found these methodologies separately. And they still seem separate. Agile development STILL is 'mis' used to protect software engineering from being falsely accused of refusing to change. That is understandable. However, agile is used to make the software engineers' job easier. The original agile theory was to increase software-product quality. And today, product quality is far down the list of conscious goals. Today's software engineers are 90% focussed on turning in the most user-stories during a sprint. They have become accidentally removed from concerning the selve with helping to deliver happy customers. Most of today's software engineers are dimly away that they are turning stories that are actually called "USER stories". Engineers are measured by their speed of turning in stories. They are not measured by the quality of the users' experience nor the delivery of new business. And I could discuss similar problems with the other two; lean design; and design thinking. And I agree with you. People on the same mission perform best when they work from beginning to end of the mission. And everyone enjoys the rewards of succeeding.
Hi. I'm relatively newbie in ux world and I stumbled upon this video. It's a nice video that helped me understanding about various methodologies in product development. Thanks for making this video! I'm just curious about 1 thing in lean methodology, which is how research can be incorporated in it? Since, as far as i know, research took quite a bit of time in prior and may disrupt the velocity of the release
Lean is all about experimentation with (just enough) informed decisions. Followed by continuous learning and iterations. A lot of UX designers and researchers absolute hate lean for the same reasons. But if you are a designer in the midst of agile product development you might be stuck in that rut. Ideally you'd want to do both: be exploitative enough but also nimble to implement and release then the time is right
As a UX designer, I complete support we should be doing quick research and focusing on design delivery and it's evaluation but Product owner hate to hear when we say we are coming up with minimal research and will evaluate it after launch.
SAFe is agile at a scale and ability to scale from small agile teams to larger org efforts at once. It's also a trademarked framework which in my eyes makes it repackaged crap. Agile at a scale also means heading back towards the factory worker ways of doing things with severe loss of soul.
@@vaexperience is SAFe crap because it's trademarked? I think I'd rather stick with your fundamental principle that these are all essentially mindsets/perception/propositions to solutioning, and usage will largely be down to individual preferences, experience and tailoring capabilities. Apart from the ART and Solution Trains, there's nothing in SAFe that's new. Nonetheless, there's no gainsaying that the foundational principles that imbue the SAFe mindset are battle tested.
Not specifically trademark is the issue, it's as you said yourself - a repurposing of other methods, frameworks, etc. but under a new name / private ownership. There's a lot of that already, and besides remarketing existing methods with new names it doesn't seem like adds much else. I might be missing a lot here though, as obviously they do have their own edge its application for bigger organizations might be it
@@FaridBoudissa @vaexperience did not touch on it in this video, but the author does in the book. Basically his recommendation for managers is the 'Going to Gemba' practice from Lean. That means getting out of your office and experiencing challenges first-hand, of your customers and your employees.
@@toddsorenson4679 thank you for the indication, the team building and the way we work together is an important key of success of the quality continuous improvement. Steering operations, managing metrics or reports, are a good base of communication. I understand the interest of the Gemba practice to coordinate teams that don't necessarily speak the same language and how it can help, effectively.
Hi, you said the templates are editable. After downloading them, I see they're jpgs. How do you edit jpgs, mr. genius? Why didn't you send the original (Native) files? Those should be editable.
a few points to clarify on this: anything before or after the lean framework is considered design thinking. In terms of a timeline, lean is used to prototype products in the present whereas design thinking is used to ideate & define products in the future. Example: we use a design thinking framework to figure out that a segment of drivers actually would like to purchase electric cars. Once what we are building is established, we then use a lean framework to create our MVP. So zooming out, here is what it looks like. Design ThinkingUse Lean to create MVPLaunch MVPUse Design Thinking + Lean + Agile to finalize PMF (Product Market Fit)
Thank you for sharing!!! I am a junior service designer. It’s easy to confuse how to combine different methods in different stages of process.
This is by far the most thoughtful perception of the Ux process
Big budget, big team, long timeline, access to resource => design thinking or ucd
Tight budget, short timeline, less resource => lean
Uncertain requirements, short timeline => agile
Based on experience, any approach will work as long as you hit the desired outcomes.
What I take away is that, there is a context for application of each approach. One needs to know that. Also, the question for the industry is how better to provide customer value. Then comes the discussion on tools/approaches. Thanks for tacking this subject in the video.
This was so clear and insightful! Thank you!
Totally agree. A clear explanation of key concepts without getting into the weeds as too much details were unneeded for this video.
Totally agree with that.
I do "Lean Agile Thinking"
So many great books recommended in this video. I'd love to see a full list of books you think every UX designer should read.
good review & summary, it's good to hear that in general it's all about communication and being on the same page with the team ;) no matter what approach we use, cheers!
The best teams rarely use the strict definitions and work together as a squad with common goal with plenty of respect for each others expertise.
Great delineations. Bought the audio book immediately under your advice. I have found these methodologies separately. And they still seem separate.
Agile development STILL is 'mis' used to protect software engineering from being falsely accused of refusing to change. That is understandable. However, agile is used to make the software engineers' job easier. The original agile theory was to increase software-product quality. And today, product quality is far down the list of conscious goals. Today's software engineers are 90% focussed on turning in the most user-stories during a sprint. They have become accidentally removed from concerning the selve with helping to deliver happy customers. Most of today's software engineers are dimly away that they are turning stories that are actually called "USER stories".
Engineers are measured by their speed of turning in stories. They are not measured by the quality of the users' experience nor the delivery of new business.
And I could discuss similar problems with the other two; lean design; and design thinking.
And I agree with you.
People on the same mission perform best when they work from beginning to end of the mission. And everyone enjoys the rewards of succeeding.
Great as always - the best product channel for me
this is very helpful, thanks for sharing.
Hi. I'm relatively newbie in ux world and I stumbled upon this video. It's a nice video that helped me understanding about various methodologies in product development. Thanks for making this video!
I'm just curious about 1 thing in lean methodology, which is how research can be incorporated in it? Since, as far as i know, research took quite a bit of time in prior and may disrupt the velocity of the release
Lean is all about experimentation with (just enough) informed decisions. Followed by continuous learning and iterations. A lot of UX designers and researchers absolute hate lean for the same reasons. But if you are a designer in the midst of agile product development you might be stuck in that rut. Ideally you'd want to do both: be exploitative enough but also nimble to implement and release then the time is right
very good summary, saved me a lot of time. and very useful personal insights.
Agree with you.
Thanks for this!
Thanks for so short and clear explanation 🙏
Glad it was helpful!
As a UX designer, I complete support we should be doing quick research and focusing on design delivery and it's evaluation but Product owner hate to hear when we say we are coming up with minimal research and will evaluate it after launch.
That's pretty good problem to have! usually it's the product owners who want to skip the research! Tell them thank you and do the research :D
Really good overview - thanks!
Thank your video was helpful 👍🏾
i want that book .
Well said! Thx
Great Video 👍
Outstanding 👍🏾👍🏾👍🏾
Thank you kindly
Excellent video!
What is the difference between Lean and SAFe?
SAFe is agile at a scale and ability to scale from small agile teams to larger org efforts at once. It's also a trademarked framework which in my eyes makes it repackaged crap. Agile at a scale also means heading back towards the factory worker ways of doing things with severe loss of soul.
@@vaexperience is SAFe crap because it's trademarked?
I think I'd rather stick with your fundamental principle that these are all essentially mindsets/perception/propositions to solutioning, and usage will largely be down to individual preferences, experience and tailoring capabilities. Apart from the ART and Solution Trains, there's nothing in SAFe that's new. Nonetheless, there's no gainsaying that the foundational principles that imbue the SAFe mindset are battle tested.
Not specifically trademark is the issue, it's as you said yourself - a repurposing of other methods, frameworks, etc. but under a new name / private ownership. There's a lot of that already, and besides remarketing existing methods with new names it doesn't seem like adds much else. I might be missing a lot here though, as obviously they do have their own edge its application for bigger organizations might be it
What about the leadership?
How do you mean?
I mean the one who is responsible of the teams and deliveries coordination like a scrum master.
@@FaridBoudissa @vaexperience did not touch on it in this video, but the author does in the book. Basically his recommendation for managers is the 'Going to Gemba' practice from Lean. That means getting out of your office and experiencing challenges first-hand, of your customers and your employees.
@@toddsorenson4679 thank you for the indication, the team building and the way we work together is an important key of success of the quality continuous improvement. Steering operations, managing metrics or reports, are a good base of communication. I understand the interest of the Gemba practice to coordinate teams that don't necessarily speak the same language and how it can help, effectively.
I totally agree
Hi, you said the templates are editable. After downloading them, I see they're jpgs. How do you edit jpgs, mr. genius? Why didn't you send the original (Native) files? Those should be editable.