“It’s All Product”: 4 Critical Product Functions You’re Missing

From the moment I started as a Product Manager up until this very second, it’s been a constant learning process about what it means to be in a product role. The role differs a lot between small and large companies, and also between tech and non-tech focused companies.

Having been part of a team that went from very small to not-so-small, and having worked with big companies as partners on projects, I’ve done things that at some point I didn’t consider “Product Functions”, including:

  1. Writing marketing copy
  2. Customer support
  3. Helping developers with their database design

Among other things. One thing I realized was that I should never think of anything as not a product function.

It’s All Product. Period.

Don’t get me wrong. I’m not saying you have to decide which exact font size is to be used in promotional material, or personally investigate every bug that comes in. But you must care about the end results of these things:

  1. Is the font-size that is currently being used good for our mainly over-65 audience?
  2. Is the bug in the product a one-off?
  3. Will it affect multiple users or just this one?
  4. What caused it in the first place?

Not caring about these things will come back to bite you.

My rule of thumb

My rule of thumb is: if the customer is going to be anywhere near it, it’s a product function. Again, I’m not saying we have to get all up in other teams’ grills, it’s just that at the end of the day the product team is responsible for the entire customer and product experience (and a lot more).

Over the last few years I’ve seen some things frequently ignored by product teams. I’ve ignored all of these in my early days. These things are surprisingly ignored in both small and large companies, just for different reasons - ranging from PMs being stretched too thin to them being so silo’d they wouldn’t know if the entire sales department went on vacation. Based on what I’ve seen, here’s my list of 4 oft-ignored product functions. Whether you currently follow none or all of these, you should find the anecdotes and stories themselves helpful.

#1: Provide domain expertise to influence Sales & Marketing messaging

I cannot stress how important this is, especially in smaller companies. Product teams by definition are supposed to know the product inside and out. From the moment a potential customer hears a sales pitch or sees a marketing ad on Facebook, your product is on their radar, and what they see in the ad is what they expect to see inside the product. If there is anything off between what the user thinks the product is and what it actually is, you’ve lost a potential customer.

If an ad says that your app allows people to organize all their photos in three easy steps, there better be three easy steps exactly the way they are described. There shouldn’t be three easy steps followed by one trivial step followed by one simple email verification.

Some time ago, I was working with a marketing colleague of mine, and he was developing copy for a landing page for a campaign. Our product was a web-based automated teaching system that broke a math problem down step-by-step for a student when they got it wrong, walking them through a problem just like a teacher would. My colleague wasn’t from the education world and his copy for an email campaign to teachers had something to the effect of “Assign concepts and assess your students.”

On the face of it, it doesn’t seem like there’s anything wrong with that copy. However, “assess” is a very loaded word for teachers, and it implies that we are conducting some sort of diagnostic or summative assessment for their students. Our product didn’t do anything of the sort at the time (it does now), so teachers signing up for the product would have been thoroughly confused. If I hadn’t made it a point to know what was being said about the product in the email (and in ads and / or sales pitches in general), it would have been a very unsuccessful email campaign.

Influence the messaging around your product and make sure it gels with what your customers experience within the product. Sometimes team members outside the product and development teams are not completely educated on the product, just the overall business idea. It’s the product team’s responsibility to educate them.

#2: Ensure the developers have context and know what they’re building

Sometimes, developers build products the same way some analysts decode parts of a message at the NSA: they never see the whole message so they can’t piece together what they are doing in its entirety.

This isn’t the developer’s fault, for they will build what the specifications say, and you can’t expect everybody to be curious about everything. However, the onus is on the Product Owner, especially in a small company, to make sure that the developers know the whole picture of what they are building.

This can be helpful in catching potential technical limitations early on, among other things. A developer at a friend’s startup was working on a widget prototype once, but approached it not knowing that the widget could appear multiple times on the same page in the final product. Sure enough, the widget he built couldn’t be used multiple times on the same page, causing a two week delay, which in small-startup-time is like a bajillion years.

Developers should know what they’re building, what it’s going to be used for, and who’s going to use it. Facilitating that is a product function.

#3: Actively be on the lookout for partnerships / integrations

We live in a pretty swell tech paradise, where products talk to each other and partner with each other all the time. Facebook integrated Lyft and Uber into Messenger. Splitwise allows you to pay your friends back with Venmo.

The right partnership can make your product 100x more useful and / or bring a lot more eyeballs to it. Product teams know the products best, and historically, Product Managers who’ve pushed for and secured successful partnerships have gone on to do great things for the products and for their careers.

One of the things that made Sundar Pichai stand out on his way to becoming Google’s CEO comes to mind. Long story short: Around 2006, when he was just 2 years into Google, IE7 was released, and Microsoft just went ahead and changed everybody’s default search engine to Bing, causing Google to lose millions of customers. Until then Google’s desktop software (Google Desktop, Google Toolbar, etc) hadn’t really been a huge priority for Google. Pichai jumped at the opportunity and made deals with computer manufacturers to get Google’s software bundle preinstalled on their computers. This partnership made Google the default search engine on a lot of PCs again (or at the very least prompted the user to set the default search engine).

#4 Take charge of support and support adjacent processes

Some of you might be thinking “Does this even need to be said? Of course support is a product function!” It is, no doubt, but it’s gone wrong so many times, not just at my workplaces, but with my friends’ and their friends’ and their moms’ workplaces. That’s a boatload of workplaces. Enough to warrant being #4 on my list.

Just like viewing a product ad is part of the customer experience, support is an integral part of the customer experience, and the product team has to dictate how the support experience will shape up as the company grows.

I’ve seen two really bad support practices being followed in my experience:

a) The support team members taking the requests have NO idea how the product works and try to serve the customer, causing a lot of customers frustration, and

b) The developers turn into shadow support because of no well defined support process, and have to deal with random issues directly (usually a small company problem, but you’ll be surprised I’ve also seen this at big companies)

Sometimes you have both a & b and every issue leaks through to the developers. At that point support teams stop providing value and become more of an obstacle to “actual” support provided by developers.

These practices frustrate the customer and waste precious developer time. It’s not the fault of the support agent, and it’s not the fault of the developers. It’s the product team’s fault. Any “process” that connects customers to the company and vice-versa is no doubt part of the product experience. If you don’t support IE and one of your customers comes in with an issue because they used IE9, don’t just sit around and laugh “at their stupidity.” It’s on you, product folks, to make sure it’s crystal clear in the product that you don’t support IE9.

As I’ve said before, these four product functions are overlooked by small and large companies alike. Having the product team actively perform these functions goes a long way in not just making customer happier and growing the company, but also boosting productivity (no pun intended) of the entire team. Sales and marketing can make a much bigger impact when the product completely gels with the messaging. Developers can contribute more when they have the bigger picture.

Sometimes when deadlines get rough some of these might slip. Sometimes you might not know what to do about your marketing colleague’s recommendation that you ship your customers a free pony. If you ever think “Hmm, I wish there was a way to…” then you should take the initiative to make sure the right people get on it. When in doubt, remember: It’s ALL Product.

The Shetland Pony, which I considered buying for one of my customers after a really long day