[This is second in my series of blogs about Product Engineering Approach for Startups. In my previous blog, I had talked about what made Product Engineering approach so different for Startups.]
Over the last many years, I have seen various different approaches being taken at the early stage of product development in software startup organizations. For the sake of discussion, let me categorize them into two types of approaches.
The first type of approach is more directed towards initiating the actual development and evolving the product as they go. The vision of product concept also starts getting built up as the actual product itself evolves. While the approach in Type – II is to have a more stress on Product Conceptualization and Visualization (aka. prototyping) first and then initiating the actual product development.
In my experience, the Type – I approach is more suited for a very small and highly cohesive team. The product architect who may have conceptualized the product is also typically engineering the product in this case. This approach is also much more suited to the teams wherein the key folks have already experienced building a product on the similar lines as what they are currently developing. There is a chance that the team may be able to save time in terms of total release time for the product, however more number of development iterations are required in this case to finally build the product. More number of iterations can add up to the cost. This approach is much more suited to startups who may already have secured funding as compared to the ones who are hoping to get funded based on the product they develop. IMO, organizations building products in a niche/new domain or untested markets should not follow this approach.
For organizations who find themselves not able to satisfy even few of the criteria listed in the approach described in the above paragraph or infact see opposites of them, the type – II approach is the safest one. This is very much required when you have a large or distributed team or when you are collaborating with an outsourcing partner to build your product up. The key idea in this approach is to conceptualize and visualize the product (in form of wire-frames, clickable prototype, stubbed application prototype, etc.) to an extent where all the stakeholders have the same understanding of the product and the engineering team feels comfortable to build it up. The engineering iterations are much simpler and faster in such cases.
Approach – II does require some additional investment (both time-wise and monetary). Organizations will also have to invest on special non-engineering skills here which are typically found in Product/Domain Specialists, Usability Specialists, Visual Designers, and Rapid Prototypers. However the returns on such investments are substantial. Barry Boehm has written about it in his book on Software Engineering Economics. (“The Options Approach to Software Prototyping Decisions” a paper from School of Computer Science at Carnegie Melon is also a good read on the same.). This approach would certainly help organizations to predict better and reduce the uncertainty associated with product development.
Trust me – Startups already have lots of uncertainties to deal with!
