Stepping into a new team or project is a mix of excitement and trepidation. You’re eager to make a strong impression and hit the ground running, but it’s essential to remember that success is a journey rather than an immediate destination.
There are a bunch of resources out there that can help you when onboarding. I gravitate to Steven Messer’s Trello Board on what to think about joining a new team. I won’t replicate what’s on the Trello board. What I do want to do is talk about my experience.
I find it helpful when joining a team to break down what to focus on in 1-week, 1-month and 3-month increments.
Photo by Sharefaith: https://www.pexels.com/photo/man-facing-road-1248418/Photo
The single most important thing in the first week is to get to know your team. These are the people you’ll be building the product with. I organise 1-1s with everyone as soon as I can.
I like to use this structure to help me when speaking with new team members. I keep this initial meeting to 30 minutes:
- What is your background?
- What is your role on the team?
- What’s working well?
- What’s not working?
- How often should we meet?
- Who else should I speak to?
- What else should I know about?
These questions give me a rough assessment of the current situation and how people like to work. When several people in the 1-1s point out a problem, I pay more attention to it so that I can work out a solution later on.
You won’t grasp every nuance of the product in the first week. Your initial focus will revolve around practical matters like setting up your workspace, attending meetings, gaining access to tools, and reviewing procedures. I advise against immediate changes unless there’s a critical issue to address. It can send the wrong message to the team that the way they worked before was not good. It can come across as insensitive.
By the end of week 2, I want to know:
- how the team works (e.g. agile structure, tools they use)
- the product at a high level (what it does, the user journey, and the technical stack)
- what the key measures of success are (KPIs)
- the vision, product strategy and roadmap
One of the best ways to onboard into your product space is to interact with your users. This may be through a sales meeting, through user research or looking at support requests. On one team, I joined a sales rep onboarding new clients onto the product. It was helpful to see what features the sales rep was highlighting and how they used the product. I also listened to early-access users. They shared what they liked and struggled with. This helped me understand the usage of the product.
Studying your competitors can provide valuable insights into their strategies, tactics, and customer preferences. By analysing their actions, you can understand what works well in the market, identify potential gaps in their offerings, and improve your own products or services to better meet the needs of your users.
I like to show value by getting something over the line. No matter how small it is, I want the team to show the business that we are improving the user experience. This approach can help build trust and credibility with the business, reinforcing the idea that your team is dedicated to driving positive outcomes.
Between 1-3 months, I’ll have implemented changes to the ways of working to help the team succeed. I’ll use observations and data from the past couple of months to do this. If something is impacting the team’s well-being or performance, I’ll look to remove it.
For one team, we didn’t have much of a backlog of tickets to work in. To make it easier, we now have a meeting on Fridays to discuss technical work and divide it into smaller tasks. This helped to ensure we had a steady pipeline of work. Later on, I asked the developers to work on tickets separately from the meeting. Then, they should come to the meeting to discuss the implementation with other developers and get their perspective. This helped our refinement meetings be more meaningful.
Be cautious with meetings; they aren’t always the solution. Overreliance on meetings can hinder team well-being and productivity. Seek asynchronous solutions when possible. Consider raising issues in platforms like Slack, followed by threaded discussions to reach thoughtful conclusions.
My aim by the end of the 3 months is to have a firm handle on the product. I want to be managing and owning the roadmap. I’ll prioritise the roadmap by looking at what the data shows and our user needs.
Onboarding into a new product is a gradual process. It involves building relationships, understanding the product, and making strategic improvements.
How do you prefer to navigate your onboarding experience in a new product? Let me know your thoughts.