Ground your feedback in evidence. Frame it as a hypothesis the PM can validate or challenge, rather than a directive.
Time your feedback strategically. The best moments are during early brainstorming and after the V1 release. Avoid flooding PMs with continuous feedback during development , it breaks their flow and creates unnecessary distractions.
Be consistent and transparent. Keep track of what you’ve said before. If you need to change your position, explain why. Contradicting yourself without explanation erodes trust.
Foster collaboration, not judgment. Your tone should communicate “we’re in this together,” not “you messed this up.”
Pick your battles. Not every issue needs addressing. Some minor details are better left alone rather than adding to an already overwhelmed PM’s cognitive load.
As far as possible criticise privately, praise publicly. This simple practice does wonders for morale.
Remember you’re speculating too. Yes, you might have more context and experience, but you’re still making educated guesses about what’s best. Don’t push too hard on any single point. At the end of the day, the PM owns the product’s success or failure , let them make the borderline calls.
Siddharth Saoji