You have likely heard of the 80/20 rule as related to business. Smart MBA sorts use it mainly to identify the 80% of business outputs that are driven by just 20% of inputs and prioritizing those critical 20% of business factors that have the most effect. Also called the “Pareto Principal” this applies for more across business and life than just the original definition.
In my experience, in the development of a new product, the 80/20 rule means that 20% of the engineering effort will yield a product that is 80% complete, and that implies that the final 20% will consume 80% of the engineering effort to complete.
If you are not in product, this might not seem right, but I can assure you that it has proven true over and over again across my career.
Example: Internal Tool Development
I work in an organization that produces training for IT products and solutions. We support career certifications around various IT infrastructure solutions, as well as product and general technology training.
Conceptually, it is simple. We decide to build a training for technology X. We find subject matter experts (SMEs) in X, we pair them with an instructional designer, they build training, and then we take their output, build great graphical elements, animations, record and add accent videos, assessments, and challenges to reinforce the learning, and publish it as instructor led, or web based self-paced e-learning through a variety of routes to market.
The last part of that, the publishing, the pushing to marketplaces, the inclusion of pricing and placement on price lists is a very non-trivial effort and requires a symphonic coordination of several teams. In the before time, this meant that the product manager was shepherding all these activities and group efforts that are necessary for a successful release of an offer.
Of course, the impetus for the development of a tool to coordinate this symphony wasn’t to make the product manager’s life better (heaven forbid!) but to “fix” the ability of our direct sales team to quickly find a training offer that a customer on the phone is looking for. Instead of consulting the price sheet that we maintain, they wanted a slick web based tool, and the first effort to translate the price sheet into a web tool was awful. The poor soul leading that project tried to get multiple disparate data sources that were rife with inaccuracies and deltas into a cohesive system that would give the right results when asked a question.
That failed, the incongruencies coupled with years of bad data equaled a mental breakdown for that original individual.
The second attempt took a different tact, instead of trying to normalize all the disparate sources of data, its goal was to create one golden set of data that would replace the 6 or so other sources, and be the definitive source. A single source of truth so to speak.
And I was involved with helping the team to apply good grooming and discipline to the data, several multi hour review sessions, and it seemed good.
In the meanwhile, the team developing the tool looked at the end-to-end process, and then defined the requirements of the tool to facilitate this process. And coding began.
At various steps in the process I was brought in to test the mechanics and to help them make the tool better, and I provided many tips that made it into the final tool.
About 4 months ago, it went live in a limited access mode. Instead of filling out tons of different forms that I would submit to different teams (operations, marketing, technical implementation, finance) I just create an entry, and type in the key information, and automatically the other teams are notified, and presumably do their work.
And I will admit that in this limited access time, it worked reasonably well. But behind the scenes, the team was working on the automation of all the system integrations. Getting on release date the details into our storefronts, into our fulfillment systems, our technical lab systems, and the like, that was the primary goal, to reduce the amount of busy work for the team members.
Two weeks ago, they made it widely available, and turned on the automation connections.
It did not go well.
First, a planned revision caused all future classes to be removed from the system en masse. Second, a typo in a date cut instructors off in the middle of a class. And further, there were tons of other glitches.
Two days later the Sr. Director of engineering sent out a glowing atta-boy email thanking the team about the successful launch of this tool. (and they also reduced the amount of engineering effort on the tool to a “maintenance” level.)
This was after the shit-show of errors.
Turns out that they did the 20% of the work that delivered the 80% of the product, called it a job well done (they can’t be blamed for the poor definition of requirements that led to the catastrophes on launch) and moved on to the next big thing.
Meanwhile, there is a half baked system that is causing tons of chaos in our organization, and lots of people are now doing MORE manual processes to fix the glitches.
Engineering, product and the 80/20 rule
In my lengthy tenure in the realm of product, I have observed that engineering is excited and engaged early, driving towards the 80% complete solution, then they lose interest.
In prior lives, this often manifested itself in the last 20% of the product being always in limbo. Things like documentation, polished UI’s, product usability, quirks that puzzle users.
You know, the things that make a product a joy to use, that makes people want to open their wallets to buy it, and that leads to influencers to become advocates for your product and technology.
But, once that first commercial shipment is done, all excitement in the engineering team is gone, shifted to the next big thing, leaving product management to kick, claw, cajole, and negotiate for scraps of resources to finish the job.
So, in this case, I can clearly say that while I understand that engineering loses interest in the last 20% of completion, we need to become more forceful about forcing the issue, and getting them to complete the job.
I mean FFS you argued vociferously that nothing off the shelf could serve the purpose, extolling the benefits of a bespoke solution tailored to our precise use case. I view this as the Pottery Barn scenario. You broke it, you bought it. You overruled the sourcing from the outside, you get it hung around your neck.
In the scenario above, do you think they owned up to their deficit of functionality? Ha. They point to the original – incomplete – business requirements, standing on their soap box claiming loudly that they built what was asked for, and are not prioritizing the completion of the project.
And that really pisses me off.
And the product manager (internal Product Owner) got a huge bonus on completion, a shout out in the announcement, moved to a new high visibility project, and we still have a tool that frankly isn’t fit for function.
