Calculating the real cost of a minimum viable product (MVP) is so important to my development team that we’ve hired a business analyst who dedicates their time to getting this right.
When I was a developer, calculating MVP was a challenge for me. It became an even more formidable problem when I started a development agency. What, I wondered, were the correct next steps after writing down everything that I wanted to build and creating a product spec?
Modern agile software development theory discourages working with specs because in a traditional waterfall approach, a spec takes months to write. Then, as soon as development begins, the spec changes. But while agile is great in theory, in practice, every business has to work within a budget. Even if you have enough cash to burn, you can’t gamble with your clients’ expectations. If you always estimate that projects will be completed in six months when they actually end up taking a year, after a while, no client will ever want to work with you.
Happily, over time, my team and I found a reliable process. Here’s how we recommend you approach calculating the real cost of MVP for your start-up:
Roughly estimate each feature that’s listed in your product spec.
Roughly is the keyword here. No matter how experienced you are in software development, any estimations that you make in this step will be inaccurate. That’s because in the planning stages of a project, there are too many unpredictable details that you won’t have the foresight to consider. Accept that the product spec is a living draft: As time passes and you learn more about your product, your draft will change.
In addition to being rough, your estimations should also be relative to each other. For example, if you estimate that sign-up will take five days, then a complex crawler should take no less than two weeks.
What if you have no coding experience and don’t know how to estimate features? Find an expert you can trust to make those estimations for you. Call on a developer friend, or, if you don’t know anyone personally, research consultants and hire a reputable professional.
Remember to factor time sinks into your calculation.
When estimating the time it takes to complete a feature or project, don’t just calculate the time it will take to complete the work. Factor in time sinks — unproductive but inevitable tasks.
Based on my experience, if your developers work in an office, they’ll generally spend at least 25% of their time chatting, going to the bathroom, and sitting in meetings. Developer productivity also heavily depends on management and team processes. Without QA engineers, developers will need 25% more time to test the code they created. If you don’t have DevOps in your team, developers will need to spend up to 10% more time setting up servers and deploying the code.
Prioritize features from greatest to least importance.
Which of your features are necessary? Put the most critical ones at the top of your list, which will encourage you to complete the most important features first. You can also split every feature up into parts that are also prioritized, so that when a roadmap is created, you’re building only the most important parts of the most important features.
For example, a login screen is a necessity; your users won’t be able to login without it. But a password reset is optional. You can substitute it with a mailto link to reset passwords manually. It won’t be perfect, but you don’t need perfection for your MVP.
Double your implementation estimates.
When I started my development agency, I attached an estimate to every task that a developer was working on, then recorded how much time it took to complete implementation. After several years of working this way, I learned the average difference between an estimate and the actual time required to do something.
It turns out that every task and every project I’ve ever worked on took roughly two times longer than I thought it would. Requirements change. Marketing situations change. Sometimes founders get feedback from early users and decide to re-prioritize. The only way to stay sane in these situations is to know how “off” your estimates are. Then do your best to mitigate the risk of the estimates veering even further off the path.
So once you have a list of estimated, prioritized features, multiply your estimates by two. That’s your ballpark estimate for the project.
Once you’ve worked your way through this process, take your initial estimation of the number of hours or days it will take to build something, then multiply that by the hourly rate of your developers. With that, you’ll know the real cost of your MVP.
Originally posted on Medium
