“Good companies manage Engineering. Great companies manage Product.”
– Thomas Schranz (Founder & CEO, Blossom)
Dear all,
those of you who have worked with me for some time, know that I am a product- and innovation guy at heart. I fell in love with this when I was a roommate and co-tinkerer of some of Larry Leifer’s Smart Product Design Lab (SPDL) students at Stanford and it became the defining theme for my subsequent career at Apple and elsewhere.
When in the early 2000s I encountered the first Agile teams at the company’s HQ who’s European organization I headed at the time, I was puzzled by the intense focus on development process and method. Just trying to get some of the customers‘ very concrete problems with our product solved, I had to deal with user stories and backlogs that were debated with almost religious fervor. Process over customer value and product, it already felt wrong at the time.
Starting to consult large organizations‘ product processes, agile methods still became our obvious choice for the increasingly complex digital components of even „classic“ mechanical products. And they work; way better than waterfall projects, no doubt about it.
Being successful in these complex contexts, and also maybe because „being agile“ sounded great, agile transformation became a rallying cry for management, who often had – and still have – a very fuzzy understanding of what Agile methods entail.
As pointed out a few weeks ago: Agile methods don’t buy you agility. In particular not, if supported by hastily trained and -certified „Scrum Masters“ who have never been near delivering a real-world end-customer product before. And therefore cling to optimizing their rituals and processes.
Not only for this reason, method focus prevails. Scaled Agile and others thrive on certifications. “Medium” and other blogging platforms are full of posts on how to improve Scrum. Management decisions are being taken to scale methods and processes to industrial levels.
Stepping back one will quickly come to understand that the underlying paradigm has become efficiency. More story points with fewer dependency risks. Better plans. Industrialized software mass production. Feature factories. Ultimately, that’s 20th-century industrial thinking…
The 21st century is digital. Successful digital products are about scientific customer focus. Product-led unicorns like Shopify or DropBox and digital world champions like Amazon show the way. As Jeff Bezos puts it in his Day 1 principles:
– Be obsessed with the customer
– Focus on results over process
It’s time to start focusing on customers and products. Worry about outcomes instead of output. We have the tools and methods. Do we need a Product Manifesto (and a pile of certifications to print money for ourselves) to change the paradigm and turn the next 20 years customer- and product-focused?
Let me know what you think!
It’s not only some product-geezer like me. Here are some more thoughts on this:
Agile manifesto is long gone! We need a product manifesto!
David Pereira point out that challenges have changed – do we need a new manifesto?
Why we Need to Rethink Product Management in an Agile Practice
Anthony Marter asks why agile practices feel uninspiring and why it may be a long way until“engineers solve problems (and not always just with code)”.
How Agile Has Changed Product Management
Roman Pichler discusses benefits and challenges of Agile for product management. A balanced view.
We’re getting ready for a few days of vacation. Not sure I can – lounging by the pool – muster the willpower to provide a new installment of WR next weekend…
Cheers,
Godehard
PS: The agile manifesto says:
„We are uncovering better ways of developing software by doing it and helping others do it.“
NOT
„We know the one true way to manage the software lifecycle. We don’t actually write software, but we can certify you.“
(from some LinkedIn feed last week…)