[HN Gopher] When MVPs Hurt
___________________________________________________________________
When MVPs Hurt
Author : mbellotti
Score : 67 points
Date : 2021-12-18 23:20 UTC (23 hours ago)
(HTM) web link (builtin.com)
(TXT) w3m dump (builtin.com)
| bertr4nd wrote:
| I had a related experience with an MVP gone awry. We were
| building a product that had an entrenched competitor (let's set
| aside whether that was a good idea in itself).
|
| We decided to build the core technology and go after some very
| easy wins first, while laying the foundation for bigger, more
| complicated wins.
|
| I thought this was a fairly sound plan at the time but we hit
| three problems that would make me rethink such an approach in the
| future.
|
| (1) the "easy" use case ended up being significantly harder than
| expected. I'd guess it took 4x longer to ship than expected,
| which allowed doubt in the project to run rampant.
|
| (2) the easy wins were smaller than expected (it didn't help that
| the system we were augmenting already had some of the features we
| were building, just implemented in a more ad-hoc fashion).
|
| (3) the more complex and profitable features required
| significantly new features in the core, the implementation of
| which had become very complex and the design compromised during
| the process of shipping the late, underwhelming MVP, and at that
| point there was no more appetite to continue investing in this
| technology.
| bramblerose wrote:
| > I'd guess it took 4x longer to ship than expected, which
| allowed doubt in the project to run rampant.
|
| Isn't that an MVP working as it should? Implement something
| small, realize the whole project is _much_ more complicated
| than expected, and therefore realizing it's a bad plan after
| investing 'MVP' sized money rather than 'full project' sized
| money?
|
| Formulated otherwise, you haven't wasted X in building a
| useless MVP, rather you invested X in gaining knowledge that
| saved the company 10X (or 100X) by not investing in the wrong
| thing.
| yawnxyz wrote:
| Since when is "MVP" an engineering term?
|
| Also, if you're modernizing / migrating your stack, aren't you
| effectively NOT talking about an MVP anymore? I thought the first
| MVP was supposed to be a throwaway prototype used to validate
| (market, technical, UX) feasibility, and once you've validated,
| you can't consider it an "MVP" anymore?
|
| I think there should be a new term for what she's talking about
| -- maybe a "minimally stable product"?
| codingdave wrote:
| Modernization isn't about product features, it is about
| architecture. The reason it is hard is because many legacy
| systems never separated their application layers, making it
| difficult to just migrate the database (for example) without also
| migrating APIs and business layers, even all the way up to the
| UI.
|
| Non-separated layers is what causes people to start to pick and
| choose features. I've been modernizing platforms for about 15
| years now, and my first move is always to identify and correct
| the areas in the app where the layers are intertwined. Even if
| that is a 2 year effort, it builds up to a day when you can just
| pick a layer and move it, and it isn't hard anymore.
|
| But those projects are not about MVPs, or features, or product
| prioritization. It is nothing but pure tech debt - keeping the
| lights on for the customers while you work hard to change
| everything under the covers without impacting them.
| jordanbeiber wrote:
| Couldn't agree more.
|
| Plowing through this atm, about 10 months in...
|
| In my experience, layers love to get intertwined in, so called,
| standard systems.
|
| You end up with a business not really in control of its
| processes and developers who are experts in non-business domain
| data models and dsl/code abstractions.
|
| What you wrote really hit it on the head for me in my current
| position.
| wpietri wrote:
| This makes me a little bonkers.
|
| The MVP is a Lean Startup tool for exploring user needs in a
| startup context when the biggest risk is that you won't find
| product-market fit. (Which is the biggest risk for most
| startups.) It's a way of testing the hypothesis, "I think X is
| the basket of functionality needed to get users to keep using our
| product and get enough out of us that they'll happily pay us
| money."
|
| If you're using it outside of that context, it's not an MVP. It's
| just a sparkling prototype. If your biggest risk is something
| other than product-market fit, please use a different risk
| mitigation strategy.
| wpietri wrote:
| Oh, and if your project hasn't explicitly thought through the
| risk, you may find out your biggest risk the hard way. If the
| team hasn't discused it, here's what I suggest:
|
| Set up a 1-hour meeting. For the pre-reading, google a couple
| of articles on the kinds of risk to software projects. For the
| meeting, explain the goal is to find the the current top 5
| risks. Open up a Google Sheet, label one column "Risk", and
| have everybody spend 10-15 minutes filling the column in. Then
| add a column called "Votes", and have everybody increment the
| votes counter by 1 for what they see as the top 5. Now sort by
| votes.
|
| If people already agree on the top 5, great. If not, you'll
| need to get more consensus around the risk. One way to do that
| is to add two more columns called "Odds" and "Impact". (You can
| use H/M/L or 0-10 for most people; an especially numerate
| audience can use actual odd and actual cost.) Jointly fill
| those in, getting people to discuss why they would pick
| different things.
|
| Once you have adequate consensus, move on to discussing them
| and how to mitigate them. Hopefully you end up with specific
| action items (which can include an MVP!). Then come back in 1-3
| months to do it again; hopefully your big risks will go away
| and you'll have new risks. If you're lucky, the meeting will
| become unnecessary over time.
| LaundroMat wrote:
| It's not always easy for team members to openly discuss risk.
| The pre-mortem technique can help with that. Basically, it
| comes down to imagining being in a future where the project
| has failed miserably and asking team members to look back and
| identify what has gone wrong.
|
| This framing allows people to speak more freely about their
| fears.
| wpietri wrote:
| Great point. I haven't tried that technique, but it sounds
| like a great way to get people to productively examine
| their fears.
| AtNightWeCode wrote:
| MVP is commonly used in agile development in the way the
| article talks about it. Products in the agile world are often
| features and not products.
| celloductor wrote:
| yes the author has taken it way out of context. imagine if auto
| manufacturers produced MVP vehicles without seatbelts etc.
| skeeter2020 wrote:
| The entire idea of a modernization project doesn't make sense to
| me. The author seems to be mixing in the MVP strategy used to
| validate product-market fit (which still has nothing to do with
| simple or easy, it's about lowest-cost value demonstration) with
| some sort of prototyping or technical spiking approach. Neither
| is pursuing "modernization", which is a valueless idea. You
| update things like architecture or implementation so that you can
| DO something with the result. It is not the end production.
| billsmithaustin wrote:
| Regardless, there need to be opportunities to re-evaluate
| decisions that don't work out. Sometimes the project will need to
| backtrack as people discover what works and what doesn't.
| interactivecode wrote:
| I come to think that an MVP is only that, when after validating
| your product case. You scrap the mvp and build the product from
| scratch.
|
| If you're not able yo scrap what you have you aren't validating
| product market fit, you are forcing a product onto the market.
| saimiam wrote:
| Not sure I agree with you. It'sa minimal product. It's still
| something you can carry forward, improve on, and enhance.
|
| Seems wasteful to build something only to scrap it once people
| say they want it.
|
| I'm right now testing out demand for a headless CMS @
| https://moogle.cc/nirvaancms.html and I'm not planning to redo
| the entire tech stack if there seems to be demand for such a
| product.
| osullivj wrote:
| "Difficult part first" is the right approach for legacy
| migration, or any mandated enterprise dev, to surface tricky
| issues ASAP. MVP is about product market fit, which is a given
| via mgmt authority in a corp environment.
| yetanother-1 wrote:
| It still makes sense to start with the core business values
| then go up with nice to have features.
|
| Compexity comes sometimes from not so important features that
| could take much longer to migrate. But of course some of these
| features are why some products are picked over others in the
| first place, however this requires a case study and more
| analysis.
| heurisko wrote:
| MVPs hurt when you cut corners (don't write tests) and mock
| functionality, then show the result to the business.
|
| Because often, they will like what they see and want to go full
| steam ahead, by which time it's too late to explain you actually
| need another couple of months to get to the position they thought
| you were already at.
| notahacker wrote:
| They can also hurt the other way when the business is sold on
| the _concept_ , but the MVP implementation is a lot less
| impressive than the concept.
| kaashif wrote:
| An MVP is supposed to actually work (be viable) and be
| something that you can actually put in front of users to test
| your business hypothesis.
|
| If you present a demo where all functionality is mocked as an
| "MVP" to business and they think it really is an MVP, that is a
| reasonable assumption in my view. If it turns out it's not
| viable at all, can't be sold as a product to anyone, and
| doesn't actually work, that seems like you misused the term
| "MVP".
|
| They want to go full steam ahead because at best there's been a
| miscommunication about the term "MVP". At worst they'll think
| you were lying to them.
|
| It's really important to have clear communication and
| definitions of "accepted" terms which are sometimes used
| inaccurately.
| Ensorceled wrote:
| > An MVP is supposed to actually work (be viable) and be
| something that you can actually put in front of users to test
| your business hypothesis.
|
| Agreed, few of the comments in this thread seem to be
| throwing the 'V' of the MVP out the window.
|
| It's not another word for a mock up or a proof of concept,
| and when did it start being a "process" instead of a "thing"?
| is0tope wrote:
| That's the distinction between an MVP and a Prototype. While
| it can be useful to put together a hack and slash version, it
| needs to be marketed as such. Shameless plug, but I wrote
| about this exact thing: https://www.machow.ski/posts/galls-
| law-and-prototype-driven-...
| oblak wrote:
| At my current employer, everything starts as an MVP. Everything.
| They even call it that.
|
| We build an MVP and go from there. New project? MVP. New massive
| feature? That's an MVP, too. And we iterate on that. I guess it's
| just different terminology, or maybe I am way stupider than them
| allenleein wrote:
| The "launch fast, fail fast way(launch an MVP and iterate it)" is
| to optimize for the company and investor, not the customer.
|
| Investor wanna see the MVP and traction because they want to de-
| risk a "deal". Most of the VCs care more about who is you lead
| investor than the potential upside of the product. As a founder,
| you need to de-risk your future by truly validate your product
| hypothesis.
|
| The Lean approach will lead you to very incremental solutions or
| even make you run around in circles achieving nothing. It lowers
| the cost of failure (downside), but also the potential impact of
| success (upside). This approach determines your mindset as a
| product designer and destroys your potential product/business
| upside upfront.
| MrsPeaches wrote:
| Of course there is useful insight here but it still irks me that
| MVP has become the word for "product with a bunch of features
| chopped out".
|
| MVPs are meant to be a business process where you try to validate
| your business idea as quickly as possible. It is not an actual
| product. [1]
|
| I completely agree with the author in terms that an MVP should be
| used to test the riskiest assumptions of the work to be carried
| out. People seem to have forgotten about that aspect of the MVP
| and have instead focused on the speed aspect.
|
| I quite like the idea of replacing MVPs with RATs (riskiest
| assumption test) [2] to stop the misunderstandings that come from
| MVP having the word "product" in it. Of course the reason for
| that is to focus the mind on selling from the start but it seems
| to have added new misunderstandings.
|
| I may just be an old fogey complaining about what words used to
| mean and need to deal with the reality that language is dynamic,
| but it seems like it causes a whole load of issues when the
| important mental model goes missing.
|
| [1] https://www.ycombinator.com/library/4Q-a-minimum-viable-
| prod...
|
| [2] https://hackernoon.com/the-mvp-is-dead-long-live-the-
| rat-233...
| nmstoker wrote:
| "product with a bunch of [essential] features chopped off" is
| the most frustrating aspect of MVPs being misused.
|
| The scenario I've seen loads with existing legacy systems is
| analogous having a decent but aging car, then some upstart
| waltzes in and pitches an MVP approach, only for the aging car
| to be replaced by an underpowered scooter, completely lacking
| boot space or whatever other essential requirement there is,
| but you cannot argue that this isn't acceptable "because MVP".
| xmprt wrote:
| Would you say that the MVP code should be thrown away when
| building the actual product?
| fcantournet wrote:
| If you built a proto as fast as possible to test hypothesis ?
| yes. IME it's always been a mistake to keep the MVP's
| codebase (and a pure catastrophy when said codebase is dumped
| on another team)
| pas wrote:
| Why throw it all away? If you use the bog standard
| components while building the MVP (and if you are bulding
| it as fast as you can why would you use non-standard
| stuff?), then you should be able to simply replace the
| "NotImplementedException" parts with the implementations
| and keep using the same codebase.
|
| I mean, unless your MVP is a Bash script that emits a HTML
| page and sends an email via telnet, plus a CGI wrapper
| using a hand-rolled HTTP server ... why would you throw
| away the working and validated parts?
|
| I mean if you use super dirty JS (Express) and jQuery ...
| then great, you can refactor that to use TS and plop the
| frontend code into components in whichever framework you
| like (Angular, React, Vue).
|
| But again, these standard frameworks have a ton of "starter
| projects" on GitHub. Why not just start with those?
| gherkinnn wrote:
| Because chances are that in building that MVP you've
| rampaged around a domain you didn't yet understand. And
| that's fine. Expected, even.
|
| Now your APIs are a mess. You have view details in the DB
| and pieces of business logic strewn across the frontend.
| There's no separation of concerns because your only
| concern was to validate an idea. And for some unknown
| reason the only test you have keeps breaking because it
| doesn't handle dates properly.
|
| Previous mistakes inform future decisions. Best set it
| all alight.
|
| The hardest part is understanding a problem anyway. The
| second try will take slightly more time but it won't fall
| apart for no apparent reason.
___________________________________________________________________
(page generated 2021-12-19 23:01 UTC)