I first encountered the term “shit umbrella” several years ago when I was a junior product manager. “Shit umbrella” was a popular buzzword at the time, and I thought it was the perfect phrase to encapsulate the sheer volume of requests, information and criticism I was handling each day. At that early stage in my career, I was often overwhelmed. It was empowering to imagine myself as a dutiful shield between the engineering team and all the crap that went on behind the scenes. Anyone who has worked directly with developers (or is one) knows the feeling. It put a positive spin on the stress I was feeling.

I wore my “poop parasol” status like a badge of honour.

That was years ago. But lately, I’ve found myself reflecting on this idea once again. Although I still think it’s a valuable metaphor, I’ve realized there’s more to it than simply sheltering the other members of your team.

What does it mean to be a shit umbrella?

Here’s what I remember about the day I first heard of the shit umbrella.

We were redesigning a UI, and it was my responsibility to present to the senior exec team. This wasn’t just my immediate bosses. It was the C-level, seasoned team. I didn’t really know how to effectively present to executive stakeholders, so it was a huge learning experience. I didn’t understand that they typically don’t—and shouldn’t—care about every little detail.

Basically, they picked my presentation apart—a major lesson in presenting to higher-level decision-makers. I remember leaving that meeting feeling super frustrated. But I also realized how glad I was that the developer who had been working on the UI—and agonizing for weeks—wasn’t in the room with me. He would have felt even worse. Hundreds of hours thinking about UX can be erased in one second by virtually anyone other than the person who put in the time.

I returned to the office and explained what had just occurred to my developer/partner-in-crime at the time. There was, after all, some good feedback that came out of the presentation—even if the delivery was a little harsh. I was still in shock and a little riled up, but I managed to filter out the worst comments and put a comedic spin on the whole mess.

At some point during the conversation, he smiled and said: “You’re my shit umbrella.” I was not pleased; I had never heard the term. But he explained the backstory and sent me a few articles.

Being a shit umbrella means protecting your team members from all the confusing, well-intentioned (but often distracting) requests and nitpicks. As Marty Cagan put it:

In the Umbrella model, which is what I believe is absolutely necessary for success, you have a critical role in protecting the product, the team and your customers from these well-intentioned but harmful forces. Now, please don’t misunderstand. Not all requests are harmful. Some will help, and many won’t matter one way or the other. So you’ll need to pick your battles.

What was nice about “shit umbrella” was that there was a term for what I was experiencing. I started to feel like I was doing something right if I was experiencing the plight of other PMs.

Why I’m still a (proud) shit umbrella

There is something really rewarding about being a buffer for your co-workers.. Depending on your personality type, you want to be in control of the situation. Many product managers are Type A—we really want to be in control of the situation. (We also might be masochists…but that’s another issue.)

However, being a shit umbrella isn’t just about shielding your co-workers from “harmful forces.” It’s more complicated than that. I’m talking specifically about how product managers are translators for the rest of the organization.

The part of my subconscious that listens to my mother is keeping me from taking this analogy any further, but as you build alignment and understanding, things get… smoother.

When you’re facing pressure from all sides, it’s your job to translate those demands into actionable imperatives for the engineering team. I look at the shit umbrella as a “translation” layer, not just a “deflection” layer. You’ve got stakeholders (including C-level), then the umbrella, then the devs. You could have lots and lots of noise coming from C-level, but then through internalization and transformation by the product manager, all that noise (*hopefully*) becomes a few quiet, manageable pieces of feedback that eventually get back to devs. It’s an act of translation.

If you’re an umbrella for too long, you ain’t doing it right

As Facebook’s Julie Zhuo rightly points out, the term shit umbrella has some pretty glaring limitations. A lot of the “shit” isn’t shit at all, but just the natural chaos that accompanies building a product and growing a business.

For me, the limitations with the term also relate to the evolution of your team. Especially when there is a new team dynamic (either because a team has just been created or restructured), there is a particular need to shield certain parties for efficiency. This allows you to figure out what those parties need from each other to interact effectively. While that’s being figured out, the product manager takes the shit. (And also helps figure out where it’s coming from and how to resolve it.) The part of my subconscious that listens to my mother is keeping me from taking this analogy any further, but as you build alignment and understanding, things get… smoother.

What was nice about “shit umbrella’ was that there was a term for what I was experiencing. I started to feel like I was doing something right if I was experiencing the plight of other PMs.

Where does all the shit come from? For us at Roadmunk, until recently, it was the design process. Everyone knew what they wanted a feature to look like. We often have a natural tendency to create ideas visually in our heads before we can articulate what problem those ideas are meant to solve, and it’s easy to get attached to these concepts. Because of this, there was often a ton of pushback, rewrites and wasted time—some of which needed to be deflected.

So we developed a process: a written, step-by-step guide to fulfilling our design requirements. Most importantly, any reference to a specific design decision or workflow was deconstructed to expose the use case it was trying to address.

I’m sure it’s a common practice, but in our case the design process was inspired by the most common response from our development team: “What is the problem you are trying to solve?” This question used to drive me crazy (and even inspired many ego-driven reactions), but the answer usually starts with “As a user…” To my chagrin, I’m a convert. It is ridiculously helpful. Once we started articulating and prioritizing use cases, it became easier to slot each use case into a list of all the other use cases, relative to their importance. This is clutch for two reasons. First, the team can be painfully specific about the concept in discussion. Second, if the topic is lower in priority than another use case, the team can elect to solve higher-priority items first.

Before we had this process, there was a shitstorm of input. We needed an umbrella—or we’d be drowning. As we gradually worked out our process, that structure sheltered us from the insanity. Now that the process has evolved, we can go hold umbrellas elsewhere.

Basically, the umbrella became obsolete. That should be the goal! I believe that the useful result of this role is creating a positive space to develop processes, communication styles, and common understandings between team members that eliminate the need for the “umbrella” in the first place.

Since being a product manager heavily relies on translation, we provide over 20 customizable roadmap templates meant to make your role easier. Click here to try a template today!