I’ve been thinking about this topic a lot, and several posts recently by Brian Lawley at the 280 Group, Tom Grant at Forrester, Steve Johnson at Pragmatic and finally one by the folks at Brainmates convinced me that the topic was ripe for discussion.
While I’m sure the topic has been informally discussed by many previously, the first formal written piece I saw was last summer. In a post entitled “The Product Management Manifesto“, Adam Bullied takes an initial stab at defining some key principles for Product Managers to follow:
- Understand the problem
- Know who it’s for
- Ascertain appropriateness or health
- Develop a clear picture of the future
- Execute in concert
- Shepard and adapt based on feedback
He also states the need for more good books on the subject and more formal education. He even created a wiki site: http://productmgmt.wetpaint.com for people to contribute to. All good stuff, but 7 months later we’re no closer to addressing the problem than we were in June.
What are we talking about?
Before getting to the problem, I want to make sure the context of this discussion is clear. While we consider ourselves Product Managers, it’s important to specify that we are technology Product Managers or even more specifically for many of us, software Product Managers.
Product Management, which originated in the Consumer Packaged Goods (CPG) industry, is very well defined. I’ve written about some of the differences between Product (or Brand) Management in CPG companies and analogous roles in hi-tech companies here.
A bit of history
Back in the 1930s, a manager at P&G named Neil McElroy wrote what is now referred to as the McElroy Memo. He was a manager responsible for Camay soap — a lesser brand to the company’s leading Ivory soap brand. Camay was not selling well and he decided that a dedicated “brand man” was needed to ensure that sales of the brand were being maximized. Here’s a good post that lists the text of that original memo.
After almost 80 years, Brand Management is well defined and is a pure marketing and business function within CPG companies. High tech, or software product management is much much younger. The origins of it can be found in an article in the Harvard Business Review in 1991, written by Regis McKenna. I’ve blogged about that article here.
In short, McKenna stated that technology is changing the traditional push marketing and selling model into one that requires insight and understanding of customer needs and wants:
Technology is transforming choice, and choice is transforming the marketplace. As a result, we are witnessing the emergence of a new marketing paradigm– not a “do more” marketing that simply turns up the volume on the sales spiels of the past, but a knowledge- and experience-based marketing that represents the once-and-for-all death of the salesman.
This is why I blogged on the article. To me it represented the birth of our field: technology product management.
What is a manifesto?
Now, let’s talk about manifestos. A manifesto is a public declaration of principle or intent. While usually political — the Communist Manifesto and the US Declaration of Independence being two of the most famous examples — they can be on any topic.
There have been quite a few business oriented manifestos in recent years including the well known Agile Manifesto, the Incomplete Manifesto, the Cluetrain Manifesto and the more recent Peanut Butter Manifesto from an SVP in Yahoo. A large list of manifestos, old and new, can be found at manifestos.net. My recent blog post about a 40year old print ad entitled “Do this or die” talks about that ad being a manifesto.
While manifestos are defined as public declarations, they are created when people see large problems that need group action to be corrected. And if that change doesn’t happen, the creators of the manifesto predict big trouble for their audience.
The Agile Manifesto was a call for change in the practices, attitude and culture of software development. The Peanut Butter Manifesto was a call for change in how Yahoo! was run as a business. The “Do this or die!” print ad was a call for change in how advertisers treated their markets and customers.
The creators of all of these manifestos saw problems around them, close the them, that troubled them, and decided to speak out and start the process of change.
And change is really what people are after when they create a manifesto: a better country, a better life, a better profession, a better industry etc.
But keep in mind that change is a process, not an event!
Creating a manifesto and publicly declaring it means nothing. It’s only when the principles and positions defined in the manifesto are enacted does the change happen. The Agile Manifesto was created in February 2001. And it is only now, 7 or 8 years later that significant change is happening based on that declaration.
Does Technology Product Management need a manifesto?
Hmmm…I can’t speak for everyone, but I wouldn’t be writing this series of articles if I didn’t think so. 🙂
I do think there are problems within technology product management that need to be addressed. Likely over time, many of them will be addressed as both the technology industry as well as technology product management mature. But who knows how long that will take and in what direction it will go?
We need to be masters of our own domain. If we want to see positive change in our profession then who else will speak for us and define what that change needs to be?
And being that we are product managers, who (amongst many other things) focus on understanding problems and identifying clear requirements to address those problems, shouldn’t addressing our own problems be at the top of our priority list?
In the next installment, I’ll talk about something we all know and love: problem statements and requirements.
In the meantime, please let me know your thoughts on this topic. What problems (if any) do you see or are you experiencing as a technology product manager or product marketer? And what ideas do you have on how to address them?
Towards a Product Management Manifesto (part 1.5)