Achieving Extraordinary Results with Ordinary People – Marty Cagan

Posted bymartin

Notes from a talk by Marty Cagan, at a Product People meetup hosted at Geovation on 19 October. Marty Cagan is from Silicon Valley Product Group has worked at places like Netscape and eBay back in the day, and advises lots of startups on how to do tech product management.

Empowered teams

Bad approach:
Tech teams exist to serve ‘the business’.

Good approach (product culture):
We set up teams to serve actual customers, meeting their needs in a way that they love, but in a way that meets the need of the business.

Why don’t most organisations do this?

Trust. Senior management don’t think that they can trust subordinates with decisions. They think the people aren’t capable.

Coach Bill Campbell, who coached Amazon, Apple and Google founders:
“Leadership is about recognising that there’s a greatness in everyone, and your job is to create an environment where that greatness can emerge”

The role of leadership

Leadership is about inspiring people to a goal. Leaders need to provide:

  • Product vision – a north star aligning every discrete product team in the organisation. Needs to be inspirational. It’s the main recruiting tool.
  • Product strategy – the plan for getting from the current state to the desired end state. Not a product roadmap – more a sequence of big milestones.
  • Product principles – princples to help you make difficult product decisions. e.g. at eBay resolving the fact that the seller team had a lot of power, and that could lead to buyers being treated worse. So eBay established a principle of always favouring the buyers, because if you take care of the buyers then the sellers will come.
  • Product priorities
  • Product evangelism. “If you ease up on evangelism there’s always someone that is going to take your resources”

The role of (people) management

“It doesn’t make sense to hire smart people and then tell them what to do; we hire smart people so they can tell us what to do.” – Steve Jobs was negative, but he didn’t tell people how to fix things. He gave them space to do that.

  • Staffing. Put the right people in place and don’t set them up to fail.
  • Coaching.
  • Objectives (Not roadmaps. Give people business problems to solve. Let the team figure out how to solve the problem. Make sure that different teams’ objectives are reconciled with each other. )

The Basis for Trust

You need to get the right competencies in the team.

Trust needs competence and character.

Often managers don’t know or understand the needed competencies.

The All Blacks have a “No Dickheads” rule. They’ve kicked players and coaches over this principle of character.

“Cultural fit” is a bad thing to recruit for because it leads to hiring people like the people you already have.

The best way to recruit is to go for competence and screen out the jerks.

How to tell if a team is empowered

  • The team is staffed with competent people with character, covering the necessary range of skills. (e.g. having teams with engineers and product and design)
  • The team is assigned problems to solve, and they are able to decide the best way to solve those problems. (Not implementing features on a feature roadmap. 3/4 of those features won’t solve the problem. Do whatever features you need to do to solve the problem.)
  • The team is accountable for solving the customer or business problem (i.e. delivering an outcome). Leadership gives the objectives – e.g. make the churn rate better. The team gives the key results – e.g. saying that we think we can do a 10% improvement. Teams can suggest objectives, but the organisation needs to think about coordinating and prioritisation organisation-level objectives, so needs to drive this process.

Bonus: Cagan’s thoughts discovery

3 things you need in a good team:

  1. Are they tackling the big risks up front? (value, usability, feasibility, business viability) PM responsible for making sure that we resolve these risks (or at least well enough) before we write production code.
  2. Are they collaborating closely around the problem, rather than passing it around between disciplines?
  3. Not about implementing features, it’s about getting results. shipping things on time and budget is not important – it’s about getting results. time to money is more important than time to market.