Product managers are often called on to do a lot without a lot of resources as a way to prove they deserve to get the needed resources. But in larger organizations, it’s about keeping everyone pointed at the same goal and making sure everyone understands the context of what they are trying to achieve.
Her personal style is not telling people how to do what they need to do but to make sure everyone understands the outcome trying to be reached. She believes that is the key role of a product manager and what differentiates that position from everyone else in a leadership role in the organization.
My next question was about efficiency or empathy: is one more important depending on someone’s position? She disagrees with the idea that empathy is on the opposite side of efficiency because a developer has to make a thousand minute decisions about how to build what they are trying to build.
So if we start at the beginning to give the context that the developer needs to understand more clearly what we are trying to achieve and who we are trying to achieve it for very often the answers become obvious to that expert developer. She is referring to lower level decisions in this respect, not that all questions and decisions become obvious.
I asked if she means she wants her teams to have what the customer would want in those daily decisions which aren’t visible at the statement of work level. Jessica says yes, they’ve tried in the past to do huge specifications that got every level of detail and they found it just doesn’t work. So agile is partly about giving that kind of context (knowing what the customer would want) to the developers and letting them do their work with that context in mind.
Then we dive into what makes a good PM and some of the mistakes she has witnessed junior PMs make and how others can avoid them. Jessica explains why the common idea that the product manager is really the CEO of the product actually causes a lot of problems. She thinks it’s straight up wrong because the essence of product management is influence without authority. She says PMs are like the reverse Spiderman: with great responsibility comes no power!
She sees relationships sour when PMs think people should do what they ask because the PM believes they are responsible for the launch of the product. It just doesn’t work that way: engineers are experts at what they are experts at. So trying to tell people to do things a certain way just because you said so just doesn’t work.
It’s not how people are wired so if a PM does this (typically a junior PM) then it won’t work and will negatively impact the relationships that PM has.
This negative impact has a way of showing up as timeline issues, so when talking about the responsibilities of a PM she really buy into the idea that a PM is responsible for what needs to be built and the engineering team must be responsible for the estimate of how it takes to make it.
That means if a CTO or head of engineering comes to her and says this is the timeline for what you’ve asked for she doesn’t get to say build the same thing faster. All she gets to do is decide on the priorities. Engineers get total control over the timeline and estimation and the product managers get to then prioritize what can be done within that time frame.
We also discuss why an engineering-led organization doesn’t always work nor does a sales-led organization, and what does instead, and why CTOs or CEOs are often product managers without realizing it. We wrap up by talking about which teams she likes working with the most, why it’s good to be wrong, and her love of sailing.