Why your MVP might not be an MVP
by James BaldwinPreviously, I had written out a list of what I considered to be features that must exist before I had a Minimum Viable Product.
This list was wrong.
How do I know?
My wife and I are getting a puppy, which we bring home in two weeks (AH!). So I realized that I have a deadline, because in two weeks, the amount of time that I can dedicate to Flowist is going to drop drastically.
With that deadline in mind, I took another look at the list of features that I deemed essential for my product. That list dropped almost by a third because the deadline forced me to be honest about what was really required for the MVP.
I think deadlines can be incredibly powerful - they are the refiner of schedules, and priorities. So I challenge the rest of you Indie Hackers to give yourself a deadline for something! And if you already have one, please share it and we can hold each other accountable!
-
6
I think you're onto something, but I think you're leaving so much useful and interesting detail out of this post!
What types of things were you focusing on, and why did you change them? What realizations did you have that helped you?
-
2
Thanks! I had more written but removed it because I know how much I get turned away by walls of text :/
To answer you (and perhaps I'll write an update once I've completed the MVP going into more detail!): I suspect it's different for everyone, but for me it was two things (after realizing my deadline).
- I expressed the value I provided to a user/team in as succinct a way as possible
- I wrote out what capability would be required for that to be achieved (in a sort of top-down approach)
-
4
Turn it into a whole article!
-
-
3
I wonder if really one can strip down what an MVP is to the minimum thing that a customer will pay for? Not what you think they will pay for, but what they actually will pay for, which might be less or more features than you expect? So come up with all the features that you want to have in an MVP, then pare it back to the one or two you need and test, if you keep adding features to what you thought was your MVP and you still have no paying users, maybe that is enough to know it’s not a product to focus on.
-
2
-"if you keep adding features to what you thought was your MVP and you still have no paying users, maybe that is enough to know it’s not a product to focus on"
Good point. I'll try to remember that...
-
-
3
Indeed, works for me too. If I just chill in my time management comfort zone, I'm super unproductive. Little pressure here and there isn't a bad thing.
-
1
Absolutely agree, there's a time for both!
-
-
2
Insightful post, James. I have been thinking about this a lot lately. Reasonable deadlines do a lot of good things for a project. I like what you said about priorities. A few more positives listed below:
*They force you to make trade-offs.
*They force you to work efficiently.
*They force you to have candor. Both with yourself and your team.
*They force you to view your project from a value perspective
*They force you to define the abstract
*They force you to finish something
Just a few things I've been thinking about. Cool to see you experience this with your puppy deadline 😁 -
5
This comment was deleted a year ago.
-
1
I get your point, and I agree. The goal of this post was to share how my "scope" of an MVP was challenged, and to challenge others to analyze their own. MVP's are scoped inherently - and often without deadlines we can put stuff into that scope that doesn't belong.
-
