There are at least two major schools of thought about the best way to release new products – especially products that contain software that can be updated by the user. The faster-to-market approach pushes designs through the development cycle as quickly as possible to release the new product to market before anyone else. A plausible tactic for faster-to-market products that have user-updatable software is to ship the product even while there are still major bugs in the system with the expectation that the development team can create a corrective software patch before the product actually ends up in the hands of the customer. In this scenario, the expectation is that the user will perform a software update before they can even use the product the first time.
The quality-to-market school of thought believes that products should work out of the box without requiring extra effort from the user such as downloading and applying software patches. This philosophy does not preclude the later use of software updates to add or improve features – rather, the out of the box experience is considered an important part of the product’s value.
An argument for the faster-to-market approach is that the user will be able to start benefiting from the product sooner – possibly months sooner because the development team is able to take advantage of the production lead time to bring the product to the desired level of performance. This argument often presumes that the development team would still be working on fixing bugs after shipping a finished product even under the quality-to-market approach. For this approach, the shorter term tactical advantage of using a capability sooner outweighs the probability that some expected features may not work properly.
Likewise, an argument for the quality-to-market approach is that the user will know for certain at the time of purchase what the product will and will not be able to perform. A presumption of this argument is that sometimes a faster-to-market product overpromises what the development team is able to deliver and this leads to customer dissatisfaction because of unmet expectations. For this approach, the longer term strategic advantage of always being able to use the features as-advertised outweighs the probability that a crippled version of the feature will cause you to lose future sales.
There are many companies that side with both of these schools of thought. Which is better? Is one always better or is there a condition when one approach is better than the other? How does your development cycle accommodate one or both of these approaches to releasing a product?
Tags: Budgets, Project Management, Quality, Schedule
Processor Tracker
All Entries RSS Feed
Answer is very situational.
Sometimes the first-mover advantages gives a company a big enough head start that it becomes dominant & difficult to beat, even if its product is inferior.
In other cases (e.g. life-critical medical devices) I think it’s pretty obvious what factor dominates.
Some companies focus initially on time-to-market, get an advantage, and then backfill/improve their product line.
Of course, most of us in product development can relate to management that says, “Yes!” (Put another way: “I want both!”)
It certainly depends on the product. If it is a product deployed in an environment where out-of-the-box operation is critical, obviously you would develop for that. Or even for a product that is not put into a critical environment, but rather in an environment where many products will not be updated.
Some products are more seamless and easy to push updates to. I tend to side with faster-to-market by ways of quick iteration software development that can be bundled up and released to testing at any point in the product’s lifecycle. This process also lends itself to easier product maintenance in the long term and thus higher quality software/product in the long term as well.
If it’s something revolutionary, perhaps *both* quick and quality are important. A new startup can’t afford to either alienate customers because their product was trash, nor can it afford to not to get to the market first.
The way to do it is fairly simple: make your initial product simple. Focus on the direct problem at hand, and ignore the rest. Create a limited-feature set, but fairly solid product. Then in your updates you can add the new features. The side-effect of this is you make your customers happy. They bought your product for the functions it did do, and now you’re adding more value to their purchase.
And, you’ve given them a good product and it came out quickly.
- Steve