I remember being at Novell in the late 90's and feeling absolute hate emanating towards Microsoft. This was despite us all using many of their products internally - including Windows - Microsoft has some extremely good products (Excel is a case in point). Novell's hatred of Microsoft caused them to go on an irrational buying binge to assemble products (Wordperfect, DR DOS et al) and compete head-on with Microsoft. As we know, this didn't work - nobody can beat a bigger adversary by attacking them head on. Hatred created a flawed strategy that led to failure.
Of course you have to observe your competitors carefully. Frequently, you'll need to react to what they're doing. However, that's not the same thing as shadowing their every move.
I've been doing a fascinating set of interviews with the successful heads of product management and product marketing organizations. Since the topic is, "Tell us your best practices," the interviews are the perfect occasion to probe many issues that vex people in this profession.
Whenever we got to the part about running a PM team, I inserted a question about the type of person who makes a good product manager. As seen in some of the research I did last year, product managers come to the profession from a motley collection of previous jobs. (No surprise there.)
However, it's clear from these interviews that the people who run PM departments are pretty unhappy with this state of affairs. Frequently, they've taken deliberate steps to fix it. Sometimes, this means an agonizing reappraisal of whether the people in the team today have all the skills and experiences they really need.
This Saturday's convocation of product managers, P-Camp 2009, was an outstanding event. Great presentation and great conversation. Many thanks to Rich, Luke, and everyone else at Enthiosys for organizing P-Camp, and to all the sponsors for making it happen.
Here are a few take-aways from the presentations I attended:
In response to the last couple of posts about invention and innovation, Jennifer says:
While this is an interesting thread to read, and can definitely cause many long hours of debate sitting in front of the fire with our pipes et al, it seems that it might be missing the mark with product management.
Yep, I agree. Which leads me to the next point I wanted to make in this series:
Inventors in development need innovators in product management.
While the two groups often don't get along very well (product managers are naysayers, development is just doing its own thing, etc.), the partnership between them is essential. Someone with a cool idea and enormous technical skill is usually the first person in a new product group, or a new startup company. However, that inventor can benefit immediately from someone who's a professional reality checker and opportunity finder--a product manager.
Last Wednesday, the part of Forrester that runs the Leadership Boards sponsored a dinner in the Boston area for product managers and product marketers. (This was part of the regular activity for the new Technology Product Management Council.) And wow, was that a good conversation.
The good news is, the research agenda is on the right track. From social media to product requirements, from the PM job description to general best practices for PM, from Agile in the tech industry to how people become thought leaders, we seem to be picking the right topics.
The bad news is, I have a lot of research to do. But that's only bad news as long as I'm not doing it.
However, that wasn't the best part of the dinner, which was when we Forresterites shut our big yaps. The product managers and product marketers had a lot to talk about themselves, comparing experiences in profession that doesn't give many opportunities to talk across organizations. Fostering and participating these missing conversations was one of the reasons I wanted to join Forrester in the first place.
What we're doing The research into a research piece on best practices for requirements documents is underway. As anyone who has ever been responsible for requirements knows, there are two sides to this question:
The requirements process. The overt part of requirements is the process of writing them. The subtler part of the process is figuring out the information needed for the audience. Development (including QA and documentation) might be the primary audience, but they're hardly the only ones.
The work product. In other word, the actual requirements document. Or, in many cases, documents. For example, while there might be a template for feature requirements, it may link to related or supporting documents (personas, customer feedback, etc.)
How you can help As with any type of research, the larger and more representative the sample, the better. Which means that you, Dear Reader, can help make this research project all that it can be. In this case, we need your help with that second aspect of requirements, the work product.
Speaking of social media, one of the two research documents now in the editing queue looks at using social media as a source of product requirements. Using Forrester's POST* methodology as a starting point, how can product managers harness the enormous amount of potentially useful information transmitted in the clear through blogs, forums, Wikis, and similar technologies?
The other document in editing is the "Agile company" piece, covering the results of the survey and interviews we conducted to understand how Agile development changes technology companies. To foreshadow the results, I had to divide Agile adoption into two stages. To date, Agile aficianados have focused on the first, Agile within the development team. Clearly, for the story of Agile adoption, that's only Chapter One.
* In this approach, the steps for analyzing social media involve people, objectives, strategy, and technology (POST).
Obviously, it's important to handle customers deftly when you can't comply with their requests. You'd like to keep the conversation friendly, but sometimes, the situation gets confrontational. Your diplomatic skills will face their toughest challenge.
All politics is local I might have been unusually blessed with reasonable, understanding customers, but I never found the "foreign policy" part of saying no to be that difficult. The real headache, at least where I've worked, was "domestic politics"--what happens within your own company when you have to say no to a customer.