7 ms·

Before I riff on him a little, I'm very thankful the author shared his experience, that takes a lot of bravery. He's also not the only person to make this mist

Before I riff on him a little, I'm very thankful the author shared his experience, that takes a lot of bravery. He's also not the only person to make this mistake, so many have. I learned a lot of these lessons from making a bunch of expensive bone headed decisions myself. I also am not implying that just because he fundamentally doesn't understand an MVP or how to build a lean startup that he isn't an awesome dev, I honestly bet he is a great dev who just learned a valuable lesson(3 times :| ) about what an MVP truly means. ( I haven't shared them because I'm awful writer, but I hope to one day ) But wow does this guy not understand an MVP or what matters for a startup. > I became more and more “aggressive” about reducing the scope and focusing on the essentials You should do this day one before you write a line of code. There should be nothing you can cut from your MVP. For the first two months of my last MVP to edit data you sent an e-mail to a dev who wrote a sql script that edited it for you. We still added 3k MRR each month. For every feature you should ask "What would happen if I cut this out?" if the answer is anything but "It literally wouldn't work for any individual who could conceivably use this product (with a broad definition of conceivable) then the answer is cut it. Is it a differentiator? cut it. Does your product suck without it? cut it. You can always trade time for features, but you can never trade features for time. > Maybe I obsess too much about code quality The answer is YES YOU DO! Code quality doesn't matter. It really doesn't matter. What killed your first three startups? Was it code quality? Or was it was not getting out a product fast enough, not iterating quickly enough, and not finding product market fit fast enough. This experience is typical. If the code quality on your MVP doesn't physically disgust you, you're probably focusing on code quality too much.

BobbyJo 6y ago
It's funny how different peoples' experiences can be. I personally witnessed one of the two startups I worked for fail as a result of code quality. Things ended up being too slow and error prone for some of our customers, and eventually they left us behind. We tried to attract new customers, we had amazing feature set after all, but the performance/stability hole ended up being too big to dig ourselves out of before we ran out of money. I agree that the poster likely focused too much on it, but it's definitely not something you can ignore completely with the assumption you'll always have extra time later to go back and fix things.
- JamesBarney 6y ago
  > It's funny how different peoples' experiences can be Yeah it is. I've never seen any startup or project fail due to code quality. Mind sharing your experience? How many dev months had you guys been writing code before code quality became an issue? And why was it so hard to fix?
  - ppeetteerr 6y ago
    I've seen it a number of times. The company would rush to build a prototype, the product would be broken but looked like it's almost ready. Then the cost of engineering would grow and it would become harder to hire people. In some cases, the company had existing customers who were promised new features, so there was no time to fix the underlying issues, and they had to be built on top of. This cycle would repeat. One might look at these companies and say that they are "successful" because they employ people, and some might even sell in the 7-figure range. But looking closely, each of the employees at the company could be more successful working for another company, where they don't spend their time firefighting, and instead focus on up-leveling their experience.
    - burnthrow 6y ago
      This is practically every software business, and is absolutely an illustration of success.
    - sk5t 6y ago
      Having a surfeit of customers clamoring to pay more money for stuff--this doesn't sound like a terrible problem to have as a startup. Sure, spend time to build a reliable core, but gold-plating everything suggests there's been time to burn.
      - ppeetteerr 6y ago
        Not quite what I meant. A lot of startups are trying to find market fit and selling customers on a vision that is not yet realized. They will pitch new features and say that they can deliver if there is a contract. However, these features take longer to develop then anticipated, and are rushed on top of bad tech.
