While I appreciate that the author put in the time and effort to write this, I have to say that I disagree with pretty much all of this.<p>Beyond quibbling about specific points, the MVP and the Vertical Slice are functionally similar they totally different in their purpose. Video Games are generally competing for a slice of a large preexisting market. The test is whether it can compete against existing products. A new to the world software start up is trying to serve a need that is currently unserved. The test is whether there is any market at all for this product (PMF). The 80/20 rule is about getting some validation that the thing you are building is worth building in the first place - not that it can be done, but that it should be done.<p>There aren't a ton of specific examples listed, but the images might insinuate some products that the author has in mind. I would just point out that Magic Leap, Humane were both hardware products that spent >5 years in development. They cam out as completed fully finished products that were complete by any standard. The problem wasn't that these products shipped with missing features, it was that nobody wanted what they were selling (see also the Apple Vision Pro, which is technically phenomenal in terms of design/engineering/manufacturing, but not really very useful). These products did the opposite of the Lean Methodology and show the risk of trying something brand new and not validating the assumptions as quickly as possible.
In terms of economics and utility, the last 80% of effort produces 20% of the result. But the last 80% give us something much more that isn’t quantified: The feeling of having completed something of value, and having done it properly, carries an inherent value that surpasses the last 20% output. It is unquantifiable and priceless. This is when work or products become timeless and truly valuable. Not to mention that feeling of satisfaction and completeness of taking an accomplishment to that level.
Software that is critical is not build like that.<p>Medical device control software is not build like that, drone flight control is not build like that, power plant safety is not build like that.<p>The problem that I noticed in the recent years is: People see the fast dev cycles for non critical software and think they can replicate it in areas where it really does not fit.<p>I guess that’s how we ended up with Teslas self driving.<p>I am a bit worried that ai seems to be build like that, using development cycles fit for a convenience appliance for what could be used as a weapon.
I feel like every concept can be taken too far or is expected to perfectly encapsulate every situation.<p>The few principles I live by are vague to avoid that predicament-<p>1. Don't let the perfect be the enemy of the good
2. Under promise, over deliver
3. Graveyards are full of indispensable men<p>1 took me a long time to really learn<p>2 In my case, where I've sucked at estimations, it's really not over deliver, but deliver my under promise.<p>3 is a De Gaulle quote and my favorite - when I think I can't be replaced because I've had an ego boost from a recent accomplishment. Alternatively, it can also be interpreted as 'the world goes on'.
There’s a conflation going on here. Pareto <i>can</i> be good engineering—a product that solves 80% of use cases at 20% of the cost is a great efficiency: tax prep software for simple tax returns only; a minimalist photo sharing site with few social features; a phone with a great UI and no user-installable apps.<p>This gets conflated with products that are 80% reliable across all their tasks (LLMs, brittle software). That makes it difficult for users to rely on the product, because occasionally a failure will happen, and the user can’t build a mental model of what works and doesn’t.
What if we come to a point where even the investors don't care if you can finish a product at all? If the pitch is good enough and they think you can bring in more investors down the road, they will get back their money at a higher evaluation anyway. This would actually explain why so many startups fail – nobody cared for them to succeed anyway, because the initial investors got rich even without there being a product.
My thought on the article is - by and large most people don't care if the product that have is perfect, they (myself included) only really care that it does whatever job it's supposed to do to a level that's passable.<p>I was, and still am, prepared to use a large number of things that aren't perfect - housing, transport, furniture, computers, clothing, FOOD, and more.<p>edit: Added Food, I don't get the best chef on the planet to prepare my meals every day, or any chef for the most part, not only because I don't have the money, but also because I don't value that sort of thing enough - I'm more than happy with my own cooking for the most part.
If the MVP finds product market fit and the market is large enough, then the economic incentive to finish the remaining 20% will exist.<p>If the market isn’t large enough, then the customer still got 80% of the value whereas in the authors idealised world, they likely wouldn’t have gotten anything at all, since the minimum cost to develop it was 5x higher (assuming 80/20 holds).<p>Overall it seems we’re better off with startups following the Pareto principal than not following it, and the authors real issue is just with bad product management decisions afterwards.
About Pareto applied to AI, I find this interesting:<p>> Even people who advocate for these technologies rarely assert that the results are useable as-is, especially in a world where people are accustomed to a much higher, human-level quality. At best they are useful as a starting point for a human to then finish the image, or the cover letter...<p>I think this might be a bit of a thought trap. Because the people working on and advocating for these technologies are definitely in the top 20% of intelligence/capabilities/whatever you want to call it. For that 20%, the (arguably achieved) 80% might not be good enough. But there are a lot of people who are already vastly outperformed by many of the currently available AI tools in many tasks.<p>There are many people who are just awful at writing and can already benefit greatly from these tools, for example to write readable cover letters. Or for explaining things in basic language, something I often use it for when trying to understand complicated texts from another field.<p>The other side of Pareto is that perfect is the enemy of good. Sometimes 80% adds so much value for the majority, that the other 20% isn't necessary to label something good enough. The article contains an image of a Cyber Truck, which is fitting, but I truly loved my early Model 3 which was arguably also only 80% done.
> I think that the Pareto Principle is technically true in a lot of fields, but I also feel our society would be a lot better off if we didn’t know about it.<p>I doubt that. From what I understand Vilfredo Pareto introduced it to describe the existing allocation of wealth in Italy on the brink of fascism. He claimed that the crops in his garden followed this principle. I highly doubt that that can be replicated. Ever since people refer to the Pareto principle when they observe a 80/20 distribution. Like it is some kind of natural law. But it is not. At least I have yet to see a scientific explanation why a 80/20 distribution would have any kind of special meaning. Just because some distributions are 80/20 doesn't mean there is anything special about it, a lot of distributions are not 80/20.<p>So I think society would be better off if people would stop acting like it is a natural law and there is nothing to change about it.<p>Paereto distribution is dangerous since it is applied to justify hierarchies in society. And it is just not a good justification.
For building software that is your basic web application/SaaS an important part of agile processes, including an MVP, is you build the minimum to get the product out there with lower priority features in a backlog. The idea behind vertical slices in traditional software development (not games) is you have a testable slice of software that can be shipped.<p>A major benefit of iterative development is you may have features sitting in a backlog that keep getting pushed aside for higher priority features that you aren't expending software development and testing resources on those features. Contrast that with a waterfall approach where an entire product is designed up front, requirements documented and then built. The product likely ends up with features that are not important and rarely used.<p>Iterative development, or agile, processes are not the best process for every project. You definitely want high risk projects like nuclear power plant control software to use a waterfall approach to ensure safety.
Doesn't this fundamentally misunderstand the Pareto principle? The 80% and 20% of causes in standard examples don't refer to portions of a sequential effort, but rather slices of competing agents/producers/customers in an economic system. Like, 20% of clients account for 80% of sales, that kind of thing.
"AI" seems like the latest example of the so-called "tech" industry's worship of the Pareto Principle. If "AI" answers are correct 80% of the time and incorrect 20% of the time, that's good enough to promote "AI" as worth something. Demos can be faked if necessary, as Google recently did.<p><a href="https://www.theverge.com/2023/12/7/23992737/google-gemini-misrepresentation-ai-accusation" rel="nofollow">https://www.theverge.com/2023/12/7/23992737/google-gemini-mi...</a><p>Perhaps this is similar to the practice of "vaporware". Musk's Tesla is a recent example. Neverending promises, mixed results.
It's true that building an MVP is a lot easier than creating a polished product that would scale to tons of users. I would even say that the skill set needed for the two are significantly different. Somebody trained at quick prototyping of full stack app may not have the skills to scale it for thousands of concurrent users and vice versa. But isn't that the reason behind raising funds? If the product demand is proven, funds can be raised to polish and scale the product out.
Good post even if only for making the term "vertical slice" more broadly known.<p>Clearly the applicability of this alternative in other domains might not be as direct as in gaming software but its an interesting way to think about how to structure deliverables on the way to the "1.0" release.<p>In other words thinking of horizontal and vertical slice chunks of work, where horizontal means perfecting one functionality that applies across all product components (may not be visible to end-user), while vertical is perfecting all functionalities of one component that is visible to the end user.
Following the discussions here, I found that it could benefit from a better understanding what the Pareto principle is generally good for and what it is not. So here are my thoughts.<p>The Pareto principle is useless if considering just a specific predetermined goal in isolation. If I want to climb to the top of a mountain, I have to climb 100 % of the height. Then it makes no practical difference, when I know that I can reach 80% of the height in 20% of the time, for example. However, the Pareto principle encourages us to (re)evaluate a goal in the light of limited resources. Is it better to be satisfied with only climbing 80% of the height of the mountain and use the time saved for other activities that I would otherwise miss out on? The answer to this question depends on other more general goals that I am pursuing.<p>Applied to software development, this tells us that we should consider for example implementing certain features or striving for a certain level of quality not as goals in themselves, but as framed by more fundamental goals. It is therefore no wonder that given the same code base, the immediate goals what to do next can differ greatly depending on what the fundamental goals are, such as earning money vs. having fun vs. taking pride in, etc. (they may align by coincidence, though). The Pareto principle helps us to (re)evaluate and compare immediate goals in the light of such fundamental goals: Is it better to implement feature A completely and dispense with feature B, or is it better to implement a simplified feature A´ and have room for a simplified feature B´ in the same timeframe (in this example the limiting resource)? Here, the fundamental goal is implicit in the utility function indicated by the word "better", in our example better according to earning money vs. better according to having fun vs. better according to taking pride in, etc.<p>Of course, considering the Pareto principle when (re)evaluating immediate goals does not gurantee to arrive at the best conclusion. And there are additional considerations outside the Pareto principle, such as short-term goals competing with long-term goals under the same fundamental goals, or legal obligations that are non-negotiable. Here, we enter the sphere of policies, where the policy makers decide upon regulations beyond the individual fundamental goals. In practice we have a hierarchy of multiple goals. On each hierarchy level the Pareto principle is still worth considering as long as there are conflicting goals and limited resources.<p>To recapitulate: The Pareto principle can only be applied meaningfully when evaluating certain alternative goals according to a given utility function for one or more specific limited resources.
You may or may not have to finish the last 20%. Since the whole article is based on the premise that you have to, it fails for me.<p>There are attributes of your project that are table stakes (absolutely required to compete) and there are regulatory or safety requirements. You need all those to ship.<p>However, everything else is “value” or even just “perceived value” and it is up to your customer which ones “you have to do””.<p>Let’s put the 80/20 rule another way. If I can get 8 out of 10 features in 20% of the time, it makes sense to do those 8 ( assuming they all have at least some value ).<p>But what do I do with the 80% of the effort that it would take to get the last two features?<p>The answer is opportunity cost. What could I do with that time instead? Put another way, what am I NOT going to be able to accomplish because I chose to add those last two features?<p>If the answer is that I have other features that customers value more, I should do those instead. If I have a backlog of features that all take the same effort as the first 8. I can do 32 of them in the time it would take to deliver the original 2!!<p>The statement was made that “customers do not like to use 80% of a website”.<p>If I read this article, maybe I implement the full 10 original features. If I embrace 80/20, maybe I implement 40 instead. Hey look, the “just do 100%” approach resulted in a website with 25% as many features as 80/20. If “customers do not like 80 percent of a website”, they are probably even less happy with 25%. Right?<p>Now, not all features have the same value. So, the math is not as simple as above. But, in my view, this is the right way to think about 80/20. The perfect is the enemy of the good.<p>So that tue perfectionists can hate me even more, the same is true “within” features (or whatever other axis you are evaluating). Sometimes customers “expect” or even “demand” features they do not really use. Compliance is a an example. Or stuff that used to matter in a product category (and is still used as a filter) not really does not anymore. You can get a lot of value in your product by adding this stuff, but it is a waste of resources to “do it right” or match every competitor like for like. You may find again that you get essentially all the market success “value” from doing some fraction of the work. Note, I am not saying to ship stuff that is buggy or stuff that does not really work. If that is what you think I am saying, you misunderstand. A shorter version may to say “build what your customers will actually use and not much more”.<p>What you really want to spend your time on is the stuff that excites people, that differentiates your offering, and takes “relatively” little effort to execute. That is probably not “the last 20%”, most of the time.