The MVP vs. The MVB
The acronym your company needs to know.
NOVEMBER, 2018
There's a lot of talk in the product development world about the MVP — the minimum viable product. Companies and founders are rightly eager to get their big idea out of their heads and into the marketplace, and the MVP gets you there — fast.
The problem is, the MVP isn't an end state. It's a pit stop en route to your ultimate destination — a fully functional product perfected over the course of multiple iterations. And you'll never get there if you don't budget accordingly.
It's all about defining what we call the minimum viable budget, or MVB.
We see this scenario play out all too often. A company spends countless dollars and months of development time to create an MVP. Once that MVP is released, critical user feedback starts to roll in, but the company can't act on it...
The problem is, the MVP isn't an end state. It's a pit stop en route to your ultimate destination — a fully functional product perfected over the course of multiple iterations. And you'll never get there if you don't budget accordingly.
It's all about defining what we call the minimum viable budget, or MVB.
We see this scenario play out all too often. A company spends countless dollars and months of development time to create an MVP. Once that MVP is released, critical user feedback starts to roll in, but the company can't act on it...
They've blown through their development budget and left no room for iteration.
While your ideas for your product are important, your customers' insights are vital. Some of the most important development work comes from analyzing user feedback. Without a budget to accommodate those shifts and changes, your product can't adapt, and you risk stalling out before you've really even started.
So, how do you set a budget that takes you not just to MVP, but all the way to V1.0?
On average, you can count on roughly 2 to 3,000 hours of work to deliver a hearty and moderately featured MVP. That includes time for design and strategy, QA/testing and front-and back-end development. With three or four people working full time on your project, that should yield working software within four months.
Now, don't let those numbers scare you. Yes, three or four full-time employees sounds like a big expense if you're bringing those people in-house. But many companies choose fractional resources instead, to get the expertise they need and save themselves the time and trouble of hiring good tech talent on their own.
After those four months, you should have an MVP, but you should not have run out of budget. There's a lot more work to be done, and that work is perhaps the most important of the entire development process.
This is when you find out if your ideas match up with your market's wants and needs, when you learn what features would constitute a better investment, when you begin to understand how the product you put out into the world will compare to your carefully laid plans.
That takes time, and money. Post-MVP launch, companies should plan on another 1,000 to 1,500 hours of work focused on iterating — improving the product based on the feedback of actual users. Is the user onboarding process overly complicated and unintuitive? Is your MVP experiencing show-stopping workflow issues? Are you spending time and money building out the right features, or is there another direction you should be heading?
Now, don't let those numbers scare you. Yes, three or four full-time employees sounds like a big expense if you're bringing those people in-house. But many companies choose fractional resources instead, to get the expertise they need and save themselves the time and trouble of hiring good tech talent on their own.
After those four months, you should have an MVP, but you should not have run out of budget. There's a lot more work to be done, and that work is perhaps the most important of the entire development process.
This is when you find out if your ideas match up with your market's wants and needs, when you learn what features would constitute a better investment, when you begin to understand how the product you put out into the world will compare to your carefully laid plans.
That takes time, and money. Post-MVP launch, companies should plan on another 1,000 to 1,500 hours of work focused on iterating — improving the product based on the feedback of actual users. Is the user onboarding process overly complicated and unintuitive? Is your MVP experiencing show-stopping workflow issues? Are you spending time and money building out the right features, or is there another direction you should be heading?
You'll find out if you listen to feedback — and if you've set enough money aside to put that feedback into action.
That doesn't always mean you need to find more money. Often times, the scope of an MVP development plan is too aggressive and all-encompassing. If you cut back on that, you can free up money for the work that takes you from MVP to V1.0. It's part of our entrepreneurial nature to want to solve as many problems as we can in the same product. While the impulse is admirable, the process means you end up spending your time and money building out features that don't resonate, rather than perfecting those features that do.
Product development is an evolution. We recommend you start with a minimum viable budget — how much you need to get all the way from idea to MVP AND user-driven iteration.
Don't get us wrong: The MVP still matters. But having the budget to support the MVP day 1 after launch matters even more.
Product development is an evolution. We recommend you start with a minimum viable budget — how much you need to get all the way from idea to MVP AND user-driven iteration.
Don't get us wrong: The MVP still matters. But having the budget to support the MVP day 1 after launch matters even more.
Receive our insights