nwienert 6y ago
MVPs work for a subset of startups and it’s important to note that. Selling the mantra around MVP wins praise, but digesting it whole-heartedly is harmful to early founders and generally bad for the world.
- JamesBarney 6y ago
  Why do you think that is? What have been your experiences where release too early has been harmful to the startup? I've seen products release to early, and it can sometimes be painful. But releasing too late can be an existential threat to your company.
  - xwdv 6y ago
    In mature markets with many organized competitors MVP type products fare poorly and provide little useful information, perhaps even misleading information. What you need to build is the minimum product that can steal sustainable amounts of market share from competitors, but that product itself won't be an MVP.
    - cuu508 6y ago
      "can steal sustainable amounts of market share from competitors" is one type of "viable"
    - JamesBarney 6y ago
      I totally agree there exist certain product market fits where an MVP approach doesn't work, or the MVP is so large it probably shouldn't be called an MVP. But I think they are rare. Also the risks aren't symmetrical. If you take an MVP approach and find out an MVP doesn't work you can always build a bigger badder product, you're out a little bit of time(relatively). If however you build out a big bad product and find out you don't have product market fit. You're much more screwed. Another reason this advice is useful, is because new founders who are more likely to rely on advice and rules of thumb over their own experience are far less capable of solving an un-mvp-able ideas simply because they'll have far less access to the capital required to build a big bad product.
loosetypes 6y ago
Would you consider something like @username mentions as excessive in scope for what would have been Slack's MVP? (I know bits of their "origin story" but am in no way familiar with their early product or whether that feature was around from the beginning)
- toast0 6y ago
  Mentions are definitely out of scope for a MVP. It's not really needed until you have a fairly sizable room.
- corytheboyd 6y ago
  Very interesting question, I have my own take on an answer. I would say yes, @mentions make a chat product like slack minimally viable. It is a baseline expectation of a modern chat solution to be able to ping others by name. However, the minimally viable form of the @mention feature is where you stop. Skip all things that are not “the @mentioned user received a notification when I send the message” If you disagree with me, please explain why. I don’t at all believe that a Slack MVP that is nothing more than a WebRTC chat demo would be a sellable MVP in 2020. MVP and prototyping seems to be very conflated.
dSebastien 6y ago
I get your points. We did finally get there with the MVP; the initial roadmap was full of envy, and I set the bar way too high regarding build, tooling, ci/cd & testing. I thought that those would help us further down the road, and I was right, but the issue was more about the time/effort it took me to get there, eventually. I wouldn't say that code quality doesn't matter, but I certainly should've made more tradeoffs on that front. It was just really hard to judge. With my background (enterprise frameworks, mostly), quality almost always needed to be top notch, because our deliverables were the basis for many other developments. I guess this created a bias in my way of looking at code quality? :p
- dSebastien 6y ago
  And to reply to your question, the first two projects mostly failed because my partners did not believe in the projects enough and weren't ready to invest the required time/energy; maybe it was more envy than profound motivation; idk, cannot speak for them. But I abandoned those too, so they're not the only ones to blame I guess ;-)
  - JamesBarney 6y ago
    My point is only that with those first two projects if you guys had stripped it down then you would have gotten feedback much faster. And if that feedback was negative then you would have been able to move on to the next thing sooner. And if that feedback had been positive it would have provided a lot of motivation for your co-founders.
  - PeterisP 6y ago
    The lack of belief and investment is not the root cause but a symptom - you had a limited budget of motivation and belief, and you ran out of it before getting a MVP. If you had "spent" that very limited motivation-time-runway more sparingly on a more-minimal-MVP, perhaps it would have been sufficient. I.e. I'd suggest looking at the constraints the entirely opposite way around than "weren't ready to invest the required time/energy" - in this equation, you can (and must) change the "requirements" for time/energy, as the time/energy available for the project is your core limitation that you should treat (in the short run) as out of your control, especially as it concerns the time/energy of others before funding. From the classic project management tradeoffs, this is a "limited budget - adjust scope to match" scenario, not "fixed scope - let's see what the budget will be" one.
