4 ms·

i think reid hoffman's quote (linkedin founder) sums it up best, "if you're not embarrassed with the first version of your product then you've launched too late

i think reid hoffman's quote (linkedin founder) sums it up best, "if you're not embarrassed with the first version of your product then you've launched too late." i have seen many posts about mvp and narrowing scope here--all right on the money. some other things that have worked for me, i'm the world's biggest procrastinator and i have literally 20-30 side projects that i've started for some time, was extremely passionate about, and then moved onto the next big thing, but i've recently had a few projects that i went deep on and actually got out, even hoping to build a business out of. i've also found that the technology stack is not that critical, as a perfectionist i want to create a kickass platform that's easily maintainable, beautifully coded, using all the right tools that can meet billions of requests per day from the start, easy to deploy, automated, etc, but that typically just leads me down a huge rat hole. if your energy is finite (for me it is), you should focus all of it on getting your stuff out the door as quickly as possible, getting it in front of potential users because often times what you think is a great idea is raw and will need tuning. make things functional, able to showcase your main idea (or a particular use case), don't have to have all use cases fully done. get it out there and iterate. i'm certain that there are people that can make all the right technology decisions from the get go to support billions of requests per day, fully automated (if you are one of these, please email me right away!) but you're solving the wrong problems, if you want to get a side project or business out there, go build it, get it out there and then iterate, and iterate fast. for the sake of argument, probably side projects like tools or libraries, these are a bit different in nature, you probably want to choose the right technology stack, etc. but if you want to build a business out of your side project, then don't dwell on this too much, use what you're familiar with that can give you the quickest turnaround, there will be pains with whichever tech stack you choose, some more than others, but it will pale in comparison to the roadblocks in front of you to build something into a business. for one of my recent projects, i use sqlite3 for my relational database, i don't even want to spend all the 30 minutes or whatever to set up postgresql, it's to that level of scope reduction. when users grow, then i'll spend the time to upgrade and add backups, etc.

brechtm 10y ago
But what's an MVP? That's very subjective. I'm working on a DITA (to PDF) renderer [1] based on rinohtype [2]. About a year ago I was in a startup coaching project. I was advised to put out an MVP ASAP. Since then, I've worked full-time on the project and only now I'm releasing what I believe is an MVP. One year ago, my product was functional, but it didn't allow easily styling the output PDF. I believe this is the feature that differentiates it with the competition. I feel that, without this feature in place, my product wouldn't offer anything interesing. I could have also released an "MVP" much earlier, but say it couldn't render tables. Who would've taken it seriously then? Even if I added this feature at a later point, how many of the people that tried the first version would bother checking it out again? For some (new) markets, I'm sure you could crank out an MVP in a month. But for existing markets, there's the established competition that sets the bar, no? [1] http://www.opqode.com/rinoh http://www.opqode.com/rinoh [2] http://www.mos6581.org/rinohtype/ http://www.mos6581.org/rinohtype/
- epynonymous 10y ago
  no doubt, you raise an excellent point--mvp is somewhat vague, hard to quantify, and there's no universal answer so unfortunately the answer is it depends on the idea/product/lifecycle. chances are if you're still trying to get a feel for a market, this could be an entirely new market, one that doesn't quite exist, or an existing one with incumbents, like airbnb as an example, an mvp could be like a simple mobile app with login (not even oauth based for facebook/twitter/google), listings, a way to book, and bill. don't implement user feedback on listings where they've stayed, don't implement icons for users, forgotten password is an email to support, etc, i'm sure you could find a million things that are needed, but what are the essentials for getting people to use your app satisfying some specific needs (crashing at a complete stranger's place). each feature doesn't really need all the bells and whistles, enough to get people to start using the basics. your assumptions and hypotheses about how the market would leverage this tool could be entirely off, so you might need to change direction (pivot more or less) and you'd need to get to this conclusion asap, sooner rather than later, etc. if you spent a year coding something you think would be perfect for a market you are defining or discovering, this could be a large waste of time, so fail fast as they say. in your case, you seem to be quite clear about what you need, what the competitors have and don't have. but let me play devil's advocate because i don't know how much effort "[rendering] tables" would take or how much you've put in the past year, but let's just say you could put something out there in 6 months time as opposed to 12 months time, it probably will have some table rendering, not 100%, but do you think that would be advantageous or not? thanks for the footnotes, much appreciated and good luck with your app!
bluedino 10y ago
>> "if you're not embarrassed with the first version of your product then you've launched too late." Carmack said it as well: Michael Abrash and I once had a discussion kind of justifying ourselves. We said, "Well, if we shipped on time, we probably weren't ambitious enough."
- epynonymous 10y ago
  nice. is this the john carmack of doom/quake/duke?

brechtm 10y ago

But what's an MVP? That's very subjective. I'm working on a DITA (to PDF) renderer [1] based on rinohtype [2]. About a year ago I was in a startup coaching project. I was advised to put out an MVP ASAP. Since then, I've worked full-time on the project and only now I'm releasing what I believe is an MVP. One year ago, my product was functional, but it didn't allow easily styling the output PDF. I believe this is the feature that differentiates it with the competition. I feel that, without this feature in place, my product wouldn't offer anything interesing. I could have also released an "MVP" much earlier, but say it couldn't render tables. Who would've taken it seriously then? Even if I added this feature at a later point, how many of the people that tried the first version would bother checking it out again? For some (new) markets, I'm sure you could crank out an MVP in a month. But for existing markets, there's the established competition that sets the bar, no? [1] http://www.opqode.com/rinoh http://www.opqode.com/rinoh [2] http://www.mos6581.org/rinohtype/ http://www.mos6581.org/rinohtype/

epynonymous 10y ago
no doubt, you raise an excellent point--mvp is somewhat vague, hard to quantify, and there's no universal answer so unfortunately the answer is it depends on the idea/product/lifecycle. chances are if you're still trying to get a feel for a market, this could be an entirely new market, one that doesn't quite exist, or an existing one with incumbents, like airbnb as an example, an mvp could be like a simple mobile app with login (not even oauth based for facebook/twitter/google), listings, a way to book, and bill. don't implement user feedback on listings where they've stayed, don't implement icons for users, forgotten password is an email to support, etc, i'm sure you could find a million things that are needed, but what are the essentials for getting people to use your app satisfying some specific needs (crashing at a complete stranger's place). each feature doesn't really need all the bells and whistles, enough to get people to start using the basics. your assumptions and hypotheses about how the market would leverage this tool could be entirely off, so you might need to change direction (pivot more or less) and you'd need to get to this conclusion asap, sooner rather than later, etc. if you spent a year coding something you think would be perfect for a market you are defining or discovering, this could be a large waste of time, so fail fast as they say. in your case, you seem to be quite clear about what you need, what the competitors have and don't have. but let me play devil's advocate because i don't know how much effort "[rendering] tables" would take or how much you've put in the past year, but let's just say you could put something out there in 6 months time as opposed to 12 months time, it probably will have some table rendering, not 100%, but do you think that would be advantageous or not? thanks for the footnotes, much appreciated and good luck with your app!

bluedino 10y ago

>> "if you're not embarrassed with the first version of your product then you've launched too late." Carmack said it as well: Michael Abrash and I once had a discussion kind of justifying ourselves. We said, "Well, if we shipped on time, we probably weren't ambitious enough."

epynonymous 10y ago
nice. is this the john carmack of doom/quake/duke?