Having worked software development as product manager and having been a software user, I came to appreciate how many things can go wrong with releasing a product. Also I have seen how products fail because of obvious issues. These tend to happen more often for a brand new product launch.
There are a million things that could go wrong when making a product. Release target may slip because of the last minute showstopper bug, documentation may not be ready in time, product may not be solving the right problem for the user and market may not materialize as anticipated. Out of all these possible pitfalls, perhaps the most fatal mistake that product manager can make is not setting the right standard for the product quality.
Here I used 'quality' to mean whether product is generally good enough for the users to put up with quirks (most products do with rare exceptions) and continue to use. Good enough quality. It requires a fine balance from product manager. Hitting the right balance could literally decide whether the product stays in the market or gets pulled from the market.
When designing a product, calculus of most product managers has two variables. Time to market is one, and feature set is another. Given organizations have finite resources, engineering team headcount is fixed. So the product manager get to adjust the slider along the more-feature-versus-shorter-time sliding scale. In doing so, it's easy for the product manager to let someone else worry about the product quality. That's a recipe for disaster.
Do not let anyone fool you. You, the product manager, is responsible for the final product quality. The worst thing that a product manager can do is to wallow around and let the product to be launched even when it is not ready for the launch. A bad product manager will notice this when testing the early builds from engineering team. A good product manager will formulate the problem in such a way that key quality target is baked into the requirement so that engineering team can turn that into a feature.
Speed, stability, scalability, usability, and so forth should be a key feature depending on a problem that the product is solving.
Take a look at these user testing videos on Microsoft Kin One and Kin Two. Someone at Microsoft knew these user testing failures. But decided to release the product anyway. You may have forgotten, but Microsoft ended up pulling the products after about 7 weeks.
I'm sure Microsoft engineers didn't intend to buffer earlier gestures.
But it sure looks like it because of poor execution.
Source: Wired
There are a million things that could go wrong when making a product. Release target may slip because of the last minute showstopper bug, documentation may not be ready in time, product may not be solving the right problem for the user and market may not materialize as anticipated. Out of all these possible pitfalls, perhaps the most fatal mistake that product manager can make is not setting the right standard for the product quality.
Here I used 'quality' to mean whether product is generally good enough for the users to put up with quirks (most products do with rare exceptions) and continue to use. Good enough quality. It requires a fine balance from product manager. Hitting the right balance could literally decide whether the product stays in the market or gets pulled from the market.
When designing a product, calculus of most product managers has two variables. Time to market is one, and feature set is another. Given organizations have finite resources, engineering team headcount is fixed. So the product manager get to adjust the slider along the more-feature-versus-shorter-time sliding scale. In doing so, it's easy for the product manager to let someone else worry about the product quality. That's a recipe for disaster.
Do not let anyone fool you. You, the product manager, is responsible for the final product quality. The worst thing that a product manager can do is to wallow around and let the product to be launched even when it is not ready for the launch. A bad product manager will notice this when testing the early builds from engineering team. A good product manager will formulate the problem in such a way that key quality target is baked into the requirement so that engineering team can turn that into a feature.
Speed, stability, scalability, usability, and so forth should be a key feature depending on a problem that the product is solving.
Take a look at these user testing videos on Microsoft Kin One and Kin Two. Someone at Microsoft knew these user testing failures. But decided to release the product anyway. You may have forgotten, but Microsoft ended up pulling the products after about 7 weeks.
I'm sure Microsoft engineers didn't intend to buffer earlier gestures.
But it sure looks like it because of poor execution.
It makes me wonder what user reaction might have been
for those who actually paid for Kin...
So here are the lessons:
1. Focus on the user problem and think of what quality user values the most. Is it speed, stability, usability, scalability, or something else? Bake that into your requirement and talk about early with engineering team.
2. Monitor intermediate builds to check on other quality issues that you may have missed.
3. Conduct beta testing with early adopters and usability testing as early as you can. It will tell you a lot about whether product is on target or missing the mark.
 |
| Yes, it requires work. Do it to build what you love because you'll spend much more time than you think. Source: http://www.sumit4all.com/career/building-the-right-product-versus-building-the-product-right |
No comments:
Post a Comment