4 ms·

But what's the alternative here? "We spent longer than was minimally viable but we still don't have a good idea if it has market fit"-product? In my experience

But what's the alternative here? "We spent longer than was minimally viable but we still don't have a good idea if it has market fit"-product? In my experience the code usually gets binned whether the idea gets traction or not. Some companies misjudge when to rewrite, but that doesn't make the MVP part of the process wrong. The absolute greatest wastes of talent and humanity I've ever seen in tech didn't come from tech debt, those efforts were almost always at least working on a product that people were paying money for. The biggest wastes were from over-delivering products that hadn't and were never going to succeed.

trentnix 2y ago
A portion of “product-market fit” failures are actually software quality failures. I think it’s easy to blame the ensh*ttification of software on corporate incompetence, but I think “minimally viable” is part of the story as well. The world we have now where everything is built to be thrown away, including software, has had the side-effect of destroying craftsmanship. And I'm becoming more convinced as I age that the world is poorer for it.
- cyanwave 2y ago
  Hard agree with the last sentence. We’re capable of greatness, im optimistic for new generation products. Not all humans are bad. Cycles and such
- generic92034 2y ago
  > The world we have now where everything is built to be thrown away, including software, has had the side-effect of destroying craftsmanship. And I'm becoming more convinced as I age that the world is poorer for it. Not every area in the software market is like this. For example, in ERP software often applications from the 90ies are still in use (maybe revamped, maybe not) by many customers. And the maintenance periods are measured in decades (typically not initially, but there always seems to be a maintenance extension).
- sethammons 2y ago
  We changed it to Most Lovable Products to reinforce that we don't just do the minimum, we need our customers to enjoy it
  - trentnix 2y ago
    I like it!
deleted 2y ago
[deleted]
usefulcat 2y ago
In the context of the topmost comment, the alternative is “don’t stop at MVP”. If you make an MVP and end up discarding it shortly after, that’s fine, and completely appropriate for an MVP. OTOH, MVP may not be sufficient for something that the business still relies on day in, day out months or years down the road.
- kiba 2y ago
  "Temporary" frequently become permanent.
meiraleal 2y ago
If it didn't get traction someone defined badly what was the MVP. As it wasn't viable. The M gives the idea of a minimal feature set or low effort but it shouldn't, a MVP now that competition is high needs much more quality and features than a decade ago
k_bx 2y ago
In my opinion, instead of searching for alternative we should use good programming languages that are extremely refactor-friendly and legacy-resistant. That's why I love ELM as a front-end langauge (and hope to see a successor ROC succeed). For back-end, that's why I love Rust, Haskell etc. All languages that are closer to Pure, FP. Because I can leave codebase to other devs and still know that it's not gonna turn into something which I've seen happening to Python, PHP and other OOP language codebases.
- FearNotDaniel 2y ago
  Nope, it's not really about the language - any mainstream language/platform can be used well or badly depending on who's guiding the design of the app (assuming somebody is, instead of falling into the "agile means no design up front" cult). You can create an elegantly structured, maintainable app in python, node, rails, .net or you can create a big ball of mud. Perhaps apps in Elm, Rust, Haskell et al have a bias towards better design because they themselves attract an elitist crowd who think more consciously about these things. If Haskell ever caught on enough to have an "eternal September" moment then the world would be littered with shitty codebases of pseudo-pure-functional code that somehow broke all the idioms that are supposed to make the language great. I once had a client who'd had a shiny but disorganized MVP developed on .NET, and of course as the org tried to scale and ramp up new features, the devs had to fight more and more against the design (or lack of it in some parts, or overly complex over-design in other parts). At some point he met some dude at a networking event who had built a successful business on a Node codebase, and became convinced that we should rewrite from the ground up in Node because our performance problems were all the platform's fault. Wrong wrong wrong. But it's much easier to believe a sales pitch than to do the hard work of learning what good, performant design in your chosen language/framework looks like.
  - wry_discontent 2y ago
    This totally isn't true. Some languages make refactoring easier and some make it harder. FP languages make it easier
  - tome 2y ago
