Tech takes the Pareto principle too far(bobbylox.com)
bobbylox.com
Tech takes the Pareto principle too far
https://bobbylox.com/blog/tech-takes-the-pareto-principle-too-far/
126 comments
>> A new to the world software start up is trying to serve a need that is currently unserved.
Well, yes in some cases. In lots of others it's just another implementation of existing software. Oh, you're building another food delivery app, because the current one is missing feature xxx?
This doesn't make them bad, the world is full of different contexts, and providing a solution tailored to a specific context is valuable.
But most startups are not "novel". Even in a novel space (like self driving cars) there are a bunch of companies in that space (basically competing for VC money. )
I'm very much in the MVP camp - if anything I'm more extreme- I'm in the "show me a market and how to reach them before coding anything" camp.
Well, yes in some cases. In lots of others it's just another implementation of existing software. Oh, you're building another food delivery app, because the current one is missing feature xxx?
This doesn't make them bad, the world is full of different contexts, and providing a solution tailored to a specific context is valuable.
But most startups are not "novel". Even in a novel space (like self driving cars) there are a bunch of companies in that space (basically competing for VC money. )
I'm very much in the MVP camp - if anything I'm more extreme- I'm in the "show me a market and how to reach them before coding anything" camp.
There are other parts than the product that can the innovation for a startup. Very few things are novel product wise when they hit it big. Innovation can be bringing existing business model to a new market for example. Then you should most likely 80/20 that new thing.
To quibble a bit, I don’t think that magic leap one released as complete products.
Magic leap had like a 30 degree FOV and no software. It was a dev kit, literally. The consumer version was never released IIRC
Also, I don’t think you argued against the main thesis which is something like “startup land is too good at the first 80% of a product, but not the latter 20%”
That rings true for me. Our industry is not known for robustness and quality. There is robust and high quality software out there, but most of it is not.
Magic leap had like a 30 degree FOV and no software. It was a dev kit, literally. The consumer version was never released IIRC
Also, I don’t think you argued against the main thesis which is something like “startup land is too good at the first 80% of a product, but not the latter 20%”
That rings true for me. Our industry is not known for robustness and quality. There is robust and high quality software out there, but most of it is not.
Magic leap is an atypical example. It wasn't a "lean startup", it spent billions of dollars and many years developing an El Dorado [1] [2] [3] technology. They would have liked to deliver the system they had promised but investors were right to pressure them to deliver something -- even a broadly available dev kit is an important milestone for a technology like that.
[1] For example, the liquid metal fast breeder reaxctor https://www.iaea.org/sites/default/files/publications/magazi...
[2] https://kguttag.com/ tells you just how hard it is
[3] Apple Vision Pro is a refined if overly expensive product that takes a different approach to the same end and consumers were indifferent
[1] For example, the liquid metal fast breeder reaxctor https://www.iaea.org/sites/default/files/publications/magazi...
[2] https://kguttag.com/ tells you just how hard it is
[3] Apple Vision Pro is a refined if overly expensive product that takes a different approach to the same end and consumers were indifferent
> Magic leap had like a 30 degree FOV
So they released both a vertical slice and a horizontal slice then.
So they released both a vertical slice and a horizontal slice then.
> 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.
I feel like it's completely the opposite. A new game doesn't need to "replace" old games. People have played those games. It only needs to be new and good enough to get people's attention.
But tools usually are replacing something existing. Tech that actually creates new possibilities is few and far between. The internet is one example of that. Can you think of another? I think most new tech is aiming to replace older tech that is currently used for those problems.
I feel like it's completely the opposite. A new game doesn't need to "replace" old games. People have played those games. It only needs to be new and good enough to get people's attention.
But tools usually are replacing something existing. Tech that actually creates new possibilities is few and far between. The internet is one example of that. Can you think of another? I think most new tech is aiming to replace older tech that is currently used for those problems.
I don't really disagree but if you look at the most played games on steam many of them are now old. There's a growing inventory of games that are turning into classics.
Not really. Prior classics age out at roughly the same rate.
>A new to the world software start up is trying to serve a need that is currently unserved.
man, really? 99% of software is basically glorified CRUD view for some DB. it's nothing novel.
If we venture outside of corporate software: most startups do not create anything novel - they just monetize existing businesses in a different(usually more predatory) way, or do X but digital. both usually go for 'virtual monopoly' by: offering service(never a product!) for free -> capture the market -> enshittify -> new startups repeats the cycle.
The actual novelty where you find a need that is unserved is sub 0.1% of them.
In reality you aim for product that fits current buzzword meta for funding.
I do 100% agree that product-market-fit is probably the thing you should try to get ASAP though.
man, really? 99% of software is basically glorified CRUD view for some DB. it's nothing novel.
If we venture outside of corporate software: most startups do not create anything novel - they just monetize existing businesses in a different(usually more predatory) way, or do X but digital. both usually go for 'virtual monopoly' by: offering service(never a product!) for free -> capture the market -> enshittify -> new startups repeats the cycle.
The actual novelty where you find a need that is unserved is sub 0.1% of them.
In reality you aim for product that fits current buzzword meta for funding.
I do 100% agree that product-market-fit is probably the thing you should try to get ASAP though.
That's the point. It's not supposed to be technologically novel, at least at start. It's a new business. The innovation is in the business part.
When we were in Rome and exited the Colosseum, it started raining. Some random dude walked to us and sold us an umbrella. Great business, both of us were better off.
When we were in Rome and exited the Colosseum, it started raining. Some random dude walked to us and sold us an umbrella. Great business, both of us were better off.
It's more akin to someone giving you an umbrella subscription(if it rains more than twice this year I'll save money!), killing our all the competition with dumping prices by running on loss for years, and then hiking up the prices, while also tracking you and telling every food vendor your favorite food so they can prepare a greeter for you.
if you think that's a sustainable model, and is good for society then you do you.
if you think that's a sustainable model, and is good for society then you do you.
I don't like those predatory businesses. I think many games are like that nowadays. But not all businesses are like that. I think a game like Factorio is honest and respectable. It doesn't have any subscription models, you buy it once and own it forever. Technologically, AFAIK, it's using old fashioned technology (Allegro was started in 1990). The innovation is in the gameplay part.
the issue is that Factorio sells you a product. outright.
and they are an outlier.
and they are an outlier.
I bet there are some local thugs that control who exactly gets to sell umbrellas to tourists outside the Collosseum on rainy days. You can quickly find out buy getting some cheap umbrellas to resell and trying to get some business there the next time it rains.
Which is precisely why the point of an MVP is not to demonstrate that something can be built but that someone would pay for it once it is built. Of course it can be built, it's technologically simple. It's not minimum viable tech demo, it's minimum viable product.
[deleted]
Sounds like the restaurant business.
Though I appreciate the effort you put into your response, I think you're quibbling and missed the point.
His qualm is with companies developing what amounts to a good demo (whether you call it MVP, prototype, Beta product, etc), validate their hypothesis but then call it a finished product. Validation is supposed to be just that, validation. Instead he's arguing companies call that initial validation market success, then relabel the demo a working product, warts and all.
And, you're correct in saying the Vision Pro didn't flop because it wasn't developed properly. It flopped because no one wants what it has to offer, and that's a different problem from what the author describes
His qualm is with companies developing what amounts to a good demo (whether you call it MVP, prototype, Beta product, etc), validate their hypothesis but then call it a finished product. Validation is supposed to be just that, validation. Instead he's arguing companies call that initial validation market success, then relabel the demo a working product, warts and all.
And, you're correct in saying the Vision Pro didn't flop because it wasn't developed properly. It flopped because no one wants what it has to offer, and that's a different problem from what the author describes
I'm still not convinced on this though. These MVPs are usually a lot less minimal than you would expect for a prototype - far more than just wireframes and a basic POC that you expect to chuck out and rewrite. Might even have a handful of paying users as well.
Since the comparison was made to games development, I think the closer equivalent is an early access release where you're generally paying for a WIP game at a lower price. Money changes hands, you get access to product in return, but there's no guarantee that it would ever be 'finished' or even what 'finished' might mean.
Since the comparison was made to games development, I think the closer equivalent is an early access release where you're generally paying for a WIP game at a lower price. Money changes hands, you get access to product in return, but there's no guarantee that it would ever be 'finished' or even what 'finished' might mean.
awesome_dude(5)
I think it’s also worth mentioning that the author fundamentally misunderstands a MVP. A vertical slice video game presentation _is_ a kind of MVP, and there are tons of anecdotes e.g. from the E3 that tell us just how minimal these can be.
MVPs take different shapes and forms, a polished but limited video game level is no different than a polished landing page with functionality limited to e.g. sign up.
The most equivalent milestone to MVP in games is first playable (FP) or prototype. This is done at first pass/L1/greybox quality.
Vertical slice (VS) is a type of beautiful corner — this is done at production quality.
The purpose of FP is to prove the game loop and that a game is worth producing — that it is viable, or you could say that it has reached the minimum viable state. The purpose of VS is to try out the entire production process and test burndowns, etc.
I can confirm, as someone who has worked in games for decades, that the author understands it correctly.
FP in automotive would be a prototype car, VS in automotive would be the first factory produced car. VS in games often marks the end of pre-production and a shift of priorities from iterating and experimenting to producing bulk content. MVP would be much earlier.
Then in another sense, MVP is already marketable and commercially viable. But a game is that neither at VS nor FP. So if you look at MVP from that perspective, it is not even close to either VS or FP. It would be like somewhere beyond around alpha. In any case, MVP != VS :)
The MVP concept doesn’t work with game production that well because it’s a hit driven industry where most of the costs go into producing the hit. Like in movies, music, TV and book publishing — there are many stages of green-lighting before a product is first made available to the market as going from zero to market is where the bulk of the costs are. Going zero to market MVP as the first green-light check would be quite expensive ($50M for market leading VR/handheld, $100M for market leading console and Windows games minimum spent by the time a game is shown to the players) and risky. So instead, we start green-lighting and reviewing the prototype when <$2M is spent in most cases.
Vertical slice (VS) is a type of beautiful corner — this is done at production quality.
The purpose of FP is to prove the game loop and that a game is worth producing — that it is viable, or you could say that it has reached the minimum viable state. The purpose of VS is to try out the entire production process and test burndowns, etc.
I can confirm, as someone who has worked in games for decades, that the author understands it correctly.
FP in automotive would be a prototype car, VS in automotive would be the first factory produced car. VS in games often marks the end of pre-production and a shift of priorities from iterating and experimenting to producing bulk content. MVP would be much earlier.
Then in another sense, MVP is already marketable and commercially viable. But a game is that neither at VS nor FP. So if you look at MVP from that perspective, it is not even close to either VS or FP. It would be like somewhere beyond around alpha. In any case, MVP != VS :)
The MVP concept doesn’t work with game production that well because it’s a hit driven industry where most of the costs go into producing the hit. Like in movies, music, TV and book publishing — there are many stages of green-lighting before a product is first made available to the market as going from zero to market is where the bulk of the costs are. Going zero to market MVP as the first green-light check would be quite expensive ($50M for market leading VR/handheld, $100M for market leading console and Windows games minimum spent by the time a game is shown to the players) and risky. So instead, we start green-lighting and reviewing the prototype when <$2M is spent in most cases.
To deliver a vertical slice you also create hacks left and right and they quite often then later stand in the way of actually delivering a proper product. I remember the blog post by Ron Gilbert where he presented Da Vinci's Vertical Slice [1] and it still sits with me as one of the best way to present the issues.
A vertical slice is not an MVP because people would never consider it minimally viable. It's a tiny product but it's completely polished and it's for a consumer of one: the publisher.
[1]: https://grumpygamer.com/vertical_slice/
A vertical slice is not an MVP because people would never consider it minimally viable. It's a tiny product but it's completely polished and it's for a consumer of one: the publisher.
[1]: https://grumpygamer.com/vertical_slice/
The complete polish is the author's very point, alongside the fact that most software products never get that complete polish.
I'd argue that an MVP is a minimal game with limited features - say, a platform game where you can walk and jump and finish the game, whereas a vertical slice is the complete experience, walk, jump, collect items, fight, achievements, etc, but the story is just a concept and there's only one level.
In other software, MVP is what you can go live with to all of your customers (often replacing something existing and omitting half the existing features to much chagrin).
In other software, MVP is what you can go live with to all of your customers (often replacing something existing and omitting half the existing features to much chagrin).
I think this is a better comparison than what the article gives. I do think it's not quite necessary to go live to all customers to be an MVP, however. Functionality that requires manual input from the company to make it work might be a reasonable MVP but not viable to go to everyone. It lets you validate what you're doing works, the customer is none the wiser that there's smoke and mirrors, but nonetheless that smoke and mirrors is there.
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.
I'd actually flip it around - in a crowded market the last 80% of work on those 20% features is what makes you stand out.
It's the detail, the little touches, that result in the comparative advantage in the market - not the shared 80% ( most chairs have 4 legs, seat and back - that 80% isn't what you compete on ).
It's the detail, the little touches, that result in the comparative advantage in the market - not the shared 80% ( most chairs have 4 legs, seat and back - that 80% isn't what you compete on ).
Exactly, the extra effort to complete it is worth it, but it is costly. I think this can be explored in a positive way by selling incomplete things cheaper to the end user while using this money to sustain the development of the last 20%. I think Minecraft is a well known example of applying this model that was fair for both the developers and end users.
While I don't believe Minecraft was the first, it did set the stage for the early access model of development, which fits in great with agile development practices and sustainable practices as the developers can release their vertical slice or MVP, then continue development and correct it based on customer feedback. One example of that is Factorio that has been in development for over a decade now, providing value (enjoyable gameplay) the whole time while also getting continuous development and new features as well as a huge and lively modding community, which in itself translated into their major DLC (based on one of the bigger and more popular mods, they hired the developer and probably a few more people from the modding community).
They're "finished" with it now though, after years of weekly updates they've gone quiet in November. But, they're also working on a new game.
They're "finished" with it now though, after years of weekly updates they've gone quiet in November. But, they're also working on a new game.
Minecraft has been rebuilt multiple times (Java, PS3, Bedrock) and is still not done.
I have not seen the code bases from the inside but I would be very surprised if not a lot of it has been touched in recent years.
I firmly believe any sense of accomplishment comes from what you give players, not how ”complete” your implementation is.
I have not seen the code bases from the inside but I would be very surprised if not a lot of it has been touched in recent years.
I firmly believe any sense of accomplishment comes from what you give players, not how ”complete” your implementation is.
this satisfaction sells. there are companies built on the premise that after the last 1% of effort the sales skyrocket. the marketing narrative of having a complete, high quality product helps to stand out.
> 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.
This is why software development _as a job_ sucks, and sucks deeply: how often do you get to put the icing on the cake, and put a ribbon on it, and get a final effort that matches what you were able to envision ?
"Job" satisfaction is for _hobbyist_ software development. Capitalism generates crap software.
This is why software development _as a job_ sucks, and sucks deeply: how often do you get to put the icing on the cake, and put a ribbon on it, and get a final effort that matches what you were able to envision ?
"Job" satisfaction is for _hobbyist_ software development. Capitalism generates crap software.
I've always looked at this a bit differently. For me the last 20% is fulfilling, but it's also a grind.
In a software job I rarely have to do that to get paid, I can spend most of my days on the easy stuff that gets far enough. The pay is good enough that I can spend my time outside of work doing what I want and put in the effort to grind through the last 20% and really feel proud if the end result.
This may be why so many software developers gravitate to wood working. If you have the time to put in the effort for that last 20% its very noticeable and satisfying.
In a software job I rarely have to do that to get paid, I can spend most of my days on the easy stuff that gets far enough. The pay is good enough that I can spend my time outside of work doing what I want and put in the effort to grind through the last 20% and really feel proud if the end result.
This may be why so many software developers gravitate to wood working. If you have the time to put in the effort for that last 20% its very noticeable and satisfying.
I think it was Paul Graham that likened software dev to gardening. But yes, the woodworking analogy is more appealing.
> Capitalism generates crap software.
As opposed to state-funded software development, which is renowed for its high quality and innovation.
As opposed to state-funded software development, which is renowed for its high quality and innovation.
You'd see a lot more from both sides if the motivations were there. The motivation in safety critical stuff is not killing people. It won't matter if I get a boring CRUD app feature to near perfection, I make the same regardless, and that's true in private companies and government.
I think the safety critical developers maybe have some deep itch to scratch and compensation is way less important to them (otherwise they should be making millions in salary given the stakes), but we don't need to use that bar for every developer or product.
But maybe AI will commoditize all of the old boring CRUD apps and those kinds developers are only worth $20-30/hr.
I think the safety critical developers maybe have some deep itch to scratch and compensation is way less important to them (otherwise they should be making millions in salary given the stakes), but we don't need to use that bar for every developer or product.
But maybe AI will commoditize all of the old boring CRUD apps and those kinds developers are only worth $20-30/hr.
> and compensation is way less important to them (otherwise they should be making millions in salary given the stakes)
I think I disagree. Doing safety critical does not mean you work 1000x more. Just that you put more care into what you do (you focus on safety vs productivity), have audits and actual processes to ensure quality.
I think I disagree. Doing safety critical does not mean you work 1000x more. Just that you put more care into what you do (you focus on safety vs productivity), have audits and actual processes to ensure quality.
NASA is a counterpoint.
If they actually have resources, the government is capable of good work. But when it is done on the cheap you don’t get the best work. Whether it’s from underfunding the particular agency, or when they have to outsource to private contractors (often by law the lowest bidder). Don’t know how that fits into the capitalist/state-funded matrix.
If they actually have resources, the government is capable of good work. But when it is done on the cheap you don’t get the best work. Whether it’s from underfunding the particular agency, or when they have to outsource to private contractors (often by law the lowest bidder). Don’t know how that fits into the capitalist/state-funded matrix.
Because it is funded by a capitalist government does not mean it's not living in a capitalist world... didn't you mix it up with the difference between private and public projects?
For yourself, sure. But likely not for your users. In fact, I would bet Pareto is not extreme enough in this scenario.
E.g. Excel or git, or their potential eventual successors. Former and latter has largely being the same commands and feature set used by 99% of users since V1. They are now old, storied projects with enhancements and features/improvements that go decades long, and even inspired or spun out new products/projects out of the ideas built within.
For the article itself, Pareto exists as a reminder that work expended is rarely if ever equal to results produced. There are instances where it pays off. But you always pay a price. Make sure you're willing to pay that price.
Sometimes a chair with 3 legs is all you need or care for. That 4th leg might give you more balance in an uneven plane, but I work in a decently flat garage and I'm not paying the premium for that 4th leg.
E.g. Excel or git, or their potential eventual successors. Former and latter has largely being the same commands and feature set used by 99% of users since V1. They are now old, storied projects with enhancements and features/improvements that go decades long, and even inspired or spun out new products/projects out of the ideas built within.
For the article itself, Pareto exists as a reminder that work expended is rarely if ever equal to results produced. There are instances where it pays off. But you always pay a price. Make sure you're willing to pay that price.
Sometimes a chair with 3 legs is all you need or care for. That 4th leg might give you more balance in an uneven plane, but I work in a decently flat garage and I'm not paying the premium for that 4th leg.
Software that is critical is not build like that.
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.
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.
I guess that’s how we ended up with Teslas self driving.
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.
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.
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.
I guess that’s how we ended up with Teslas self driving.
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 always wonder where the devs come from who end up doing important work.
Seniority doesn't mean anything if a dev's 20 years has been spent flinging crap over the wall and then wondering how to keep up with all the support tickets being filed.
How does one get onto the "software is suppose to work" career track.
Seniority doesn't mean anything if a dev's 20 years has been spent flinging crap over the wall and then wondering how to keep up with all the support tickets being filed.
How does one get onto the "software is suppose to work" career track.
> How does one get onto the "software is suppose to work" career track.
Boring companies that have had IT for a long time; industries like government, taxes, energy, administration, CRM, insurance, pensions, banking, etc. You won't get recruiters knocking on your doorstep to come and work for those though, and you'll possibly be working with 10+ year old tech and development practices.
Boring companies that have had IT for a long time; industries like government, taxes, energy, administration, CRM, insurance, pensions, banking, etc. You won't get recruiters knocking on your doorstep to come and work for those though, and you'll possibly be working with 10+ year old tech and development practices.
10+ year old development means practices like scrum and agile? Or do you mean 10+ year old tech like Golang and Rust? /s of course but I think you need to calibrate your level of "old" :)
React included
Yes, I think a lot of people underestimate the age of some of the popular frameworks/"libraries". React has been "Enterprise approved" for a long time, and is a safe choice for managers.
Go into database internals, or flight control, or hard real time operating systems. Those are areas where it has to work.
In my experience: all over. It's the company that teaches them not to screw up the important work.
Join a robotics team in college
> Medical device control software is not build like that
> power plant safety is not build like that.
Agreed.
> drone flight control is not build like that
You obviously haven't been working in the drone industry, have you? Just a guess :-).
Agreed.
> drone flight control is not build like that
You obviously haven't been working in the drone industry, have you? Just a guess :-).
Depends on the drones. 249g Camera drone ? Probably.
45k€ agricultural spraying drone? At least the ones I had the privilege to look at were programmed quite paranoid. Farmers tend to get really pissed if their equipment dies because of software issues.
45k€ agricultural spraying drone? At least the ones I had the privilege to look at were programmed quite paranoid. Farmers tend to get really pissed if their equipment dies because of software issues.
May I ask the brand of the ones you are referring to? I'm curious now :-)
*built, not build, just fyi, as it is past tense not present tense.
I feel like every concept can be taken too far or is expected to perfectly encapsulate every situation.
The few principles I live by are vague to avoid that predicament-
1. Don't let the perfect be the enemy of the good 2. Under promise, over deliver 3. Graveyards are full of indispensable men
1 took me a long time to really learn
2 In my case, where I've sucked at estimations, it's really not over deliver, but deliver my under promise.
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'.
The few principles I live by are vague to avoid that predicament-
1. Don't let the perfect be the enemy of the good 2. Under promise, over deliver 3. Graveyards are full of indispensable men
1 took me a long time to really learn
2 In my case, where I've sucked at estimations, it's really not over deliver, but deliver my under promise.
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'.
That quote is Georges Clemenceau, not Charles De Gaulle. He was a French politician, but long before De Gaulle.
Not Clemenceau either. https://quoteinvestigator.com/2011/11/21/graveyards-full/?am...
That’s a rabbit hole level of interesting! Thanks for sharing!
It's why I come to HN honestly
There’s a conflation going on here. Pareto can 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.
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.
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.
That's not pareto. That's just finding a niche of people who would prefer more focused products.
Tax prep software for simple returns only is an entire product. Adding support for the other 20% would lose your initial base's interest.
Tax software that aims to solve all problems whose MVP is it handles 80% of people's tax returns is the pareto the author is talking about. But the real complexity is the other 20%.
Pareto as a minimalism process for focused product development is not engineering (good or bad).
Forgetting pareto and believing (or lying) that you are truly 80% of the way there is a big problem in engineering and funding. The author is correct in that.
Tax prep software for simple returns only is an entire product. Adding support for the other 20% would lose your initial base's interest.
Tax software that aims to solve all problems whose MVP is it handles 80% of people's tax returns is the pareto the author is talking about. But the real complexity is the other 20%.
Pareto as a minimalism process for focused product development is not engineering (good or bad).
Forgetting pareto and believing (or lying) that you are truly 80% of the way there is a big problem in engineering and funding. The author is correct in that.
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.
That just means the investors are your real customer.
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.
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.
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.
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.
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.
First 20% of effort will finish 80% of the work. Second 20% effort will finish 16% of the 20% left.Totally 96% will be finished.
I once had a PM who loved the Pareto principle a little too much, and would constantly push us to "apply it" even after we already had. I got frustrated by this and drew the graph that goes along with your sentence, showing that miraculously about 99% of the work can be done with 60% of the effort!
My PM did not take the correct lesson away from the encounter.
My PM did not take the correct lesson away from the encounter.
If the MVP finds product market fit and the market is large enough, then the economic incentive to finish the remaining 20% will exist.
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).
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.
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).
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:
> 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...
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.
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.
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.
> 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...
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.
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.
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.
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.
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.
Paereto distribution is dangerous since it is applied to justify hierarchies in society. And it is just not a good justification.
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.
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.
Paereto distribution is dangerous since it is applied to justify hierarchies in society. And it is just not a good justification.
Hum?
There's pretty much a mathematical rule that states that variables free to have any values tend to distribute themselves like that, just like the one that states that variables that are bounded tend to distribute themselves normally.
Or are you talking about the specific numbers? Because yes, the specific numbers are almost never correct.
There's pretty much a mathematical rule that states that variables free to have any values tend to distribute themselves like that, just like the one that states that variables that are bounded tend to distribute themselves normally.
Or are you talking about the specific numbers? Because yes, the specific numbers are almost never correct.
Pareto distribution can be expressed in mathematical terms. So what? That does not explain why a specific distribution should follow this rule.
This all is the most minor aspect of Trattato di Sociologia Generale. Treatise on General Sociology, the translation is the 4 volume The Mind and Society.
The whole point is that we have these arbitrary subject divisions of knowledge for convenience. Physics, economics, biology, chemistry, etc. Then he spends 4 volumes trying to describe what he sees as the mechanics of society without worrying about these divisions of knowledge.
I have been stuck on volume 2 for years. It is brutal read.
A Pareto distribution is a type of power law distribution.
80/20 is Joseph Juran's pathetic simplification. It is something MBAs can easily remember. It is like the most minor and trivial of Pareto's thought.
The main idea of his thought is that society is largely based on types of "non-logical conduct". Pseudo-logical conduct. The best I have been able to understand it is that Pareto believed society operates on unthinking, almost quasi religious beliefs, then after the fact we invent logical and scientific sounding reasons for the action/behavior and fool ourselves into believing the action/behavior was logically arrived at from the start.
His work is trying to catalog these non-logical conducts like a butterfly collector collecting types of butterflys.
Basically, nothing much at all to do with 80/20 or fascism.
Pretty sure all the big Italian political philosophers from that time believed in the Iron Law Of Oligarchy politically. Democracy being basically a type of performance art while it doesn't matter the system, you always get oligarchy in reality.
The whole point is that we have these arbitrary subject divisions of knowledge for convenience. Physics, economics, biology, chemistry, etc. Then he spends 4 volumes trying to describe what he sees as the mechanics of society without worrying about these divisions of knowledge.
I have been stuck on volume 2 for years. It is brutal read.
A Pareto distribution is a type of power law distribution.
80/20 is Joseph Juran's pathetic simplification. It is something MBAs can easily remember. It is like the most minor and trivial of Pareto's thought.
The main idea of his thought is that society is largely based on types of "non-logical conduct". Pseudo-logical conduct. The best I have been able to understand it is that Pareto believed society operates on unthinking, almost quasi religious beliefs, then after the fact we invent logical and scientific sounding reasons for the action/behavior and fool ourselves into believing the action/behavior was logically arrived at from the start.
His work is trying to catalog these non-logical conducts like a butterfly collector collecting types of butterflys.
Basically, nothing much at all to do with 80/20 or fascism.
Pretty sure all the big Italian political philosophers from that time believed in the Iron Law Of Oligarchy politically. Democracy being basically a type of performance art while it doesn't matter the system, you always get oligarchy in reality.
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.
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.
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.
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.
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.
>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.
In software development, waterfall projects were often iterative, though in longer cycles. I'm sure there were some that weren't but each version is essentially a waterfall iteration. For example, way back when, we would do 2 major releases and 2 patch releases every year, so our iterations were 3 months. Keep in mind this was software that we cut onto CD's and shipped out.
The benefit of waterfall is that biz is required to think about the project as a whole instead of a wishlist. Sometimes with agile, you end up with a Homermobile because the biz isn't forced to think of everything at once. Both have plusses and minuses.
In software development, waterfall projects were often iterative, though in longer cycles. I'm sure there were some that weren't but each version is essentially a waterfall iteration. For example, way back when, we would do 2 major releases and 2 patch releases every year, so our iterations were 3 months. Keep in mind this was software that we cut onto CD's and shipped out.
The benefit of waterfall is that biz is required to think about the project as a whole instead of a wishlist. Sometimes with agile, you end up with a Homermobile because the biz isn't forced to think of everything at once. Both have plusses and minuses.
Waterfall is iterative. It's been so in practice in every place I've seen it in use, since the 90s.
Not quite sure why so many devs assume that agile exclusively means iterative.
Not quite sure why so many devs assume that agile exclusively means iterative.
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.
Seems analogous to me. “20% of the functionality (in a product) is 80% of the work (to implement it)”
"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.
https://www.theverge.com/2023/12/7/23992737/google-gemini-mi...
Perhaps this is similar to the practice of "vaporware". Musk's Tesla is a recent example. Neverending promises, mixed results.
https://www.theverge.com/2023/12/7/23992737/google-gemini-mi...
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.
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.
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.
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.
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.
If I had around 8-12 weeks to live and have a project that is 5% complete what would the right allocation of resources be?
Allocate 0% of resources of the project, and spend your remaining time with loved ones, see some wonders, give them experiences to remember you by, make things right, etc.
what if the project is all i have? no family or friends etc
Still travel, see the world. Experience physical reality! Spend whatever money you have to make your final days pleasant.
12 weeks isn't going to build you a legacy. So just drop the workaholism.
12 weeks isn't going to build you a legacy. So just drop the workaholism.
if there is an ideological bent, or other driving reason -- write it up! make treatise / requirements document for someone else to implement.
Go see the world.
assume poverty is a big factor what is something a poor person can do? truly curious if anyone has a cheat code
I'd go for a 3-month hike. Maybe try a big one like the Appalachian trail. Sure you need some money for a tent, good coat, camping stove etc. But the day-to-day costs for hiking are minimal.
Sign up for some credit cards...
Travel on a budget working as a volunteer. I’ve done that when I was homeless and desperately broke. It was the best time of my life at the time.
Genuinely, if I had 8-12 weeks to live, the project would not be my priority, unless it was a welcome distraction. Prioritize whichever parts bring you joy, and do something about the 8-12 weeks if you can.
Scanning the comments, it looks like 80% of you agree with 20% of what the author is saying.
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.
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.
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.
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.
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.
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.
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.
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.
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.
I actually like this stuff. I get to use a lot of software. One of my favorites is half baked open source. Pretty good to read and get ideas from.
Everyone knows you're only supposed to use Pareto 20% of the time
video games are guilty of this too, and the proliferation of Unity and Unreal is partly due to an overoptimization for prototypes
A lot of Unity and Unreal games seem to have one thing in common: unoptimized slop with garbage performance with smeary TAA and needing a 4090 GPU to get decent performance.
Game studios don't care about optimizations anymore, they care about shoveling something out the door as quickly and as cheaply as possible.
Game studios don't care about optimizations anymore, they care about shoveling something out the door as quickly and as cheaply as possible.
At first I thought this was about the "Peter Principle" and I couldn't agree more.
Video games are not tech?
Yeah, let me drop one example: JIRA.
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.
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.
However, everything else is “value” or even just “perceived value” and it is up to your customer which ones “you have to do””.
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 ).
But what do I do with the 80% of the effort that it would take to get the last two features?
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?
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!!
The statement was made that “customers do not like to use 80% of a website”.
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?
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.
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”.
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.
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.
However, everything else is “value” or even just “perceived value” and it is up to your customer which ones “you have to do””.
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 ).
But what do I do with the 80% of the effort that it would take to get the last two features?
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?
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!!
The statement was made that “customers do not like to use 80% of a website”.
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?
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.
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”.
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.
monero-xmr(1)
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.
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.