For my related post on involving customers during product development by making them co-creator, one of the readers comment that the same approach will not work in every product development. By involving customers during product development, it might look like a “service” to the customers by taking example of Google v/s Apple way of building products. In case of Google, they work on a product discovery approach, whereas Apple has taken the approach of “Don’t ask the customer what they want, many of the times they themselves don’t know” approach. In my opinion, major differentiation between these two approaches come from what we “refer” as a “product”. Buying a “box” product from the store and experiencing it with hands-on is way different from accessing an online product. This has a significant change the way products are developed. Let me explain this from my own experience.
I used to work in a firmware development team, which had very close traction with hardware. We made certain firmware changes specific to hardware, any further changes to it will result in re-manufacturing the whole PCB. Also product milestones, changes/defect fixes were controlled (ex: All level-1 severity defects should be fixed before manufacturing release, which is the final release). Later point I moved to other team, where we were building cloud solutions from the scratch. Our first major launch was two days away where we had at-least a dozen level-1 bugs were open. When I asked how we can make the release, the product manager replied “We can go ahead and launch then regularly roll-in patch releases by observing customer usage. If customers are not facing any issues, it is fine. After all for this flexibility only we are moving to cloud”. Well, this fundamental elementary thinking of how we look at defect fixing itself different when it comes to looking into products as something.
Thanks to advancement in cloud technology, tons of mobile and internet products are getting built every day by following the discovery process. They can release, iterate and then improve their products depending on how customers are responding to it. Recently there was an article about Amazon’s product building which talks about similar approach. On contrast, when you are building anything that is closer to the hardware, taking this approach might create more problems. For example, given a trial a customer might say he wants infrared interface in it, which might result in months of time to tape out and re-design a new board. Whereas in case of web, if the customer wants a button to be changed, probably it can be done in few hours.
In conclusion, I would say product development largely depends on what exactly we call it as product. The development methodology should change and be in sync with it.