As a PM, what was the best piece of advice you received early in your PM career?
If you don’t truly understand the problem, you haven’t earned the right to solve it.
Aka talk to your customers and build real empathy plus vetted data.
@PriyaVarma, couldn’t agree more. Don’t just build features because it looks cool. Customers may never even open that feature.
Always ask yourself if this is the best use of your time
@JoelSchulman, 16 months into my PM career and I am consistently asking my manager/mentor (who’s been in PM 12 years) this question because of how reactive they are vs proactive prior to testing, troubleshooting, meetings, etc.
Don’t limit your view of product to just technology. The e2e life cycle of the product is important, understand it, optimize it, and help as many people as possible along the way to achieving this.
Solve problems for people, be approachable and build up the social capital so you can call in favors as PM.
Spend as much time as possible with customers. This bypasses the bullshit filter.
Don’t forget the financial performance of your portfolio. Stay close to the P&L.
You are not perfect. You are going to spoil things up. Try your best, you are only human, don’t stress and keep moving. Be humble, kind, determined, and aim high.
You’ll smash it. Good luck.
Is social capital the right word for this context?
@Ahmad, Yes. Never too soon to start building it up, and you ignore the need for it as a new PM at your peril.
How does one build social capital? Does social capital just mean being liked by engineers and other coworkers? Or like from a u scratch my back I scratch yours perspective?
Hard to day which is most important, so I’ll let you decide:
- Become a true expert on your product, users and market by talking to customers (a lot) and using the product and competitor products (a lot).
- Really understand the underlying customer problem beneath the feature request. Find out what they do and look at how you could improve that, rather than what they want (faster horses and rocket ships)
- Try to perform at one or ideally two levels above you. That makes promotion conversations much easier.
- Don’t tell people what to do. Challenge your triad by setting a goalpost and make it clear what you are optimizing for while being open minded about what that might look like.
- Build relationships across the business and learn how to manage expectations and align, especially with leadership.
@NathanEndicott, Could you explain more about the social aspects here?
You mention not telling people what to do but “challenging your triad by setting by goals”?
You basically set a goal, “ok guys I’m going to do this” - but if everyone else has their own priorities etc. and decides to just ignore you how do you go about getting them onboard?
Also, with company culture, how do you deal with the disrespectful assholes on the team who you made need help from, but also don’t want to allow yourself to be disrespected?
These are not issues I’m facing personally but I’ve seen them, and may run into them I am sure someday. My company culture I’ve noticed upper management regularly yell (sometimes with profanity). Heard someone dropping F bombs across the floor at 08:30 recently.
“Taking the high road” sounds nice, but allowing someone to walk over you instead of professionally giving it back doesn’t seem like a good long term plan. However, neither does enraging them and creating more barriers by firing back (they won’t help you)
It seems the only solution is to, for example, take a rude or disrespectful assholes behavior for the time being, for the purpose of using them to get your way, or get your goals achieved (which is frustrating but also seems kind of sociopathic)
@MarcoSilva, Awesome questions, this could really be a whοle book and I wouldn’t be the best person to write it. From what you’ve said, there are two different challenges here. One is aligning leadership and stakeholders and the other is aligning your immediate triad (engineers, designers and anyone else in the immediate team).
When I work with a team, I try to provide context and define the goalposts with the various team members. The goal is to find people who are talented and can drive things themselves and sharing discovery with them so they get it. That means getting them involved in customer interviews and providing clear requirements that say what the solution should do but not how it should do it. Designers get free reign to design whatever experience they want and engineers get to pull them back down to Earth based on what is actually possible. Difficult people can be difficult but if you know whom to empower, they can then drive things for you.
Aligning sales, marketing and leadership can be hard. A lot of it is having relationships with them, knowing how to drive influence (whom do you need to convince to get enough buy in to have an official meeting etc) and being very clear on their perspectives. If they are super focused on acquisition and you have a customer satisfaction initiative, they will always push back. So, having your buddy in their team that you can talk to off the record is super important. It’s basically about coalition building and making sure you are proposing mutual wins, rather than something that is good for the company but will negatively affect their OKRs.
The first challenge is hard but way easier than the second one. But most PMs start with the first problem (and elements of the second).
But that’s the job of the PM. You get everyone excited about the customer problem and show that you and your team will solve it.
Does this help? Just speaking to my experience and acknowledging that some companies just aren’t compatible with product but even when the conditions are good, the work is hard. That’s why they hire us, right?
Hi @MarcoSilva. One part of your post I’m particularly interested in is “if everyone else has their own priorities etc. and decides to just ignore you how do you go about getting them onboard?” For me, what is most vital here is the distinction between output (we are building feature X) and outcome (let’s reduce onboarding time by 50% this quarter). The former is a challenge and often not the best way to go. In defining the output, you are already removing agency from the designers and engineers. Trying to rally a team of designers and engineers around the exact output is usually demotivating for them and can crash productivity and lead to time wasting debates, especially if you’re not the highest-ranking product person in the org. When an outcome is defined that clearly maps to a key metric for the org (e.g., hypothesizing—based on extensive observation—that reducing onboarding time will enable you to increase retention rates, with retention rates being a business level KPI) the team(s) can rally around this outcome and work collaboratively on figuring out the best way to achieve it. From here, any debates are constructive, rather than destructive, and no one would accuse the PM of micro-managing the work of the designers and engineers. It also forces a different quality of discussion and planning. For example, the engineers must define a heuristic to rapidly test whether the feature(s) they’re building do indeed reduce onboarding time and the designers are incentivized to get closer to customers, to understand the existing bottlenecks in the onboarding journey. Inevitably, the result is better with an outcome-oriented approach, and no one is walking over anyone else.
@NaomiNwosu, This is a great comment. I learned a lot from your perspective, thank you.
One last question I’ll ask is, any recommendations to start quickly internalizing - “make sure to focus on defining outcomes, rather than outputs” as a matter of habit?
I am not a product manager yet, just a BA now, but I will try to start implementing this today!
@MarcoSilva, Thanks a lot! I’m really pleased you found it helpful. The way I internalize this is by focusing every single project on pushing a particular metric. This starts with the c-suite. For example: Are there clearly defined outcomes for the org in the current period (year or quarter)? Then what proxy metrics (that are more immediately measurable) map to these? We aren’t plucking outcomes out of thin air; we are looking for strategies that will impact the business level objectives and finding metrics to represent these.