Can a team with a recently-departed product manager learn to survive on its own? How we built a bottom-up product development culture on my team at Lyft.

What if there were no product managers?

A former PM colleague once told me, with some amount of jest, “I don’t know why product managers need to exist.”

While it shocked me at first (coming from a product manager, no less), she was emphasizing that the core value of product managing is ephemeral - it’s strategic, it’s relational, and it’s hard to quantify and measure. It’s the stuff that fills the gaps and spaces between the orgs in the company, teams and process. A PM’s core function is to be the glue - maintaining alignment and developing strategy and execution planning among different areas of the business.

This post is certainly not about bashing PM’s. Let’s get that out of the way - I love PM’s, and a good one is worth their weight in gold. Their skills in focusing the team on building the right thing the right way at the right time can be a game-changer for many companies.

But sometimes that role isn’t needed. Businesses and companies in specific configurations oftentimes have plenty of runway where they can operate without a formal Product Manager. For example, plenty of founding engineering teams operate in a vacuum without a product owner. In those cases, their engineers develop the skills and product intuition to work like a PM.

Only once an organization scales and the focusing powers of a PM are needed, do PM needs really reach their zenith.

However - there’s sometimes an exception where engineering teams at all scales can and do operate without PMs - I’ve met with some world-class engineers at Pinterest and (once upon a time) at Stitch Fix. These were product teams (often growth) that were formed as 100% engineering teams that - surprise - do not operate with PMs.

You may not need one right now either. To explain what I mean by that, I need to tell a story about my team at Lyft.

Life with a PM was good

When I first joined Lyft, my team operated the same way many standard software teams do. We had a dedicated product manager and a team of engineers, along with design and marketing as shared resources. Our product manager was responsible for the usual things a PM does - prioritization of new projects, creating product specs (including market research and opportunity analysis) and doing all the legwork to communicate between teams.

And it was glorious. All the hard work of communicating with stakeholders all along the org? Done. Prioritization decisions? Instantly made. Deep domain expertise about our product? Batteries included.

Then one day, it all stopped.

Our PM colleague came in one day and announced his departure. Just like that, we were thrown for a loop. What were we to do? A replacement was not coming - instead, the team was to own their output and impact for the business. Gulp.

We improvised. My manager (the team’s engineering manager) and I (the tech lead) decided that we’d split up PM responsibilities between the two of us. So I took on the organizational part of the role, and got busy organizing stories and the backlog. He got busy jumping into lots of meetings with leadership and other stakeholders. We held it all together with duct tape and Slack chats and prayed the whole enterprise would hold together till the end of the year.

The Reckoning

The end of the year arrived and quite honestly, we whiffed on our goals. Our team performance against our OKRs was underwhelming. What went wrong?

We looked back at our team output and concluded:

1. We had not been working on the most important (the most impactful) things. We worked too hard and too long on projects that did not end up with much business impact. We had spent so much energy just keeping the lights on for the team that we forgot to be strategic and ruthlessly audit and reprioritize our plans. Instead, we got emotionally involved in the details over concrete analysis of the data.
2. We were blockers for the team. We felt overwhelmed with a constant stream of tasks - planning, stakeholder management, backlog grooming and the mundane tasks that keep a team running. The team was often blocked and waiting to be fed work.
3. We were not communicating enough with stakeholders. We were often slow to broadcast our work to the rest of the organization, and so our team’s work remained low-visibility. We missed opportunities to seek out feedback and gain corrective wisdom from our peers.

Surprise, surprise. Having lost a PM, we had one less teammate who could be wholly devoted to guiding the team to build the right solutions for the customer. As hard as we worked, we were still the bottlenecks, limited by inexperience and lacking time to deeply think about the product needs of the team.

We needed to empower the team - the entire team - to think like product owners.

In the next post, I’ll talk about how we made some changes to the team - and empowered every engineer to think like a product owner. Read Part 2!