Marty Cagan in London, April 2018

As part of diving into Product Management, I noticed that Marty Cagan of Silicon Valley Product Group was speaking at a Business of Software evening in London. Marty was recommended as a figure to follow by Brie, my colleague at Automattic, so I grabbed a ticket immediately.

Marty centred his talk around unleashing and empowering the engineer, and it was incredibly impressive and inspiring to listen to him. It’s always wonderful when you’re learning from someone with sufficient mastery of their subject that questions always trigger a well thought through response, backed up by multiple examples. Here’s my tl;dr for the evening:

My takeaways from @cagan last night: take good engineers, soak them in the business, expose them to customers; discover deeply; experiment frequently; work to metrics. #BoSInspired

(As a fully remote team we’re going to crack distributed product innovation & get back to you 😃)

— Simon Wheatley ✊ (@simonwheatley) April 26, 2018

(This post is from my notes, my memory and my impressions throughout the evening. In many places I’m paraphrasing and sometimes I’m even doing it deliberately. What I’m trying to say is any mistakes or misquotations are mine, and I apologise.)

You can’t listen your way into innovation. Customers can’t tell you how to innovate, they’ll tell you what they want (which will inevitably be anti-innovative), they’ll tell you what they don’t want. A strong, passionate engineering team, empowered and inspired by a vision, and fully versed in the business context, are where your innovative solutions will come from.

As an example, Alexa was born from a simple voice controlled speaker… and an engineer on the project was sitting next to the Chromecast team and wondered if the speaker could control the Chromecast. He hacked a solution, and hawked it around. Now we have Alexa.

“No customer ever asked Amazon to create the Prime membership program, but it sure turns out they wanted it…”

– Jeff Bezos, 2016 Letter to Shareholders

“A lot of times, people don’t know what they want until you show it to them.”

– Steve Jobs

Marty discussed six rules for giving your engineering team the maximum opportunity to present great and innovative solutions:

1. Soak your engineers in the business context, they need to understand the metrics for success, the contracts, the customer pain, everything. Give them all the context you can.

2. Engineers must have access to customers, as close as you can get them and ideally in the same room. This brings the problem up close, and makes the solution personal for the team.

In my own little experience, it is amazing how fast just a few testing or interview sessions with customers can settle long running discussions within the team. After you’ve talked to a customer, it’s no longer a matter of people’s individual opinions.

3. Give as few requirements as possible, don’t limit the solution by defining it. If necessary, constraints can serve in place of requirements.

There are many approaches you can use in place of a set of requirements. Jobs To Be Done is currently fashionable, but it’s just one approach among many, you might also look to Google’s Discovery Sprints. There is no silver bullet here, just a large array of tools that fit your situation to varying degrees.

5. Measure by results, not by output; “has what we produced moved the numbers?” Focus relentlessly on the numbers.

6. Have a competent PM.

This is where the challenge and the inspiration was for me. I know I have some of the required skills, but I’m aware I have significant areas of weakness to strengthen and mitigate through collaboration. In the Q&A session, Marty recommended his article “Developing Strong Product Managers”, and I’m working through the scorecard he lays out to help me understand my strengths and weaknesses through that lens.

The leading issue Marty sees with PMs is not enough training, and in particular that there’s too many people out there running PM duties with just Certified Scrum Product Owner training… which in Marty’s opinion is a qualification focussed on the administrative work of running a backlog.

Marty recently defended the term “CEO of the Product”, but clarified that you are not the boss and you absolutely cannot boss the team. The reason Marty likes the CEO analogy is there is no other role which needs to know so much and cover: all the development costs, running costs, partnerships, support, life time value, and more. (I blogged some of this.)

Judy Gibbons in the audience pointed out that all Marty’s Iconic Product Manager stories in the latest edition of his book were about women Product Managers, and I’d noticed when Marty writes he always uses “she”.

As I mentioned above, the Question and Answer session was where you really got a sense of the depth of Marty’s experience in the Product Management field, and I scribbled a lot of notes during this section. Here’s just a few questions and answers I noted down…

Q: What’s the wrong best advice that gets given out for product management?

The biggest mistake is to listen to your customers. The next biggest mistake is not to listen to your customers.

I can’t recall who Marty said this was a quote from, perhaps Steve Jobs? It speaks to the ideas right at the start of Marty’s talk, that you can’t listen your way into innovation but by listening you will hear things that spark innovation in your team and by presenting back, you can validate your ideas.

At another point during the evening, Marty mentioned the four areas you need to validate product ideas against:

• Is it desirable: Would a customer buy or use it?
• Is it usable: Can the customer use it?
• Is it feasible: Do we have the technical resources to build it? Can we support it?
• Is it viable: Is it legal, does it match any compliance requirements, are there contractual issues, etc?

Q: How should teams prototype?

Mostly avoid spending engineer’s time on prototyping, because code is not the quickest way to prototype and experiment. Prototyping is mostly a design exercise, along with the PM and the Engineering Lead. Engineers should be involved, but just half an hour a day keeps them in the loop and give opinions, warnings, and suggestions.

Many teams spend a lot of time in delivery, but without discovery you’re probably wasting time. Various companies express this in different ways, AirBnB say:

Discovery: Build things that don’t scale, then… Delivery: Build things that do scale

One figure that really caught my attention, was Marty saying that in Discovery you are looking for 15/30 experimental iterations a week. This is certainly something we need to ramp up within my team, and it’s interesting to consider the changes we’d need to make to achieve this.

Q: How can you make product innovation work with remote teams?

This was a killer question for me, because at Automattic we’re a completely distributed company… Marty was cold and clear here, and he said that working remotely is much much harder. There are exceptional distributed product teams, but they are very much the exception. The key element, in Marty’s opinion, is to prioritise a close and low latency working communication loop during Discovery, to facilitate that high rate of experimentation and to allow the engineers to briefly and rapidly check in to remain involved.