My 14 Pieces of Advice for new Product Managers

Last update: 2021.03.28

A few years back, I made the decision to leave my current role leading an internally-facing, strategy consultant and make the move to Product Management. I made that move for a bunch of reasons, and was so damn lucky to have the support of an unbelievably generous set of partners who enabled my success.

As part of my goal to pay it forward, I’m starting a brief series of articles about my transition #FromGM2PM.

So here are my14 rules for Product Management.

1. Everything — EVERYTHING — is a draft version of the next thing. Product Management, more than any job I’ve ever had, is all about iterating and learning. You want to develop thin, iterative slices of work, and you want to learn from each. Even this list here is a draft.
2. Product managers need to live at the intersection of Human Centered Design, Business Analysis and Technology so they can constantly assess Desirability, Viability, and Feasibility. Perhaps the biggest misconception I had about Product was that you have to be a strong coder. There are certainly roles where being more technical is helpful (more on that in a minute), but the main skill you need to have is the ability to synthesize these three, distinct information sets: Design, Analysis, Technology. Your ability to live in those three worlds simultaneously will govern your success.
3. There are two types of PMs in the world: those focused on front-end/customer facing products, and those focusing on platforms. Figure out which one you are, and optimize accordingly.
4. Features get all of the attention but platforms make money. This is especially true at big companies trying to rebrand themselves as tech companies. To succeed in Feature-land, you need to have a keen insight into consumer behavior, an environment supportive of iterative testing, and a bit of luck. To succeed in Platform-topia, you need to be willing to get deep into technology and architecture, a deep relationship with your tech leads… and a bit of luck.
5. Your number one responsibility is to know your end-user. My PM mentor always used to say this to me. More than anything else, your success as a PM will be governed by this factor. Note: it’s important to distinguish between who is using your product and who is paying for your product. Often, it’s not the same person, and that has critical implications.
6. Corollary to 5. Your Customer Service, and Distribution Partners (Marketing / Biz Dev, etc.) know your customer really well. They may be overly focused on wants vs. needs, but finding ways to engage them in ideation, feature definition and testing is hugely valuable.
7. Your number one job as a leader of product teams is to maintain your team’s (Product & Tech) enthusiasm.
8. Your number one asset is the trust of your developer team. Work hard to maintain that. Your job as a PM is to shepherd a $1.5M asset in the form of a dev team and reduce the risk of crappy software. You will never do that unless you cultivate the trust of your developer team. Work to understand their motivations, and encourage their transparency with you. The worst teams I’ve seen have been scared to admit mistakes, and were not empowered to say “there’s a better way of doing this.” Actively work to build a culture where the opposite is true.
9. Eat Food, not Snacks. Hunter Walk posted a great article about how to run successful product planning. TL;DR: Don’t focus on “filling up” your time with easy things. Focus on doing the hard things that support your long-term strategy. In the rush to make sure your team is fully utilized, this is very easy to overlook. Don’t make that mistake.
10. Business context is your number one most important ceremony. One of the best ways to maintain enthusiasm, and to develop trust is to aggressively share business context. Despite knowing way, way more about how to build a product than I do, my own teams had not had the opportunity to learn about business fundamentals (e.g. how our business makes money, who our customers are, what our marketing strategy is). Share this context often, and gauge your success on the engagement from your developer team.
11. Agile metrics are useless outside of your own team. Never compare teams. Agile metrics can be really useful at helping manage sprint commitments, bringing data to retros, and helping a single team improve. However, they are insidious when used to compare teams. Teams work differently due to team composition, areas of focus, nature of work, etc. so they will naturally have small differences in story pointing/estimation, working style, even ceremony structure. This means that comparisons of agile metrics are largely misguided across teams. In fact, the more you focus on this, the more you violate Principle 6 above. Comparisons will erode trust, and lead to secret keeping that will manifest itself eventually in burn out, attrition, or tech debt.
12. Product never works when led by top down management. It has to be inside out. The most effective management form I’ve seen over the last dozen years has been an inside-out approach. Ideas were created at the middle-management level, vetted by their analyst teams, and sold to executives. Product Management is no different. The people best capable of building product strategy are those closest to the product, and to the customer: the individual PMs on the teams, the designers/researchers talking to users, and the tech leads / developers who know where the tech debt lives. Corporate Agile implementations (e.g. SAFe) only work when executives are driving objectives and teams are driving the development agenda.
13. Don’t go forward unless you can go forward quickly (i.e. uncared for, tech debt will ultimately sink you). This is sort of a basic one, but tech debt needs to be tracked, and worried about. If you’re struggling to make progress, assess what investments are needed to enable your success. Maybe you need to refactor some code, train your developers, get better customer research. Whatever it is, invest in the solution intentionally so that you don’t just solve the symptom, you solve the problem and enable speed and stability in the future.
14. No hero worship. Comfortable delivery >>> A successful Hail Mary. Does this sound familar? An issue comes up with a huge release two days before it’s set to be deployed. Two developers work for a dozen hours to figure out what happened, and implement a last minute save. The release goes off without any further hitches. The next day, the senior E/M/X-VP sends a note out congratulating the two developers for their heroics, maybe buys them lunch, and everyone goes back to their jobs. Of course we want to show thanks to developers for going above and beyond. But this type of hero worship inevitably rewards mistakes and secret keeping. Worse, it ignores properly developed, well maintained software. Instead, the E/M/X-VP should listen in to the retro, figure out how we implement a fix to avoid the problem again, and then congratulate the entire team for learning from the issue. This isn’t about punishing mistakes. It’s about rewarding safe stewardship of software to the finish line.

That’s what I’ve learned (so far!) in Product. I’d love to connect here, on LinkedIn, or anytime you’re in DC to hear what principles you use to drive your product teams.