Entries Tagged ‘Quality’

Which is better: faster- or quality-to-market?

Wednesday, March 23rd, 2011 by Robert Cravotta

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?

Are consumer products crossing the line to too cheap?

Wednesday, January 19th, 2011 by Robert Cravotta

I love that the price of so many products continues to fall year in and year out. However, I have recently started to wonder if in some cases the design trade-offs that the development teams for these products are making to lowering the cost to produce them are crossing a quality line. I do not have a lot of data points, but I will share my observations with my office phones as an example that might inspire you to share your experience with some product. Maybe in the aggregate, our stories will uncover whether there really is a trend for razor thin quality margins.

Over the previous ten years, I have relied on three different cordless phone systems. The price for each phone system was progressively lower than the previous phone system and usually provided more functionality than the previous phone. In each case, the phone that I replaced was still working, but there was something else that made replacing the phone worthwhile.

The first cordless phone I purchased was a single-line, 2.4GHz cordless phone. It consisted of a single handset that mounted on a full function base station. I liked that phone a lot. Everything about it was robust – except the fact that it operated in the 2.4GHz band along with so many other devices in and around my office. For example, if someone turned on the microwave, it would cause interference with the phone.

I eventually replaced the 2.4 GHz cordless phone with a dual-line, multi-handset, 5.8 GHz phone systems. That system cost me less than the 2.4 GHz phone and offered additional valuable features. The hand-set was smaller and weighed less. The dual-line capability allowed me to consolidate my phone lines to a single system and the multi-handset feature allowed me to make both phone lines available everywhere in my home office. There were a few features that the new handsets did not provide that I missed from the original phones, but I could use the phones no matter how other devices were being used around the area – so I was happy with the phones.

After a few years of heavy use, the batteries could not hold enough charge. I would regularly switch between handsets during a typical day because the battery in each handset provided less than an hour of talk time. I bought replacement batteries which were better than the original batteries, but only slightly so. With continued use, the new batteries provided longer life (I assume this was because each handset’s state of charge values were slowly adjusting to the new batteries – I’d love if someone could explain or point me to where someone explains why this happened). However, the batteries were only useful for about a year.

At this point, I bought my current cordless phone system which is made by the same manufacturer as the previous two phones. It is a DECT 6.0, dual-line, multi-handset system. It cost less money than either of the other two systems and added a larger database on the base station. However, the phone system exhibits intermittent behavior that I never experienced with my other phones.

Most notably, the communication between the base station and handsets is not always robust. Sometimes a handset will start doing a continuous ringing instead of the normal on/off cycle. Other times the handset will not receive the caller-id that the base station normally sends to it. And other times I will notice a clicking sound that I have not been able to attribute to anything. These examples of lower robustness make me wonder how much the design team shrunk the product’s performance margins to meet a lower price point.

Are these systemic examples of margins that are too small or did I just get unlucky with the phone I received? Because the phone works well most of the time, I suspect it is narrow quality margins that are the culprit – and this made me wonder if other people are noticing similar changes in the robustness of newer products. Do you have a product that you have noticed a change across generations?