[This is fourth in my series of blogs about Product Engineering Approach for Startups. In my previous blog, I had talked about why it is necessary to implement a Goals-Driven Planning Approach.]
My group – Version 1.0 in GlobalLogic reached a very important milestone this week. Using an unique business and engagement approach, we successfully rolled out a Version 1.0 of one of our first client in the group. This was done in-time and within-budget with all the quality requirements which we had agreed with our client. Two more products are in its way to be completed within the same parameters in the next few months.
I would not like to claim that we were the first to finish a project on-time or within a fixed budget. However the unique thing about this achievement was the approach and methodology we took to reach to this stage – especially when we had to consider the driving forces behind rolling out first version of a product. (fixed time to go-to-market, changing or evolving requirements, and most important a fixed budget)
We are currently engaging with more than 8-10 organizations who are keen in seeking our help in soup-to-nuts aspects of engineering and rolling out their product to its Beta. While each of these organizations bring in an unique vision and passion associated with their products, there was one thing which was common in almost all of them. Almost all of them – in our first meeting with them – were keen in knowing a ball-park number associated with how much time it was going to take to build their product and how much was that going to cost them. We had to tell most of them that in software world there was probably no formula or a calculator which existed which could easily tell them that. Well, unfortunately, at least we did not have one!
Having said the above, we also do realize it was also important for such product entrepreneurs to get a feel of the time/cost numbers before they jumped into their mission. So to all of them we typically have been suggesting the following thumb-rules.
- Regarding time required to build a Version 1.0 = This, IMO, for a product at an inception stage should be same as when the product should be taken to the market. So time estimates to build the product should be the same as the product’s pre-determined go-to-market date/s.
- Assume that it would always take x amount of time for one person to build up a product feature. Increasing the number of people does not reduce the time. So for example in 98% of the scenarios, it is not possible to reduce the time to build a feature to half if you have twice the number of people working on it. This is a very important aspect to be considered in software engineering.
- It is a risky proposition to build the first version of the product on a fixed cost; it should be always built on a fixed budget. So the best possible answer associated with how would it cost to build a Version 1.0 of the product is typically best answered by the entrepreneur themselves.
- You can assume fixed regular cost associated with the raw materials required to build a software (intellectual property, human services cost, hardwares, softwares, etc.)
- Only variable which remains is the product scope which the product entrepreneur wants to be part of the Version 1.0 release. This is an important variable which the product entrepreneur can use to optimize time and cost associated with Version 1.0
Hope the above thumb rules helps in some manner with the estimations. As Sachin puts it very nicely – “There are two things any product entrepreneur has in abundance – vision and passion. There are two things which he/she does not have in abundance – time and money.” Keep that in mind while doing your estimations.
Thoughts and comments are most welcome.