Your product is ready to release with a known issue. Your biggest customer is seeking a bigger discount than ever before. A sales team wants to start selling an uncommitted feature. You feel very uncomfortable in each of these situations. As a busy product manager, do you need to step into these conflicts? Yes! Can you set the rulebook for handling these situations? Yes!
Why are you uncomfortable in these situations? Whether you ignore these issues or take action, you are setting a precedent for your product. When you set a precedent, you are establishing a new standard that affects similar situations in the future. Setting a precedent of not responding to product issues devalues your role as a product manager. When you respond to a product issue, you set a benchmark for product leadership.
When you feel that discomfort about a product issue, take a few steps to set a good precedent:
Develop your skills in precedent-setting
Give yourself space to recognize you are about to set a precedent
Decide about setting a new precedent and communicate about it
Over time setting precedents, extends your reach because your product team and stakeholders have established standard ways to handle issues together. Let's dive into setting precedents!
Building Your Precedent Setting Skills
You are likely to send your colleagues running if you come on strong about precedent-setting. Ideally, it would help if you had precedents emerge from daily work and daily conversations. Some ways to improve your skills in setting precedents are:
Strategic thinking: consider the impacts of decisions over the long term
Stakeholder involvement: to get different perspectives and insights
Data-driven decision making: using market analysis and customer feedback to support decisions
Risk assessment and mitigation: evaluate the risks of setting a new precedent
Collaboration: leverage the knowledge of your team and encourage open discussion
As you consider these skills and apply this to your product, you can talk about possible precedents with your team.
Recognizing When a Precedent is Being Set
As you build your skills in strategic thinking, data-driven decision making and risk assessment, you naturally have precedent-setting conversations with your product team and stakeholders. Here are some examples:
Product ready to launch with a known issue
Investigate the risks and mitigation
If there is a risk, consider what kind of precedent this sets
A customer is seeking the biggest discount ever
Evaluate the risk of further price erosion
If there is a risk, investigate a different solution
Sales teams want to sell a future item
The usual practice is for product managers to talk to customers with sales to understand future needs
If sales teams are allowed to sell future features, then understand the history of this practice
It is crucial to recognize these fork-in-the-road points where your actions or non-actions cause a precedent that is harmful to your product's future. In the above examples, there is a risk to product quality, price erosion, and revenue recognition. Your collaboration skills can help you work with others to spot a possible precedent. When caught early, you can undo a precedent that conflicts with your product goals.
Try to keep some open time in your calendar so you can think about the impacts of a possible precedent. Then use that time to prioritize your actions to set or remove a new precedent that risks your product goals.
Decide and Communicate
When you recognize a situation that could establish a new precedent, decide what is best for your product. Key product areas to consider are:
Customer satisfaction
Cost overruns
Financial forecast
Product quality
Ethical and legal
Your leadership and stakeholders want your opinion and recommendation about handling a new precedent. You do need to communicate about the precedent at their level.
Here are examples of communicating a precedent at your stakeholders' level:
Product ready to launch with a known issue
DO communicate the facts on customer satisfaction and significant financial impact
DON'T comment to stakeholders on minor issues
A customer is seeking the biggest discount ever
DO communicate about broader financial risks and alternatives
DON'T approve/disapprove - stakeholders need to decide based on your recommendation
Sales teams want to sell a future item
DO set a precedent to lead discussions of product futures with sales
DON'T change historical practices until collaborating with all stakeholders
You won't spot a potential new precedent often - perhaps once or twice in a product iteration. Needing to decide and communicate about a new precedent is less frequent. Awareness of new precedents is a good thought exercise for product managers. When there is a change in your product, you naturally think about the impacts and this leads you to consider if you are setting a new precedent.
Conclusion - Strategies to Set Precedents
That uncomfortable feeling about product decisions could be caused by setting a new precedent. Setting a new standard for future actions on your product can be scary or invigorating for you as a product manager. Either way, your team needs your leadership in setting precedents for your product.
The steps to recognize and act on a new precedent are:
Develop your skills in precedent-setting
strategic thinking, decision-making, and collaboration are a few
Give yourself space to recognize you are about to set a precedent
Thinking time to recognize the pattern of a new precedent
Decide about setting a new precedent and communicate about it
Let stakeholders and your team know
This gives you the steps to build your precedent-setting muscles and define your product rulebook.
Link of the Week
Building Trust with Your Stakeholders Turning requests into shared goals and other ways to build an environment of trust. @Kax Uson shows how to do this with examples and more.
I like the specific bullets on the stakeholder management side of this. Great post!
I really like building decision structures/automations that enable you to decide once and then automate decision making because you set a precedent.
I wonder how to document such decision rules (in a Team Playbook? https://www.leadinginproduct.com/p/team-playbooks) or whether to document them at all? Most often, they are cultural knowledge that is never written down.