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

21–30 of 37 posts

Re: When MVPs Hurt

#21

Post by LaundroMat »

wpietri wrote: post #20
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…

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.

Re: When MVPs Hurt

#22

Post by saimiam »

interactivecode wrote: post #10

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.

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.

Re: When MVPs Hurt

#23

Post by wpietri »

LaundroMat wrote: post #21
wpietri wrote: post #20

Earlier quoted context omitted.

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…

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.

Great point. I haven't tried that technique, but it sounds like a great way to get people to productively examine their fears.

Re: When MVPs Hurt

#24

Post by gherkinnn »

pas wrote: post #19
fcantournet wrote: post #16

Earlier quoted context omitted.

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

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.

Re: When MVPs Hurt

#25

Post by oblak »

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

Re: When MVPs Hurt

#26

Post by allenleee »

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.

Re: When MVPs Hurt

#27

Post by yawnxyz »

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

Re: When MVPs Hurt

#28

Post by skeeter2020 »

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.

Re: When MVPs Hurt

#29

Post by notahacker »

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.

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.

Re: When MVPs Hurt

#30

Post by AtNightWeCode »

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…

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.
Post reply on HN