How Product Managers Get Team Commitment with Limited Influence
Leading without authority in product management
Is it normal for your product requirements to sit in the backlog for months? When you write good requirements and there is no reaction from engineering, then what does it mean? After spending time researching and developing requirements, you do need a reaction beyond going into the backlog. As a product manager, you need to get out of this situation quickly.
However, you have limited influence in your organization - perhaps you are new to product management or in a new team or maybe someone else is supposed to get commitment to your requirements. Or possibly this is a repeating pattern for you. For many reasons, you feel as if you have limited authority to get commitment to your requirements.
How to Get Commitment to Your Requirements
Even with limited authority, there are things you can do to get commitment to your requirements:
Think about the priority of your requirements
Collaborate on who you need to get commitment
Prepare a story for your target reviewers
It is important to lead your product team to a conclusion on your requirements. You need one of these outcomes:
Commitment to planning the effort to deliver on the requirement
Decide not to do the requirement
Defer the planning of the requirement until a trigger brings it up for consideration
Too many other things are competing for your product management time to leave requirements hanging out with no direction!
Let's talk about the strategies to get a response to your requirements.
Get the Priority Straight by Collaborating
Talk to potential reviewers of your requirement about the priority of the requirement. You likely have an opinion of the priority and this is a good basis of 1 on 1 conversations with your team about the priority.
Suppose you have written requirements about auto-discovery during the installation of your SaaS product. Customers are making mistakes and need to get help from Support to complete installation. Your program manager is about to put this in the backlog since no one from engineering is planning to address this.
You meet 1 on 1 with engineering to discuss the priority of this auto-discovery feature. You learn the following:
Architect thinks this is low priority because it is high effort
Test leader thinks this is high priority because it will make testing easier
Sales engineer thinks this is high priority because service activation is delayed
Lead software engineer thinks this is high priority since he has a script that does auto-discovery
Now you got a breakthrough! Your requirement can be handled with a script. You hold a follow-up review of your requirement and engineering agrees to include the feature in the plan.
Collaborate to Find an Owner
Sometimes a requirement is high priority but no one is working on a plan to implement the requirement. This happens a lot on features that have business requirements. Software licensing, usage tracking, and freemium versions of products are examples of requirements that are hard to get committed.
The strategy in this case is to break the requirements into business and engineering parts. You need to write the requirements to align with organizational boundaries while orienting to the customer experience you need.
Suppose you need to add a premium license tier to your SaaS product. You have defined the user experience of ordering and upgrading to the premium license. No one is planning for this feature. You decide to break the premium licensing into 2 parts:
Business licensing for your IT team to implement in your licensing system
Engineering requirements for using the updated licensing keys from IT
With this separation, you and your program manager can work with IT and engineering independently. When both the IT work and the engineering work are done, then you can enable the premium tier of service.
Make the Benefits Clear
Sometimes your most straightforward requirements just don't get any attention. Often performance improvements and UI improvements fall into this problem. Examples of these requirements are:
Reduce the installation time by 25%
Provision customer data before accounting data
Support more transactions per second
Simple requirements that have multiple solutions across the product team.
The strategy to break out of this limbo is to provide a story behind the requirement. With a story, engineering can address a specific issue. Examples:
Reduce installation by 25%
John kicked off the installation in Public Cloud and it took 4 hours to complete. He was charged for 4 hours of reserved computing with no benefit. A reduction of 1 hour provides 25% savings to John.
Provision customer before the account
Lisa uses your SaaS product for her small business customers. Each account has one customer per account. Lisa has to put in duplicate data for each customer and each account.
More transactions per second
Zac has several enterprise customers of your database service. Zac's largest customers are unhappy with the response times on database queries.
You might feel uncomfortable that these stories only address part of the requirement. Your goal is incremental improvement. You can always write new requirements after getting these requirements finished!
Conclusion - Break Your Requirements Out of Limbo
When you can't get commitment to develop your requirements, it is easy to get frustrated. You might feel powerless to influence work on your requirements.
After your hard work in writing clear requirements, there are 3 strategies to drive requirements into your product plan:
Confirm the priority of your requirements with your product team
Collaborate on who owns the plan for the requirement
Communication on the problem behind the requirements
By using these strategies, you can drive the closure of each requirement into:
A committed plan for implementation
Cancellation of the requirement for business or demand reasons
Deferral to your backlog until a triggering event
The benefit of these strategies is progress on the backlog through teamwork and collaboration.
Related Articles
Product Management IRL now has a paid subscription option! Many of the articles in this newsletter come from my experience in product management. Once a week I write the backstory of an article in Product Management IRL and what happened when I put the article into practice. This gets sent to paid subscribers on Friday nights.
If you are interested in the paid subscription option, you can learn more by hitting the upgrade button
or get a free month for referring 3 subscribers
Yes! Collaboration with stakeholders is key for a good work culture. All stakeholders need to understand context and constraints even if it’s not in their favor now and then.
Clear measurable benefits are so useful for any conversation I'm in. Framing them up in the language of the stakeholders (eg using sales conversion words your company is used to) helps a lot. Great and useful post.