A note for new subscribers: This post is part of a series on my notes on technology product management (this is what I do for a living). You might notice that these posts often link to older posts in the series on LinkedIn even though they are all available on this blog. That is intended for folks who only want to follow future product management related posts. Finally, for all those of you who don’t build tech products for a living, I believe many of these notes have broader applicability. And, I hope you find that to be the case as well…
A quick overview of what we’ve covered on “Notes on Product Management” so far –
—————————————————————————————————————
Every few months/quarters in our time as Product Managers, we will find ourselves working on new problems with new groups of people. This can happen due to a multitude of reasons – change in scope/focus, new strategic priority, new data, and so on. Some of these are better reasons than others. Regardless, it is inevitable we will find ourselves in situations where we work on new projects with new sets of people.
The two dysfunctions of a product team
The default way of working is to just get on with it. We get a few of our close partners together, begin writing up a doc, schedule a brainstorm or two along the way, and bring people along as and when we realize we need to do it.
This default way of working is also suboptimal because it doesn’t address the two most common dysfunctions in a product team –
(1) Absence of shared context. Everyone in the product team is paid to make decisions. It is impossible to make good decisions when you are missing context. A simple test – can everyone on the team confidently articulate the problem statement, our desired solution, and the key data points that give us conviction in our approach?
(2) A lack of trust and a resulting deep care for the work and for each other. If people in the team don’t trust others to make the right decisions, we’re going to frequently find ourselves in decision making bottlenecks that get in the way of progress. A simple test – would your Eng/Design/Data/Marketing partners trust you to make the right calls on their behalf? Would you do the same?
It is tempting to think of product teams as complicated organisms with unique sets of dysfunctions. But, when we’re dealing with dysfunctional product teams, you’ll find that it nearly always comes down to one or both of these dysfunctions.
It is rarely about the politics of the situation or that one problematic character. While it helps if you’ve got a group of individuals who all get along, we rarely have that luxury. Product teams are fluid, and it helps to build muscles to be able to make the best out of most situations we are in. When in trouble and in doubt, look for an absence of shared context and trust/deep care.
So, what’s the solution?
Let’s start with the disclaimer – there is no guaranteed solution to all problems in life. We all have our own unique situations.
But, that said, there are two things we can do every time we find ourselves working on a new project/team that will solve these problems ~90% of the time:
(1) Start the collaboration with an effective Kick off (this post)
(2) Run effective weekly/bi-weekly update meetings (next post)
This is both ridiculously simple and hard. Simple because it is easy to know we should do it. Hard because it requires discipline to make the time to invest in these. It is always tempting to skip the Kick Off to make immediate progress. But that progress is always fleeting.
The 3 elements of an effective Kick Off meeting
An effective kick-off meeting has 3 elements:
(1) Get to know each other – deeply: We start by spending time getting to know each other. That knowledge will help accelerate our ability to understand each other and build trust.
(2) Understand context: This covers the “why” we’re starting on this project (typically business context) and time spent to understand user problems and the current solutions (if any).
(3) Get creative juices flowing with a brainstorm: Understand what is on everyone’s mind and tease the possibilities ahead.
Let’s now dig into each of these.
(1) Get to know each other – deeply
I have a go-to “get to know” activity I’ll recommend as an example.
At this point, we’ll already start to see something special emerge. We’ll often hear people saying – “Wow – I didn’t know this about you despite working with you for 3 years!” or “That’s crazy. Me too!” It is also lovely to hear someone else replay what they understood and felt.
It is nice to keep these organic – e.g., encourage others in the room who know the person to add what they know. When these evolve into a celebration of the people in the room, the atmosphere can feel magical.
This activity can take between 1-2 hours depending on the size of the group. If there’s one thing I’ve learnt, it is to not cut this short. In the long run, this 1-2 hour investment is among the most important investments we will make.
(2) Understand context
There are 4 kinds of context that are helpful to share (keep this to 1-2 slides per type for simplicity):
(a) Why/business context. Help everyone understand why this project or team exists. This is typically thanks to some combination of business objective and user problem. It is good to talk about both.
(b) Qualitative understanding of the user (research): Share a synthesis of all the qualitative user research available. A good kick-off meeting is creating in partnership with the team. And this is a great opportunity to prep with our design, user research, and marketing partners.
It is also a great opportunity to build empathy for our users. Having any clips/recordings of impactful user interviews go a long way in grounding the group.
(c) Quantitative understanding of the user (data): Share a synthesis of any data available on the user. This includes dashboards that measure user data, past experiments, or analyses. Again, this is an opportunity to prep with our data partners.
(d) Technology challenges: If possible, it is also great to give folks an overview of any key technology challenges/hurdles we might need to solve for.
(3) Get creative juices flowing with a brainstorm
Again, I have a simple formula I’d recommend:
At this point, this exercise would have given everyone a taste of working with each other, previewed the possibilities ahead, and hopefully gotten them excited.
9 times out of 10, a group with the same shared context arrives at the same set of conclusions. That early alignment then gives us the opportunity to begin writing our shared strategy doc/product spec.
———————————————————————————————————————————-
Here are 2 resources that might help bring this to life –
———————————————————————————————————————————-
This was a detailed dive into what a good kickoff meeting looks like. Done well, this single exercise provides enough positive momentum to move the team forward together for months. It helps ensure we start a collaboration with shared context and an understanding of each other which provides the foundations for trust.
A great kickoff won’t permanently keep the dysfunctions at bay. The next step to build on a successful kick-off is to run effective weekly meetings. More on that in the next post.
