Product development special projects: building teams with open communication and a growth mindset

Scenario

A big opportunity

To a small startup, a big enterprise customer can mean a huge opportunity to build relationships with big industry players, win market share, and extend the company’s runway. I was a product manager* at a growing startup when a VIP Enterprise customer showed interest in signing a big contract. The prospective customer was on the fence about signing, because they had a few deal-breaker concerns about our product.

The executives and product team decided to combine two product teams** onto a big, urgent project to meet their needs and close the deal. We formed a “mega-team” and our stakeholder count tripled. The project, already complex from a technical and design perspective, would require alignment and coordination across a lot of people - many of whom had never worked together before. This opportunity was a high risk, high reward project.

*product manager: a team leader that facilitates decision-making on a product team to develop software while balancing business needs, customer needs, usability, and feasibility; and that facilitates communication between the product team and cross-functional stakeholders such as marketers, sales reps, customer success reps, operations managers, content experts, executives, and other specialized roles

**product team: a cross-functional team including several software engineers, a designer, an analyst, a researcher, and a product manager

A defining moment for company culture

Aside from the obvious concern of the project succeeding, another big concern was how changing our working norms for this one project might negatively impact our working culture in the long term.

We had spent the prior year growing the product team from one scrappy team that executed against the founders’ vision into five autonomous product teams that, within their domain, each had a practice of deeply understanding customer problems and driving iterative solutions. Our culture was on a positive trajectory toward ownership and inclusion, and this project represented the risk of taking steps in the opposite direction - toward top-down, “telephone game” of feature requests with the team blindly implementing them. My role was to lead this project and guide the working culture toward the inclusive, participatory, creative atmosphere that we all wanted for the long-term. Beyond the outcome of the project itself, the way we worked on this project would become a defining moment for a company culture in transition.

Pre-mortem goals

With another product manager, I designed a pre-mortem activity with the goals:

Pre-mortem activity

Opening: statement of purpose and explanation of terms

Because many folks had never done a pre-mortem before, we started with a simple statement of purpose:

Name things that can go wrong, even the things that are difficult to say, so we can get real and address the most important issues.

We then shared some terminology and an overview of the agenda for the workshop.

Bill.jpg

Solo writing time

Next, we turned on some music and gave everyone solo writing time to reflect on their biggest fears for the project.

pre-mortem-blank.jpg

Solo reading time, affinity mapping, and voting

Next, we invited the group to review others’ input and group them into similar themes. As the themes emerged, we asked each person to spend five votes and mark the themes that most resonated with them.

Teams for Bill.com - Pre-mortem - Final Board.jpg

Around-the-room sharing

After these quiet activities, we facilitated a debrief and went around the room for folks to share what resonated most.

Open discussion for solution building

Between the votes and the debrief, it was clear we had some top concerns to address. In an open discussion, we went through the prioritized risks and discussed possible mitigating interventions, ownership, and next steps.

Pre-mortem outcomes

We left the meeting with a sense of optimism about the large group’s ability to communicate openly about this complex and risky project, our eyes open to potential challenges, and even some excitement about the opportunity to move fast and make a big impact for the company. We also left with some clear action-items for strategies to mitigate risks.

mitigtations.png

Post-mortem goals

A few intense months passed, and the mega-team successfully delivered the releases needed to close the deal and sign the VIP enterprise customer! This success was due in part to iteratively reevaluating scope and requirements and communicating clearly them with the customer.

I designed a post-mortem workshop with the following goals:

Post-mortem session

Prep

We decided to keep most of the original invite list from the pre-mortem, but to practice “generous exclusion” and ask the executives to sit this one out. Afterward, the product managers would share a summary of what came out of the post-mortem with the execs. We believed this would increase psychological safety for all of the IC teammates to be honest about challenges in the project.

Opening: statement of purpose

Once again, we opened with a statement of purpose:

Reflect on what went well and what could have gone better, so that we can decide what practices to keep and what to change.

Solo writing: vibe check, wins, and challenges

We asked everyone to write down their answers to three prompts:

Multiple Teams Retro.png

This open format allowed space for reflections beyond the themes from the premortem and a visual way to check in about team morale.

Dot spectrum voting: how did we do on pre-mortem concerns?

Next, we showed folks a list of concerns that had arisen during the pre-mortem. Each concern was placed next to a spectrum with “We avoided this concern!” on one end and “This was a major issue!” on the other end. We invited participants to place a dot each spectrum based on how well they thought this concern was handled during the project.

Premort.jpg

This format created an immediate visual representation of how we did. It was also clear where there was more alignment (dot votes clustered close together) and where there was more variation in opinions (dot votes spread farther apart).

Open discussion about themes

Next, we had an open discussion about the themes that arose. For challenges and issues, we wrote down action-oriented takeaways to implement or share with the executives. For the wins and successfully-avoided concerns, we gave shoutouts to teammates that had played a big role.

Biggest wins

Middle-of-the-spectrum

Biggest challenges

Post-mortem outcomes

Overall, this pre- and post-mortem exercise cultivated two big successes: deploying interventions to reduce risk and successfully deliver the project, and fostering and reinforcing a culture of proactive, non-blaming, transparent communication and a growth mindset.

We also started to identify a chronic, complex issue: UX and technical debt. As this style of pre- and post-mortem caught on amongst the product teams, this issue arose repeatedly over the next six months. Even though it wasn’t solved immediately, the increasing visibility of the problem was an important step. In the new year, as the executives and product teams were updating the product strategy, this visibility resulted in allocating staffing for a large investment in a holistic design overhaul and paying down some critical areas of technical debt.

Reflections

In subsequent versions of this exercise, I’ve started playing around with these updates: