Practical advice for a smooth transition into a new company.

Curtis Stanier

Follow

Sep 8, 2019 · 10 min read

Changing jobs isn’t something one does often. It’s a big decision. Being a Product Manager requires having both breadth and depth of understanding, which needs to encompass the organization, the business, the people, the customers and the technology. When starting a new company you possess little of this knowledge. I recently went through this transition. I went from having over four years of domain knowledge and historical context to knowing nothing. It’s daunting and scary.

But something daunting and scary should not stop you. In my career, I’ve spent a lot of time on-boarding new employees and developed a framework to support them during their transition. I had the chance to test this framework myself and wanted to share my approach with others embarking on their next challenge.

Most of these tips work in conjunction with the on-boarding activities, your new company organizes. However, it is beneficial to formalize tasks to give yourself a degree of structure for times you are feeling overwhelmed. Your first few months are going to be hectic as you learn the job and meet new people, so it’s nice to have a framework to refer back to.

In total, there are seven tips.

1. Understand the business
2. Understand what you are trying to accomplish
3. Learn what has been done
4. Learn what is being done
5. Get to know everyone
6. Understand the tech stack
7. Don’t change anything (yet)

1. Understand the organization

For me, being a Product Manager is fundamentally about how technology can support and drive the business forward by building amazing products for customers. You, along with your colleagues, play a unique part in the success of your organization. To effectively contribute, you need to understand where the organization wants to go, and where that destination is relative to where it is now. This helps you understand how you can help the organization get to its destination. Regardless of the size of the company, you must understand this delta. So how can you do this?

These are examples of sources for understanding your new organization:

• The Company Mission and the Company Values are basic ways to gauge the company culture.
• The CEO and CFO present latest Quarterly and Annual Earnings Reports (if your company is Public). These reports give you a high-level answer to the question of “where are we and where are we going?” directly from the leadership of the company.
• The latest company update or all-hands usually contain more tactical information than the Earnings Reports, and provide more context beyond the business numbers.
• The latest department update will help you understand you and your team’s role.
• The Key Metrics (and why they are key) are often overlooked but expand your knowledge of company vocabulary and provide insight into what is essential.
• The Key Markets / Demographics (and why they are key) as this is your basic understanding of your customers.
• Understand the business model and its nuances. Spend time thinking about the business model and answering the question, “how do we make money?” Once you know that, find all the reasons why your model isn’t that simple (trust me, it never is).

2. Understand what you are there to accomplish

Early on, you should schedule a meeting with your manager. It is essential to recognize the role that your manager envisions for you. It’s a way of getting alignment and setting expectations early on.

Set up regular check-ins with your manager (ideally, no more than every two weeks). Track these sessions and refer back to them. They’re an excellent way to maintain that alignment and focus your early development on the areas that matter most.

Come to an understanding with your manager:

• Which strengths did they hire you on?
• What are your areas for development?
• What are your manager’s expectations for months 1, 2, 3, and 6?
• What are their top 3 priorities at the moment?
• Who are some of the key people they want you to meet?

3. Learn what has been done

As I mentioned above, going into a new company means you have none of the historical contexts. While this can leave you with knowledge gaps, it also means you don’t have the biases, blinkers or politics that can narrow your perspective.

Sources you can use for educating yourself about the past:

• Use Squad Retrospective notes to understand how the team has evolved. It will provide insights into their particular pain points and how they’ve been working to improve them.
• Look for any frequent updates that have been sent out by the teams. These are things such as Release Notes, Update Packs or Internal Blogs which explain achievements, changes and challenges.
• Previous Roadmaps will provide an overview of prior initiatives and priorities, helping you piece together the Product’s evolution.
• Previous discovery and experiment results will give you a more granular understanding of what has been tested before. By taking the time to revisit these topics, you’re reducing the risk of organizational relearning.
• Understand how the Design of the Product has evolved. You can do this using tools like webarchive.org and sitting with your Product Design team. They’ll have a lot of the context around the evolution.
• Depending on how your organization processes them, you may have access to previous Feature Requests. Learning what hasn’t been done is just as useful as learning what has been done, it gives you a sense of the organization’s priority.

4. Learn what is being done

Turn your attention to the present state of the company and the short-term goals. This is usually the more natural part of this list because it makes up the majority of the day-to-day work and conversations you’ll be having anyway.

• The best frame of reference is the company and department goals. Look for items such as OKRs and objectives that are shared widely.
• Organizations continue to grow and evolve. This means there is usually some kind of ongoing organizational or process change. Change, by its nature, can be disruptive, but as a newbie, you have no frame of reference to compare it with.
• Spend time at different team’s Sprint Reviews. These are a way of getting the latest update on the various work streams. It also gives you an appreciation for how the different groups operate.
• Some companies operate Standups not just for individual squads but also other groups or teams. If you want to learn more, follow up with the individuals after the session (the standup isn’t the place for those discovery questions).

5. Get to know everyone

