“This may be a product cliché, but you really want to strive to understand the problem your stakeholder is trying to solve,” said Anusha Tomar. “Can you describe in plain language the personas involved, the job to be done and the quantifiable benefit to the customer or your business?”
At Zus Health, Tomar and her team develop software tools that allow digital health companies to build new technologies and offer new services. As director of product management, it’s Tomar’s job to shepherd products through the development and implementation lifecycle, to understand the variety of features and focuses that each product needs and to balance the priorities of the company’s clients and end users as well as internal stakeholders — from senior leadership to engineering, sales and marketing teams — throughout Zus Health.
It’s also frequently Tomar’s job to say “no.”
“At Zus Health, we have many stakeholders who are passionate about the company’s long-term vision. We also have customers who have complex and often conflicting needs,” said Tomar. It’s by building trust and cultivating a deep understanding of various stakeholders’ problems that Tomar is able to manage these conflicting needs.
“Balancing stakeholders’ asks and saying ‘no’ will be easier if they recognize that you hear and empathize with their needs,” said Tomar. “It will also become easier when they see you delivering results and solving other problems with the work you chose to prioritize.”
Built In Boston sat down with Tomar to gain insight into the product manager’s role and the ways in which product managers can balance competing needs while building an abiding sense of trust.
Not all stakeholders are created equal. How do you decide whose requests to prioritize?
In order to prioritize work, our product team follows a few general principles.
Customer and prospect feedback, user research and clinician input take precedence over internal input that is thoughtful but theoretical.
We invest in setting annual and quarterly company objectives and prioritize work that allows us as product teams to achieve those objectives. Occasionally, this means choosing not to pursue a capability that a prospect is requesting.
We try to build the lightest possible version of a product and then add features based on customer feedback rather than investing in a rich feature set from the start. YAGNI — short for “you aren’t going to need it” — is a motto you’ll hear often at Zus.
Please share an example of a time you had to say “no” to a stakeholder. What was the request, why did you have to reject it and what was the ultimate result?
As a platform company, we provide tools and data to customers who in turn deliver services to their patient and clinician end users. How much of that end-user experience we build is therefore an important strategic choice.
A few months ago, we had interest from internal stakeholders in building certain patient experiences and UIs on behalf of our customers.
We conducted interviews with prospective customers and members of our early access community. Our buyer personas told us that they wanted to own that aspect of the patient experience, and in many cases had made investments in it that they would be reluctant to abandon. They also shared pain points with the underlying infrastructure that they did want Zus’s help with.
The feedback from those customer conversations resonated with our research and development team. It helped shift our focus towards capabilities our customers could benefit from while still owning the patient experience. Since then, we have invested in more features that empower customers to build products that are critical to their businesses while still benefiting from our platform underneath.
In deconstructing the problem, you might find a simpler path to solving it or realize that you can defer it.”
What tips would you offer to a product manager who is struggling to balance the needs of multiple stakeholders?
Balancing stakeholder requests is always hard, especially since an engaged user with real pain points and feedback is a gift to a product team. I’ve found two strategies useful over the years.
First, this may be a product cliché, but you really want to strive to understand the problem your stakeholder is trying to solve. Can you describe in plain language the personas involved, the job to be done and the quantifiable benefit to the customer or your business? In deconstructing the problem, you might find a simpler path to solving it or realize that you can defer it.
Second, invest in building trust and credibility with your stakeholders. Balancing stakeholders’ asks and saying “no” will be easier if they recognize that you hear and empathize with their needs. It will also become easier when they see you delivering results and solving other problems with the work you chose to prioritize. Setting clear expectations when you choose not to pursue a request will help.
