Revisiting Past Decisions
While product managers are responsible for making decisions, they’re also responsible for revisiting past decisions to ensure that those previous decisions are still correct.
And, if those decisions are no longer helpful for the company, product managers are responsible for updating those decisions to reflect the new reality of the market.
In other words, your decisions should never be set in stone – markets change, competitors change, etc.
But on the other hand, it’s not productive to question every single decision you’ve ever made. Rather, it’s better to have triggers in place to help you determine when you need to revisit a decision.
Here are the three core kinds of triggers that you should use to determine when it’s time to revisit a product decision:
- Knowledge-based triggers: if some fact about the marketplace has changed, revisit the decision
- Metric-based triggers: if metrics fall below a certain threshold, revisit the decision
- Time-based triggers: review key historical decisions about once per quarter
I’ll discuss each kind of trigger below, and I’ll share my own experiences on how I’ve used these triggers to update decisions to maximize positive impact.
Knowledge-based triggers for revisiting past decisions
For any large decision that you make, you should have identified the assumptions or facts that led you to make the decision. For example, you might have said that the industry was XYZ size, or that it was consolidated, or that it had a compelling two-sided marketplace, etc.
These are the large business context items that you’ll naturally be exposed to through sales calls, customer feedback, industry reports, conferences, etc.
When you find that one of your key assumptions has changed, it’s time to revisit the decision.
Here’s an example for how I revisited a past decision.
I previously used the uncertainty framework to make a decision on how much to invest in one of my product offerings.
Due to changing market circumstances, one of my product areas had seen a significant drop in usage, since our customers no longer needed that particular product for their businesses. It wasn’t that the product wasn’t good, it was just that the market no longer needed it. Multiple customers shut off the product so that they could focus on using other functionality instead.
My product had shifted suddenly from a growth product into a “keep the lights on” product, due to market circumstances. I used the uncertainty framework to decide on our investment strategy for the suddenly abandoned product.
But, one year later, we started seeing significant inbound interest in prospects for this product. That meant that our previous knowledge about the ROI of our product offering no longer held true. It was time to revisit the decision to identify how to grow the product offering further.
Previously, we had said that we could create more ROI for customers by investing in areas outside of this product, so I had donated my resources to other areas of the organization. Now that we saw significant increases in demand, we saw that the ROI balance had shifted, and it was time to advocate for this product again.
Using this knowledge, I revamped the roadmap to go on offense so that we could determine how to grow the product.
Metric-based triggers for revisiting past decisions
Other times, we need to use metrics to decide whether our decisions make sense anymore.
We won’t always get clear qualitative customer feedback or external industry reports to signal that we should revisit a decision. Rather, we should be using our own analytics.
For one of my products, we started noticing that our metrics no longer seemed to make sense. We saw multiple actions happening on a single user account that shouldn’t have been possible.
This particular product was a CRM mobile app for real estate agents to accept inbound leads, i.e. people who were interested in speaking with a real estate agent to set up an open house.
We had previously assumed that a single real estate agent would use a single device for their own needs. So, we had decided on a particular architecture for our product.
We decided that we would not implement a hierarchy of accounts; in other words, the only kinds of accounts that we supported for real estate agents were individual accounts.
However, what we actually saw was that agents would give their logins to assistants and junior agents, where they’d simultaneously log in on different devices to accept leads.
Since we didn’t enforce “only one active session per user”, we saw unexpected metrics where certain accounts seemed like outliers. But, when we tried to normalize the metrics by “actions per device” rather than “actions per user”, the outliers went away.
Our metrics taught us that we could no longer use the underlying assumption that we had a 1:1 mapping between user accounts and devices.
To resolve the problem, we decided to create a new framework where you could have teams of users, which wound up better satisfying our agents’ needs. In other words, we created a hierarchy of accounts where a “team leader” could work with multiple teammates to accept leads and reassign leads.
These group accounts yielded a lot more value to our agents, which then yielded a lot more value to our company.
Time-based triggers for revisiting past decisions
While knowledge-based triggers and metric-based triggers are powerful, you should still allocate regular time to revisit past decisions, since sometimes markets and metrics may change slowly.
Generally speaking, whenever your product organization or your company is tackling strategic planning (e.g. once a year or once a quarter), you’ll want to take this time to revisit your past decisions.
As an example, for one of my initiatives, we had decided to focus engineering effort on customer-facing features and not on internal enablement features. This worked when we had only 3-4 customers using these new pilot products. We kept a tab on revisiting every quarter “when should we invest in internal-facing enablement and scalability.”
At one point, when we had crossed the 10 customer threshold, we decided that we were at a point to start investing in internal-facing enablement, since the time required to manually set things up through existing interfaces and the engineering support time spent on triage and enablement was no longer working for us.
So, we invested in a new interface to enable our customer success managers and deployment leads to self-serve their own setups, rather than needing to coordinate with engineering.
Why triggers reduce uncertainty
When we have triggers in place, we no longer need to worry about our decisions going out of date. We’re no longer uncertain about how long our solution will hold up – instead, now we have an action plan that will kick in as soon as it’s relevant.
By reducing uncertainty and risk, we enable our product to stay agile and to best meet the needs of our customers and our cross-functional stakeholders.
Closing thoughts
Use the framework for reducing uncertainty to get to a decision in the first place.
Then, set up triggers behind your decision so that you know when to revisit the decision. You can use knowledge-based triggers, metric-based triggers, or time-based triggers; which one you should use depends on what kind of decision you made.
Want to learn more about how to manage uncertainty? Chat with other product managers around the world in our PMHQ Community!
