Time codes with simplified topics and Q&A's: 0:00 Intro 1:41 Misguided Product community: most what you've been taught does not help you, your company and your clients 5:00 Challenges from the rest teams to the great teams are the same 6:00 Which product team is Agile? 6:30 Team "Red" (non-Empowered) 7:30 Team "Blue" (Empowered) 8:20 Comparison "Red" and "Blue" in terms of Agile 11:47 Coping with complexity with "Process". SAFe. I don't know any single strong product company that uses SAFe 17:04 Examples of how leaders of great product companies are afraid of "Scaling with Process" 21:33 Alternatives to "Process" 22:55 Spotify Model 33:07 How top product companies deal with complexity: principles, thinking, talking 33:56 First principles 40:43 Thinking 44:42 Talking 51:17 How to help company to work like the best: changing how they build, how they solve problems, how they choose which problems to solve 51:22 Change how you build 51:58 Change how you solve problems 52:49 Change how you decide which problems to solve 54:07 Books: Inspired, Empowered, Loved 55:20 Contacts to reach Marty Cagan 56:15 Q&A session 56:26 Q: what is the problem with rodmaps? A: nothing wrong, but in 99% it is made instead of Product Discovery 58:42 Q: what are the risks in Product Discovery? A: Value, Usability, Viability, Feasibility 1:04:40 Q: how to solve "engineers are too far from top management" problem? A: first product principles 1:08:04 Q: how to bring teams to work together? A: it's leaders job 1:12:10 Q: how to make empowered teams? A: it's managers job to coach 1:15:30 Q: could be a loan in banking considered as a product? A: yes 1:19:00 Q: how to solve a problem of shielding product owners from customers A: CEO has to be educated and coached, because this is totally broken company
I have worked for companies that never insisted on processes and stayed away from all these pieces of "crap". They innovated and were fun to work for. I also happened to work for a company that heavily used SAFe. There was no thinking, the product was mediocre, and a lot of money was wasted on managing process. This company moved like a snail and nobody liked to own anything. Teams were not empowered. They were all there to collect paychecks and tick the process. I didn't survive there more than a couple of months. I love this talk!
Love this. Marty is right. The state of the art today with product development teams is embarrassingly poor. It doesn't help that a large swath of the coaching world is complicit in perpetuating the cargo cult approach to delivering value ("clueless to the substance of the job"). But look - these problems that Marty calls out aren't some esoteric workplace challenge - they affect people's lives. The companies that made the websites that people use to schedule a medical appointment, or for banking, or for taking a class are all produced by organizations that engage in this buffoonery and it harms people (how many of you had to help your parents figure out how to schedule their vaccination appointment in the past few years?). I wish others who participated in this asked Marty whether there's an approach that an org needs to go through in order to reach the empowered-team end state that he cites as being the most effective (I'll send him an email). e.g. it doesn't seem like Marty sees SAFe (or equivalent) is a means to a worthwhile end.
The “you never have a second chance to make a first impression” is a myth… thats just being timid and shy. That is silly. STOP THAT!! ;) Take a look at the innovation in video games, they launch what is known as “open beta” time frames where you can get customers, interaction and analytics to make the product perfect. Also: have you ever seen someone get married to the person who was their best friend? What is important is: QUALITY & CARE.
Thank you Mr. Marty for sharing your wisdom. However, with all due respect, a few things don't add up. 1) Not all companies are product companies. Their structure is adopted from heavy manufacturing industries from 1900s. Example: for every problem, they have a division/silo. Unfortunately they don't have any division for customer success though. They are setup for stability, risk reduction & governance. Example big banks. To move these big ships to make more nimble/adaptable, we need agile processes. With validated experience, once they can start thinking and structuring like modern day organizations, then only we can drop agile processes and adopt only agile principles for them. 2) Outsourcing - This is a messy thing. This will hurt product management approach every single day when you have teams comprised of 5 different vendors. We can't deny that reality. Without certain processes, there will be complete chaos. There are many other factors as well. IMHO, history is the only lens through which we need to see things. Then empathetically suggest 'how can we help them to become more nimble/adaptable?'. Thank you.
We iteratively deliver value to our customers, but the cost for this is an annual roadmap with a bunch of predictable features we are going to build. You can't have both.
I'd say the value in those features can change over time (they're not relevant anymore, competitors have something better to solve that same problem, something else even more valuable shows up). While predictability is comfortable for stakeholders, there's a limit of how long into the future you can plan. I'm not advocating for "no plan", but making a point that year-long roadmaps may be more of a "safety blanket" rather than actual proof of the biggest value you could deliver.
This guy makes a number of flawed assertions in his slams of scrum, SAFe, how PM/PO training is done, the capability of a trained PM/PO vs a team as the best or only role to engage customers, and the mindset of teams as a heads-down 'coder only' orientation (as if scrum and agile have no collaborative refinement with PM/PO as voice of customer or to imply scrum discourages a team from thinking through stories and acceptance criteria). He also fails to qualify his CI/CD belief in rapid regular iterative pushes of hypothesis test to users - while its ok in cases like netscape or spotify, and during the early innovation phase of immature products, its not what many customers and product domains allow when the user community values reliability and stability above the risk of live disruptions to explore a feature idea. It is agile to be iterative and incremental in a cadence longer than 1 sprint if the user needs and values are respected, and hypothesis testing is done in ways not requiring a CD into live systems each sprint cycle. His red team characterization is deeply flawed as a desired outcome of scrum, as if we teach mechanical execution as "false scrum", or 'you are just a coder' handover of stores to developers, with no intent to leverage or collaborate with the PM/PO as the voice of customer. In between blue and red team extremes, between Bezos' day 1 and day 2 example, there is a target rich place for good guidance on teams doing scrum and SAFe well, with PM/PO roles who do their job well, and with shades of maturing from innovative wild west cycles towards more predictable and scalable outcomes. He offered no such guidance in this video. He fails to recognize the process of process improvement is a core early belief of kanban and lean that inspired retros and I&A concepts at the PM/PO role and teams adapt and improve. He appears to assume the team of developers is better positioned to engage stakeholders and users and judge outcomes better than roles trained to do so (PM/PO and UX). Some scaling approaches advocate making the team closer to users, which he says is not true. There are some product domains where his assertion may be true that a team is better than a PM/PO role to lead production direction and course corrections (he should qualify the characteristics of those situations where developers may know as much about end user needs and can be a proxy to a great PM/PO). In many cases the PM/PO is better qualified to be accountable for direction and outcomes. Teams often lack time to become experts in the product domain, and they will lack experience inside that product domain's competing solutions and business context, and teams generally lack the time to become fully engaged in ideation with every point of contact a PM/PO should be engaging. A better use of your time would be to study how a PM/PO (and UX) collaborate with stakeholders, SMEs and teams during ideation, and to learn how strategic selection of target objectives and plans to fulfill objectives can be done, and to understand good backlog ordering lead by the PM/PO in collaborative ways with teams.
No offense, but CI/CD doesn't mean instability. In fact it has the opposite as its goal. Your entire comment is littered with inaccuracies and a lack of understanding of development best practices. SAFe is overflowing with unnecessary bloated management overhead due to a desire to control and not empower. SAFe costs companies more that it benefits them. Having worked with PM/POs out of SAFE I can say they have no idea how to do product management effectively. At all. They would make good project managers for a car company... but they don't understand PRODUCT management at all.
Time codes with simplified topics and Q&A's:
0:00 Intro
1:41 Misguided Product community: most what you've been taught does not help you, your company and your clients
5:00 Challenges from the rest teams to the great teams are the same
6:00 Which product team is Agile?
6:30 Team "Red" (non-Empowered)
7:30 Team "Blue" (Empowered)
8:20 Comparison "Red" and "Blue" in terms of Agile
11:47 Coping with complexity with "Process". SAFe. I don't know any single strong product company that uses SAFe
17:04 Examples of how leaders of great product companies are afraid of "Scaling with Process"
21:33 Alternatives to "Process"
22:55 Spotify Model
33:07 How top product companies deal with complexity: principles, thinking, talking
33:56 First principles
40:43 Thinking
44:42 Talking
51:17 How to help company to work like the best: changing how they build, how they solve problems, how they choose which problems to solve
51:22 Change how you build
51:58 Change how you solve problems
52:49 Change how you decide which problems to solve
54:07 Books: Inspired, Empowered, Loved
55:20 Contacts to reach Marty Cagan
56:15 Q&A session
56:26 Q: what is the problem with rodmaps?
A: nothing wrong, but in 99% it is made instead of Product Discovery
58:42 Q: what are the risks in Product Discovery?
A: Value, Usability, Viability, Feasibility
1:04:40 Q: how to solve "engineers are too far from top management" problem?
A: first product principles
1:08:04 Q: how to bring teams to work together?
A: it's leaders job
1:12:10 Q: how to make empowered teams?
A: it's managers job to coach
1:15:30 Q: could be a loan in banking considered as a product?
A: yes
1:19:00 Q: how to solve a problem of shielding product owners from customers
A: CEO has to be educated and coached, because this is totally broken company
The best 'real' talk I've seen on Product Management, Agility and Coaching. Marty is a gem! Thanks you @CrispAgileAcademy for sharing this!
I have worked for companies that never insisted on processes and stayed away from all these pieces of "crap". They innovated and were fun to work for.
I also happened to work for a company that heavily used SAFe. There was no thinking, the product was mediocre, and a lot of money was wasted on managing process. This company moved like a snail and nobody liked to own anything. Teams were not empowered. They were all there to collect paychecks and tick the process. I didn't survive there more than a couple of months.
I love this talk!
Cagan was on fire here. Pretty sure "crap" and "shit" were his top words. Love it.
Wow, this talk is gold and you offer it to us free of charge, amazing
What a legend!
The entire talks was amazing. But the last 20 secs were final nail when Mckinsey's point came!
Love this Marty!
Excellent overview of how to reduce noise and unwarranted complexity in how we organize and do things!
Marty's talk is awesome again, as always! Spot on!
Thanks for saying this clarification out loud.
You bloody legend
¡¡¡This is gold!!!
Finally 🙂
Love this. Marty is right. The state of the art today with product development teams is embarrassingly poor. It doesn't help that a large swath of the coaching world is complicit in perpetuating the cargo cult approach to delivering value ("clueless to the substance of the job"). But look - these problems that Marty calls out aren't some esoteric workplace challenge - they affect people's lives. The companies that made the websites that people use to schedule a medical appointment, or for banking, or for taking a class are all produced by organizations that engage in this buffoonery and it harms people (how many of you had to help your parents figure out how to schedule their vaccination appointment in the past few years?).
I wish others who participated in this asked Marty whether there's an approach that an org needs to go through in order to reach the empowered-team end state that he cites as being the most effective (I'll send him an email). e.g. it doesn't seem like Marty sees SAFe (or equivalent) is a means to a worthwhile end.
Great candid presentation!
Great stuff, thanks a lot for this!
Thank for the video
Pretty amazing talk. Thank you Marty
Nice video, thanks a lot!
P.S. Cheers to the ones reading through the sample Amazon 6 pager by Jesse Freeman after watching this master class :)
100% agree. A lot of craps in not bring value to the Org.
Lack of empowered teams is often the reason for OKRs failure.
Any chance you can post the slides - really hard to read some of them.
I agree. Hard to read e.g. the Spotify first principles slide. That is a powerful slide to check in more detail 🙂
The “you never have a second chance to make a first impression” is a myth… thats just being timid and shy. That is silly. STOP THAT!! ;)
Take a look at the innovation in video games, they launch what is known as “open beta” time frames where you can get customers, interaction and analytics to make the product perfect.
Also: have you ever seen someone get married to the person who was their best friend?
What is important is: QUALITY & CARE.
Thank you Mr. Marty for sharing your wisdom. However, with all due respect, a few things don't add up. 1) Not all companies are product companies. Their structure is adopted from heavy manufacturing industries from 1900s. Example: for every problem, they have a division/silo. Unfortunately they don't have any division for customer success though. They are setup for stability, risk reduction & governance. Example big banks. To move these big ships to make more nimble/adaptable, we need agile processes. With validated experience, once they can start thinking and structuring like modern day organizations, then only we can drop agile processes and adopt only agile principles for them. 2) Outsourcing - This is a messy thing. This will hurt product management approach every single day when you have teams comprised of 5 different vendors. We can't deny that reality. Without certain processes, there will be complete chaos. There are many other factors as well. IMHO, history is the only lens through which we need to see things. Then empathetically suggest 'how can we help them to become more nimble/adaptable?'. Thank you.
We iteratively deliver value to our customers, but the cost for this is an annual roadmap with a bunch of predictable features we are going to build. You can't have both.
I'd say the value in those features can change over time (they're not relevant anymore, competitors have something better to solve that same problem, something else even more valuable shows up). While predictability is comfortable for stakeholders, there's a limit of how long into the future you can plan.
I'm not advocating for "no plan", but making a point that year-long roadmaps may be more of a "safety blanket" rather than actual proof of the biggest value you could deliver.
This guy makes a number of flawed assertions in his slams of scrum, SAFe, how PM/PO training is done, the capability of a trained PM/PO vs a team as the best or only role to engage customers, and the mindset of teams as a heads-down 'coder only' orientation (as if scrum and agile have no collaborative refinement with PM/PO as voice of customer or to imply scrum discourages a team from thinking through stories and acceptance criteria). He also fails to qualify his CI/CD belief in rapid regular iterative pushes of hypothesis test to users - while its ok in cases like netscape or spotify, and during the early innovation phase of immature products, its not what many customers and product domains allow when the user community values reliability and stability above the risk of live disruptions to explore a feature idea. It is agile to be iterative and incremental in a cadence longer than 1 sprint if the user needs and values are respected, and hypothesis testing is done in ways not requiring a CD into live systems each sprint cycle. His red team characterization is deeply flawed as a desired outcome of scrum, as if we teach mechanical execution as "false scrum", or 'you are just a coder' handover of stores to developers, with no intent to leverage or collaborate with the PM/PO as the voice of customer. In between blue and red team extremes, between Bezos' day 1 and day 2 example, there is a target rich place for good guidance on teams doing scrum and SAFe well, with PM/PO roles who do their job well, and with shades of maturing from innovative wild west cycles towards more predictable and scalable outcomes. He offered no such guidance in this video. He fails to recognize the process of process improvement is a core early belief of kanban and lean that inspired retros and I&A concepts at the PM/PO role and teams adapt and improve. He appears to assume the team of developers is better positioned to engage stakeholders and users and judge outcomes better than roles trained to do so (PM/PO and UX). Some scaling approaches advocate making the team closer to users, which he says is not true. There are some product domains where his assertion may be true that a team is better than a PM/PO role to lead production direction and course corrections (he should qualify the characteristics of those situations where developers may know as much about end user needs and can be a proxy to a great PM/PO). In many cases the PM/PO is better qualified to be accountable for direction and outcomes. Teams often lack time to become experts in the product domain, and they will lack experience inside that product domain's competing solutions and business context, and teams generally lack the time to become fully engaged in ideation with every point of contact a PM/PO should be engaging. A better use of your time would be to study how a PM/PO (and UX) collaborate with stakeholders, SMEs and teams during ideation, and to learn how strategic selection of target objectives and plans to fulfill objectives can be done, and to understand good backlog ordering lead by the PM/PO in collaborative ways with teams.
Safe is a piece of crap. Period. Ask anyone who ever worked with it.
No offense, but CI/CD doesn't mean instability. In fact it has the opposite as its goal. Your entire comment is littered with inaccuracies and a lack of understanding of development best practices. SAFe is overflowing with unnecessary bloated management overhead due to a desire to control and not empower. SAFe costs companies more that it benefits them. Having worked with PM/POs out of SAFE I can say they have no idea how to do product management effectively. At all. They would make good project managers for a car company... but they don't understand PRODUCT management at all.