Andrew Clark

Here's one that I don't think gets enough love: humility. Product people are very smart*, and it takes a lot of confidence to say no to a series of good ideas just so you can get to a great one. Very smart, confident people aren't always the most humble. Humility, though, is a key trait as a PM or Product leader. Product work is inexact, and big misses happen. A PMs ability to recognize their missteps early, acknowledge them with the team, and set things on the right course will save time, bandwidth, and a lot of team pain. I've seen PMs that have their teams banging their head against the wall on the wrong problem or solution just because it was their idea. Humble PMs are more effective and better at driving alignment, and humility is one of the easier soft skills to screen for in the interview process. This is a must-have for me. *usually, anyway

I flinched at the word "approval" here. I don't like the idea that Product would be seeking roadmap approval from other departments in the org. What you really want is buy-in. You want your key stakeholders to be as confident and excited about the roadmap as you are. Here's how to make that happen: 1) Provide channel(s) for continuous input and take that input seriously. Stakeholders will make sure their teams to provide good input so long as they see how that input influences the roadmap. You may have to connect the dots for them. 2) Over-communicate roadmap strategy and the why behind it. Do this all the time. Product priority can often seem random to others in the org, regular reminders about what you're aiming at can help. 3) Shop the roadmap around to key stakeholders on an individual basis, and speak their language when you do it. This is typically a quarterly exercise, done before decisions are final. You want it to be clear that they have genuine influence during this stage, but you/team are still making the final decisions. Speaking their language means talking about things they care about—most don't care too much about your prioritization process/formula/etc, they just want to know how what you're doing will impact their team's success and the business overall. Usually in that order. : ) 4) Build trust by delivering on your claims. This one can be tricky! When you get good at estimating impact, you can go back to your stakeholders and say "See? The process works." Depending on your team's maturity, this may be broad and somewhat vague or very specific to the direct impact your releases had. You want to always move toward the latter. If you can do those things consistently, you won't be asking stakeholders for approval, you'll be regularly collaborating with them on the best way to move the product and the business forward.

I've tried to drive a writing culture in every team I've been on—with varying degrees of success. I don't think there's a more effective way to drive alignment, especially for remote teams. I'm a big fan of providing pre-reads for meetings, so that everyone comes in to the meeting with the same context. Meetings are slow when each person involved is figuring out what the meeting is truly about at a different pace. Anchoring around a written document helps keep everyone focued. Writing tends to spur more discussion, too. If a detail is left out in a verbal discussion, it can seem like an oversight. If it's left out of a written doc, people take notice. Admittedly, this is diffcult to practice consistently. It requires more up-front time, and it forces you to commit to an expression of an idea because it's right there on the page. I still don't do it as often as I should, and I've seen firsthand how valuable it can be.

This one is interesting. If your goals are truly inversely correlated, I'd say there is something wrong with the top-line goals. That would suggest misalignment or lack of clarity higher in the org. If it's more a case of mismatch in focus—say, your primary goals are around customer retention, and you're collaborating with stakeholders from sales—you want to optimize around lowest-effort, highest-impact projects for that team. You're going to spend the majority of your time and resources on current customers, but you want to partner with sales to understand what those low-effort, high-impact projects might look like. Funnily enough, identifying small efforts like these typically requires more collaboration up front than the big ones do, but they allow you to support your stakeholders while putting the majority of your team's resources toward your primary goals.

Yes and no. I think of these relationships in terms layers of depth. Design and Engineering are, of course, your deepest stakeholder relationships. You're building a product together, so the dynamic is fundamentally different. Customer Success (and Support) should be the next layer. They should generally have a better understanding of the product than your go-to-market stakehodlers, and the time they spend with customers usually leads to more specific insights. This relationship can and should be more collaborative than the next layer. Sales and Marketing are the next layer, as their input is typically based on pattern recognition. Incredibly important, but often not as deep as the other layers. You also need to nurture this group differently, and be intentional about demonstrating your impact, because they can often be the loudest when they don't feel they're being supported.