At Pivotal, we rotate developers, designers, and product managers during a project. One of the reasons we do this is that we want our clients’ to have confidence in their own ability to make decisions and follow the process without any particular Pivot by their side.
Here are the top ten things we do when transitioning PMs in the middle of a project (but they apply no matter what the impetus is for change or who’s being swapped in.) In a recent quick transition we only did a few of them, but would have loved to do more.
-
Set goals for the transition
Have a meeting to establish what people think is valuable to accomplish during the transition. Make sure everyone is on the same page about what knowledge needs to be transferred. Choose what activities should happen during the transition period and which are less important based on the objectives. -
Manage expectations
Help the team (especially the client) understand what will happen during and after the transition. Encourage them to explain and repeat things that are familiar to them but may be unfamiliar to newer team members. Remind them that the new teammates will have their own style and perspectives, and that change is good for the team and the product. Make sure everyone knows that you are available after the overlap period is over to answer unanticipated questions. -
Have daily check-ins
Set aside time every day to chat for Q+A and a mini-retro. Provide an opportunity to ask any nagging questions and also to bring up concerns about how the process is going so far. Adjust the following days accordingly. -
Make a list of topics to discuss
Outline the features (current and requested) for which it’s key to understand the full background beyond what’s in the backlog. Add all the domain vocabulary and acronyms that might be confusing to someone new. Don’t forget to include the names of stakeholders, potentially with some sort of hierarchy. Write out the list on a notecard or piece of paper that you can keep with you and add to as you think of more topics to discuss. -
Demo the product
Show off what you’ve built and how the product is positioned. Let your client do this if you have one, that helps surface what’s important to them. Run through older designs, user research, and notes from strategy sessions so that the decisions leading up to the current state of the product are clear. Forward important email chains and share document links so that they can have as much context as possible. -
Review the list daily
Look the lists over daily and make sure they are getting more comfortable with the product, terms, and people. Add things as needed to the lists; be Agile :) -
Discuss the next epic
Bring together the team and talk about the next big group of user stories. Explain the motivation for the features and their priority. Encourage everyone to ask questions and challenge assumptions. -
Leave the building
Get together for lunch, drinks, or something else out of the office and socially focused. Help the new team member build rapport with the existing team members. Share the funny stories from the past few months so that the newest teammate gets the inside jokes. -
Meet the stakeholders
Introduce the product’s stakeholders in person or via video chat so that they can get to know each other. Setup multiple meetings if the group is large. Open the conversation to questions from both sides and try to minimize focus on team members who are leaving. Have the new people talk about why they are excited to join the team. -
Ask for help
Reach out for help if you are having trouble or aren’t sure about something. Ask your anchor/lead developer to help with the training. Poll others to share something they loved from when they took over a different project. See if your company has a transition checklist; create it or share this if you don’t have one.
What else could do you make sure to do when transitioning responsibility?
About the Author
