Readers of my book and articles know how much I value a strong project manager. I’ve written earlier about the positive impact to velocity a great project manager can have (see http://www.svpg.com/ebay_secret_weapon/ and http://www.svpg.com/product-management-vs-project-management/. And one of the reasons I advocate for Scrum is that as a process it values this role of project manager as “impediment remover” (known as the Scrum Master role).
In the consumer packaged goods industry, most people have a pretty clear image in mind when you refer to the “product” that they manage or work on. You can hold the bar of soap or the razor in your hand. However, in the Internet world, when we refer to “product” it is much less clear. First of all, most of the time we’re not even referring to a physical item but rather to software. Second, most of the time the software isn’t even installed on your computer but rather it’s running on a some remote server, or even more abstract, it’s running “in the cloud.”
I’m not the first person to come to this conclusion, but over the years, I’ve really come to dislike the entire concept of a “requirement.”
Believe it or not, there are still people out there that think that a technology company is really about two types of people: engineers and sales people. People to write the software, and people to go sell it. Everyone else is overhead and at best a necessary evil.
For nearly every organization that has grown beyond a very early stage startup, one of the most common, yet difficult, questions is the optimal way to split up the product work. As soon as you have more than one product manager, or more than one interaction designer, teams face this question. And for larger organizations, this becomes a very significant and ongoing struggle.
One question I’m often asked is whether an early stage startup needs to hire a product manager or head of product. The answer really depends on the skills of the founders, especially the CEO. Much more often than not, I see the CEO as the head of product, and I argue that in most cases this is a good thing. This is especially true in consumer-facing companies.
I want to be clear up front that this is not a typical article. I have had as a policy to only provide product development process related content to my SVPG readers, and this is the first time in the 5 years I’ve been writing these articles that I’ve strayed from that. So I completely understand if you do not wish to read further. However, I’m hoping that people will give me a one-time pass on this one because it really is for a good cause, I don’t gain anything personally, and I promise I’m not asking anyone to contribute money.
In my last article I discussed the top reasons for slow product, and here I wanted to highlight the top reasons for weak product. I am defining weak product here as product that fails to meet its objectives and provide new and expanded sources of revenue and/or growth for your company.
I work with quite a few product teams, and after a while you start to see patterns. Many organizations are frustrated because they believe that it takes far too long to move from concept to delivery. They often just blame the skills of their developers, which is rarely the root cause in my experience.