Reflection: I think the correct thing to do would have been to create detailed UI screens. Then print them and show them to people (and Eliezer). This probably would have taken a month or two, but it would have been worthwhile. The reason I never got around to it, aside from the ugh-field around doing UI mockups, was because it always felt like in a month or two we would be done with the MVP.
This stands out as my favorite paragraph of the post.
I understand where Eliezer is coming from about building a product that is the best in the world for that particular workflow. An MVP is a test. The point is for you to be able to say to yourself, “Uh oh. People don’t like the MVP. That (probably) means that they won’t like subsequent versions either, and so I don’t need to waste any more time working on this.” If the version you release doesn’t allow you to say that to yourself in the case of a failure, well, I don’t see that it’s a useful test. And if it’s not a useful test, then what’s the goal of the release? Sometimes the goal is just to get feedback on usability and features/product stuff, and I think that that is often a valid goal.
So, I’m firmly on the side of “make sure your MVP is actually viable, and thus a useful test” rather than the side of “release early, release early, release early!”. But at the same time, I think it’s important to really look hard for ways to release your MVP earlier (while still having it be viable) as opposed to just conceding, “Oh well, it’s just going to take months of development before I can test my hypothesis”. I love the idea of making UI mockups, and demoing them to potential users. If people really, really want this, then they’d get excited at the demo and say, “Yes, yes, yes! I want this! Build it for me!” Right? Perhaps not. Perhaps my model of users is flawed.
I’d also like to highlight the comment you made about always feeling like you’ll be done with the MVP in a month or two. I’m working on a software startup too right now, and I make the same mistake. It started out as a project to help me develop my coding skills so that I can level up and start freelancing. It started out as a Rails API with no front end. Then I figured, “what the hell, let’s build a little front end”. Then I started to think I was on to something that could make me money, and that it’s worth spending a month or two improving the front end (partly to improve my coding skills). Then I figured I should learn ReactJS (I had spent the past year self-studying CS, and before that, Angular was my thing), so I redid the front end in React. Then I decided that I don’t like React, and that I do like VueJS, and so I redid it in Vue. At that point I was really feeling like it could make me money, and that it’s worth another month or two to improve it further. Then I realized that hitting my server’s API takes too long (because of network latency), and so I rewrote all of my backend code on the front end. From there it was just a lot of me saying to myself, “it should only be another month or two”. At the end of the day, I’ve spent over a year on a project that I never really intended to spend more than 3-4 months on, and I still feel like I only have another month or two before I release and can test my hypothesis.
Anyway I really just want to say that this planning fallacy failure mode is real, and that it seems especially harmful for people working on startups, because agility is so important with startups. (Also, I initially felt too embarassed to share the extent of my planning fallacy failures, but your honesty and disclosure inspired me to do it.)
This stands out as my favorite paragraph of the post.
I understand where Eliezer is coming from about building a product that is the best in the world for that particular workflow. An MVP is a test. The point is for you to be able to say to yourself, “Uh oh. People don’t like the MVP. That (probably) means that they won’t like subsequent versions either, and so I don’t need to waste any more time working on this.” If the version you release doesn’t allow you to say that to yourself in the case of a failure, well, I don’t see that it’s a useful test. And if it’s not a useful test, then what’s the goal of the release? Sometimes the goal is just to get feedback on usability and features/product stuff, and I think that that is often a valid goal.
So, I’m firmly on the side of “make sure your MVP is actually viable, and thus a useful test” rather than the side of “release early, release early, release early!”. But at the same time, I think it’s important to really look hard for ways to release your MVP earlier (while still having it be viable) as opposed to just conceding, “Oh well, it’s just going to take months of development before I can test my hypothesis”. I love the idea of making UI mockups, and demoing them to potential users. If people really, really want this, then they’d get excited at the demo and say, “Yes, yes, yes! I want this! Build it for me!” Right? Perhaps not. Perhaps my model of users is flawed.
I’d also like to highlight the comment you made about always feeling like you’ll be done with the MVP in a month or two. I’m working on a software startup too right now, and I make the same mistake. It started out as a project to help me develop my coding skills so that I can level up and start freelancing. It started out as a Rails API with no front end. Then I figured, “what the hell, let’s build a little front end”. Then I started to think I was on to something that could make me money, and that it’s worth spending a month or two improving the front end (partly to improve my coding skills). Then I figured I should learn ReactJS (I had spent the past year self-studying CS, and before that, Angular was my thing), so I redid the front end in React. Then I decided that I don’t like React, and that I do like VueJS, and so I redid it in Vue. At that point I was really feeling like it could make me money, and that it’s worth another month or two to improve it further. Then I realized that hitting my server’s API takes too long (because of network latency), and so I rewrote all of my backend code on the front end. From there it was just a lot of me saying to myself, “it should only be another month or two”. At the end of the day, I’ve spent over a year on a project that I never really intended to spend more than 3-4 months on, and I still feel like I only have another month or two before I release and can test my hypothesis.
Anyway I really just want to say that this planning fallacy failure mode is real, and that it seems especially harmful for people working on startups, because agility is so important with startups. (Also, I initially felt too embarassed to share the extent of my planning fallacy failures, but your honesty and disclosure inspired me to do it.)