How much time you spend on a MVP?
I have heard two main answers:
- Launch quick to test the market and understand if it's of importance to anyone (usually 1 month or two)
- Launch with the key features cause you don't want users to see a unfinished product, they'll run away (usually from 3 months to infinity)
--
Personally, I'm for the #1 option - iterate fast and a lot. Of course it's important to show the features and what's your proposition to the user, but I have seen that the development time is multiplied by a magnitude if you want to polish the product, the team can lose sight of purpose and it's harder to see progress.
From my personal experience, I'm curious how much time people spend on their MVP's, cause I know some situations where development has taken 9 months with no market-fit checking just to polish a product and "be ready"
I know some people will die on a hill on behalf of their definition of MVP (I used to be one of those), so instead of using that term, I'll tell you what I've been doing the past few years of my career.
I focus on the "first release." It needs to provide real value to the user and is the smallest scope of work required to deliver that value. It's polished, and everything that's there is complete. There aren't any buttons that don't do anything, there aren't any broken widgets. If it's on the screen, it works.
I believe software is never done, so I approach every iteration with a single question: What is the value that I need to deliver to my users? I then plan the smallest scope that delivers on that promise, release it to the wild, and keep iterating from there.
When I'm working full-time on a project, I try to keep the iteration cycle to days or weeks, not months. For a specific delivery, I try to think in this order:
As the product owner or founder, I find that I have a pretty strong intuition of which of these levels is appropriate for the given iteration. I'd say it's as much art as it is science.
But don't you encounter the problem that sometimes you believe that all the features you have in mind are needed for the user. Thus you start developing all of them, whereas you can start with a few and iterate little by little?
Cause sometimes even the little things bring value to the user.
But everything isn't needed for the user. If they are, they aren't all needed upfront. In my experience, it's better to have a great version of something small than kinda-okay versions of lots of things. You only get one shot at a first impression.
I'll use the example of an ice scraper since I just got done scraping off my car. I have one scraper that has a brush, an extending handle, a little rubbery wipey thingie, and the scraper. The scraper I actually use, though, is just a $5 hard plastic scraper. It's more effective at completing the job, so that's what I use.
I think of it this way: I'd rather someone come to my app and have it be small but well-executed and delivers value effectively. Workflowy is a good example of this. There are competitors out there who do more, but Workflowy is the best at exactly what it wants to be.
A lot of truth you wrote and couldn't agree more. Cause I have encountered that most people, when creating a startup with similar products in the marker start to replicate everything and on top of everything, add new features.
In some markets maybe, but one wouldn't want to copy Foursquare in order to create something similar in the first step.
This question made me look in the mirror :).
So I'm with Andrew, the easier the better, but functional. Your copy (text) should lure people in. Plenty of people these days launch a landing page, say it's coming and then only once they hit 20 users start building. Proper product-market fit.
Remember using Word Perfect or Word 95? That crashed all the time, but still, users used it. If you're offering something worthwhile, people will stick around. So focus on setting that expectation right.
My first side project took 1.5 years, the next 1 year and the last six weeks. The results are similar, wasted effort on feature fatigue are not.
Keep it short.
This question came from my own personal feature fatigue (I liked this term you mentioned). Therefore during my second project I started to understand the same - it's need to be relevantly easy and functional.
Not a big load of features, which one thinks are all important.
We took 1 month for our MVP.
But it really depends on the core process you are aiming! In the first iteration we released a functional product that helped the customer automate his process.
In the second iteration we added a Mobile solution that consumes the services in the first iteration.
The MVP helps your presentate yourself to a potential customer, showing that the solution you provide cover their top needs.
If the process was simplier it could take less time.
Sounds like great steps forward! But did you concentrate on one particular feature or you had a list of features you wanted to implement?
Hi Tomas_egl,
We concentrated in a core process, this core process needed some auxiliar features to be implemented.
Does seem very variable due to what product you're building, and the competitors in your space.
From a technical perspective, you may want to make sure that you have solid foundations to launch your product.
For example, fast iteration is good, but: can you iterate fast without breaking things? Maintaining a good codebase? Preserving retro-compatibility with previous versions?
I'm all for releasing early on, but early is relative. I cannot release something if it's not tested, or if the underlying architecture I'd flawed. I know it's going to bite sooner or later and possibly destroy the business before it takes off.
As said initially, depend on what you are building, and choices on what you can compromise.
Of course, if one is making spaghetti code and poor architecture choices - it won't be long till it strikes back. But also, the initial start shouldn't be over engineering with various services and rewrites.
Between a few months to 5 years just to give you a range. There are markets (eg. anything related to hardware, regulated fields of fintech and biotech) where the barrier to entry is high, and you should not expect fast iteration.
Of course, these markets are hard, but I have seen many examples of fintech with 4 / 5 months of needed work.
I consulted on a project for one of the top 3 banks in the US. Our team of 6 went from idea to production traffic with real users in 8 weeks, then continued to update the app multiple times a week after that. That was back in 2015, but it's still up and running and the team is still supporting at the same cadence.