3 things to avoid saying as a Product Manager
johnmicahreid.medium.comRegarding #3
Asking users how they were referred is by no means reliable. Many times we have kept that question in place even though we had strong tracking in place.
People tend to just select the first option in a dropdown or radio series or select an option that we can see is not their actual path. The solution offered in the example seems as if he thinks it's a legitimate replacement.
It is not.
Eerm sorry, either misunderstanding something, but the first point sounds like totally incompetent POing and classical overengineering (though here we have the PO wanting to show off, to overengineer is the engineer's job please!!) even before the realization that the CEO just wanted to share an idea?
I mean a simple "let hires watch a video about our product" is just about saving some repetitive time... who asked for a "video onboarding solution"? And let the full tech team work on that for two weeks, jeeez! Be happy noone else noticed that wasted time and fired you?
A motivated PO could do this on his own if he has a little bit knowledge and the right tools in his spare hours (at least ours could)...should be good enough just for new hires. Or maybe better delegate that to some marketing guy that maybe even already has video material and who is done within half a day??
Yep, guilty as charged and I look back on this experience and see a lot of things that could have been done differently. To clarify, the video idea was about new users of the product not internal hires, so the production quality would need to be higher. These days I'd probably whip up a Retool-style intro video using Loom + Wistia in a day or so.
I'm more suprised that a PM can up and change what a dev team is working on with such frivolity, especially one whos so green. Typically I'd rather get a commitment from a developer or development team, and expect them to ask why this random thing trumps what is being displaced.
I think more people in product positions or even leadership positions would really benefit from learning comedy improv. Even just the most basic ideas like "Yes, And" can go very far if you understand them in the sense of "accept the reality and add upon it".
Communication is really important, but it's not the end all be all for the job. It sounds like the author was "too busy" to communicate effectively and the lessons learned are what happens when you aren't listening, immediately shut down an idea, or tell someone to do something without knowing what you're after.
You live and learn. That's how you gain experience.
Well said - I'd say the hardest part of the job is balancing listening/gathering feedback, and maintaining a core vision for the product that's not just a wish-list of feature requests. There's a dark art of making someone feel listened to, without necessarily doing anything about it.
How about, "oh no! No! NO! NOOOOO! The goggles. They do nothing. It's out of control! Run for your lives!"