Ramping Up as Head of Product
How to manage your first 90 days
An acquaintance asked recently how I get a handle on product and build out the roadmap when I join a new company (he’s a CTO moving into a CPTO role). Here's my process, based on experience at B2B and enterprise scale-ups/start-ups:
Plan for a plan
Team interviews
Customer interviews
North star goals and key pillars
Roadmap
Start the drumbeat
Plan for a Plan
The first thing to do when starting as head of product, assuming there isn't an immediate emergency to deal with and assuming you have a team in place, is to lay out how you will do the investigations that will result in a roadmap. I find that stakeholders feel better when they understand what's coming and what the milestones are.
First, spend time with key stakeholders to understand goals, challenges and expectations. Then, lay out goals and set a tentative timeline so that stakeholders have something to orient towards in your periodic update meetings (which you should be having). The plan can change as you go along (as you will see in the example below), but just having something to track to helps a lot.
Here’s an example of an initial plan-for-a-plan timeline for an internal product:
In this particular case, after getting up to speed on the ongoing development and plan (which was very early-stage), I came up with a hypothesis (“straw man”) about what the go-forward plan might be based on what I had been told before joining. Then I spent what ended up being a couple of weeks doing in depth interviews with the team and internal customers of this proposed product to test and update my understanding and hypotheses.
Over time, I learned that the project had been under-scoped and I took a step back with the overall plan and re-did this timeline to add a deeper research process (it ended up being about 6 weeks longer than originally planned). It’s fine to make adjustments to the plan as you go - the main point is giving visibility to stakeholders so that they know what is happening and what you are learning.
This slide becomes the artifact that you review with stakeholders at weekly or bi-weekly status meetings to help everyone stay aligned about where you are in the process.
Team Interviews
Joining a new team is a great opportunity to listen, learn, and set the foundation for any potential adjustments in the future. Listening is key here. You want to understand:
What are people working on?
Why they are working on it?
What they think the company goals are (for tech and in general)?
How they think the work of the team moves those goals forward?
What processes are being followed in the team?
How decisions get made?
What friction is there in the planning and development processes?
How people feel about what they’re doing and how they’re doing it?
etc…
These interviews should span people from across the team - not just product. You need to understand the team and the ongoing work holistically. Assuming you have an engineering counterpart, this is also a great opportunity to start building trust in that key relationship by listening, asking good questions, understanding any challenges, and agreeing on how your individual and team interactions will work.
Also, I like to create artifacts as I do these interviews. If someone explains a process, I diagram it. If they tell me about a feature, I update the documentation if needed. This is a form of active listening that gives the team a sense that you are adding value from the get-go, and it does actually also add value.
Customer interviews
For external customer interviews, assuming you have some, I usually collaborate with sales and/or customer success to find appropriate customers. Do your research beforehand to understand the product, how it is used (using Hotjar or similar if available), the differentiators, how customer relationships work at your company, how delivery has been (do customers get what they are promised on time), etc. Also, it’s a good opportunity to start building relationships with the revenue teams and show how you engage with customers and the sales process.
For customers, this can be an opportunity to provide feedback and suggestions for the roadmap. Most customers appreciate meeting the person leading product and like to be involved in making the product they use better.
Be aware that, depending on how things have been going, you might meet annoyed people (for example, I once worked at a company where customers had been promised certain features for 2 years that were not even on the roadmap). Usually, there is a reason the company is hiring a new head of product, and you may find out more about why as you go through this process. Regardless, this is a good opportunity to listen and to come back to customers with a plan. It is obvious, but always under-promise and over-deliver to customers. If you can’t fix a problem and/or you don’t have timelines that you can stand behind, don’t promise. Be honest and knowledgeable (because you did your homework), and focus on building a good relationships. These initial interviews are probably with important and/or friendly customers, so they may be potential members for a customer council or people you will want feedback from in the future.
In terms of questions to ask, it will depend, but I like to understand why the customer chose this product, what they use it for, what other products they considered, how their experience has been, what feature requests they might have, what they know about the roadmap, what they like most/least, and what they’re looking forward to. It’s critical to understand what is top-of-mind about your company to customers and what they expect, both now and from past conversations with the team.
North Star and Pillars
A key part of my process for aligning stakeholders are teams is having a north star goal (usually for the year, but can be less if the project is newer) with execution pillars. Essentially team OKRs. I usually make one slide that captures this and then show it all the time.
Here’s an example for an early-stage machine learning cybersecurity product. In this case, our hypothesis was that getting to 25 customers was related to improving our adversary detection and the cycle time for our proof-of-value process for potential customers.
We put together the goals and then set up a system (with specific KPIs) to measure our progress. At our weekly team meeting for that 6-month period, we tracked these goals and ensured everyone on the team was working on something related to one of them. By the end of the period, we got to 22 of the desired 25 new customers.
This approach makes it a lot easier to get to the full roadmap (because everyone is already aligned at a high-level), and it is much better for alignment because people don’t have to keep all the details in their heads.
Roadmap
Once you’ve gotten agreement on what the team is targeting and how it relates to company goals, you’re ready to make the roadmap. There is tons of content on how to do this, so I won’t go into much detail here. I typically use Janna Bastow’s Now-Next-Later roadmap approach and avoid timelines if possible. If timelines are necessary (which they often still are), I bucket items into themes/pillars and stack rank - with a very clear focus the overall goals. I find that keeping attention on the north star goals and pillars, and ensuring all stakeholders essentially have these memorized, makes it possible to be more flexible at the feature level. When stakeholders know what goals are being achieved, they don’t worry as much about the exact set of features needed to make that happen.
Note, if the team is not already in place, I usually sketch out the goals and pillars and then a very high-level sketch of the features needed to achieve those goals (instead of a full roadmap). I use this to make a staffing plan and start hiring. A roadmap without a team is kind of pointless.
Starting the Drumbeat
Finally, once you have buy-in on the goals and roadmap, you’re ready to get the drumbeat going. In my view, this is the most critical step in actually turning the goals into reality. My target here is to ensure that 90+% of the team and all the key decision makers are able to answer questions about what the customer story is, what the goals are, how the goals will be achieved (at a high level), and, for the technical team, how the thing they are specifically working on maps to the goals for the team and company. I’ve found that if you can achieve this milestone, the right things just start to happen naturally because people are genuinely aligned.
To do this, I use KPI dashboards, posters, and repeated goal slides (one slide they see all the time for months - I usually show it at the beginning of all scrums and team meetings). Posters can focus on the team goals, personas, even operating principals (like the one at the top) - whatever needs to be top of mind to ensure the goals get achieved.
The main point is alignment. We are all doing this thing together and we’re 100% focused on making it happen. It goes without saying that an important part of your role as head of product is to manage up and ensure that the alignment holds at the management level, and that the team actually has enough time to realize the goal. If you keep things super clear and transparent, and you choose a company with solid/experienced management, this is usually possible.
The 90 Day Mark
That’s it. By the 90 day mark, I try to have this drumbeat going with the existing team, or be underway with hiring and building out a new team if needed. Sometimes, it takes longer, but if stakeholders are clear about the process and where you are on the journey, it usually works out fine. I would love to hear what process you use and whether you have alternative approaches to any of the steps here.