This post is written by LIBT CEO, Sesiri Pathirane on his website, Sesiri.com
I had a pretty detailed chat with two visionary entrepreneurs in Sri Lanka yesterday, without even realizing we had talked over 3 hours. We talked a lot about execution and why it is important for any startup with products in the technology space. Execution is not just traction. Executing on an idea involves building the product as well. Here are some guidelines for startuppers to avoid execution mistakes in product development.
This information will best serve startups, on a lean budget, working on an innovative web or mobile product. Will not fit best if you are a corporate over 100 employees, working on the third version of the mobile app for a financial software that’s been in the market for 5 years! Hope you’d get my point.
They simply have different DNA. Its almost impossible to change the service-oriented mindset to a product mindset. Product development is lean and very agile. The definition of ‘Agile’ is far different from one another. Developers from traditional outsource models tend to work with larger corporations and they are used to getting 300 page SRS documents. If you are working on a product, you can write the 300 page SRS for 6 months and your product will not have a market fit by the time you are beginning to code. If you have one of these types of developers leading a development team, that will be even worse! Remember, sometime, you only need to stay 6 months ahead of the rest to “make it!”
It is much more productive when the hackers themselves work on the technology research oriented work together. Just guide them! You are not going have enough time for your CTO to do the research on whatever the technologies you’d want to use and have him transfer the knowledge over to the developers. This happens in tradition outsource models, but it will not work for startups, rushing to get the product out or trying have a MVP ready to raise money.
If you have a team of 5 developers working on the product with a CTO, it’s not always best to make all decisions based solely CTO’s comments. When you discuss technical issues, get the whole team involved in it. Sometimes fresh developers tend to see product problems and its solutions much clearer than the experienced CTO.
During the product development phase, until you get the right market validation, keep the team as small as possible. Just make sure they are the best you can select. Innovation is best in smaller teams. When you have 20 developers or 5 MBAs in a room discussing the features, it won’t get anywhere. You will be ideating the product than building it.
It is extremely difficult when you have many hierarchies to develop a product. Your findings will change what you’d want to build basically EVERYDAY! The feature you so wanted two days ago, will be the last item you wanted built today. You will for sure have good reasons for it, but only you will understand. If your team is not used to this, they will probably think you have no idea what you are doing and they will probably say with a lot of frustration “this cannot go on!” That’s the last place you will ever want to be. Read Eric’s Lean Startup if you need help in this area.
