Product is a Feature (of the Service)
PM humility and collaboration for fun and profit
TL;DR: In SaaS, the “Service” isn’t just Software. It also includes sales, marketing, support, documentation, billing, and more. PMs will be more effective if they spend some time improving the overall service, including parts of the service beyond product features.
Years ago when I first started doing Product work, I knew Sales, Marketing, and Support existed, but I viewed them as supporting players whose main goal was to get the product into customers’ hands and unblock them if they got stuck. My naive mental model of the customer relationship looked like this:
As I learned more about how B2B companies really worked, I realized that only inexperienced product managers took this myopic view. A great example was my first week at Splunk when I tried to install and use the product. Setup was confusing, documentation was limited, and some use cases required a lot of trial and error. How could a successful company’s product be so hard to get working?
So I asked a Splunk customer about this. “Sure, some things were hard at first”, he said, “but whenever I get stuck I just call tech support and they know how to fix it.” To me, requiring a support engineer’s help was a product failure. But to the customer, it was a minor annoyance. As long as he got unblocked, which part of the company did the unblocking didn’t matter.
Here’s another example from a few years later: at my first board meeting as VP Product at Cantaloupe, I presented two Product slides in a long deck that otherwise focused on financials and sales. I was excited to brief the board and expected many questions, but everyone just nodded and within a few minutes the meeting was back to cashflow, budgets, and churn risks. Like that Splunk customer above, the Cantaloupe board didn’t see the product as the sole focus of the company; instead, the *company* was the focus. The product was just one piece. An important piece, sure. But just one piece.
After that, I started noticing the breadth of customer interactions outside the product:
Our billing process was complicated and partly manual, which caused mistakes in customers’ monthly bills, which in turn created headaches and churn risk for the sales team.
Customers who interacted with Support on a regular basis were more satisfied than customers who tried to muddle through on their own.
Customer Success Managers kept finding smart workarounds for customers which helped us avoid building low-priority features into the product.
Salespeople would ask if they could use the promise of a particular new feature (which we were building anyway!) to help close a renewal deal.
I finally got it: in SaaS, the important “S” is the “Service”. The Software is just a means to an end. To deliver a service, a product is needed, but that’s not enough. The product needs to be sold and renewed, new customers need to be found and educated, technical questions need to be answered, the customer’s money must be collected (accurately!), and so on. Unless all those pieces work seamlessly together, customers won’t be happy and the service won’t succeed.
Here’s how I think about customer relationships today:
One can quibble about the size of each slice, but the fundamental idea is that the product is part of a service that contains multiple, inter-dependent parts. The product is a feature of the service.
Note that by “product” in the pie chart above, I don’t mean “Product Managers”. I mean, literally, the thing that customers interact with that was the result of hard work from engineers, designers, data scientists, PMs, and everyone else who contributed. My point is that in addition to a product, customers *also* interact with Support, Sales, Finance, Marketing, etc.—and all those parts can (and should!) work together to deliver a great customer experience.
OK, now I get it too. So what?
Thinking of the product as just one slice of the “Service Pie” seems like a minor thing, but it made it much easier to spot cases where the Product team could help the rest of the company deliver a better service. This led to many low-hanging-fruit wins. For example:
We built an “Internal Tools Backlog” and allocated a small percentage of total engineering capacity to proactively whittle away at the biggest pain points for the Finance and Support teams.
We met quarterly with the Support team to understand the top support issues, which we triaged together to decide which ones should be fixed soon.
The PM team started attending monthly Account Review meetings run by the Sales team, so that we could hear about deal-blocking issues earlier and help advise them how to work around customer concerns.
At the Sales team’s request, we scheduled work to improve the “demo site”, which made it easier for non-technical salespeople to deliver professional demos to prospects using more realistic data.
We started collaborating with Marketing to help them proactively plan PR around our every-3-weeks product releases, and to align product documentation with marketing messaging.
We started putting more effort into documentation for each new feature.
We got more methodical about sharing product updates with the company, so that salespeople and CSMs could train themselves ahead of time before we released new features. (Better documentation helped a lot here!)
I helped the Marketing team redesign the corporate website to better align with our mobile-centric product strategy.
A PM sat with the Finance team while they generated monthly bills. He was able to identify fixes—both in our billing systems and in Finance’s manual steps for customers with unusual deals—that helped reduce billing mistakes.
We hammered out unambiguous guidelines for how salespeople should (and should not!) talk about unreleased product features.
In other words, by thinking of ourselves as team players we started *acting* more like team players. The result: better customer experience, faster revenue growth, and much better relationships with our peers inside the company.
But wait, we’re already too busy!
You may worry that helping other parts of the company would distract PMs from improving the product, or would tie up too much engineering time. I was worried about this too. But in practice, having a company-wide focus changed less than 10% of what PMs spent their time on. For engineers it was more like 5%. And that 5%-10% paid for itself in faster sales and better cross-team efficiency. Plus it made work a lot more pleasant for everyone: less complaining, more collaborating.
Does this approach work in a big company?
No, at least not in my experience building B2B and developer products at Microsoft. In a small company, every team has the same scope. For example, Sales sells the same product that Product and Engineering design and build. In a big company, salespeople, finance, and (sometimes) marketing and support deal with multiple products. So it’s unlikely that any particular product’s PMs can make company-wide improvements to the overall customer relationship.
Many big companies have a centralized Product team, which in theory helps solving company-wide problems, and all BigCos obviously have PM and Engineering teams that maintain internal tools. But the most ambitious and skilled PMs, engineers, and executives seldom focus on internal-facing projects. This means that internal-facing teams are usually starved of resources and talent.
Also, human psychology is optimized for individuals and small groups. If your company has 1000 salespeople, they’re “out of sight, out of mind” for PMs and engineers. Psychologists even have a name for this: the identifiable victim effect. If a company has 10 salespeople, 5 marketers, 5 support engineers, and 2 accountants, you’ll probably see them every week and it’s human nature to want to help them.