Marty Cagan on making better use of engineering teams

We hosted Marty Cagan, founder of Silicon Valley Product Group last night in London for a talk based around the new edition of his book, Inspired: How to Make Tech Products Customers Love.

Originally meant to be a slight update, Marty soon realized that the evolution of Product Management in the past 10 years called for a full rewrite of the original book. One of the topics he covered was making better use of engineering teams. Super-smart, experienced and an absolute gent, he talked about some of the latest developments in the world of Product Management before taking questions from a sell-out audience of very smart product people. We overran but no one cared.

A highlight for me was the six points he made on making better use of engineering teams…

 

It says a lot about how engineers are treated in many organizations that every point had an audience of mainly product people and software engineers nodding along in recognition. There is almost certainly a Dilbert cartoon that we could insert to illustrate each of these points about making better use of engineering teams but we don’t want to get in trouble with the licensing police.

On making better use of engineering teams

1 Provide Engineers with Full Business Context.

Far too many CEOs and executives ‘protect’ their team to the detriment of progress and innovation. They think engineers just want to be left to code and not be worried by the rest of the world. Managing Engineers like this leads to bad outcomes.

2 Provide Engineers with Access to Customers.

Magic happens when engineers see their customers face-to-face. This is NOT the same as watching them work on a video link, a research report or a piece of market research.

“They need to be with people in person to understand the visceral motivations of the customer.”

“How can we drag them away from their coding for an hour which is what they love?”, goes the refrain. It’s true that not all engineers are into this but at least some of the team should be – if you don’t have any engineers that actively want to do this, you haven’t got the right team.

3 Provide Constraints NOT Requirements.

Think about the Jobs-to-be-Done, not requirements to deliver. Engineers are smart people and can make good decisions given the right objectives. If they are simply told to deliver X, you get what you deserve.

4 Provide Engineers Time for Discovery.

There are lots of different techniques – Jobs-to-be-Done, Design Thinking, Discovery Sprints… There are even techniques to manage your techniques these days. However, there are no silver bullets, all have strengths and weaknesses and you need to be able to choose the right one for the job.

“Most companies are much better at delivery than discovery.”

Agile is about delivery, not discovery. Move fast = discovery. Don’t break things = delivery. Lean Startup is great when it is used properly but terrible when it is used inappropriately or badly. An MVP CANNOT take 4 months in discovery. You can do 15-30 iterations a WEEK in discovery.

5 Measure Product Team by Results not Output.

Understand the OKRs and focus on business results your engineering teams deliver, not the amount of work they do.

6 Provide Engineers with Competent Product Managers.

Too many product managers just have a Scrum Certificate as qualification. You need something like that as a minimum but that isn’t even 10% of the job.

“Should the Product Manager be the CEO of the product?”

This is a controversial point for many as they are NOT the CEO usually, except in startup phase, but they ARE like the CEO as they need to understand all of the aspects of the business – user acquisition cost, engineering, design and UX, legal issues, compliance issues, marketing, onboarding, contracts, sales channels… Great product managers  need to be able to look across the business.

“The only other role in the company that is like that is the CEO even if the product manager doesn’t have the power and authority of the CEO. That is what makes it a super hard job – the hardest job on the team.”

We Couldn’t Agree More.

That is why Business of Software Conference exists but we would go further. Of course, it’s true that if Product Managers understand how all of the pieces of a business work, they will do a better job, so why isn’t this also true for other parts of the business? As Marty suggests, getting engineers in front of customers helps build better products. Equally, if marketing people understood the motivations and  constraints that other departments of the business, wouldn’t good things happen?

At Business of Software Conference we aim to help a better understanding and dialogue between teams across an organization. That’s why we curate a set of talks that is very deliberately not focused on the needs of a single team.

Business of Software Conference Europe is next month, (May 21-22), in London. We’re focusing on how to promote sustainable growth in a company, by looking at Product, Marketing, Sales, Culture, Innovation, Design, and more.

See the schedule here and grab yourself a place before it’s too late.

A huge thank you to both Marty for sharing his experience and to everyone that came to such an engaging, entertaining and thought provoking CEO Tales.