So, what the heck is *outbound* product management, and should you have this function too?

When the executive recruiter pinged me about joining Google Cloud to lead an outbound product management team, my first question was: “um, what’s an outbound product management team?” After a year in the job, I now know. Sort of. I’ve saved a list of questions people have asked me, and figured I’d answer them here.

As an aside, smarter people that me have done a good job explaining the fundamentals of product management itself. Read anything by Melissa Perri—her book is great, and see this post how a product owner is different than product manager. Also dig into the tremendous archives of Marty Cagan to learn what product managers should be skilled in, and what a good job description looks like. And John Cutler is a must-read for regular, insightful perspectives on product thinking.

Here’s what I get asked fairly often about outbound product management.

Q: How are outbound product managers different than “regular” product managers?

Both types of PMs have foundational product management skills, technical expertise, and a focus on product success. Outbound product managers are product managers who are primarily focused on go-to-market activities and customer interactions. We don’t maintain a product backlog, partner with engineers to plot out a given release, or directly own the product strategy.

Instead of working with one product or subsystem, outbound PMs often work across a portfolio of products. We champion the portfolio and products to internal and external audiences, and spend a significant amount of time talking to customers, partners, industry analysts, and field personnel. Outbound PMs take what we learn and feed it back into our overall portfolio and product strategy.

Q: What’s the purpose of the team?

I describe the mission of our team as “increasing the adoption and fit of our products.” The “adoption” part is outbound focused and includes customer briefings, analyst updates, field training, partner enablement, content creation, and more. The “fit” part is how we take this broad set of things we learn about, and ensure we have a relevant, customer-focused strategy for every product in the portfolio. That means doing things like advocating for new products and features, owning and updating roadmaps, and helping construct cross-product strategies.

Q: Where did outbound product management come from?

I don’t know exactly. I think that our CEO Thomas Kurian had this at Oracle, and brought it to Google Cloud because it worked well. I’m told that other software companies had this practice, or a variation of it at different times in their history.

I’ve seen more and more people put outbound PM on their resumes, so I’m not sure if that’s because they had that actual title, or if they did related work and want to align more closely to my job description 🙂

Q: Isn’t this just a marketing team or an “office of the CTO” type team?

We do a bit of a lot of things. From what I’ve observed, the biggest difference between outbound product management and its sister teams (product marketing, office of the CTO, developer relations) is the direct alignment with product management. I sit in engineering reviews, talk daily to product managers, contribute to our product roadmap artifacts, and help create our product strategy. The related teams do wonderful work broadcasting information and engaging outbound with customers. We do parts of that, but also the inward-facing work that takes what we learn from being outbound, and make the products better.

Q: Where do you sit in the org chart?

Outbound product management sits in the product management org, and outbound PMs are just “PMs” in our job ladder. At times, I feel like I answer to a dozen different people, given that OPM sits at the center of so many things.

The person actually stuck managing me is a VP of Product Management. When performance review time arrives, we’re evaluated alongside the rest of the product managers. That said, we do different things that inbound PMs, and I’m working to ensure that it’s accounted for during perf and promo cycles!

Q: How is the team arranged?

I think I was the first outside hire for outbound product management at Google. Now, there are 40+ folks, spread across 8+ product areas (e.g. Storage, Networking, Compute, Analytics, AI, App Modernization). Teams range in size from 2-10 individuals.

Currently, my team is arranged by product area. We drive our developer tools (Cloud SDK, Cloud Code), serverless (Cloud Build, Cloud Run, Cloud Functions, Cloud Workflows, App Engine), and container services (GKE, and Anthos). Individual outbound PMs focus on a given product (e.g. GKE) or product area (e.g. CI/CD).

Everyone pitches in on cross-cutting efforts like analyst briefings, events, and joint messaging. Subsets of the team have expertise in different areas, and pair up to tackle those projects.

Q: What skills do you hire for?

It’s taken me a year to build out the team, so I’m not sure I’m a good person to ask. But basically, the best outbound PMs are continuous learners who are good communicators, customer-focused, and technically savvy. Ideally, candidates have meaningful product management experience, worked in the enterprise software space before, know the industry landscape, and have outstanding soft skills. That said, I’ve hired people who were new to cloud, people who hadn’t officially been a product manager before, and people who were in different roles within Google. We have a fun, diverse team of people with complementary skills who think strategically while learning constantly.

Q: What does your team do, day to day?

Let’s look at last week, shall we? Our team worked on the following things:

  • Delivered 20-ish talks to individual customers.
  • Helped a handful of customers onboard into private previews of new product features.
  • Updated product roadmap artifacts based on changes in priority for a couple of planned features.
  • Wrote announcement blog posts for multiple upcoming launches.
  • Hosted analyst inquiries with Gartner, Forrester, and Redmonk to learn about topics like software composition analysis, container management, and developer needs.
  • Filled out multiple analyst questionnaires and prepared for an upcoming hour-long presentation to Forrester for an upcoming “Wave” evaluation.
  • Created competitive overviews to summarize the container platform landscape. One is given to the field, the other is for an offsite with GKE product leadership.
  • Published video assets created for the Google social media team.
  • Did product roadmap reviews and Q&A sessions with our field teams and Certified Fellows community.
  • Drafted keynotes for upcoming public events.
  • Conducted multiple interviews of product management candidates.

Q: How do you measure success? What are your OKRs?

An inbound PM often has objectives and key results related to launching a given product and landing it in the market. For our outbound PM team, the four objectives we agreed on for 2021 include:

  1. [Enablement] Educate and enable the field, partners, and customers for success on product portfolio
  2. [Revenue] Engage with customers to meaningfully improve the adoption of product portfolio
  3. [Positioning and Strategy] Unify the positioning and strategy of the product portfolio across internal teams, partners, customers and developer communities
  4. [Team] Build an outbound PM organization that leads by example with expert people, repeatable systems, and inclusive culture.

Each of these has some very specific key results to track progress towards those objectives. And it’s all a work in progress, so who knows how this will evolve.

Q: Should every software company have an outbound product management team?

No? When I ran product management at a previous company, our product managers did both inbound and outbound activities. There wasn’t a separate function. This specific discipline might make sense for your org if you have VERY technical products and want help landing those in the market and ensuring fit. Or, add outbound PMs if you have a very broad portfolio of products and need to unify the market positioning while better integrating the internal strategy. Outbound PM might also make sense if you have PMs that need to be very focused on day-to-day prioritization and delivery, and want help getting constant customer feedback and educating internal teams (e.g. field staff, marketing) about product capabilities.

For some, outbound product management may be a temporary team, for others, it’ll be a durable part of how they plan and deliver products. It’ll be interesting to watch!

Q: Are you having fun as an outbound product manager?

I am. Honestly, I’ve enjoyed every job I’ve ever had. They each scratched a different itch. This one is unique, however. It requires the combination of every professional skill I’ve developed to this point, while still teaching me new ones. It’s a privilege to work here and lead this team, and I look forward to starting each day.

We’re still hiring for a few OPM teams, so if this sounds interesting, throw your hat in the ring.

Author: Richard Seroter

Richard Seroter is Director of Developer Relations and Outbound Product Management at Google Cloud. He’s also an instructor at Pluralsight, a frequent public speaker, the author of multiple books on software design and development, and a former editor plus former 12-time Microsoft MVP for cloud. As Director of Developer Relations and Outbound Product Management, Richard leads an organization of Google Cloud developer advocates, engineers, platform builders, and outbound product managers that help customers find success in their cloud journey. Richard maintains a regularly updated blog on topics of architecture and solution design and can be found on Twitter as @rseroter.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.