Marty Cagan’s “Transformed” workshop – some key takeaways

So last Monday I spent a fascinating day with about 50 other senior product folk, being taken throught the first version of a new workshop/book “Transformed” from Silicon Valley Product Group. It was the first time Marty Cagan had run this workshop, and there was definitely more to fit in than there was time for – but it was still all really great stuff.

The inspiration for the book seems to have come from a pretty universal mental rollercoaster after attending the “Empowered” workshop. It turns out former-boss Miranda and I were not remotely the only people to get on a video call with Marty afterwards to say “that all sounded great, and we’re a big organisation who are definitely doing ok at becoming more agile and product-centric, but we’re still miles away from that! How and where do we start?”

“Transformed” is not the complete answer, but it’s definitely enough to give hope. And, like so many of these events, being in a room full of other people going through the same new challenges and sharing their own practice gave me enormous heart. I definitely felt like I was no longer alone.

I don’t want to basically blab the whole day, but here are a few notes I’ve made and shared with internal folks at GDS.

The premise

Fundamentally he talks about changing how you build (move to continous delivery), how you solve problems (continuous discovery) and how you decide which problems to solve (product strategy). This needs organisations to make sure they’ve got competencies in product management (NOT product ownership the Scrum role), product design, product engineering, and some other supporting roles. It also means building proper product leadership to enable the teams through coaching, staffing and making sure the right strategic context is in place for teams to be truly empowered (but also have the right guardrails in place). He also talked quite a lot about creating Product culture and principles. The latter part of the day was “and now…how do you assess your current organisation, create a plan for getting where you want to be, and overcome the objections along the way”.

Interestingly he also said it was important to focus on principles, and not fall into a temptation he sees across Europe of turning those principles into a process – which can become an end in itself. He was quite anti telling us any process at all, in fact. So that’s us well and truly told!

For practitioners

(The latter part of this list contains familiar points from “Inspired” or “Empowered”, but they’re still worth repeating)

  • Probably don’t describe where you want to get to as “product-led”. That’s sounding like we know best and we’re here to take over – Marty prefers “the product operating model”
  • Lots of product writing is from the startup perspective, when you have little to lose. Enterprise organisations have lots to lose – be sensitive to this
  • Marty was really explicit about separating out mission and vision, when a lot of literature blurs them together. He used Trainline as an example: their mission was something like “enable people to make greener travel choices”. Their vision was a four-minute video showing the sort of experience they were hoping to create that would get them there. It didn’t get into specific features, but every team member who saw it would know the sort of thing they were headed for to realise that mission
  • Marty’s observed that remote working seems to be OK for delivery, but isn’t working so well for discovery – he thinks teams that get together f2f are more successful
  • Spotify say that 100% predictability means 0% innovation
  • There’s a HBR study that says that only 10-15% of our original ideas have the benefits we expected (i.e. “work”) so discovery to validate them is important
  • Every company has more opportunities and risks than they can fully address – it’s all about choosing. Spreading your teams super-thinly and trying to lightly please everyone is unlikely to have the impact you’d hope for
  • PMs have to show they know the customer, the data and the industry in order to be trusted by the organisation – it would be negligent for leaders to let you have free rein until you can show that. Do you?
  • Empowered software engineers are the most important thing you can get – your job is to give them all the context they need to be empowered.

For leaders

  • You need to change how you deliver software, how you solve problems and how you decide which problems get solved.
    • The first – continuous delivery – is probably easiest because it’s largely within the control of the technology organisation.
    • Changing the “how we solve problems” through continuous discovery is hard, but thinking about “time to money” rather than “time to market” is a good starting point. It’s not just about shipping that idea, but shipping an idea that’s valuable.
    • Creating better evidence-led product strategies, that contain their own work to validate assumptions and become smarter, is harder still.
  • CEO backing is the biggest factor in whether a move to product operating model will succeed
  • Keep coming back to the principles, don’t let process take over – relationships with finance and any PMO will change lots and their work will need to change lots as well, be transparent about that and don’t let process settle in before those changes have happened
  • Remember Steve Jobs’ takedown of John Sculley’s Apple – “the disease was thinking that having a good idea was the hard part, and the rest was just execution”. How will you share the evolution of ideas and the learning that shapes that?
  • You are only as good as your weakest PMs, so remember to keep coaching
  • Don’t tie performance management to OKRs, otherwise nobody will be prepared to work on anything risky or hard
  • He talked about the impact of generative AI, and thinks it will make prototyping – where risks can be managed – easier and faster, but production code will take a lot longer. He’s written an article called “preparing for the future” that goes into this in more depth.
  • This new culture and way of working is a product in itself – start small with pilot teams, learn and iterate, but keep telling the story of what’s working
  • The product operating model is fragile. A new senior manager who doesn’t buy the idea of empowered teams working on problems, and wants to be specific about what they’re going to get, can destroy years-worth of work on culture in just a few months. Finding ways to make this resilient and ensuring the story is easily told is hard. It’s also emergent practice, and the last chapter in the book.

What am I going to do next?

So what are my own next steps?

  • I’m working on a survey of my PM community anyway, and I’m going to ask them about trust, but also how they understand their responsibilities to leadership
  • I’m going to think about other ways to regularly temperature-check “trust” and “empowerment”.
  • I’m also going to ask about whether they feel they truly know the users, data and policy context – triangulation points on the trust and empowerment ideas
  • I’m also going to ask where people are on the missionaries/mercenaries scale and think about leading indicators of teams becoming more like the former
  • I want to delve into the collective responsibilities of trios and how well that’s working
  • I’m going to pick 2-3 teams I think I can helpfully influence them and their leadership without risking delivery, and where there’s going to be a story to tell, and see if we can build trust in this model
  • I might also borrow some of the ideas Which? use to support this – rotating engineers through the discovery part, and rotating who presents at the team checkin
  • I’m going to get myself copies of Anne Duke’s “Thinking in Bets” and Tony Fadell’s “Build” which are both long overdue. I need to reopen my old Steve Blank books and read up on him talking about principles over process.
  • Marty’s kindly shared a few other bits with me that I’ll be thinking about too.

All of which will keep me very busy.

Further reading/social whirl

So that’s my own personal take. There are also other good summary posts on LinkedIn from:

  • Nick Jemetta – ex-Argos, now a Product Coach
  • Paulo Gaudencio – Product Ops lead at Cofidis
  • Tobias Freundenrich – ex-Xing, now also a Product Coach, who knows a couple of people from my Cimex days
  • Marty himself – where you can see a lovely photo of the back of my and Rico’s head, captured beautifully by either Chris Jones or Jonathon Moore.

I got to meet some fabulous other people too – Monica Viggars, some lovely long-suffering folks from MOD that I’ve met before, and the Crisp gang (Mattias Skarin, Marcus Castenfors, Matthias Holmgren, Jan Grape). I’d never heard of Crisp before, but they were product coaches to Spotify! Marcus also co-wrote a book called “Holistic Product Discovery” that looks worth a read.

Nick Jemetta also put me onto Graham Reed who runs an interesting-looking community called “Product Mind“, looking at the mental health of our practitioners. We do a stressful job, and often feel quite isolated or caught between impossible choices, so anything I can do to help people as part of that feels like a good thing.

All in all, a brilliant day. Different from what I expected, but definitely one that opened a new chapter in what I do.

One thought on “Marty Cagan’s “Transformed” workshop – some key takeaways

  1. Pingback: Weeknote 29th July – a gentle return - LeaningForward Blog

Leave a Reply

Your email address will not be published. Required fields are marked *