[HN Gopher] Following the Lean Startup Method
___________________________________________________________________
Following the Lean Startup Method
Author : vinnyglennon
Score : 73 points
Date : 2024-03-14 10:41 UTC (12 hours ago)
(HTM) web link (www.june.so)
(TXT) w3m dump (www.june.so)
| arkitaip wrote:
| One of the most important life lessons I've learnt is to not
| conflate the model for the reality it tries to capture but also
| not waste a good model because it doesn't perfectly capture the
| underlying reality. In this case, poor understanding of both the
| model and the underlying reality means that people will dismiss
| both the lean startup methodology and MVP as a technique when
| both are incredibly powerful tools aimed at exploring if and how
| a product might be successful.
| soulofmischief wrote:
| The map is not the territory.
|
| https://en.wikipedia.org/wiki/Map%E2%80%93territory_relation
|
| > The point is not that all maps are useless; rather, the point
| is simply to maintain critical thinking about the
| discrepancies: whether or not they are either negligible or
| significant in each context, how to reduce them
| drc500free wrote:
| Absolutely. It's become almost trite at this point to note that
| "all models are wrong; some models are useful," but it's true
| and the MVP is one of the better ones. The difficulty is the
| same one Agile has - the model has become more useful as an
| excuse to avoid rigor than as a way to get better outcomes or
| understand the world.
|
| If you say you're "doing agile," you don't have to put the
| effort into writing rigorous requirements. If you say you're
| "doing an MVP," you don't have to put in the effort into
| building a rigorously-engineered product. Neither model is
| supposed to be about being lazy. They're supposed to be about
| making trade-offs between different kinds of rigor.
|
| Agile is supposed to unlock the ability to truly re-plan after
| each sprint and make very different decisions about your
| product direction. It's only a positive tradeoff if you are
| being rigorous about looking at your results, generating
| alternative paths, and assessing them. Otherwise you just end
| up with no documentation and a shitty architecture.
|
| MVPs are supposed to be prototypes that reveal the answer about
| a specific hypothesis that is critical to your strategy. It's
| only a positive tradeoff if you are rigorous about what
| knowledge you don't have about your customers and technology,
| and build exactly the thing that will answer the question.
| Otherwise you just end up with a half-baked and buggy product.
|
| Together, they give you the information you need to head in the
| best direction and the means to do so. But only if you're
| taking all that time you were originally spending on system
| design, rigorous documentation, and product quality and putting
| it towards stuff that tech teams aren't usually as comfortable
| doing.
| Beldin wrote:
| > _MVPs are supposed to be prototypes that reveal the answer
| about a specific hypothesis that is critical to your
| strategy. It 's only a positive tradeoff if you are rigorous
| about what knowledge you don't have about your customers and
| technology, and build exactly the thing that will answer the
| question._
|
| Put differently (to put the misunderstanding to rest): MVPs
| aren't alpha- or beta-versions of software; don't treat them
| as such.
| iAkashPaul wrote:
| Those slanted underlines on hyperlinks was really cool though
| rqtwteye wrote:
| To me they look like separate links.
| baxtr wrote:
| The lean startup approach will regain relevance in a non-ZIRP
| world where money truly costs money once again.
| ggeorgovassilis wrote:
| So essentially MVPs need to demonstrate higher quality now,
| attesting not only to the product, but to the capabilities of
| engineering organisations. Team topologies [1] is an
| organisational paradigm that solves a major issue with tribes
| locking themselves up in silos, while contributing to quality on
| both product- and platform- levels.
|
| [1] https://blog.georgovassilis.com/2022/07/10/team-
| topologies-f...
| webinar wrote:
| "I believe some folks in tech love to make simple things sound
| complex, maybe to seem more impressive."
|
| Seems to apply here
| nadam wrote:
| "What Ries and the Lean Startup advocate is picking an X value so
| that you have to build as little as necessary to validate your
| long-term assumptions. Neither the book nor the method prescribes
| whether the "X value" should be high or low on the spectrum. This
| decision is entirely up to you, influenced by your market and
| your criteria for evaluation."
|
| For exactly this reason, although the lean method still works, it
| is no longer a 'revelation' or an 'edge'. It was a revelation
| when the cost of validation was low. Now using the lean method is
| just a triviality: you constantly need to validate your ideas. As
| the cost of validation increases dramatically the importance of
| other success factors (like insight, strategy, deep knowledge)
| increase.
| mikehollinger wrote:
| Y - the concept of frequent validation differentiated the stuff
| I've worked on that's done well from the stuff that didn't. Put
| a different way: the items that we didn't get good validation
| on had to landed with a thud in market, or needed to make
| sizable changes before they were accepted. The items we
| validated effectively had to make the same changes, but we got
| there in smaller steps with less pain.
|
| Also: don't forget business model validation. Having great tech
| that sellers won't sell, or customers can't buy is a tremendous
| waste.
| wouldbecouldbe wrote:
| There are a few problems with the approach:
|
| - Technical debt /migration costs when mvp matures / more bugs -
| High support costs, since MVP often doesn't solve everything lot
| of manual work needs to be done. - Often making promises of
| future features to close sales - This leads to high emotional
| costs, continue asking of clients when promises are fullfilled.
|
| Now of course you can create a very stable solid product,
| properly tested with perfect data structure. But that's highely
| unlikely to happen with an MVP, due to the nature of the
| approach.
|
| Also very hard to get exact feature set right.
|
| These things are solvable, but I don't think they are always
| properly adressed by the advocates of the approach.
| hresvelgr wrote:
| > Now of course you can create a very stable solid product,
| properly tested with perfect data structure. But that's highely
| unlikely to happen with an MVP, due to the nature of the
| approach.
|
| I think this is more to do with "move fast and break things"
| than MVP specifically.
|
| > Now of course you can create a very stable solid product,
| properly tested with perfect data structure. But that's highely
| unlikely to happen with an MVP, due to the nature of the
| approach.
|
| The interpretation I've always had is that an MVP is the
| smallest subset of useful features to take the product to
| market. How you reach that subset is entirely up to you, and in
| my opinion, you should take time and do a good job, not rush.
|
| In my experience, if you solve _only_ the problems you have,
| you 'll be fine as far as long term maintenance goes. Hacks and
| corner cutting are inevitable but you'll be doing a lot less of
| it if you can stave off the desire to invent new abstractions.
| wouldbecouldbe wrote:
| Yeah but those ideas don't work well together, the whole idea
| of MVP is to move fast, since you don't know if it's worth
| investing time in those features yet. So it also doesn't make
| sense to fully develop it to maturity in that line of
| thought. So practically that's what happens.
| throwuwu wrote:
| Your definition is incomplete:
|
| an MVP is the smallest subset of useful features to take the
| product to market _in order to prove or disprove its
| viability_
|
| and the reason you want to keep it to the minimum is to
| minimize the time and money invested in it so that you can
| throw it away if it doesn't work and then try a different
| product. You'll probably have to do this several times before
| succeeding so your budget for each should be about 1/10th of
| your available time and money.
| ToJans wrote:
| To me, an MVP is about reducing functional and non-functional
| scope: which requirements (functional and non-functional) can I
| take away from my solution, while still having built something
| people want?
|
| Maybe your MVP doesn't require full HIPAA compliance, or nine
| nines availability, or the ability to manage users via a front-
| end, or...
|
| Typically people do want software that's intuitive to use and
| doesn't crash, so you don't want to ignore those requirements,
| but most of the others are for grabs.
|
| This implies your MVP is tightly coupled to your ideal customer
| profile, your GTM strategy etc:
|
| Which audience will want to pay for this specific piece of
| functionality, despite all of its flaws (why opt for a non-
| established supplier? What's the out of of the ordinary part of
| the service that makes me willing to buy this? ...)
|
| An MVP is built to validate a business hypothesis, and you
| should try to do the minimum to do this. Technical debt is
| unavoidable, as you usually don't know upfront what all the
| requirements will be within 5 years from now. Trying to
| architect upfront for this will usually fail, as most of your
| assumptions will be wrong anyway.
|
| My #1 tip is to try to build a composable system where you
| assume the majority of the components will have to be replaced
| multiple times over a cycle of n years, so make them easy to
| throw away and start over...
| peterhadlaw wrote:
| While I'm a huge fan of the lean startup method, Ries was heavily
| associated with the R E S I S T movement and ultimately ended up
| creating resistbot. Kinda lame imo.
| RamblingCTO wrote:
| If someone from the company reads this: for gods sake, limit the
| width of text. This is horrible on wide screens.
| punkspider wrote:
| And for some reason the scrollbar doesn't display on Chrome
| (tested with multiple profiles and latest Chrome 122.0.6261.95)
| 0xferruccio wrote:
| Oh thanks for reporting this just pushed a fix!
| 0xferruccio wrote:
| Does it look better now? I just pushed a fix for larger
| screens! We just redesigned our blog so there's still some
| rough edges :)
| greenie_beans wrote:
| does your browser not have a reader mode that fixes typography
| problems like that?
| ryukoposting wrote:
| The author argues that the notion that an "MVP is an outdated
| idea" is a misunderstanding of the definition of MVP, but I think
| the _author_ is missing the the point that those folks are trying
| to make.
|
| As the minimum _viable_ product approaches the complexity of a
| complete product, the difference between the two shrinks to the
| point that the concept of MVP isn 't all that useful anymore.
| That's the actual case against Lean Startup in 2024.
|
| To be clear, I personally think MVP is still an immensely useful
| concept, but Reid's own 0-100 scale makes it hard to understand
| that. There is no 100. Most SaaS, and user-facing software in
| general, must be developed and maintained perpetually. It's not
| about approaching 100, it's about approaching a limit at
| infinity.
|
| Today's MVP identifies a local maxima that's a composite of two
| axes: user experience, and technical debt. If that sounds
| surprisingly similar to the original definition, that's because
| it is.
| enra wrote:
| > As the minimum viable product approaches the complexity of a
| complete product, the difference between the two shrinks to the
| point that the concept of MVP isn't all that useful anymore.
| That's the actual case against Lean Startup in 2024.
|
| I think this is an excellent way to summarize this.
|
| I'm one of the anti-MVP persons out there, and my point is that
| more often than not people tend to use MVP as practice ship
| something half baked, not truly trying to build something
| viable or trying to validate anything. Then the response is
| crickets. In many professional domains, people are busy and not
| willing to spend time or evaluate solutions that are half way
| there to provide any value.
|
| For startups with limited resources, more practical advice
| would be focus on building great core experience for a specific
| user group. You narrow the scope, build less but something
| better and different and shows the value for that group fast,
| whatever it takes.
|
| You could call this a MVP but I'd just call it building a
| product people want to use. The MVP term is unnecessary.
|
| Some ways maybe the success of Lean Startup also means that
| it's just a normal to build things iteratively. I don't think
| anyone is recommending here go back to the days shutting
| yourself in a basement for 5 years and then shipping 10,000
| copies of it on a CD to all the RadioShacks.
| 0xferruccio wrote:
| > You could call this a MVP but I'd just call it building a
| product people want to use. The MVP term is unnecessary.
|
| Isn't the difference here just semantics
|
| From my understanding the premise of the article is that over
| the years there's too much negative sentiment around the term
| MVP.
|
| This negative sentiment comes from too many people building a
| half assed product instead of a kick ass half
| enra wrote:
| It's is but that's the issue. The term is misused and
| misunderstood. Meaning variety of things and activities.
| How the definition has emphasis on building something
| quickly and cheaply, can do more harm than help.
|
| When that happens maybe it's just time to retire the term
| and move on. These days it's common to validate products as
| you build them. You can critically think what a good
| product looks like in your space and aim for that. Then
| iteratively improve from there. Not sure what the MVP term
| really contributes to the practice.
| gardenhedge wrote:
| TLDR: (from the article) "test and challenge your hypothesis
| early and often"
| 0xferruccio wrote:
| love it. no need to make it more complex than that!
| resource_waste wrote:
| My strong 'Anti-Lean Startup' take. I partially blame that book
| on my first failed company. I passively maintain that company
| now. Sure I was 23 years old, but....
|
| >Showing my first, most loyal customers a MVP ruined my
| image/branding. Instead of looking professional, I looked like a
| cheap blog.
|
| >Selling a MVP to these people made them never return as
| customers. While I stand by the base quality of the product, it
| didn't have the shine we see in Apple products.
|
| >I see sites in my space that are far worse, and much more
| popular because of the shine/marketing. I really have the best
| website from an objective standpoint. The discoverability is a
| real issue, I mostly grow organically or from SEO.
|
| tl;dr I showed my 95% finished product to the thought leaders,
| they thought I was unprofessional and couldn't be trusted. Still
| trying to gain that trust back 10 years later.
| Beldin wrote:
| It sounds as if your MVP wasn't viable...
|
| That is: what you thought was the important part of the 95% and
| what the potential customers thought, differed too much.
|
| Sidenote: I wouldn't be surprised if you closely followed what
| customers stated and still ended up somewhere they didn't care
| for.
| rqtwteye wrote:
| There is a lot of luck in figuring out what's minimum viable.
| even if you listen closely and deliver what the customers
| say, there is a good chance they won't like it when they get
| it.
| riku_iki wrote:
| I think marketing is more critical choke point in current
| saturated markets. And if company needs lots of fund to promote
| product, it doesn't really matter if product is lean or not.
| nradov wrote:
| What are current saturated markets?
| riku_iki wrote:
| All of them. What markets are not saturated in your opinion?
___________________________________________________________________
(page generated 2024-03-14 23:01 UTC)