Product Manager as Facilitator

The Overlap #9

Welcome to The Overlap, a biweekly newsletter that explores the relationship between product & organization design.

In this essay, I share two takeaways for product managers:

1. It’s normal to question the necessity of your role. Unnecessary ≠ unhelpful.

2. Facilitation is the most valuable skill you have to offer.

In this post, PM = Product Manager. This stuff might be relevant to Project Managers, but Project Managers aren’t the intended audience.

Oftentimes, hiring a PM is the last resort.

Companies rarely hire a product manager before hiring a designer or developer. Founders generally know what they want to build. They need folks who can make their vision a reality, rather than folks who can talk about what to build. 

The first product manager is typically hired only after designers and developers are hired. The exception to this is when a founder hasn’t launched a product before and needs help from someone who has.

When a company hires its first PM, it’s usually a response to one of many things:

• Founders get busy. Which leads them to unintentionally block their team’s progress. They become the bottleneck.

• The product achieved product/market fit. Now it just needs to scale.

• Coordination feels messy as teams get larger and larger.

• Teams struggle to keep track of what to build next.

• Their solutions don’t work because the assumptions behind those solutions weren’t invalidated initially.

Despite these reasons being valid reasons to hire the first PM, it’s possible to run a company with one. Some companies have done this. We’ll look at Basecamp, Stripe, and my current company, Sanctuary Computer.

1. Basecamp: PMs prevent self-management.

Basecamp doesn’t have PMs. Their CEO, CTO, and Head of Product Strategy usually decide what should be built, while their teams coordinate their own time, effort, and focus.

Ryan Singer @rjs

@nurijanian @Suhail @jasonfried @dhh FWIW I think “Product Management” decomposes into some mix of these three: 1. Defining what the work is (shaping) 2. Choosing what work to do and when (betting) 3. Coordinating other peoples’ time/effort (managing) We don’t have PMs because our teams self-organize #3.

I imagine this is informed by their strong belief in hiring “managers of one”: people who can come up with their own goals and execute them. From their 2008 blog post:

“A manager of one is someone who comes up with their own goals and executes them. They don’t need heavy direction. They don’t need daily check-ins. They do what a manager would do — set the tone, assign items, determine what needs to get done, etc. — but they do it by themselves and for themselves. (...)

When you find these people, it frees up the rest of your team to work more and manage less.”

2. Stripe: PMs slow iteration.

Stripe had no PMs for five years. Patrick, Stripe’s CEO, wrote about this as as a Quora answer in 2012:

There are obviously many great product managers in the world. Still, to the extent that having a “product manager” implies having a separation between the person who builds the product and the person who manages it, a few downsides seem to come up repeatedly:

1. They can slow the iteration that’s at the heart of creating great products. If the same person is designing and implementing, the feedback cycle takes place within that person’s head. Even if product managers have equally good ideas, they’re likely not able to experiment with as many of them.

Patrick challenges the notion that the decider and the doer must be separate people. He believes that if the deciders are also the doers, the team learns more quickly. I’ve written about this in “Strategy vs Execution” is not a helpful distinction:

Instead of thinking of strategy and execution as separate, think of it as a feedback loop that tells us whether our strategy works or not.

3. Sanctuary Computer: PMs dilute specialty.

Sanctuary Computer is a technology studio that builds web applications for early-stage startups, hardware companies, and restaurant groups. 

I was hired as Sanctuary’s first full-time Product Strategist: a PM type that’s more focused on helping clients craft sound product strategy and less focused on helping developers stay on track.

Before I was hired, Sanctuary collaborated with freelance product strategists when they worked on open-ended client projects. They (I’ll be using “they” instead of “we” since this was before I started) were adamant about not hiring strategists and designers since they were known for being a best-in-class development studio. Hiring a PM would dilute their specialty. So for four years, they didn’t have a PM. 

This changed in August 2019.

Sanctuary kept receiving more inquires about open-ended projects, as a result of being design-savvy and building large products like a phone designed to be used as little as possible. They realized that they could use a product strategist to shape these open-ended projects into a more concrete product backlog that their devs could run with.

So, they started looking for their first in-house product strategist. I feel fortunate to be their choice.

Are PMs even needed?

Companies that don’t have PMs bring me to an existential question: 

Are PMs even needed?

It depends!

Let’s look at two situations.

Situation #1: You’re hired to change the culture when the culture doesn’t want to change

