Product Management in a new domain

Every product management job I’ve ever started has felt like entering a burning building. At many companies, there’s usually a developer who can pick up the slack from a departed developer. The same is often true in sales or support. But in product management, by its definition, there’s typically a single individual responsible for the products they manage. When starting a new role, I’ve either been replacing someone who was no longer with the company or creating a position that was missing to begin with.

This is a stressful enough situation as it is, but when you are brought in to the company as a “professional product manager” rather than as a domain expert, this is all the more difficult. With no experience in the new product or market, you’re being asked to make decisions based on anecdotes and opinions rather than research and data. And usually you’re being asked to make them in a hurry.

Having done this a couple times now, I have a couple tricks that I use in the first couple weeks of the new job that I hope are valuable to others.

  1. Find out the existing plan

However informal it is, there’s usually a plan in place. It may or may not be called a roadmap. It might just be a list of ideas or features. Worst case is it’s in someone’s head. But in whatever state it is in, find it, nail it to the wall, and get stakeholders to agree that it is the plan of record until you come up with a new one. If it’s not called the roadmap, call it the roadmap. A plan, even a bad plan, removes the immediate stress of “what are the developers going to do next.”

2. Determine how the plan benefits the business

Even if you know nothing about the domain you are entering, you can break down an existing roadmap to see how each item benefits the business along four different dimensions.

  • Acquisition — Does it help get new customers?
  • Expansion — Does it expand revenue from existing customers?
  • Retention — Does it prevent churn and help retain customers?
  • Cost — Does it reduce costs?

I like to force every item in the roadmap to have one of these as its primary objective in part because it begins to force a discipline of making choices (which often wasn’t happening before I got there). Once you have a map of roadmap items to business benefits you can see if the balance is right for the current state of the business. For example, if there’s no account manager role at the company, features to expand revenue won’t help with no one there to upsell it. If you’re roadmap is a long list of sales objections, but you can’t retain the customers you have, you might want to shore up your ship before adding new passengers.

3. Abstract the problems

Features on the roadmap are meant to be solutions to problems. But you have no idea how much discipline went into determining if it’s the right solution to the problem. It could be based on thoughtful consideration of user needs, or it could just be a “cool idea” that no one is sure who would use. By stepping back and identifying the problem each feature was intended to solve, you can start to reexamine whether the items on the roadmap are the right solutions or not. At the very least, it gives you the basis to begin your research into your new domain to find out if these are the right problems to solve for your target market.

These are all things that you can do in the first two weeks of starting a new job or inheriting a new product. You will have immediately provided value in your new role, provided clarity to stakeholders, and given yourself some breathing room to do user and market research.