theFco 2y ago
The MVP shows if the idea would get traction. But what good is an idea that gets traction if it is unfeasible to scale, or the organisation is not willing to support it. I think this is what google does with many of its products that end up cancelled. They tested the MVP, people bought in, but the organisation already moved on, so there is no will to support and further develop it. We should be responsible and do an MVP only after deciding if the organisation would be able and interested to scale a product and support it. Otherwise, the downsides are a toxic crunch to support the product, customers are unhappy with yet another product dies, etc...

trentnix 2y ago

A portion of “product-market fit” failures are actually software quality failures. I think it’s easy to blame the ensh*ttification of software on corporate incompetence, but I think “minimally viable” is part of the story as well. The world we have now where everything is built to be thrown away, including software, has had the side-effect of destroying craftsmanship. And I'm becoming more convinced as I age that the world is poorer for it.

cyanwave 2y ago
Hard agree with the last sentence. We’re capable of greatness, im optimistic for new generation products. Not all humans are bad. Cycles and such
generic92034 2y ago
> The world we have now where everything is built to be thrown away, including software, has had the side-effect of destroying craftsmanship. And I'm becoming more convinced as I age that the world is poorer for it. Not every area in the software market is like this. For example, in ERP software often applications from the 90ies are still in use (maybe revamped, maybe not) by many customers. And the maintenance periods are measured in decades (typically not initially, but there always seems to be a maintenance extension).
sethammons 2y ago
We changed it to Most Lovable Products to reinforce that we don't just do the minimum, we need our customers to enjoy it
- trentnix 2y ago
  I like it!

deleted 2y ago

[deleted]

usefulcat 2y ago

In the context of the topmost comment, the alternative is “don’t stop at MVP”. If you make an MVP and end up discarding it shortly after, that’s fine, and completely appropriate for an MVP. OTOH, MVP may not be sufficient for something that the business still relies on day in, day out months or years down the road.

kiba 2y ago
"Temporary" frequently become permanent.

meiraleal 2y ago

If it didn't get traction someone defined badly what was the MVP. As it wasn't viable. The M gives the idea of a minimal feature set or low effort but it shouldn't, a MVP now that competition is high needs much more quality and features than a decade ago

k_bx 2y ago

In my opinion, instead of searching for alternative we should use good programming languages that are extremely refactor-friendly and legacy-resistant. That's why I love ELM as a front-end langauge (and hope to see a successor ROC succeed). For back-end, that's why I love Rust, Haskell etc. All languages that are closer to Pure, FP. Because I can leave codebase to other devs and still know that it's not gonna turn into something which I've seen happening to Python, PHP and other OOP language codebases.

FearNotDaniel 2y ago
Nope, it's not really about the language - any mainstream language/platform can be used well or badly depending on who's guiding the design of the app (assuming somebody is, instead of falling into the "agile means no design up front" cult). You can create an elegantly structured, maintainable app in python, node, rails, .net or you can create a big ball of mud. Perhaps apps in Elm, Rust, Haskell et al have a bias towards better design because they themselves attract an elitist crowd who think more consciously about these things. If Haskell ever caught on enough to have an "eternal September" moment then the world would be littered with shitty codebases of pseudo-pure-functional code that somehow broke all the idioms that are supposed to make the language great. I once had a client who'd had a shiny but disorganized MVP developed on .NET, and of course as the org tried to scale and ramp up new features, the devs had to fight more and more against the design (or lack of it in some parts, or overly complex over-design in other parts). At some point he met some dude at a networking event who had built a successful business on a Node codebase, and became convinced that we should rewrite from the ground up in Node because our performance problems were all the platform's fault. Wrong wrong wrong. But it's much easier to believe a sales pitch than to do the hard work of learning what good, performant design in your chosen language/framework looks like.
- wry_discontent 2y ago
  This totally isn't true. Some languages make refactoring easier and some make it harder. FP languages make it easier
- tome 2y ago

theFco 2y ago

The MVP shows if the idea would get traction. But what good is an idea that gets traction if it is unfeasible to scale, or the organisation is not willing to support it. I think this is what google does with many of its products that end up cancelled. They tested the MVP, people bought in, but the organisation already moved on, so there is no will to support and further develop it. We should be responsible and do an MVP only after deciding if the organisation would be able and interested to scale a product and support it. Otherwise, the downsides are a toxic crunch to support the product, customers are unhappy with yet another product dies, etc...