Beyond Lean and Agile - Marty Cagan

Product  · 

Article Link: Beyond Lean & Agile

Video Link: Lean Product Meetup

Video Link Connected

Author: Marty Cagan

Type: #literature #article #video

Beyond Lean & Agile

Key Takeaways

Context

Cagan frames the convo with the backlash (c2016 ish) against lean and agile. It’s inevitable he says - an idea forms, gains momentum and traction, folks become zealous about how it will save the world and an industry quickly forms around it selling training, books & salvation.

Backlash examples

At it’s heart Agile & Lean have a few core principles

Understand the core principles at work and not be too tied to one methodology, process or approach. There is far too much religious fervour, backed up with a willing Agile industrial complex ready to sell you silver bullets.

The core principles boil down to

  1. Tackling the biggest risks up front
  2. Design products collaboratively not sequentially
  3. Solve problems rather than implementing features

This is predicated on empowered teams - without empowered teams you will only realise some of the benefits. Empowered teams:

Biggest risks first

Lean is essentially about tackling waste. In manufacturing it’s around limiting variability, focus on quality and continual improvement. In software waste is slightly different - it comes from spending time building the wrong thing. Therefore we need to tackle the risks upfront.

One of the biggest things that Cagan has learnt is that the batting average on your ideas is pretty low - i.e. the number of ideas that turn out to be great is much lower than you imagine. Some folks quote 50%, but Cagan reckons more like 10-20%. So you are best off learning which are in the 10-20% as fast as possible.

Lots of teams and orgs don’t even tackle the value risk - it’s assumed. If you’re working with a roadmap then this might very well be you. Weaker teams just focus on the feasibility and usability - generally the easier two anyway. If you have a stakeholder generated roadmap and no meaningfully empowered teams this is all there is to do since the value is given to you via the roadmap. When the outcome turns out to be not what was expected this results in predictable internal blaming, politics and general finger pointing (without anyone being really accountable).

The viability risk is one that can really set a great product person apart. Recall a story (citation needed!) about Jonny Ive as a student - what set him apart was not just the quality of the designs but the fact that he also gave much thought to how the thing would be made. Often the difference between great and also ran is how much you look up and out, how much you inhabit a thing rather than just sitting on the surface.

Also worth pointing out that some things aren’t that risky - the value may be clear, the feasibility risk isn’t that high etc. In these cases just crack on.

Often the reason CEOs don’t value product folks is that they don’t see them taking the value and viability risks seriously. They’ll often point out that they don’t even know the basic business model. This is why Cagan thinks that “the CEO of the product” is an appropriate metaphor.

The point of discovery is to tackle these risks without building anything approaching a product. An MVP that has been worked on for 4 months not an MVP - it’s more like 4 days. MVPs are experiments not products. It’s the main role of the PM and designer to do discovery. Cagan suggests that the PM should be spending around 4 hours a day (i.e. roughly half of their time) on discovery. A good team is running in the order or 10 to 30 experiments a week. And these are not just A/B tests - of course should be doing but they don’t create value (they are value capture) - in fact some teams just do optimisation and not discovery.

50+ discovery techniques, most of them done by designers not engineers. Most described in Inspired by Cagan.

The PM role therefore is hard. It’s not a junior role. You need smart, creative and persistent folks. Cagan doesn’t agree with an Associate position. It’s hard and they need to embrace collaboration and they need to do their homework.

Cagan talks about the book “Creative Selection” by Ken Kocienda - in some ways it’s essentially a book about discovery. It describes the design process at Apple and lots on the keyboard on the iPhone. Now it seems obvious, but at the time it was completely new and very high risk - touching all for but in particular feasibility, usability and viability. Cagan makes the observation that one of the most influential and profitable products of our time was driven by the quality of the discovery work into text entry.

Collaborate

Even in orgs that are doing “Agile” often the overall process is sequential. The Product Manager defines the requirements in a story, the designer designs it and the engineers implement. Each stage is left with the constraints of the previous step. Cagan suggests that this is a crippling way to work, one that will not results in meaningful innovation.

The alternative is empowered teams that deeply collaborate in discovery to figure out what works. As much innovation comes from the enabling technologies as from the customer problem side. It is the interplay between the technology and the customer problems that gives rise to innovation - and it is the PMs, the designers and the engineers together who figure this out. This is how the best teams work. It isn’t a stand-up, or a meeting - this is meaningful discovery work between the three. Co-location (i.e. folks physically sat next to each other and working together daily) is key and therefore more of a challenge when working remotely ((a potential approach here)[https://svpg.com/prototype-of-the-day/]).

Consider solving a problem like fake news in Facebook - this isn’t going to be solved by the PM writing users stories!

Focus less on passing artifacts between each other and embrace collaboration. If discovery is going well, and the engineers are involved in discovery you can have your prototype as spec and avoid writing requirements.

Focus on outcomes not output

It’s the results that matter, not the feature that is shipped. It’s not actually that hard to ship on time or on budget. The hard thing is to actually achieve results.

Product teams exists to solve problems that your customers love, yet work for our business.

(Note the “our” in the above - I think this is subtle but important. The “our” implies the “missionaries not mercenaries” idea. I’ve never loved the word missionaries here - it’s a bit too religious for my taste since it borders on being rigid, dogmatic and zealous. But the “our” does imply a commitment to the mission and vision and a sense of shared ownership and pride.)

Time for roadmaps to go. Roadmaps are a prioritised list of features. The are a list of output. They’re not agile since you’ve locked in what you say your going to do. They’re are not lean since the value is assumed

Roadmaps are generally liked by stakeholders since they satisfy two very reasonable needs. Firstly they give the (false) sense of certainty that things will ship at certain points. Secondly folks want to know that people are working on the most important things. OKRs (while not perfect) do a better job at both. This works if the KRs are tied to real business results that are agreed to be the important things and are an outcome measure (e.g. bump international conversion by 2% vs integrate Paypal since it’s assumed that that will drive international conversion).

If the teams are asked to (implicitly or explicitly) focus on output then they are not really empowered in any meaningful sense.

How does this work in teams

Essentially there are lots of flavours of the approach that all follow a similar pattern that essentially boils down to

Objective
   +
   |    Continuous discovery
   v +-------------------------------------->
                 Continuous delivery
              +------------------------------------------->

Discovery and delivery are continuous processes - they are never “done”. You work on these things for years - consider Google AdWords, it’s 15 odd years old as of 2016ish with some 50bn in revenue.

There is also continuous learning and feedback between the two tracks - and also at multiple scales. Things are learnt in discovery, in delivery (e.g. was harder than we thought), when small things go to customers (didn’t move as much as we thought, moved waaay more than we thought), when bigger things go to customers and as the macro environment changes (competitors, trends, regulation, tech etc).

Cagan points to multiple other styles