Starting a new job as a PM
People talk about "30 day plans", I wrote about "30 day plans", but is it a good way to start a new PM role?
Previously, I wrote “Bringing on new product managers” with specific suggestions for people managers. But every manager and company will have a different onboarding and orientation process. So today, I thought to share tips if you’re joining a new company as an experienced PM. What should you do? Should you create a 30-day plan?
You versus the company
Before diving straight into a list of tips, let’s pause for one moment to discuss the company you’re joining. Joining a 10-person startup is going to be very different than joining a Fortune 100, even if the roles and responsibilities are the same. As a result, any specific tactic that I offer that might work for one situation won’t translate to another. Yet, there are four good principles applicable across companies of all sizes and maturity:
Be curious by asking non-leading questions
Take small initiatives where you see opportunities for action
Accept that it’ll take time with repeat interactions to build relationships
Find situations to uncover how people frame problems
These four principles work together to help compound learning. Remember, your first mission when you join a new company is to become operationally effective as quickly as possible. That’s because as a new PM at your company, you’ve got the title but aren’t 100% functional.
Principles explained
The first two principles work together to balance gathering information against taking action on the product you manage. Sometimes, we spend too much time reading and listening (you know who you are if you fall into this camp). On the other hand, if we dive into action without understanding the situation, we could be “drilling perfect holes in all the wrong places.”
Typically, small/younger companies lean toward action because you’ll have fewer people to talk with and less information to uncover. However, it’s also possible that you’re joining a large organization in crisis mode (e.g., product restructuring) where the action is warranted.
If principles 1 and 2 are product-centered, principles 3 and 4 are all about people. Most product managers don’t spend nearly enough time thinking about the people they work with, considering that it’s the people around them that make the product. I’ve definitely made this mistake so learn from me.
Unlike learning about products, learning about people takes more time. It is difficult and sometimes not possible to rush relationship development. This isn’t drinking through a firehose of information, but finding ways to sip tea. While you have to accept building relationships takes time, you should find situations that can help you uncover how people think about issues and problems. That’s because the way people frame problems will heavily influence how they evaluate solutions. Using examples from the news in the U.S., consider these words and how they might frame an issue differently: pro-life, pro-choice, anti-abortion, pro-abortion (let’s not forget to ask, can’t someone be pro-life and pro-choice?). I digress, but remember, if products are complex, humans are more complex, and uncovering that complexity is rarely linear.
Ditch the 30-day plan; embrace weekly goals toward a mission
In the past, I’ve briefly discussed 30-day plans. Last year, I spoke with a PM who started a new job. He asked if I have a template for 30-day plan for new PMs. I didn’t, but when I thought about creating one, I struggled. The difficulty wasn’t the template itself, but I struggled with the approach. Instead, I landed upon “embrace weekly goals”. Here’s why.
Recall that your mission as a new PM is to be operational and effective, as quickly as possible. What does operational and effective mean? Well, the short, generalized answer is you’re effective and operational when you can confidently answer more questions and give more directions than replying “I don’t know, let me look into that.” Roughly, when you’re able to do 80% of your job without assistance by asking for help, I consider that operational. This reads like a very loose definition and that’s intentional. We can never be 100% all-knowing as PM and I can’t define what operational looks for each PM role at a company. But you know when you have the confidence in the majority of situations, then you’re operationally effective.
How quickly you’ll reach this state, I don’t have an answer. If you’re lucky, you could ask your manager for some historical data as a very rough guide (“How long does it typically take a PM to become self-sufficient and operational?). Yet, even with this data, the data is a terrible guide because more than likely, the situation has changed between the previous PM and you. Instead, you should think of this as the evaluation benchmark your manager has in her/his head.
Because it varies from job to job. Setting an arbitrary 30 or 60-day target doesn’t make any sense. At a 10-person startup, maybe it should take 1 week. At a 25,000 global company where your product is localized into multiple geographies, languages, and regulations, maybe 6 months. Just as we shouldn’t set arbitrary development deadlines, it doesn’t make sense to use 30/60/90 day deadlines or terminology either. Understand your only capability, but also understand the expectation.
In replacing a 30-day template, I leave you with the alternative: embrace weekly goals. What does that mean in practice? It requires learning in 5 areas and you should structure your weekly goals in each area:
The organization and its people
The product and technology
The process and tools (how people work, how things are done in what order)
The industry (including competitors)
The company and its business model (i.e., financials)
As you look at the 5 areas, rank them in order of importance and breadth. For example, maybe you are a PM leading an internal platform product that’s non-revenue generating. It’s still important to understand the company and business model, but your product will only contribute to its cost and thus, this area is less important initially. Alternatively, you might be joining as a GPM overseeing multiple products. While understanding how they all work is important, it might be more important to understand the organization and its people and how people work across teams (conflicts and resolution).
Once you’ve ranked the above in order of priority, each week, set a few knowledge goals in the top three areas. For example, maybe an organization and its people goal is “meet with 8 people across engineering and design”. Don’t focus on more than three areas per week. I find it is better to learn in-depth rather than breadth because it allows you to be partially operational faster.
At the end of the week, summarize what you’ve learned in each area. By summarize, I mean write out a few sentences. You’re creating your own knowledge repository, so write what you find most important.
As the weeks progress, you’ll notice you’ll set goals in more depth. Whereas before it was “meet X number of people”, you might now set “meet with [name] & [name] to seek their input on [Y]” or “propose one process improvements to [X process] and receive feedback”.
This process of embracing weekly goals enables you to make changes within a framework. Remember, your goal is to become operational so you’re more than a PM by title.
Have a tip for PMs starting at a new company? Leave a comment below.