What things should a product manager do in the first 30 days on the job?


6 Replies

My first 30 days as the PM for a product are spent learning the product (assuming it is an existing product) and talking to customers and users of the product.

If I'm hired to build a new product, I spend the first 30 days focused on understanding why the product should be built, who will use it, how they will want to use it, how we can sell it, and what the competitive and market landscapes look like. I'll get in front of potential customers and ask questions that will confirm or deny the validity of the product idea. The most important thing to do is find out quickly whether you should build the product you were hired to build or, as difficult as it may be, tell whoever hired you why you think you shouldn't build it (and I'd find an alternative, if possible).

A couple of additional points aside from those you and Deirdre mention relating to understanding the wider influences on product decision making.

Try to find the 'skeletons in the closet' as well. Products will often have some hidden technical debt or invisible constraints which affect decision making when building features. Speak to the experienced engineers/customer support people or investigate past developments to try and uncover them.

Also different teams also have varying inputs into strategy. What are the outside influences into the PM decision making? Do other areas of the business have inputs to strategy (eg Sales)? Will you have pressures to include 'special' features for Customers/Projects in releases?

My answer is one word - listen. Meet with all of your stakeholders both inside and outside of the company. This includes setting up meetings with all of the different teams within your organization that work on or with your product. It also includes scheduling meetings with your customers too. Find out: 1) how is your product helping them 2) what things do they think could make it better and 3) what are they struggling with.

Those first 30 days are all about getting a good lay of the land to level set where you are. Then after you have that information, you can figure out how best to go forward.

During your first 30 days, you're a detective--try to discover the state of the product and the health of your team. What business documents can you find from your predecessor? What do the execs and sales people and clients think you're working on? What is your team actually working on?

I like to start with the product team, asking "Where do you need my help?" I've heard "get management to understand" and "tell sales to stop bothering us" and most often, "We need to know about the market, the personas, and their problems. We don't need to know what features you want--we'll take care of that."

You want to spend some time with your sales and support teams but beware: sales and support teams don't really listen to learn; they listen to solve or sell. Set up some appointments with real customers to get the unvarnished truth. Phone calls are fine; onsite face-to-face observations are better.

I've written more about Your First Days as Product Manager at https://www.under10playbook.com/articles/first-days-pm

One approach could be to...

  • spend a few days with the product, relatively alone, as if you were a brand new user who was just sold the product, sight unseen, to get a sense of what its like to 'activate' the product using its default stance along with any materials your company has made available as 'getting started' material
  • spend a few days with the customer success/support team, to get a sense of what types of issues 'real world' users of the product are having (these might represent some first efforts with which to prioritize so as an aid in improving CAS and NPS)
  • spend a few days with the sales team, to get a sense of areas where the product 'sells itself,' or where it has a clear, and possibly not-previously-marketed, advantage (these might represent some efforts with which to prioritize as an ad campaign, or updated sales materials)
  • spend a few days with the development team, to get a better understanding of what's under the hood, so to speak, and begin to develop a shared vocabulary with them
  • near the end of the 30 days, spend some time assembling this information into a set of high level themes and begin tying them to the existing roadmap