November 2024
The job of a PM One of the best things about being a PM at Datadog is the incredibly high level of autonomy and trust that is offered to me. This is something I may treasure more than others, perhaps because I’m young. I joined Datadog at 22, fresh out of college without much formal professional experience outside of a few internships. I feel especially lucky that I’ve really enjoyed my experience so far — I’ve expanded my technical and domain expertise, gained exposure to the many moving parts of the product development lifecycle, and worked with great teammates who taught me things and trusted me, simply because they could.
One of the ways I’ve grown the most here is through the countless number of customer conversations I’ve had. They say that a core function of the “product manager” is speaking with customers to understand their problems and working with eng/design to come up with solutions to those problems. This statement isn’t difficult to understand at face value nor disagree with, but tends to be watered down to a paraphrase of “the PM’s job is to talk to customers.” I think this is an oversimplification, as meeting with customers so often has forced me to discover that there is actually an incredibly high amount of nuance in navigating a conversation with a customer and understanding the problem(s) they need solved.
When I hop on a call with a customer, I can treat it as time spent to fill out a checklist: know what they do, why they’re here today, ask them what they want, probably show them what we have to see if it is what they want, and then figure out next steps. It’s quite easy to go through a checklist, and it will probably work — the customer will answer my questions, and when I go back to my team and say “I met with this customer, they have problem A and requested features B and C”, they might take my word for it.
The problem I’ve found is that this almost always doesn’t actually get me to the truth about where customers find value. How do they actually think about their problems? Are they as important to solve as I assume? Am I even asking the right things? Is there something else in the picture that I’m missing? A checklist-type approach is almost an automated proxy to finding the truth about where the customer finds value, the truth that will serve as the foundation for insightful decision-making by the product manager. Because there are inherent differences in every customer, relying on the proxy will never be as good as directly seeking the truth with a myriad of levers we have as PMs (tailored questioning, in-person meetings, and some level of emotional intelligence, not to mention the quantitative usage data we have). When we start to think about understanding customer problems in this way, we suddenly go from arguably lazy “product management” to an art that is actually quite difficult to master.
Why is it hard? There are many reasons why it’s difficult to master, but a big one is that people don’t want to get hurt. Customers don’t want to hurt you, so they say things nicely or conveniently leave out parts of their answers that they think will be hurtful. You don’t want to be hurt by customers, so you make assumptions and only ask questions for which you’re comfortable with the range of potential answers. The fact that people generally don’t want to get hurt makes it harder to find the truth. (This isn’t original thought — see The Mom Test).
This same “art” doesn’t just apply to customer conversations – it also applies when PMs work with internal teams. Engineering, design, marketing, and other stakeholders have ideas, and they don’t want to feel hurt when these ideas are not validated by the truth. Accepting unvalidated ideas and looking the other way results in no hurt feelings. I think this is why meetings happen with no clear agendas, and entire projects that end up leading to unsatisfying results are planned and executed upon.
A person who can take a step back and ask, “what are we here for? What’s the goal again?” and be a truth-seeker is very valuable, because the fact that they are asking means that they aren’t afraid to hurt people in service of arriving at the truth. This person doesn’t have to be a PM, but if no one does it, the product manager has a duty to do it. It’s hard – it’s much easier to go with the flow and assume that someone else is taking on the truth-seeking (which often comes with people-hurting to some extent). (This is why it’s cool to work with someone who can do the truth-seeking and the people-hurting without anyone involved feeling like they were hurt. It feels like next-level PMing.)
Working on early products Getting to the truth is important (in general), but in the context of building products, it’s probably especially important for early products where there are so many unknowns and much less is proven. You’re only starting to build up heuristics for what resonates, and you have less customer data to go off of. Using a checklist and going through the motions is not an option if you want to succeed.
I’m not very good at finding the truth, but I think I’ve gotten better. The times when it’s easier for me are when the people I’m working with are open to truth-seeking. I’ve really enjoyed working with my current design and engineering counterparts because of this – we place trust in each other, check each other by asking questions to make sure we’re doing right by the product, and push each other to have higher levels of clarity. I think this open-mindedness from the team is an example of what being low ego means — being in the habit of putting our own ideas and opinions beneath ourselves, testing and iterating despite the possibility of getting hurt, and seeing what resonates.
On the flip side, I’ve enjoyed the job less when truth-seeking is met with resistance. It can be so easy to prioritize not wanting to get hurt (or hurting others) over truth-seeking that it’s often subconscious, and it shows up in the smallest day-to-day interactions and decisions. For example, in a design review, it can be easy to think something like “this type of persona wants this, because they’re responsible for y” [1]. When discussing requirements for the next iteration of a feature, it can be easy to say, “this part of the feature has been around for so long and some people are using it, thus it must be valuable.” As a teammate, it’s much easier to agree with these remarks and move on, because they generally make sense at face value, and if you don’t question them, no one will be hurt. But when small remarks like these go unquestioned, they compile and become the basis for designs (that are then referenced by other products as accepted precedent), product functionality, and ultimately make up something that may not actually be valuable enough for customers. Death by a thousand paper cuts.
In recent months, I’ve had to remind myself more and more that very few things matter. I think truth-seeking is one of them. (Having focus is another – the two are quite related.) I’m extremely grateful for the culture Datadog has built around serving customer needs, as this empowers PMs like me to stare into the abyss to find the truth, as well as have conviction that this is the right thing to do.
[1] The “persona x definitely wants y” example especially irks me, because oftentimes these statements stem from a basis of industry knowledge and experience. “I’ve worked in this space for a long time, so I know these users.” I don’t doubt industry expertise is incredibly valuable as an input to great decision-making; I’ve seen the kind of unique insights someone who really knows their user brings to the table – sometimes they’re able to see around the corner. However, I think industry expertise can be a trap when it’s used as a proxy for truth-seeking. Even if we’ve worked in the exact same industry on the exact same type of product, the combination of our current customers, market, and company goals is still unique. Thus, there are unknowns, and what we build should be tested against these unknowns. (Of course, my thoughts are informed by my own bias as someone who doesn’t have many years of expertise. I may be very wrong.)