Perhaps you were hired because your company needs to fix its bad processes and reduce organizational debt. 

Willie Tran @willietran_

I truly believe the creation of a PM role was a band-aid solution to poor team processes that just happened to stick around.

Better ways of working could fix bad processes and reduce org debt. The PM role could spark better ways of working. But they need the support and safety from their org to facilitate change. From the first edition of The Overlap:

…if the architecture of the PM’s org isn’t designed to support the architecture of their product, the PM can’t ship a great product. PMs need to understand that their org’s architecture must support their product’s architecture. Otherwise, their product is at the whim of their org.

If your org is asking you to change the organization when it doesn’t want to change, you—as a product manager—aren’t needed. Instead, the organization needs to wake up to its resistance to change. If you take that task upon yourself, godspeed. It’s possible. Just difficult. That’s a topic for another newsletter.

Situation #2: You’re hired to shape, bet, and manage when the company is already doing these things

Let’s return to Ryan Singer’s three jobs of product management:

1. Shaping: Defining what the work is

2. Betting: Choosing what work to do and when

3. Managing: Coordinating other peoples’ time and effort

Someone needs to be doing the shaping, betting, and managing. The question is: is it beneficial to hire someone to do these three jobs? Or can these three jobs be done well by current employees?

Regardless of whether your company truly needs a PM, you may have asked yourself “So… am I actually needed?” Maybe you were hired to do the shaping, betting, and managing, only to realize that these three jobs are already being done at your company. Uh oh. What is even your job, now?!

Using “am I needed?” as an inflection point

To me, “Am I needed?” is a familiar thought. “Am I needed?” is a visitor that drops by regularly. “Am I needed?” forced me to reflect on my own needs around feeling needed and helpful, and how those needs can both serve and inhibit my teammates.

As a big believer in self-management, I strive to build capacity in others and avoid being a bottleneck. I try to make sure I’m generative instead of productive. I carry a bit of a consulting mindset into my role: my job is to work myself out of the job. If my team can prioritize and manage without me, I’ve done my job.

But if I’ve worked myself out of the job, what then? If my team is excelling at the jobs that a PM usually does, what do I focus on now?

Here’s what I’ve learned: don’t react to “Am I needed?” by making ourselves needed. That’s selfish. Instead, sit with that question. Unpack it. Understand what needs of yours aren’t being met.

If we react to this question by making ourselves needed, we will behave in a way that inhibits our team’s success. Some examples: 

• Not involving our team in any product decisions and making them on their own. 

• Being the sole decider for how the team spends their time.

• Believing we’re the hero. Attributing the product’s success to how we shielded and led the team, and ignoring the fact that our colleagues put in the hard work to build the damn thing.

• Shutting down feature ideas that come from developers or designers.

• Avoiding asking for feedback.

Product managers who behave this way should objectively observe what’s going on with them. Are these behaviors serving my team or myself? Am I projecting insecurity? What can I do instead to be helpful? Working with a coach or therapist helps.

You aren’t the CEO of the product. You are a vessel for others to be the CEO of the product.

My mind is the sky and my thoughts are clouds that come and go. “Am I needed?” is just another cloud that appears and drifts away. I learned to observe this thought non-judgmentally.

Regardless of whether my role is needed, I realized I can always be helpful. How? Facilitation.

Facilitation is the practice and skill of amplifying a team’s capacity to solve hard problems on their own. The Latin origin for facilitate is facilis, meaning “easy to do.” Through facilitation, we make it easy for teams to achieve their goals.

Facilitation is the most valuable skill a product manager can have. We are constantly working with groups to achieve outcomes, and there’s no better way of getting better at this than practicing facilitation. 

John Cutler @johncutlefish

Different models of product management.... A - Auctioneer / Translator B - Backlog Owner C - Context Builder / Catalyst #prodmgmt #ux #design #agile

As an org designer, I’ve been fortunate to work with folks who take facilitation seriously. I feel lucky to have gotten exposure to great facilitation. I feel lucky to have been forced to exercise this muscle: I wanted to learn how to facilitate well so that my clients would make progress towards the organization they wanted to be.

Few product companies invest in their PM’s facilitation skills. PMs aren’t formally trained on it. PM interview processes put too much weight on presentation and strategic thinking and not enough weight on facilitation. Hiring managers look for “the MBA grad who knows some programming” or “a designer who knows some code”, which leads to hiring PMs with little facilitation experience.

