TL;DR version – he argued for making the engineering team also responsible for the outcome of their development. Based on some other discussions at and around the conference, I think it might go a bit further than that.
He was on some well-tread ground of his, focusing on the antagonism many product managers hold against agile. The (literally) first principle of the agile manifesto seems like it’s heading in the right direction:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. [source]
According to Patton, the problem begins with a massive anti-pattern that plagues both Product and Engineering teams, that results in Engineering ultimately seeing itself as a fast-feature-delivery factory. It basically goes like this:
- Product goes away and works out what the market needs
- As the Voice of the Customer, Product talk to Engineering about the requirements (in the form of stories or what-have-you)
- Engineering estimates the requirements
- Product and Engineering negotiate a feasible, smaller estimate, and in the process limit scope
- Engineering builds and releases the feature in the quickest, cheapest manner based on the newly-limited scope
This is what Patton calls the ‘Vendor-Client anti-pattern’. Effectively, the relationship between Product and Engineering becomes one of client and vendor, with Engineering seeing only the discussion around (the classic project management triad of) quality-time-cost, meaning that everything comes down to how much cost they can save and how quickly they deliver solutions. In other words, Output is confused with Outcome, Product is seen as the Customer, Value is conflated with Cost-saving, and hence the emphasis on Velocity in agile development teams.
— Adrian Makohon (@a_makohon) April 20, 2018
I’ve spent much of the last two years thinking about the relationship between product managers and the rest of the organisation, especially for purportedly ‘product-focused’ organisations. Having a bad fit between the definition of (market/customer/user) Value, on the one hand, and organisational culture and practices on the other, can lead to a lot of nasty situations.
CEOs who think they’re their own customers or users, who are so output-focused they don’t care whether it actually provides value for the market or if the team is ground to a pulp, or who ultimately don’t care about what the product does as long as they get their golden parachute. (I’ve worked for all three – sometimes they’ve been the same person).
Developers who just do what’s written on the user story or the JIRA issue, without questioning what it does, or who spend so much time worrying about the elegance of the code or technology, that they never finish anything valuable to the market. (Oh, the stories I could tell).
Designers who are too busy coming up with the right agile/lean/customer-centric framework, or agonising that the the GUI doesn’t look pretty enough, that a single screen design takes forever. (Diva, design thyself).
Worst of all, product managers who take the phrase ‘CEO of the Product’ just a little too seriously (Guilty, as charged).
Patton is right: value is misunderstood across the organisation, and this is our fault. His proposed solution includes bringing engineers into discovery and design activities to understand what really matters – as he has argued for quite some time – and also to include holding the engineering team responsible for the market outcomes of the solutions they build.
I think they’re both good ideas. But I’m not sure we should stop there.
Patton’s talk was in the context of a couple of days of talks and workshops – MTP have done a great write-up here – but I think the following, final talk by Paul Adams from Intercom had a few extra things to add. Adams argued that we need to consider our work in the context of the broader organisation. To do this, he proposed a product value chain that goes beyond Product, Design and Engineering.
— Lena Haydt (@LenaHaydt) April 20, 2018
I don’t think it’s a coincidence that Adams’ value chain contains twelve steps. We need to wean ourselves off the idea that we are the centre of the product universe, or from (actively or otherwise) encouraging the conflation of the Voice of the Customer with the Customer. We need to fit better within the organisation, and help the organisation fit better with the market.
If that means involving others across the organisation in identifying, measuring and taking responsibility for the value we create, then that should be a welcome measure for product people. In the end, we’re neither the CEO of the Product, nor our own Customer. Isn’t that what we should have been saying all along?