Aug 2008
Product Management Certification?
08.21.08 Filed in: SVPG Blog
Occasionally product managers will ask me if they should get “certified” as a product manager. There are half a dozen or so organizations that have created their own “product management certification” programs. Now, I do not blame any of these organizations in the least for doing their very best to persuade product managers that they really need to get their company’s certification, or to persuade managers that they really should only hire staff that has passed their company’s certification. This is simply smart marketing.
But I think there is actually a very significant issue here for our industry, and in this article I’d like to share my views on the topic of certification of product managers.
Through my roles at some very fast growing Internet companies, I have probably hired as many product managers as any person in the high-tech industry, and I can tell you that I have never considered this credential meaningful. And I do not know of a single one of my colleagues at leading Internet companies that values it either.
Specifically, I believe it is premature to have certification for our field, and that having a certification at this stage actually hinders the progress that is so critically needed. I have five key reasons for this view:
First, let’s please all admit that as an industry and a profession, product management is nowhere near the science that we wish it was. The overall success rates for software products is dismal, and the product manager is at the heart of this. The certifications are effectively endorsing the same old failed tools and processes that the industry has been using for decades.
Second, internet software product management is not like product management for a new type of laundry soap. Product management from the consumer packaged goods area has very little to do with the job of a product manager for a new commercial internet service. Too many people mistakenly believe that they can leverage the same tools and processes from the packaged goods world. Similarly, product management for commercial products is very different than product management for custom or contract software. The certifications generally don’t understand these distinctions.
Third, I argue that there is no single product management model that makes sense for all product software companies. See http://www.svpg.com/blog/files/the-best-pm-model.html for a detailed explanation of this important point. A certification that effectively encourages a product manager to try to fit a square peg in a round hole is not helpful to the team or the product manager.
Fourth, mostly these certifications aren’t even covering product management in the sense that tech companies need, which is all about product discovery; instead they’re really much more about what most Internet companies would consider product marketing. For non-tech companies this may be fine, but for commercial product companies, hiring a “product manager” that is really trained in product marketing is a recipe for frustration.
Finally, and most important, I argue that teaching and certification of old and failed techniques simply works to institutionalize the bad practices.
I argue that what we need to be doing as an industry is aggressively trying out and sharing new practices, role definitions and processes. We need to be encouraging and rewarding innovation not just in the products we create, but in how we create those products. We need to be sharing the results of our experimentation. This is not the time to lock in a set of practices, especially an old and obsolete set of practices.
This is why even though I also offer training for product managers, I do not want to call it a certification (despite the advice of my marketing friends). The workshops I do are all about sharing the very latest practices from the leading commercial product teams in the world. The practices are changing and evolving constantly.
If and when I ever get to the point that I truly believe that we have cracked the code on creating great products every time, then I’ll offer a certification.
In fairness, some of the different certification programs out there are more useful than others. In my view, some are fairly harmless, but others simply create bad habits that your manager will need to try to help you break. Also note that I’m only talking here about the relevance of these certifications for product managers at commercial software product companies. If you work in other industries they might be more relevant.
The bottom line is that if you are a hiring manager, you must know that you need to do more to find the right staff than to hire someone because of a so-called “certification” in product management. See http://www.svpg.com/blog/files/recruiting-product-managers.html for a much more effective and actionable description of what to look for.
If you are a product manager considering a certification, I would instead encourage you to put your energy into following some of the excellent bloggers on the topic (see www.svpg.com/resources), using your social network to learn about how your friends at leading companies do their jobs, and especially in trying out new techniques.
Sign up for the free newsletter here.
But I think there is actually a very significant issue here for our industry, and in this article I’d like to share my views on the topic of certification of product managers.
Through my roles at some very fast growing Internet companies, I have probably hired as many product managers as any person in the high-tech industry, and I can tell you that I have never considered this credential meaningful. And I do not know of a single one of my colleagues at leading Internet companies that values it either.
Specifically, I believe it is premature to have certification for our field, and that having a certification at this stage actually hinders the progress that is so critically needed. I have five key reasons for this view:
First, let’s please all admit that as an industry and a profession, product management is nowhere near the science that we wish it was. The overall success rates for software products is dismal, and the product manager is at the heart of this. The certifications are effectively endorsing the same old failed tools and processes that the industry has been using for decades.
Second, internet software product management is not like product management for a new type of laundry soap. Product management from the consumer packaged goods area has very little to do with the job of a product manager for a new commercial internet service. Too many people mistakenly believe that they can leverage the same tools and processes from the packaged goods world. Similarly, product management for commercial products is very different than product management for custom or contract software. The certifications generally don’t understand these distinctions.
Third, I argue that there is no single product management model that makes sense for all product software companies. See http://www.svpg.com/blog/files/the-best-pm-model.html for a detailed explanation of this important point. A certification that effectively encourages a product manager to try to fit a square peg in a round hole is not helpful to the team or the product manager.
Fourth, mostly these certifications aren’t even covering product management in the sense that tech companies need, which is all about product discovery; instead they’re really much more about what most Internet companies would consider product marketing. For non-tech companies this may be fine, but for commercial product companies, hiring a “product manager” that is really trained in product marketing is a recipe for frustration.
Finally, and most important, I argue that teaching and certification of old and failed techniques simply works to institutionalize the bad practices.
I argue that what we need to be doing as an industry is aggressively trying out and sharing new practices, role definitions and processes. We need to be encouraging and rewarding innovation not just in the products we create, but in how we create those products. We need to be sharing the results of our experimentation. This is not the time to lock in a set of practices, especially an old and obsolete set of practices.
This is why even though I also offer training for product managers, I do not want to call it a certification (despite the advice of my marketing friends). The workshops I do are all about sharing the very latest practices from the leading commercial product teams in the world. The practices are changing and evolving constantly.
If and when I ever get to the point that I truly believe that we have cracked the code on creating great products every time, then I’ll offer a certification.
In fairness, some of the different certification programs out there are more useful than others. In my view, some are fairly harmless, but others simply create bad habits that your manager will need to try to help you break. Also note that I’m only talking here about the relevance of these certifications for product managers at commercial software product companies. If you work in other industries they might be more relevant.
The bottom line is that if you are a hiring manager, you must know that you need to do more to find the right staff than to hire someone because of a so-called “certification” in product management. See http://www.svpg.com/blog/files/recruiting-product-managers.html for a much more effective and actionable description of what to look for.
If you are a product manager considering a certification, I would instead encourage you to put your energy into following some of the excellent bloggers on the topic (see www.svpg.com/resources), using your social network to learn about how your friends at leading companies do their jobs, and especially in trying out new techniques.
Sign up for the free newsletter here.
What’s a Beta?
08.14.08 Filed in: SVPG Blog
For years people have been arguing about what the real purpose of a “beta” is. I used to argue this point as well, but today the term is so ambiguous that we all just need to accept that the term can be used for many different purposes, and what’s important to you is what you’re trying to accomplish.
Some teams use “beta” as essentially a QA phase. Basically you’re letting your customers help you test the product. Either because you don’t have much QA staffing yourself, or because for your product, there are just too many run-time environments out there for you to replicate and test, so you put the software out in “beta” and then tackle the bugs as they come in. This sounds worse than it is. In truth, there are many bugs that you’ll only find once you launch, especially related to scale and performance. As long as the release has achieved a reasonable level of quality before launching this is fine.
Some teams use “beta” as a gentle deployment mechanism. See http://www.svpg.com/blog/files/gentle_deployment.html for the details, but the idea is that you deploy the new release as “beta” while you keep the existing release live, and over time you move users from the old to the new system, and when enough are there, you remove the “beta” tag and you then phase out the old. Think Yahoo Mail’s massive gentle deployment to their new Ajax-based mail client over the past year.
Other teams use “beta” as a way to get user feedback on a product idea. For most types of products there are much less expensive ways to get this feedback than to build and launch the service like this, but for some types of products, it really is the only way to see if the idea is a good one. Especially products introducing something new enough that there isn’t an established or proven market, and you don’t really know if enough people out there are interested enough to make this product idea worthwhile.
All of these uses of “beta” are useful and appropriate in the right situations. The key is that all three of the above cases are actively managed by the product team and site analytics and feedback from users is used to make the product better as fast as possible.
There is, however, one other use of the term “beta” that is not quite as virtuous, but is nevertheless fairly common. Some teams use the term “beta” to represent software that has largely been abandoned by its product team. The software has the “beta” label because nobody wants to stand behind it. It essentially means, “take it or leave it.” This may be because the idea didn’t get traction, or because there aren’t people available to work on it because it’s not a high enough priority, or because business priorities changed, or because the company has a form of corporate ADD and they simply lost interest part way through. The internet is so littered with these “betas” it reminds me of all the orbiting space junk. For much the same reason. It can be easier to launch a new web service than it is to kill it and tell users they have to get off.
I’m not thrilled about this use of “beta” because it can harm the three good uses of “beta” above, as it can make users hesitant to engage with something called “beta.”
If you have a product in this last form of beta, this is where it’s useful to be honest with your users and let them know that you are no longer promising to take this forward. Some teams label these products “sustaining only” meaning you’ll keep it running but that’s all. In any case, engaging with your users is good, and using their feedback to improve the product is even better.
Sign up for the free newsletter here.
Some teams use “beta” as essentially a QA phase. Basically you’re letting your customers help you test the product. Either because you don’t have much QA staffing yourself, or because for your product, there are just too many run-time environments out there for you to replicate and test, so you put the software out in “beta” and then tackle the bugs as they come in. This sounds worse than it is. In truth, there are many bugs that you’ll only find once you launch, especially related to scale and performance. As long as the release has achieved a reasonable level of quality before launching this is fine.
Some teams use “beta” as a gentle deployment mechanism. See http://www.svpg.com/blog/files/gentle_deployment.html for the details, but the idea is that you deploy the new release as “beta” while you keep the existing release live, and over time you move users from the old to the new system, and when enough are there, you remove the “beta” tag and you then phase out the old. Think Yahoo Mail’s massive gentle deployment to their new Ajax-based mail client over the past year.
Other teams use “beta” as a way to get user feedback on a product idea. For most types of products there are much less expensive ways to get this feedback than to build and launch the service like this, but for some types of products, it really is the only way to see if the idea is a good one. Especially products introducing something new enough that there isn’t an established or proven market, and you don’t really know if enough people out there are interested enough to make this product idea worthwhile.
All of these uses of “beta” are useful and appropriate in the right situations. The key is that all three of the above cases are actively managed by the product team and site analytics and feedback from users is used to make the product better as fast as possible.
There is, however, one other use of the term “beta” that is not quite as virtuous, but is nevertheless fairly common. Some teams use the term “beta” to represent software that has largely been abandoned by its product team. The software has the “beta” label because nobody wants to stand behind it. It essentially means, “take it or leave it.” This may be because the idea didn’t get traction, or because there aren’t people available to work on it because it’s not a high enough priority, or because business priorities changed, or because the company has a form of corporate ADD and they simply lost interest part way through. The internet is so littered with these “betas” it reminds me of all the orbiting space junk. For much the same reason. It can be easier to launch a new web service than it is to kill it and tell users they have to get off.
I’m not thrilled about this use of “beta” because it can harm the three good uses of “beta” above, as it can make users hesitant to engage with something called “beta.”
If you have a product in this last form of beta, this is where it’s useful to be honest with your users and let them know that you are no longer promising to take this forward. Some teams label these products “sustaining only” meaning you’ll keep it running but that’s all. In any case, engaging with your users is good, and using their feedback to improve the product is even better.
Sign up for the free newsletter here.
