In a previous job, I had a brief stint where I had transitioned from a software engineer to a product manager. I learned many things in this role (including that I did not want to be a product manager in the long term), but by far the biggest lesson was seeing the 80/20 rule in practice and how it affected my approach to software.
In case you're not familiar with the 80/20 rule (formally known as the Pareto Principle), it's the idea that 80% of results come from 20% of the work. Conversely (and arguably more importantly!) is the idea that the remaining 20% of work takes 80% of the time to finish.
I had known about this principle before working as a product manager, but seeing it in action while working with developers was another story. I was used to being an engineer and going to my product manager to tell them that a feature was more difficult than originally estimated. It was a strange feeling to be on the other side of the table where developers would come to me echoing that same sentiment.
What was particularly interesting was seeing exactly what parts of a feature request developers were getting hung up on. Often the specific parts they were struggling to accommodate was of little/no consequence to me as the feature requester.
For example, a feature may be something like "Add a new pricing page to our website as depicted by the attached mockup." And if a developer came to me saying something like, "this is actually going to take much longer than we estimated because the design of these dropdown boxes is totally new." Chances are I'd be happy to downscope that design or maybe even drop it altogether. The main goal was to add a new pricing page, not recreate a mockup verbatim for the sake of pedantry.
I'd be lucky if that conversation happened early on in the sprint, but often I wouldn't hear about problems until we were close to feature freeze which was always the most painful and rushed time to have to make those sorts of decisions. Many headaches would've been curbed or avoided entirely had I had better insight into which parts of a feature request were going to be the most problematic.
Leveraging the 80/20 Rule to Your Advantage
Now that I've returned to my role as an engineer, I feel like I have more empathy and can communicate better than ever with my teammates.
How can the 80/20 rule make you a better software developer? By knowing that not every feature needs to be implemented verbatim. In fact, you should always be asking yourself: "What is the problem that this feature is trying to solve?" when building software. In the case of the pricing page, the answer was to convey pricing information to users, not to have the fanciest dropdowns a user had ever seen. Know that your product manager and designers don't have complete information about a system, and you're actively doing them a favor by calling out hard-to-implement features early on in the development process.
Hope you enjoyed this read! If you liked this article, I talk about the 80/20 rule more in my book Keep Calm and Code On.