The job of a product manager is to solve problems for the business and the user.
As you mature in your career, you unlock more and more ways of figuring out where the potential problems could be, such as user interviews, analytics, AB tests, etc.
The longer you work on a product, the more problems you’ll be aware of. However, the trickiest part of this job is figuring out which problems to solve and in what order.
Suppose you want to have an impact on your business and your users. In that case, you need to understand the potential order of magnitude of each problem so that you can easily ballpark how your possible solutions might drive your overall goals and metrics.
In this article, you will learn what the order of magnitude is and how you can prioritize your problem solving to achieve the best results for your product.
The order of magnitude is the ability to guess the rough size of something before you know for sure.
Being able to guess the order of magnitude is a key skill in product management because you can’t know the exact impact of a project before you start working on it.
However, you should be able to roughly guess if it will be a large, medium, or small win.
There are multiple frameworks for order of magnitude estimation, such as:
These systems work because our brains are much better at understanding how big something is in relation to something else versus being able to guess its size exactly.
When building a road map as a product manager, you’re frequently tasked with delivering a certain level of impact against an OKR or KPI, or however your company does goal setting.
These goals are often tied to a financial plan that involves growing the business to hit certain
milestones that are either public or private but material to the company.
You want to be able to choose the problems and solutions to these problems to give yourself the best likelihood of hitting these targets.
All product managers have a finite amount of resources, typically engineering hours, design hours, etc., that they can allocate to projects with the hope of hitting these targets.
If you need to increase your primary KPI by 10 percent, you can only afford to spend 70 percent of your engineering hours on a project that will increase it by 1 percent.
This sounds simple to say, but hands down, the most common mistake of new product managers is putting too much effort into solving a minor problem that only impacts a few users.
Estimating impact most commonly happens during your planning process, be it quarterly, six-month, annual, etc.
To be extra sure of your estimation, it’s tempting to build a complex quantitative model to predict the potential impact of your projects.
This is typically a mistake for a few reasons:
Estimating with the order of magnitude solves all of these problems because all you have to do is stack rank the potential projects on your roadmap in order of potential impact.
This is faster and more accurate than trying to get into the weeds and finely estimate what each project will do.
When you look at the bigger picture, your overall velocity as a team is what matters. You learn more by shipping more things, so the faster you can make your overall process, the more you’ll learn in the end.
As mentioned above, there are many ways of using order of magnitude estimation, however the most common one in the industry is t-shirt sizing.
The process of using t-shirt sizing works like this:
This is a very high-level summary of roadmap building. A few nuances that I picked up over the years:
They’re multiple ways that estimation can go wrong. Here are some tips that I found over the years that make this easier:
Frequently, estimation is done during the planning cycle, and projects might not be launched for multiple months after that.
If you put yourself in the shoes of your VP of Finance, they may have completely forgotten about the roadmap that they reviewed five months ago by the time your big project ships.
A lot else is happening in their world, and their attention is pulled in multiple directions.
When reviewing a feature’s impact, it’s helpful to remind stakeholders what you initially estimated this project would deliver, as their understanding might differ from yours.
You might have shipped a “medium” impact project that you thought would be “small.”
Your VP of Finance might have been expecting a “large” impact, and setting this context for them will be very helpful in making sure your projects are getting the attention that they deserve.
Additionally, any artifacts you’re producing, such as OKRs, product specs, etc., should link back to the estimation work and the ballpark expected impact.
When reviewing these artifacts, I ensure that any columns containing these ballpark costs and impact numbers are viewable by default.
Correctly being able to ballpark the impact and cost of projects through an order of magnitude estimation system allows you to help your team ship high-quality projects and focus them on the most critical areas of the application.
It’s less important which estimation framework you choose to convey the order of magnitude of your projects; what’s important is that you’re choosing one and getting comfortable with it.
Additionally, the more you familiarize yourself with how the product works, your metrics, and the problem space you’re within, the easier and faster you’ll be able to ballpark the impact of the work your team is doing.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
WAgile integrates the structured, sequential phases of waterfall with the iterative, flexible practices of agile.
Ryan Lee talks about how to focus on building your background, personal brand, and track record of success.
While you probably hear a lot about MVPs, two MVP concepts — a concierge and the Wizard of Oz — rarely receive much attention.
Maria Cuasay, Director of Product, Growth at Ancestry, talks about building MVPs and running experiments as fast as possible.