So broadly speaking I think the same is true from a leadership perspective and PMs need to be leaders. If you want to be a great PM, learn how to give those around you open fields. Each time they make a mistake or are given the space to figure out solutions on their own, they get better. Your team consequently gets better. The goal is to end up with individual contributors that have the sort of discretion and decision-making ability that you would hope a great PM has. You’re team is in really good shape if you get to that point.
Never force yourself upon all parts of decision-making. Never make the mistake of disallowing others to learn by making the decisions on their own.
Rearranging Deck Chairs on the Titanic
Today’s product managers live in a world where data-based decision making isn’t just smart, but it’s hip. Everyone in the company has access to Google Analytics. It’s very easy for anyone in the company to be negative about any decision a product manager makes — either by finding fault in it early on or questioning the data upon which it’s based — and A/B testing and optimization are king.
However, there are some times when doing the safe thing is wrong. It’s easy to A/B/N test your pages to infinity, but you are destined to find the local maximum. Losing site of the long-term, big picture goals and just optimizing what you have means you’ll never try anything radical. Someone else without the sunk costs of your existing platform will, and you’ll be out of luck.
The deck will look great but the ship will have sunk.
Controlled Flight into Terrain
Possibly one of the more fascinating occurrences in air travel, controlled flight into terrain is essentially when a perfectly good pilot takes a perfectly good airplane and flies it into the ground because he or she is unaware of his or her surroundings (http://en.wikipedia.org/wiki/Con…). If you’re a product manager, don’t do this with the development team.
Roadmaps are extremely powerful communication tools. A clear and well-communicated and supported roadmap can lead to massive output improvements. But, in a similar vein to what I talked about above, it can also be a crutch to rely on the status quo when more aggressive decision making is required. Don’t be afraid to change organizational structures and focus, even if it means you’ll need to create a brand new pretty roadmap and backlog from scratch.
When things go wrong, it’s tempting to point figures in either direction out from the product team: the marketing team, biz dev team, content team, QA team, or the engineering team. In reality, there will always be an infinite number of external and internal factors out of your control. Take responsibility for all of them.