Building a Prototype With Limited Resources

Problem

As an early startup, we were constrained with limited resources and focused on building core components of our business. However, we were intrigued to test out something that we thought could be highly valuable to our company. We were interested in building a sustainable solution but with scarce resources. As is the case with prototypes, we were curious to see if we could build it and more importantly, if successful, what would be its added value to the business.

Actions taken

We did some serious pondering about what our goals were, why we were doing it, and what success and/or failure meant to us. That included setting up clear objectives and success metrics.

Then we focused on envisioning what the MVP should look like and would it be feasible to complete it with the limited resources that troubled us. Following that, we discussed if we should single out one component of a prototype that would secure us the highest ROI and an overall validation.

Considering our uncertain situation, it was not the time to experiment and we had to rely on things we were familiar with instead of trying new or cutting edge technologies. Also, we had to frequently check-in to ensure that we were within our constraints both in terms of budget and time.

My main concern as a CTO was that whenever you were building a prototype there was a risk that it would end up in production though it was not meant to be production-ready. The idea behind this prototype was that we would build, test, evaluate, and then we would invest properly in building the proper version. I had to repeatedly emphasize to the other executives that it was a version not meant for production as well as to the tech team that was concerned with scaling it to 100 million users.

Lessons learned

• Building a prototype is always a high-risk activity and figuring out what is its value to the business is hugely important. I knew that there was a very good chance (more than 50 percent) that it might not work out and all the time and effort put in this activity would be thrown away. I relied on the business team to calculate if we were in the situation to waste allocated money if the prototype would fail to work properly. Make sure to have enough visibility into a long-term value, but also secure buy-in in case of failure.
• Though I was repeatedly explaining that this was not a production-ready version and that we would need to invest much more time and money into developing one, once our prototype succeeded there were many pushes to put it in production. To prevent those misunderstandings make sure to keep a written trail to which you can refer.
• I missed out early on to regularly check-in. Make sure that whatever you build, you are on track. This is especially hard when the process is rapid and poorly documented, as was in our case.
• The person who manages this project should have a clear understanding of what the end goal is and not go off a tangent.
• Make sure that everyone is aware in advance it is a risky project and that chances for success are not always high.