In 2020, during the COVID-19 pandemic, when I was first forced to use Google Meet to speak with a few teams, I was seriously underwhelmed. The reason was quite simple: the product barely worked. I’m not talking about weaknesses in fringe features but literally, the audio and video did not work reliably. Although my regular browser is Firefox, I used Google Chrome to load Google Meet, surmising that staying withing the native Google ecosystem would result in good performance. Switching browsers made absolutely no difference. The video quality was so bad that only the person actively speaking would come through in a badly artifacted feed; everyone else would be frozen or turn into a black rectangle. I couldn’t see why anyone would suffer through this terrible experience that was not only worse than Zoom, but worse than WebEx, GoToMeeting, or even (gasp) Verizon BlueJeans. (It takes real effort to make software that’s worse than what a telco can provide.)

Because of my poor initial experience with Google Meet, I cringed when first joining Chainguard – a company founded by ex-Google employees who have naturally standardized on all things Google. But six months into using Google Meet, not only am I tolerant of it, I’m actually a huge fan. I’m now a fan to the point where I think Google Meet – and Microsoft Teams – will be the ultimate winners in enterprise videoconferencing. Zoom, I’m afraid, is going to fall by the wayside and die a slow death as both a product and a company.

As a product leader, time is my most valuable currency. Time spent on tasks not related to the unique value I can provide to the company is wasted. And the unique value product management creates is in our unique insights and a point of view. These insights come from meeting with customers to understand their needs and combining that with an understanding of the market to develop and maintain a product strategy and roadmap. We then iterate on those artifacts by testing product ideas (and sometimes the strategy & roadmap) with trusted customers, bringing additional features or products to market, measuring and reflecting on the outcomes, and doing it all again. These activities should not be new to anyone who understands modern product management. They are table stakes.

Unfortunately, we have a major problem in companies today. Product management, and our ability to conduct these activities, is being strangled by well-meaning but ultimately ineffective support functions. Firms today are bloated with program managers, program analysts, sales operations managers, GTM operations managers, product operations managers, managers of planning and operations, technical project managers, and the like. Unfortunately, whenever I encounter such titles in the wild, I get ready to have an adverse reaction because while many of these individuals purport to want to help, the majority of my engagement with them leaves me disappointed. Instead of undifferentiated heavy lifting getting removed from my plate, what invariably ends up happening is that not only is there another cook in the kitchen slowing down meal prep, but I now have 3 additional TPS reports to fill out every week.

All of this bureaucracy creates drag on innovation. But the problem isn’t with the specific ICs that I mentioned above by title, who like I say, are well-meaning but ultimately just following directions. The problem is with operations leadership. There are three major things that I see operations leaders getting wrong today that hurt other functions.

I recently attended the Mind the Product conference in San Francisco, marking my return after six years. As a senior product leader now, my perspective on product management has evolved significantly: In 2017, I was an individual contributor, essentially a Product Manager II still learning the ropes, and now that I’m a senior director of product, I don’t find talks about “what makes a good product manager” that useful, since I have my own strong opinions about that. While the conference covered various aspects of product management, two talks particularly stood out to me: Aniket Deosthali’s presentation on the AI Product Arms Race and Janice Fraser’s radical approach to leadership, based on her recent book Farther, Faster, and Far Less Drama. Let’s dive in.

When I was first introduced to the concept of the message house as a product manager, I saw some value in it, but I found it way too abstract to be useful. Perhaps that’s because I was shown message house templates that look like the following:

There wasn’t any guidance attached as to when to develop these, what level of resolution they should be at, and more importantly, after the messaging is completed, who should use the completed artifact, when, and for what activities. Unfortunately, many frameworks used in marketing seem to be academic exercises with little applicability to real-world activities. Even if “plans are worthless, but planning is everything”, shouldn’t the plans that are developed count for something, even directionally?

In the spring of 2009, I created my first Twitter account. To be completely honest, I didn’t understand Twitter’s utility at first, having previously ridiculed my wife, the early adopter, for wasting time on a tool purpose-built for oversharing-by-text-message. (Remember when you could post to Twitter by texting TWTTR on your phone?) I eventually came to perceive some value in Twitter, though I’m not entirely sure why I got hooked on it even though I had few people to connect to. Perhaps it was because I’d been keeping a blog in some form since 2000 or so (you’re reading it) and so I was more comfortable putting thoughts out onto the Internet with little expectation of response or engagement? Either way, Meredith and I loved the tool so much that we eventually turned our kitchen blackboard wall into a miniature version of Twitter, giving the house an “account” and using the Tweet format to leave messages for one another, as well as imagining observations the house would make if it could. (Mostly about the cats.)

Sorting through customer feedback on your product is one of the main duties of a PM. Once your product is successful at scale, you will need to move beyond analyzing and responding to individual, discrete pieces of feedback, and trying to find patterns in that feedback: patterns that help you to discern users’ true needs (problems) and not their wants (solutions).

Unfortunately for you as a PM, customer feedback tends to come in the form of solutions. This isn’t to blame users, far from it: that’s the most tangible interface for them, so exhorting users (or even your technical sales team) to “bring problems, not solutions” is unlikely to solve the issue. Defining the problem is your job, not your customers or your SEs.

If you are currently my customer, and you see the above headline, you might be understandably alarmed. “I spend my valuable time meeting with this guy, and he brazenly admits that he ignores half of what I tell him. Why should I take his call again?” Let me be the first to assure you that this is not what I mean. For one thing, forgetting is not the same thing as ignoring. For another thing, I am actively listening to whatever you are telling me in the moment, and truly trying to analyze and synthesize it. I am also writing down the most substantial or insightful things you say, with pen and paper (because studies show that this physical act, rather than typing out notes, is the best way to retain information). But after that? I probably won’t remember exactly what you said, and I’m definitely not taking immediate action to prioritize anything. That’s because successful product management is about pattern-matching and sense making across a market, not individual customers, and any individual data point, even from our most important customers, might be an outlier. Which leads me to the practice that I call selective forgetting.

As a product leader, I have been using PR/FAQ in some form with my teams since about 2016. While I’m heartened that there is now a robust body of work describing the artifact, there is much less information about when and how to use it effectively in practice. That is what I intend to convey in this article.

There’s an overused and overloaded aphorism: words matter. Usually, this phrase is used to state that the selection of words has particular import (true). Yet to a product marketer, the definitions of those words and a company’s alignment around them is much more important. I don’t just mean the terms that you use to market your products (though I’ve had many vigorous arguments about “incident management” versus “incident response” that I’ll save for another day.) I mean the terms that you use inside your company to refer to the various parts of the kit you produce – your firm’s products and solutions. “Products” and “solutions”, though… what the heck do those terms mean, anyway?