Are You the PM on a New Product Team? Start Here!

Recently, I joined a completely new team made up of completely new folks. All of this newness made it immediately apparent that we needed to get on the same page and build shared understanding rapidly with the end goal of providing value and delivering on desired outcomes.

Because our team is small, there are fewer paths to communicate which is definitely an advantage. You don’t want to take it for granted though and simply assume your new team magically knows how to GSD.

The natural instinct can be to start churning out stories as soon as possible and “prove yourself” but if you don’t take a step back and look at the system in which you want to work, you may be setting yourself back long term. There are a lot of things to get the team off the ground related to setting strategy, getting epics or stories ready to go. This is still all secondary to having a shared agreement on how the team works and operates.

I have always felt strongly that a Product Manager plays a critical role in creating the entire system in which product initiatives are brought to life and my new team is no different. Follow along for how my team did their kickoff and the outcomes we achieved.

Ceremonies

Just because we are a new team doesn’t mean we have total free rein on how we operate. There are other teams that we need to account for and generally need to align to their overall flow.

Prior to this kickoff session, I simply listed out the ceremonies that exist (the ones in gold) and how our organization currently uses and defines them. Once we gathered, we simply discussed these to make sure there was shared understanding. We then pivoted to discuss what we may want to consider adding.

Outcome

As you can see, we kept the gold, decided on some new ceremonies with timing, and agreed on the “Not Now” items. Keep in mind the whole purpose of this activity is to get your team talking and building shared understanding. So just because a sprint review didn’t make sense for our team at this time, doesn’t mean that would be the same for your team.

Work Types

After agreeing on the overall cadence and ceremonies, we pivoted to the types of work that we want to classify. This turned out to be one of the most critical pieces.

Before the session, I listed out the common types of work I was seeing either at my current company or prior companies. Then when we gathered through using a divergence and convergence approach. We went lane by lane and silently brainstormed what that word means to us and how we’d define it. Each contributor’s definition was on a sticky note. We’d then discuss and elaborate as needed then move on to the next lane. UI debt specifically was identified as missing during the exercise and was added as an additional work type.

Brainstorm

It was immediately obvious that we had very different understandings of the exact same words. We spent most of the time discussing tasks, epics, tech debt, and features. Our different work backgrounds had led us to all define these fairly differently.

Outcome

After the kickoff session, I simply took the stickies with notes from the exercise and created the above shared team definitions. The team then reviewed these and gave their thumbs up.

Card Format

It is critical that everyone on the team knows what to expect when they open a ticket. To achieve this, we had a discussion on formats we’ve used past or present for detailing out new work. After having the prior conversation on what different work types mean, this part was fairly simple for us to just talk through and make changes real time. You’ll notice we have a few that we need to come back to… it’s all iterative. :)

Outcome

Workflow

Ok, so now we know what kinds of work we will focus on, and the information we expect to see for that work. Now it’s time to pivot to the system that all of this work will flow through.

I started by taking the lanes that were automatically given to us when our workspace was created. This serves as a refresher for where we are at now. Then using a divergence and convergence approach again, we all took an area of the board and mapped out our ideal workflow. It was incredibly telling to see the difference in workflows given our respective backgrounds.

Brainstorm

We then went around and each shared the thought behind our proposed workflows and noted the similarities and differences between them. This was also a great time to have an honest conversation about when and where engineering should be involved. Our team wants engineering to be informed as far left as possible so we noted that within the workflow as well.

Outcome

Similar to work types, I once again took the stickies and notes from the exercise and distilled it into a cohesive workflow. The team again reviewed and gave their thumbs up.

Now What?

This exercise was incredibly useful in setting a baseline and giving us a starting point. Now that we have been using it, things have changed yet again — which is good! We have already tweaked some statuses and swim lanes based off of learnings from simply working together.

Copies of this agreement are kept in a few different places for the team to access. We quickly learned that some of the pre-existing teams also wanted to do this exercise as an opportunity to build consensus and level-set.

Additionally, I took this workflow and aligned it to our high level roadmap that is then shared with key stakeholders. (Maybe that will be a part two?)

With any new team, we have a long way to go. There are still strategies to define and KPI’s to set. Our mission needs to be further clarified. It is nice to know that we have a sound system in place to keep moving forward while we make progress in these other areas.

I encourage any team regardless of “newness” to give something like this a shot. This type of session can really recharge the team and invigorate your ways of working. You’ll be surprised to learn that you may be missing the mark on the things that you thought were obvious!