Because the existing strategy is not scalable and does not align with the way the product portfolio it is a part of is headed, we are essentially overhauling our product.
Although currently an internal product, it is moving toward having an external facing. The majority of my existing users and stakeholders are internal, and they frequently ask for things that are only useful to them and cannot be used for other purposes. I’m working on self-enablement capabilities that will enable me to free up my team from having to construct unique custom solutions themselves.
What we are working on will help them long term, but this will be a big change for them because the PM before me kind of spoiled them and set them up to see my product as a feature factory.
Any suggestions on how to address the circumstance?
I would start by assisting them in putting together a business case for their requests. Assume that their qualities will raise the worth of the company.
@JuanAllo, Best answer, 90% never come back
They just want IT resources to save them 15 mins of their weekly work
@CathrynCui, I believe it would be quite beneficial to include a Google form with various fields where users can contribute feature suggestions and improvements. It does several tasks:
encourages them to consider their request carefully.
gives those requests a central location to be forwarded to for voting and prioritising. After ideas have been reviewed with the voting add-on, we use Trello. This enables users (internal or external) to vote on the issues they find most aggravating about the system or the most important to resolve.
Bonus: You will receive more valuable goods if you can persuade internal teams to approach requests with the problem in mind rather than the solution.
Example: “I can’t seem to find the button where I can save my progress.”
“I believe the save button on the account screen should be moved to the top of the page.”
I’ve noticed that business people who aren’t on the product team frequently attempt to provide solutions before properly understanding the situation.
@MarcoSilva, It is the most optimum method. @DavidKim should consider it if the culture of his organization is open to it.
Systemizing this process is important, otherwise you lose these requests in emails and IMs .
Absolutely @MarcoSilva, getting the stakeholders to accept a Framework, any Framework!!LOL
In case of OP, the last PM, IMO did not spoil the stakeholders.
If you use that option for voting, is Trello costlier? We’re searching for a solution that will allow us to deliver future updates to feedback submitters so they can follow when their issue statuses change.
I am aware of their use case and the alleged business benefits they believe it will provide. The problem is that the team must perform manual effort to fulfil it, adding neither value to the product nor to other users.
To put things in perspective, I work on recommendation systems as a data/ML PM. Here is an illustration of an everyday request. Our data engineer works with millions of rows of data to clean and label these customers with an identifier, which the stakeholder uses for their marketing campaign to target only those particular users. A stakeholder has an idea for a marketing campaign to sell a new headset to gamers. They come to me and ask me to identify the customers who don’t own that headset and like gaming.
They launch the campaign for their channel and because of their targeting rules it only went to 2000 people. The engagement is low and then I’m told my product sucks lol.
In reality, they think this is the ideal target audience instead of letting the data determine who to recommend the product for. I’m trying to move away from this and improve the actual recommendation system so it is not so rule based. We’re also planning to build a tool for these stakeholders to label their own users if they continue to want to use a rule based recommendation system instead.
Everything you’re doing is correct. To transform their vision and strategy into a product is your main goal. Don’t say it out, but they are accountable for its success or failure, not you (they like to hear this).
There are steps you may take to alter their behaviors, but it’s challenging to offer advice because every circumstance is unique. You might think about the following: a. The initial product plan should be repeated every week or until all stakeholders are on board. b. Check and approve any changes to the scope or new concepts with the executive/sponsor c. Make time to calculate the revenue lost due to scope changes in flight.
As a data PM, I suddenly felt queasy from familiarity.
Your team must believe they can create an abstracted product-user score (ie using matrix factorization).
Assume you’re in the wrong going in but be ready to prove it. Rerun your most recent unsuccessful campaign using only the real users who were targeted for it using this revised model. You should receive a great ROC demonstrating your new model performs poorly for the majority of people and well for the minority who did purchase. Present this continuously; in fact, at every meeting you attend, regardless of the subject, you bring it up with slides.
The next time sales comes to you, show them this and add "We believe we have something that will improve your outcomes. Do you mind if we conduct a split test? We’ll divide the users equally between this new model and your approach ". If there is pushback, reduce the ratio to 75/25 or 90/10 and simply say okay. Your sales staff will get inspired to change from bothersome stakeholders to ardent advocates if your system really is superior and outperforms competitors.
“Thanks for the suggestion. We’ll add it to our backlog, and prioritize it as we hear from other customers.”
I feel like my stakeholders are catching on that, this means basically “no go away”, when I saw this now.
I hate that way of communicating with stakeholders
I agree, but OP made it seem like the stakeholders were unreasonable. If that’s the case, it’s best not to engage more than necessary. If the stakeholders are constructive, and willing to invest in the long-term health of the product, then it’s a different conversation.
Personally, I dislike using the “backlog” as a backup. If you just throw things in whenever someone has an idea, managing overtime gets pretty bad.
I believe it is worthwhile to have a dialogue with someone if they are putting forth a concept that they feel is significant but doesn’t fit with the product strategy in order to understand where they are coming from and why they believe it is so.
If necessary, describe how it conflicts with the present plan and priorities in order to prevent further instances.
Improve your EQ and foster communication.
To put it another way, gently pinch the bud. Don’t make it a problem for them or for you in the future.
The other day, I told my accounts team up front that I would be lying if I ever told a client that anything was “in the backlog” when it wasn’t. So that we may continue, I simply want them to stop. Do not ask me to provide updates. Never discuss it with them again unless I do. If they inquire about updates, apologize and explain that “important projects have taken the team’s attention.”
I’ve found it helpful to encourage them to run a lightweight test - using existing tools - to validate their idea / hypothesis. Empower them to prove that it’s something worth building. If they do, everyone wins. If not, you can stay focused on building!
@RobMartin, if they don’t have access or the know how to leverage the existing tooling required to test out hypothesis, are there other options you’ve recommended?
I work with semi to non technical stakeholders who don’t have the time to mess with tools they aren’t in everyday.
Or is this more of a deterrent?
Politely decline and explain why it is incompatible with the objectives. Ask them to prove the business case if they’re insistent. While they’re at it, prove ROI for the mentioned feature. Basically, I’ll entertain the concept if you can show me that your innovation will increase adoption and, consequently, income, at a considerable level, all while lowering churn.