You’re going to meet and be introduced to a lot of people in your early days at the company. Meeting is useful but knowing someone is invaluable. Those quick hallway introductions or round-the-room “hi, I am …” are a good starting point but won’t form relationships or substantially build your knowledge. Take the time to get to know more about your colleagues, their teams and their work. For all these chats, I recommend avoiding meeting rooms — instead, head to the kitchen or a local coffee place for a more open conversion.

I titled this section “Know Everyone”. I know that phrase is a little hyperbolic, but I want to stress the importance of making a conscious effort to reach out to people. Below, I’ve broken down Everyone into a few key groups and why they’re essential.

1. Your Team : take the time to have a 1:1 with everyone on your new team. This is everyone that you’ll be building products with daily. These are perhaps some of the most important meetings you will have. The purpose of these sessions is to get to know more about them. As a Product Manager, you have a significant influence on the day-to-day of what team does. For this reason, understanding how you can support their motivation and interests is imperative.
2. Your Tribe: depending on the size of your organization, teams may be grouped into Tribes (from the Spotify Model). Other teams inside a tribe will be contributing to a similar overall objective, so take the time to understand how the pieces fit together. Reach out to the Product Managers and Engineering Leads. They’ll be able to provide a wealth of information not just on the product but also on the processes that work (and don’t).
3. Your Department: Keep meeting Product Managers from other areas. The result won’t be that you know the product in its entirety, but hopefully, you’ll at least know who to reach out to for specific questions. As well as Product Managers, be sure to spend time with the leads and architects from all disciplines that you’ll be working with — Design, iOS, Android, Backend, Web and Data. I firmly believe that a Product Manager has a responsibility to understand and support the technical estate, so knowing those that lead it and design it is a must.
4. Other Departments: A common mistake when on-boarding is to only spend time with your immediate colleagues and some key stakeholders. Early on, however, ensure you make time to learn about the breadth of the organization. Product, by its very nature, requires a broad understanding with a range of different input. Learning about other parts of the organization and making friends with those you may not work with daily is essential for you to dip into the separate knowledge silos. It also helps to build bridges between the tech team and other departments, improving the relationship and information flow.

Finally, when you’ve made some of these connections make an effort to spend time with them regularly. I’ve taken to booking Tuesdays to tour the building and sit with different teams for the day — Marketing, Operations or even another Squad. Don’t ever underestimate the value of informal or ad-hoc conversations.

1:1 Questions

Below, I have listed some of the questions you can use in your 1:1 conversion. Don’t fear to ask about the challenges — you will find that most people do not want to be overly negative with a new employee but probing into these areas will help prepare you for your role. You don’t need to ask all the questions, but I recommend to at least ask the first and sixth. At very least, you have a basic knowledge of their work and it extends your discovery of new colleagues.

1. Tell me about what your team has been working on recently
2. What has been your most significant success lately?
3. What are the biggest challenges facing you or your team?
4. What are the biggest challenges facing our company?
5. What are you most proud that you’ve accomplished so far?
6. Who is the one person I really must talk to?
7. What is the one piece of advice you would give me as a new employee to be successful?

6. Understand your Tech Stack

Product Managers who are new to an organization often overlook their understanding of the Tech Stack. There is a continued debate in the community about how technical a Product Manager should be, but I firmly believe they must have a good grasp of the technical estate. In modern Product Teams, we expect the whole team to take responsibility for the success of the business — similarly, Product has a responsibility for the technical estate that their product operates in. This is valuable for two reasons. First, it gives you insight into any risks, such as stability, scalability, security. Second, and most importantly, it is one of the main steps you can take to build trust and respect with the team.

Sources for learning about the Tech Stack:

• Architecture diagrams and documentation
• Whiteboard session with a knowledgeable engineer
• Information gathered from your 1:1s with other Product Managers
• Label the technical services supporting different parts of the user journey
• Identify the services the teams dread working on and why (there is always one)
• Review any end of life strategies
• Github Repo READMEs

7. Don’t change anything (yet)

When joining a new company, you’re likely to find examples of things you “know” could be done better — however, in your early days at a company, you should be in an “absorb and learn mode.” One of the benefits of being new to the organization is the very fact you lack that historical context about why things are done a certain away, which is excellent. However, that same lack of knowledge will mean you’re blind to things that you need to know to make an informed decision about a change. There will be more you need to know and understand before you can make an objective assessment. Coming in and immediately attempting to make changes is disruptive and can fray relationships early on.

I recommend making a list of areas that can potentially be improved, but don’t share it yet. As you settle in, continue to add notes. Review this after several weeks and see if it still makes sense with what you’ve learned and asked others for their thoughts on problem-areas without jumping directly to a solution. Change is most effective when people are bought-in, and the easiest way to get that is when there is a shared appreciation of a problem.

Conclusion

So that’s it — my 7 tips for your first 30 days as a Product Manager in a new company. I sincerely hope these tips help you build a strong foundation.

The best of luck in your new role!