For the first three years of my product career, I worked on nine product teams at three very different companies.
My average tenure per team was four months. Every time I changed roles, I had to quickly learn how this new team functioned and, most importantly, how it defined success. On one team, my top priority was doing whatever it took to raise revenue per session. On another team, my top priority was executing the roadmap handed to me by leadership and not missing a single deadline. Once, I worked on a product team that, I would later learn, leadership didn’t even know existed.
As I churned, rotated, and lept from team to team, I grappled with the question: How do I know I’m doing this job well? I searched for fundamental principles that could apply to any product team. After months of pouring through books, podcasts and blogs, I still couldn’t find the answer I was looking for. Instead, I developed my own.
Here are my three guiding rules that hold true on every team I’ve worked on.
3 Rules for Product Managers
- Be a problem solver.
- Build connections.
- Say no, then say yes.
1. Be a Problem Solver
You’re here to solve your user’s most important challenges by bringing the best solution to life.
There’s an old product management adage: “Your customer doesn’t want a drill. They want a hole.” Put another way, your users “hire” your product to complete a job. It doesn’t matter if you’re building drills, complex SaaS offerings or a vendor management platform that only your four-person operations team will use. If you’re not building something that solves a real problem, you become nothing but the background noise your user tunes out while they search for the right solution.
Several years ago, I worked at a company that was building a voice-activated smart device that could reorder office supplies on command. Leadership poured money into specialized data scientists, industrial designers and hardware and software product managers to bring a device to market that would compete against Amazon’s Alexa. About a year later, the company scrapped the project and laid off most of the team.
I never got the exact details of this decision, but it was pretty clear to those of us remaining that there was just no market for this product. What problem was it supposed to be solving? Who was going to spend the money on a device with such limited capabilities when they could buy an Amazon Alexa or Google Home? This taught me to always make sure that I am building solutions to my user’s actual problems — not chasing ideas that just sound cool.
2. Build Connections
Invest in your relationships with the engineers and designers on your team.
I once worked with a product manager who always opted out of his team lunches. When I asked him why, he matter-of-factly said, “I’m not going to get promoted by hanging out with the engineers.” He also skipped standups because, he said, “That’s when the engineers talk about tech stuff, and they don’t need me there.” He invested in his relationships with business stakeholders, committed his team to unrealistic deadlines and emailed the engineers requirements as they came up. The result? Stakeholders loved working with him, but his engineers and designers didn’t trust him.
I think about this guy a lot. There are a lot of PMs who believe their job is to throw business requirements “over the wall” to engineering and let them handle the rest. In my experience, those PMs are the least effective and successful at executing solutions to their users’ problems because they separate themselves from the people who are actually building the experience.
As a product manager, it’s my job to collect user problems, prioritize them by severity and impact, then bring them to the real experts (business stakeholders, designers and engineers) to brainstorm the best solution. Sometimes, the best solutions come from open discussions where our diverse team throws out lots of ideas, and we challenge each other until we find the best one. From my experience, teams that operate this way operate faster and more effectively than siloed and divided teams.
3. Say No, Then Say Yes
In my first week as a product manager, I accompanied another PM to a stakeholder meeting. The stakeholders walked him through a long list of requests and ideas for the upcoming quarter.
He stayed quiet and took notes for most of the meeting, except to ask a few clarifying questions. At the end, he thanked the stakeholders for their time and said he would get back to them. I was surprised, because some of the requests seemed small and reasonable. Why not agree to them in the room? When I asked him about it, he said, “It’s our job to say no, then say yes.”
It took me a few years to understand what he meant, but now it’s a rule that I live by, too. I’ve worked on some teams where my stakeholder request list included more than 50 items! That doesn’t even include tech debt, bug fixes or product-driven feature improvements. I would love to be able to say yes to everything, but we have a responsibility to our users to vet all ideas and prioritize the right things to build.
The Takeaway
The first few years of my product career were a whirlwind of changing products, priorities and teams. At the time, I found it pretty stressful to deal with the constant context-switching and insecurity that came with being the new person.
Now, I’m grateful to have had the opportunity to learn from everyone I worked with. I know that no matter what product or company I work for in the future, I can rely on these three fundamental rules to be a great product manager.
