Cagan was on fire here. Pretty sure "crap" and "shit" were his top words. Love it.

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!

The best 'real' talk I've seen on Product Management, Agility and Coaching. Marty is a gem! Thanks you @CrispAgileAcademy for sharing this!

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

Wow, this talk is gold and you offer it to us free of charge, amazing

Marty's talk is awesome again, as always! Spot on!

Excellent overview of how to reduce noise and unwarranted complexity in how we organize and do things!

Love this Marty!

What a legend!

¡¡¡This is gold!!! Finally 🙂

Pretty amazing talk. Thank you Marty

You bloody legend

Great stuff, thanks a lot for this!

Great candid presentation!

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.

Thanks for saying this clarification out loud.

The entire talks was amazing. But the last 20 secs were final nail when Mckinsey's point came!

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 :)

Thank for the video

100% agree. A lot of craps in not bring value to the Org.

Any chance you can post the slides - really hard to read some of them.

Lack of empowered teams is often the reason for OKRs failure.

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.

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.

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.

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.