Don’t Believe This Myth about a PM’s Day 1 Duties

Image by DALL-E at OpenAI

There’s a lot of advice about how a new PM should spend their first days on the job. Not all of it is sound. Don’t believe this myth about what PMs should be doing on Day 1.

I recently just celebrated the successful completion of the “First 90 Days” of my job at Persefoni. For every product job I’ve had, I’ve found that the first 90 days are the most important. If you speak to other veteran PMs, they’ll probably echo my thoughts on that.

For a function in which credibility is currency, failing the first 90 days can spell catastrophe for a PM’s long-term prospects at a company. Fortunately as an eager practitioner, I found reams of literature published by many brilliant product thinkers expounding upon how new PMs should best approach this phase (see Anthony Murphy’s blog on this, by the way, is my favorite). However, reflecting back now on the dozen or so pieces I read, I realize that many of them propagate some bad advice in answering this one oft-asked question from new PMs.

When do I start talking to customers?

There’s a cohort of product bloggers that suggest that new PMs should start talking to customers on Day 1. I see where this thinking comes from: when I first started managing enterprise software products — and I was directed less by practice and more by customer-first product management theories like design thinking, lean software development, and continuous discovery — I used to think the same thing. Now, I know better.

Talking to customers too soon in enterprise software is reckless. Enterprise software PMs play an indispensable role in the customer journey. Enterprise software buyers don’t just purchase a bundle of features: they also are buying into the team — specifically, the product team. The product team delivers the roadmap, prioritizes feedback, and offers technical expertise, among other things that are paramount to a customer’s long-term success. Good enterprise software sales teams know wary customer teams will want to be assured that they’ll have access to the product teams. That’s why account executives bring in PMs to close an anxious prospect, and renewal managers bring in PMs to smooth over shaken trust.

Talking to customers before you’re a product expert can erode their confidence. If you have “product manager” in your title and you show up to an enterprise customer conversation, they’ll expect you to answer questions about product features, technical capabilities, and the roadmap. If you can’t, they’ll think your company’s product team is weak. That’s bad for the business. Saying that you’re new and you set up the call hoping to develop customer empathy won’t absolve you. Put the needs of your customers and the business above your own onboarding!

I’m not suggesting new enterprise software PMs are relinquished from the responsibility of empathy-building. Quite the opposite: developing customer empathy in the first days is absolutely mission-critical. I suggest new PMs use arrows in the quiver other than customer interviews. For example, when I started at Google, I filled my calendar with customer learning during the first 30 days without ever leading a single customer needfinding call.

How do I develop customer empathy in my first days?

Here are the 5 top ways I’ve developed customer understanding during my first days as a PM:

1. Use the product. I like to create an account, read the support documentation, and write a friction log in the first week. It boggles my mind how many PMs don’t do this. I like to call this immersive needfinding.
2. Read feedback boards. If your company hosts a product feedback board like UserVoice, I’ll venture to guess that there are some strong, honest opinions from vocal customers you should tune in to. If not, try scouring other sources like social media, Reddit, or Hacker News.
3. Talk to sales and customer support. These field teams hole up at the front lines and almost always absorb product feedback first before even PMs do. I like to practice journalism’s maxim of “gather multiple sources” when it comes to feedback from sales and support. Use their insights as a launching point for further investigation.
4. Review user research. If your company is savvy enough to have a user research team, read their stuff. User research reports are almost always chalk-full of compelling quotes and insights. I also check to see if the original user interviews were transcribed too.
5. Shadow other PMs. I’d ask to tag along with my manager to shadow his customer calls. If you aren’t the founding product hire, this is a safe way to learn what customers are asking about, without risking your department’s credibility.

When are you ready to start talking to customers?

Now we’re back to the original question. Here are the boxes I make sure I have checked before I lead my first conversation with a customer:

• Product expertise. Can I demo the product and answer the first line of questions? Do I know my product better than the sales team does?
• Customer understanding. Can I map out the customer segments and product users? Can I tell a customer story that clearly articulates their needs and how our offering met them.
• Competitive positioning. Do I know the competitive battlecard? Can I explain who our competitors are and why we win? Can I address the main competitive gaps in our offering?
• Technical architecture expertise. Can I walk through our system architecture and explain how the components work? Can I answer the first line of technical questions to come from an engineer on the customer team?

If you are determined, you’ll have all the boxes checked and be ready to talk to customers by day 30–60. Armed with product expertise and a solid foundation of customer understanding, you’ll be poised to begin those customer interviews and still help your sales team win.