ChrisMarshallNY 6y ago
> If the code quality on your MVP doesn't physically disgust you, you're probably focusing on code quality too much. Maybe. But it helps if the person writing the code has a habit of Quality. That takes many years. When that level is reached, the person basically can't write bad code. Early on, code Quality takes extra time. Down the road, once it becomes habit, then it is just "how it goes." No extra effort at all. But design Quality, in my experience, is even more important. This applies to both architecture and UX. Again, programmers with a great deal of experience will deliver in this arena, as well. "We are what we repeatedly do. Excellence, then, is not an act, but a habit."
- mcjkrw 6y ago
  I'm reviving an old abandoned project/product of mine which I failed to sell initially. This is pretty much how I justified rewriting it from scratch. It makes very little business sense, because I already had a finished product which I could try to sell right then and there, however, I just wanted to learn some proper software development. The project was a front-end app built in jQuery (I started it in 2015) and had terrible code quality in general. If I rebuild it, and fail to sell it, at least I will have some base knowledge on how to build a front-end app properly which I could re-use in a future product.
  - ChrisMarshallNY 6y ago
    Thanks for sharing that. I can def relate. I wrote the BAOBAB server[0] as a "dissertation." It was an exercise to "retrain" my ship software Discipline. Now, two years later, I'm using it in a brand-new application project. It's working amazingly well. [0] https://riftvalleysoftware.com/work/open-source-projects/#baobab https://riftvalleysoftware.com/work/open-source-projects/#ba...

BobbyJo 6y ago

It's funny how different peoples' experiences can be. I personally witnessed one of the two startups I worked for fail as a result of code quality. Things ended up being too slow and error prone for some of our customers, and eventually they left us behind. We tried to attract new customers, we had amazing feature set after all, but the performance/stability hole ended up being too big to dig ourselves out of before we ran out of money. I agree that the poster likely focused too much on it, but it's definitely not something you can ignore completely with the assumption you'll always have extra time later to go back and fix things.

JamesBarney 6y ago
> It's funny how different peoples' experiences can be Yeah it is. I've never seen any startup or project fail due to code quality. Mind sharing your experience? How many dev months had you guys been writing code before code quality became an issue? And why was it so hard to fix?
- ppeetteerr 6y ago
  I've seen it a number of times. The company would rush to build a prototype, the product would be broken but looked like it's almost ready. Then the cost of engineering would grow and it would become harder to hire people. In some cases, the company had existing customers who were promised new features, so there was no time to fix the underlying issues, and they had to be built on top of. This cycle would repeat. One might look at these companies and say that they are "successful" because they employ people, and some might even sell in the 7-figure range. But looking closely, each of the employees at the company could be more successful working for another company, where they don't spend their time firefighting, and instead focus on up-leveling their experience.
  - burnthrow 6y ago
    This is practically every software business, and is absolutely an illustration of success.
  - sk5t 6y ago
    Having a surfeit of customers clamoring to pay more money for stuff--this doesn't sound like a terrible problem to have as a startup. Sure, spend time to build a reliable core, but gold-plating everything suggests there's been time to burn.
    - ppeetteerr 6y ago
      Not quite what I meant. A lot of startups are trying to find market fit and selling customers on a vision that is not yet realized. They will pitch new features and say that they can deliver if there is a contract. However, these features take longer to develop then anticipated, and are rushed on top of bad tech.

nwienert 6y ago

MVPs work for a subset of startups and it’s important to note that. Selling the mantra around MVP wins praise, but digesting it whole-heartedly is harmful to early founders and generally bad for the world.

JamesBarney 6y ago
Why do you think that is? What have been your experiences where release too early has been harmful to the startup? I've seen products release to early, and it can sometimes be painful. But releasing too late can be an existential threat to your company.
- xwdv 6y ago
  In mature markets with many organized competitors MVP type products fare poorly and provide little useful information, perhaps even misleading information. What you need to build is the minimum product that can steal sustainable amounts of market share from competitors, but that product itself won't be an MVP.
  - cuu508 6y ago
    "can steal sustainable amounts of market share from competitors" is one type of "viable"
  - JamesBarney 6y ago
    I totally agree there exist certain product market fits where an MVP approach doesn't work, or the MVP is so large it probably shouldn't be called an MVP. But I think they are rare. Also the risks aren't symmetrical. If you take an MVP approach and find out an MVP doesn't work you can always build a bigger badder product, you're out a little bit of time(relatively). If however you build out a big bad product and find out you don't have product market fit. You're much more screwed. Another reason this advice is useful, is because new founders who are more likely to rely on advice and rules of thumb over their own experience are far less capable of solving an un-mvp-able ideas simply because they'll have far less access to the capital required to build a big bad product.

loosetypes 6y ago

