Beyond Lean and Agile by Marty Cagan

• Worked at HP as a developer for ten years. Worked on software tools for other developers.
• Then worked for Marc Andreessen at Netscape. Had an amazing time there. Would still be there today if Netscape hadn’t lost the browser wars.
• Then went to ebay and for the first time my customers were not developers, but rather buyers and sellers.
• Started the Silicon Valley Product Group with some friends after this. Mostly advising startups and some growth stage companies.
• At SVPG we are technique agnostic, and we didn’t invent any of them. Good product people know when to use which technique.

What’s the state of lean and agile?

• There’s a backlash going on right now against these topics.
• Pundits get involved and try to oversell any new method that comes up.
• There’s another framework called Safe (Scaled Agile Framework), which I’m hoping nobody here uses. It’s used by banks a lot. I don’t know a single tech company that uses it.
• Three principles of agile are still solid though.
• There is a correlation between the number of “at bats” you get and the amount of success.
• We need to go fast if we’re going to innovate.
• Each iteration is something we can test, and learn from.

So what’s different about strong teams?

• Have had an advantage, in that I’ve been able to work with really good people. Was introduced to Google when they only had six people.
• When they do something well, I get those techniques and spread them around.
• The best teams work very differently to the basic IT agile style teams do. They have taken the benefits of lean and agile, and taken steps beyond that.
• 3 Key Themes
  • Risks
    • Product teams are typically happier to optimise, rather than take risks.
    • Good teams focus on tackling these risks early and often:
      • Value risk
      • Usability risk
      • Feasibility risk
      • Business viability risk
    • All the best teams know these risks and tackle them before their engineers go build stuff.
    • Not everything we build is risky, it’s clear that we just need to do it. If design, PM and engineering look at those four risks and are fine with them, then you just build.
    • Feasibility and usability are not that hard, but the other two are much harder.
    • Value risk is by far the biggest. Most things we think are valuable to users don’t turn out to be. Don’t know any company that has better than a 50% batting average on this.
  • Collaboration
    • Define products collaboratively, not sequentially.
    • You need all three roles working closely together. Design, engineering, product.
    • It’s a lot of give and take between them.
    • A lot of companies don’t have the right people doing these jobs. Some companies have the old IT developer mindset, who just want to be told what to do.
  • Results
    • It’s not that hard to ship things on time, and meet budget.
    • It’s hard to build things that achieve results.
    • a weak product teams are there to ship feature on a roadmap.
    • A good product team is there to solve hard problems.

Recommended book: Creative Selection by Ken Kocienda. Great example of a huge risk that had to be overcome, removing the keyboard from the phone and having the on screen iPhone keyboard. Very detailed description of how they worked on products with Steve Jobs.

• Discovery and Delivery: this is not a process, it’s a conceptual model.
• Start with an objective, rather than a roadmap. A clear problem to solve.
• Discovery is about build to learn. Delivery is more like build to run a business.
• Some call this dual-track agile.
• You want to be doing something in the order of 15-30 iterations a week on discovery prototypes.

Truly empowered teams

• This whole talk is predicated on having empowered teams.
• The team must be staffed with competent people with character, covering the necessary range of skills.
  • Competent = Too many product people don’t know how to do their job. They have not done their homework. They can usually be trained, but if they haven’t been, they’re not up to the job.
  • Also no assholes on the team.
• The team is assigned problems to solve, and they are to decide the best way to solve those problems.
  • It doesn’t mean they can go off and build whatever they want. It means they have a clear objective and is accountable for solving it.