Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When MVPs Hurt

builtin.com

Post reply on HN
Print view View original

11–20 of 37 posts

Re: When MVPs Hurt

#11

Post by kaashif »

heurisko wrote: post #9

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.

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.

Re: When MVPs Hurt

#12

Post by jordanbeiber »

codingdave wrote: post #6

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…

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.

Re: When MVPs Hurt

#13

Post by Ensorceled »

kaashif wrote: post #11
heurisko wrote: post #9

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.

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 l…

> 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"?

Re: When MVPs Hurt

#14

Post by is0tope »

kaashif wrote: post #11
heurisko wrote: post #9

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.

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 l…

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-...

Re: When MVPs Hurt

#15

Post by bertr4nd »

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.

Re: When MVPs Hurt

#16

Post by fcantournet »

xmprt wrote: post #8
MrsPeaches wrote: post #4

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. Pe…

Would you say that the MVP code should be thrown away when building the actual product?

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)

Re: When MVPs Hurt

#17

Post by bramblerose »

bertr4nd wrote: post #15

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…

> 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.

Re: When MVPs Hurt

#18

Post by wpietri »

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.

Re: When MVPs Hurt

#19

Post by pas »

fcantournet wrote: post #16
xmprt wrote: post #8

Earlier quoted context omitted.

Would you say that the MVP code should be thrown away when building the actual product?

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)

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?

Re: When MVPs Hurt

#20

Post by wpietri »

wpietri wrote: post #18

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 us…

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.

Post reply on HN