As a product manager, trade-offs are a consistent theme. Being the voice of the customer and balancing that with the resources your team has available means that you can’t do everything the market demands. That is where prioritization plays such a critical role.
This can be especially tough when you are building net new products that will be compared to your company’s existing, similar products.
For example, my company is about to make a new wires solution generally available. I’ve been very happy with the level of interest our customers have shown in the product. Still, we regularly struggle with comparisons of that product to other wire services that the company has had for a long time. The reality is that any new product is unlikely to be at feature parity with very established older products. That said, there are plenty of reasons why the new wires solution is an improvement upon the older ones.
We are running into similar challenges with other net new services that the teams are in the middle of building. These services are being built on top of a modern technology stack and are meant to augment our existing solutions. Still, the comparisons are already occurring, and it has been a challenge to get folks to understand that the first available version of a new product will struggle to live up to an existing product.
If time to market weren’t an issue, we would continue iterating on those products. But we can’t do that since we have deliverables to meet. That means that my product team is going to have to force trade-off discussions and decisions.
How my product management team is forcing trade off decisions
Here are the steps we are taking:
1) Make sure we understand customer demand and what of those demands are musts, shoulds, or coulds. All musts are going to be included in the MVP. Everything else is a nice to have for now. That’s been a tough sell, but we are holding the line.
2) Determine if any of the musts are areas where our company experience and skill sets don’t align to allow us to build a great product. When they don’t we are looking at partner options.
Just last month, we finished an exercise where we mapped out all the musts and assigned them a t-shirt size estimate. Those estimates were used to plan out our program increments, which were overlaid with the timelines in place for our agreed-upon deliverables.
I had the team begin socializing that data with the development teams.
Next, we will share that data with leadership.
This approach has worked like a charm. In some instances, the work showed that our timelines were doable. In others, it's clear that we will have to descope.
This approach has worked so well for us because it’s allowed us to roadmap groom at the program level. Which has created visibility across the organization.
Another benefit of this exercise is that my team was able to see how well they had spaced the work load. In some places increments were almost 300% resource utilization, while other increments were only at 65% utilization.
Don’t be afraid of descoping
A lot of product managers struggle with the decision to descope.
I don’t see it as a bad thing in most instances. In virtually every product build there are likely some features that crept into the build and that don’t add value or they don’t add value at this stage of the product life cycle.
It certainly would be easier to not allow scope creep in the first place. In fact, I regularly preach to my team that they need to be gatekeeping on the front end as much as possible.
But, that requires time to breathe and the team has been running really hard lately. Which is an altogether different challenge I need to address.
Want more out of your subscription to the Product in Public Newsletter? Consider upgrading to a paid membership to get access to member-only posts and live online events.