Would you consider something like @username mentions as excessive in scope for what would have been Slack's MVP? (I know bits of their "origin story" but am in no way familiar with their early product or whether that feature was around from the beginning)

toast0 6y ago
Mentions are definitely out of scope for a MVP. It's not really needed until you have a fairly sizable room.
corytheboyd 6y ago
Very interesting question, I have my own take on an answer. I would say yes, @mentions make a chat product like slack minimally viable. It is a baseline expectation of a modern chat solution to be able to ping others by name. However, the minimally viable form of the @mention feature is where you stop. Skip all things that are not “the @mentioned user received a notification when I send the message” If you disagree with me, please explain why. I don’t at all believe that a Slack MVP that is nothing more than a WebRTC chat demo would be a sellable MVP in 2020. MVP and prototyping seems to be very conflated.

dSebastien 6y ago

I get your points. We did finally get there with the MVP; the initial roadmap was full of envy, and I set the bar way too high regarding build, tooling, ci/cd & testing. I thought that those would help us further down the road, and I was right, but the issue was more about the time/effort it took me to get there, eventually. I wouldn't say that code quality doesn't matter, but I certainly should've made more tradeoffs on that front. It was just really hard to judge. With my background (enterprise frameworks, mostly), quality almost always needed to be top notch, because our deliverables were the basis for many other developments. I guess this created a bias in my way of looking at code quality? :p

dSebastien 6y ago
And to reply to your question, the first two projects mostly failed because my partners did not believe in the projects enough and weren't ready to invest the required time/energy; maybe it was more envy than profound motivation; idk, cannot speak for them. But I abandoned those too, so they're not the only ones to blame I guess ;-)
- JamesBarney 6y ago
  My point is only that with those first two projects if you guys had stripped it down then you would have gotten feedback much faster. And if that feedback was negative then you would have been able to move on to the next thing sooner. And if that feedback had been positive it would have provided a lot of motivation for your co-founders.
- PeterisP 6y ago
  The lack of belief and investment is not the root cause but a symptom - you had a limited budget of motivation and belief, and you ran out of it before getting a MVP. If you had "spent" that very limited motivation-time-runway more sparingly on a more-minimal-MVP, perhaps it would have been sufficient. I.e. I'd suggest looking at the constraints the entirely opposite way around than "weren't ready to invest the required time/energy" - in this equation, you can (and must) change the "requirements" for time/energy, as the time/energy available for the project is your core limitation that you should treat (in the short run) as out of your control, especially as it concerns the time/energy of others before funding. From the classic project management tradeoffs, this is a "limited budget - adjust scope to match" scenario, not "fixed scope - let's see what the budget will be" one.

ChrisMarshallNY 6y ago

> If the code quality on your MVP doesn't physically disgust you, you're probably focusing on code quality too much. Maybe. But it helps if the person writing the code has a habit of Quality. That takes many years. When that level is reached, the person basically can't write bad code. Early on, code Quality takes extra time. Down the road, once it becomes habit, then it is just "how it goes." No extra effort at all. But design Quality, in my experience, is even more important. This applies to both architecture and UX. Again, programmers with a great deal of experience will deliver in this arena, as well. "We are what we repeatedly do. Excellence, then, is not an act, but a habit."

mcjkrw 6y ago
I'm reviving an old abandoned project/product of mine which I failed to sell initially. This is pretty much how I justified rewriting it from scratch. It makes very little business sense, because I already had a finished product which I could try to sell right then and there, however, I just wanted to learn some proper software development. The project was a front-end app built in jQuery (I started it in 2015) and had terrible code quality in general. If I rebuild it, and fail to sell it, at least I will have some base knowledge on how to build a front-end app properly which I could re-use in a future product.
- ChrisMarshallNY 6y ago
  Thanks for sharing that. I can def relate. I wrote the BAOBAB server[0] as a "dissertation." It was an exercise to "retrain" my ship software Discipline. Now, two years later, I'm using it in a brand-new application project. It's working amazingly well. [0] https://riftvalleysoftware.com/work/open-source-projects/#baobab https://riftvalleysoftware.com/work/open-source-projects/#ba...