Starting a new PM job well

Photo by Christian Chen on Unsplash

Starting a new job is exciting. You learn about a new problem, build new relationships, and get a chance to reinvent yourself. Along with it comes a certain sense of nervousness. How do you win trust? How do you add value? How do you learn to navigate an organization? I am starting a new job soon, and these questions have been on my mind. Reflecting back, here are some things that have worked for me — and some new things I want to try. For a Product Manager starting a new job, the objective is to set yourself up to deliver valuable products to users.  To build that foundation, you need to:

1. Understand the product problems that are worth solving
2. Build relationships with the people who will partner with you to ship products
3. Evolve processes to efficiently deliver products to users

When you first start, take the first thirty days to learn how things work now, the next thirty to execute on delivering something valuable, and the thirty days after that to meaningfully improve the results and processes.

The Learn Phase: First thirty days

The early days with a new team feel like an archaeological excavation. You are parsing through a trove of work done over months and years. It’s daunting, but it’s a rare window of opportunity to ask judgment-free questions about the ‘why’ behind past decisions. In the learn phase, you are trying to soak in as much context as possible across product, people, and process.

Product

When people are busy in the trenches, it’s hard to keep track of the broader picture. One of the most helpful things a new person can do is to share context on how the product landscape has evolved, and to reaffirm the product vision. The objective at the end of the learn phase is to share a State of the Union with the team. The outline of a good State of the Union looks like:

1. Recap of product strategy
2. Analytics on how we are doing
3. Key user insights and feature requests
4. A high-level overview of how the system works
5. Insights into how other people have solved similar problems
6. Opportunities and threats
7. Magic moments showing what people love about our product

To write this report, the context I find helpful to gain can be divided into two categories: Company awareness

1. Company and team objectives, and how they relate to the overall product strategy
2. Technical deep-dive into the product’s architecture
3. Seminal user research
4. Customer feedback tickets
5. Analytics on growth, engagement, and profit

Market awareness

1. Competitive analysis: who else is doing it/strengths and weaknesses/key differentiators
2. Market analysis: What jobs are people hiring the product to do?
3. Ecosystem analysis: upstream/downstream products

People

When you first start, one of the most impactful things to do is lay the foundation for relationships with your future coworkers. Time spent building friendships and learning about what’s personally important to people makes a huge difference when you go through rough patches.  The allies I have found myself leaning on the most often fall in three groups:

1. Immediate engineering, design, and product team
2. Managers and executives
3. Stakeholders in extended teams such as sales, marketing, customer success, and corp dev.

With each person I meet, I ask some form of the following questions: Questions to ask everyone

• What are you currently working on? What are your goals for the next few months?
• What are some of the biggest challenges we are facing as a company?
• What can I do to help make our relationship successful?
• Is there anyone you’d recommend I meet with to learn more about the team/project/company?

Questions for immediate team

• What’s working/not working well?
• What should I read to get a better understanding of our product and process?
• What would you do in my shoes?

Questions for managers and executives

• What is the team’s goal? How does this map to the company’s objectives?
• What are our core theses on how we would achieve that outcome?
• How will we know we’ve succeeded?

I appreciated Julie Zhou’s take on how to follow up after a meeting:

After each meeting with someone new, follow up with a brief thank-you message highlighting something you learned or appreciated about the meeting, and a thought on how you may work together, or when it could make sense to get together again, so as to start laying some pavement towards an ongoing collaboration.

Process

You can always tell teams that have too much process by their sluggish pace, and the ones with too little by how many fires are being put out. Typically, there are four types of processes teams put in place to streamline execution:

1. Co-ordination processes to keep everyone in the loop; for example cross-functional stakeholder meetings
2. Decision-making processes to ensure high-quality outcomes; for example, prioritization and roadmap
3. Execution processes to drive streamlined implementation; for example, sprint planning
4. Learning processes to improve how we work; for example, retros

The best way I have found to gain context is by reviewing the current state of processes:

1. For co-ordination, reference guides created by teams on how to work with them. Set up 1:1s with other PMs on the team and stalk calendars to see what recurring meetings they have set up.
2. For decision-making, roadmaps and OKRs. Look for any notes shared on how products were prioritized. Ask about controversial decisions and how they were resolved.
3. For execution, recent product docs and sprint board. Look for how well the team has done at defining and sizing tasks.
4. For learning, 1:1s to talk about sprint, retro, and planning processes. Read up on postmortems.

The Execute Phase: First sixty days

Once you have spent time gaining context, the next step is to get your hands dirty. There are two goals at this stage: the first is to win the confidence of the team in your ability to deliver. The second is to go through the execution cycle to identify inefficiencies.

Product

Ship something valuable. Find little wins by fixing bugs and shipping minor features that have an outstanding impact on the user experience.Remove dead weight. Stop projects that no longer make sense. A key advantage of being new is that it’s easier to spot initiatives that have outlived their usefulness.Set your sights on something big. Write a product spec for a more significant initiative that will help move the needle. Get feedback, develop consensus, and build excitement for this new initiative.

People

Building open lines of communication is the first step in developing the relationship. The first few activities that help increase transparency are:

1. Set up recurring 1:1s with your immediate team.
2. Define a cadence for sending progress updates on goals.
3. Send shipping announcements to all stakeholders.
4. Share context externally as early as possible, and get stakeholders excited about upcoming work to get prioritization on their roadmaps.

Process

The goal is to add as little process as possible to streamline execution and keep everyone informed. The minimal set of processes that have helped me grease the wheels are:

For co-ordination, Product kickoff and Product launch planning

For decision making, Product/design review and Roadmap review

For execution, Stand ups, Sprints, and Demos

For learning speed, User research, Retro, and Peer feedback

The Improve Phase: First ninety days

After some time, the team gets into a cadence of shipping releases. Now, you’ll have two goals. First, build a healthy portfolio of initiatives that make a dent in the objectives. And second, set up a feedback loop so that with each release, we refine the process to get closer to our ideal state: a motivated team shipping valuable products.

I am excited about the adventure ahead and look forward to refining this list based on my next experience. What else should I keep in mind to start well at my job?

Appendix

• Great product leaders win games
• How founders hire a VP of product
• Starting Well — The Year of the Looking Glass — Medium