90/10 Product Management.
While what I am writing about today is applicable across life, I want to zoom in and focus on how this can benefit product management.
This is not an essay just for professional product managers but for anyone who finds themselves in a product manager position. That is anyone who has to decide how a product or service is designed, built, and delivered to people.
Product managers are responsible for the planning, forecasting, and executing a product throughout its entire life cycle. This includes developing a product strategy, gathering requirements, creating a product road map, managing the product backlog, and ensuring that the product meets customer needs. Product managers also work with other departments to ensure that the product is successfully launched and marketed.
The role of the product manager has become increasingly important in recent years as companies have come to realize that successful products require a deep understanding of customer needs and market trends. Product managers are often seen as the link between the customer and the company and play a vital role in ensuring that products are developed and marketed effectively.
Even more specifically, this is about products and services that are digital and software-based. This is a fascinating niche because often, anything feels possible if we are coding it instead of having to build it physically, but this is just an illusion.
There are just as many restrictions and limitations when creating a product or service in software. You still have plenty of constraints such as legal limits, budget, time, team capabilities, and the laws of physics in general.
One of my favorite forcing functions when working on my products or advising startup founders is to think of how much of your vision of your product you can dilute, significantly reduce effort, and make things much simpler for yourself.
So if your 100% vision takes 100% effort, can you get 90% of what you want but expend only 10% of the effort? In other words, where are the compromise areas, especially in the things that are difficult and perhaps do not add as much value as you think they do?
My favorite tactic to achieve this is to constantly think of the “v1” of what we are doing. Can we ship something smaller, more straightforward, with fewer moving parts to think about?
I think like this because I have been constantly humbled about my abilities about being able to estimate or understand even the simplest of features.
I have never been able to accurately understand features as a whole up-front in my entire professional career. Additional considerations and complexities come into play as soon as you start designing, and then even more come up as you start coding.
So, start with the assumption that you don’t even know how complex something is going to be, but that it will for sure be more complicated than you assume it is going to be.
It is a little strange to treat yourself like a child, but this is what is required to put yourself in the right frame of mind. Sketch out the big ideas of your feature, scale it down, and then consider some of the edge cases. You will likely underestimate your edge cases by 50-100% at a minimum — and this is where the problems are.
If you bundle together enough edge cases for a given feature, they actually add up to both a significant amount of design and development work and also a lot of the usage of the product.
The other problem, often outside of the product manager’s responsibilities, is that budget and time are already fixed. Contracts and agreements and plans may have been made even before you started working, and you may or may not have been consulted, so these are constraints that you have to work with.
And so, the only lever left for you to manage is the scope. More often than not, you will regret taking on too much scope than taking on too little.
Don’t be scared to ship something that feels “underwhelming” to users or your management team. Just shipping something that works and is actually used is already a huge win, plenty of organizations fail at even this essential task.
Once you’ve got something in the hands of real people, speak to them. With a surprisingly small sample size (<10) you’ll have a good idea of what additional improvements you need to make, and this is your new starting point. And you apply the above 90/10 thinking to this improvement, make life easy for yourself, and ensure that you ship.
And then repeat.
Over time, this will lead to a team that has little stress, ships a consistently high-quality product that is user-centric, and gets in the habit of shipping a product regularly instead of having “one big-bang release”.
I am always skeptical of scheduled large product launches for this reason. My experience, and what I have seen others do that have been successful, is that good products don’t “launch” in one day. They take months and years to improve slowly until they solve specific problems really well. That’s when most people then become aware of the product, and it looks like an overnight success.
It’s not — it is lots of small, good decisions compounded over time.