Adam Thomas @TheHonorableAT

No one cares about how well you can dig into SQL if you can't go in a room with a bunch of folks and come out with progress. Why the FUCK do we act like we care more about SQL than facilitation skills when product people are together and or hiring?

Facilitation is the most valuable skill a PM could have. When people say “PMs need to be able to lead without authority”, facilitation is the vehicle that drives us to do this. 

Matt LeMay @mattlemay

9. I cannot stress this enough: that facilitative work is often *the most valuable part of real-world product management*. But it is rarely acknowledged as such.

Getting better at facilitation requires serious practice

If you want to be a good facilitator, practice it seriously. Facilitate bad meetings and learn from it. Collaborate with challenging stakeholders who often disagree with you and believe they’re always right. Help others who facilitate workshops and unpack what made the workshop go well.

It takes decades to become a great facilitator. The best facilitators I know aren’t product managers. They help groups navigate topics like race, gender, religion, and social issues. Some are even zen practitioners!

I’m nowhere close to that level. But I do want to offer four tactics that have helped me improve:

1. Co-facilitate with experienced facilitators. Find a colleague who runs awesome meetings (it could be a designer, developer, a PM, or a leader), and offer to help them run any meetings they have. Share your intent to learn, and be willing to take on any prep work that they’re happy to delegate. You learn facilitation quickly by doing it with someone experienced.

2. Facilitate towards outcomes, not process. For every meeting you facilitate, write down the outcome you want to achieve before you plan the agenda. What do I want to walk away from this meeting with? What does progress look like? What questions can I ask to help the group achieve that progress?

3. Treat your meeting design like a product. Once you get into the habit of writing down your outcomes, evaluate whether your agenda/process/flow/format achieved your outcome. You’ll start to develop your tools and style over time by testing different tools, frameworks, and formats.

4. Learn to pick the right tool for the outcome. There are tons of facilitation tools out there. Liberating structures. Gamestorming. Fun retrospectives. Integrative Decision-Making. Choose the tools that best fit the problem or outcome at hand. Eventually, you’ll find ways to improve the tools that you read about, make some tweaks, and ultimately develop your style.

If you’re a good facilitator, your team will learn to facilitate themselves. Your team can solve hard problems, prioritize, and make tough decisions without you in the room. That’s the beautiful irony: your goal is to help your team not need you. Being not needed is the most valuable thing you can do for your team.

---

What I’m reading

1. Consultant as Capacity Builder.

This piece invites consultants to be capacity builders, not just problem solvers. I think this lesson applies to PMs too. Great PMs aren’t just problem solvers—they’re capacity builders, and they use facilitation as a way to build capacity.

2. When to hire your first product manager. (💸 Paid post 💸)

If you read The Overlap, you might also like Lenny’s Newsletter. He dives deep on when to hire your first PM—and when it might be too late.

3. Adaptive organizations are like an octopus.

We humans can't seem to adapt to emergent change fast enough or with an eye to the future, but Octopuses have evolved in relation to uncertainty. They can not only adapt to a given moment but can come out better on the other side.

4. Spatial Software.

This made me feel like all the hours I played video games as a kid was worth it. This essay is a fantastic read on how software can leverage space. After all, the real world isn’t a 2D screen.

5. When to software.

People less familiar with building software tend to think that software is the solution to everything, while people more familiar with building software are skeptical of software as the solution. Conor Davidson writes about how building software at scale is like working at a smoothie shop: if we prioritize efficiency, we lose flexibility. It’s all about balancing both, and knowing when to prioritize one over the other.

Job opportunities

Alex Nemeroff @nemy

I am hiring for three key #Product roles at MTTR: Head of Product Design, Director of Engineering, and PM. Come build a new media and community platform helping people *understand* the stuff that truly matters — and each other. willitmatter.com Job descriptions👇 1/5

willitmatter.comMTTR homeUnderstanding over Information. Discourse over Discord. Empathy over Hostility.

MTTR (pronounced matter) is hiring three product roles to help them launch their MVP:

1. Head of Product Design

2. Director of Engineering

3. Product Manager

MTTR combats the misinformation, overwhelm, and antagonism that news creates today. They are redesigning the way we learn about universal issues and aim to foster a safe space for difficult conversations about these issues.

Important problem space, good people. Pass it along to folks you know.

See you in two weeks.

–tim

First image sourced from this link.