Enter The World of Product Management

One of the best parts of being a Product Manager — besides solving customer problems, of course — is getting to work with every department within the company. On any given day, I talk (or email or Slack or . . .you get the idea) with our Customer Success teams, senior execs, Sales, Engineering, and of course Marketing.

If you consider the total Product Development Lifecycle, there are two main interaction stages between Marketing — generally Product Marketing — and Product Management. For simplicity, I’ll call them Inbound and Outbound.

  • The Inbound function works to get the voice of the customer, uncover market needs in new markets or market segments, and does user validation via surveys, focus groups, social media outreach, etc. prior to building the product. That function sometimes lives in Product Management, sometimes in Product Marketing, and sometimes in more technical fields, in R&D. But in software, this is generally some combination of Product and Product Marketing.
  • The Outbound function is responsible for getting the word out once the product (including MVP or beta) is built. This is where Product Management works closely with Marketing on messaging (what story do we want to tell the market?), Sales enablement (training the Sales team to effectively tell that story in their interactions with prospects), and collecting customer feedback for improvements via surveys, social media, events, etc.

The Pragmatic Marketing Framework does a great job of outlining all the various tasks associated with defining and launching a product. Which tasks fall to which team are ultimately up to each company to decide.

 

 

Pragmatic Marketing Framework

Are We Speaking The Same Language?

Some of the challenges that Product Management encounters in working with Marketing can be around mismatch of market characterization. For example, Marketing may think in term of demographics (age, gender), Psychographics (attitudes) and personas. All of these can be useful in understanding who the users are, how and where to reach them, and find large enough market segments to make Marketing outreach cost-effective.

Product Managers must go beyond personas and understanding users’ needs to be effective in building products and features with a high adoption rate.  For example, a “developer” persona doesn’t tell me, as a Product Manager whether they know anything about sending domains and DNS — elements that are critical to getting up and running with sending email and getting into the inbox; and therefore, whether their needs require a step-by-step wizard for setting up DNS or is clear documentation all that’s required.

This challenge, of course, goes the other way as well. Once a product or feature is developed, we Product Managers will very enthusiastically talk about all the nitty gritty details of what it is, what it does, how it works, and why it’s awesome . . . often to the blank stare of our Marketing counterpart asking “what does this mean for <insert persona here>, how does it make their life better, and why are they more likely to buy our product/service as a result?”

Small, Practical Steps Make A Big Difference

Like any growing business, our team at SparkPost is still figuring out how to get the right working balance between Product and Marketing roles as we’ve scaled. But we’ve found even small steps can make this challenge more manageable.

For example, for every feature we work on, Product fills out a quick template in Jira that addresses what problem the new feature solves, for what use case, and what new thing the customer will be able to do as a result. This helps get Product, Engineering, and Marketing on the same page in terms of what’s being built and why.

We also have a structured weekly check-in where we review everything in flight. It’s an opportunity for people from across the company (generally a representative from each team) to ask questions. Finally, we’re working on planning further ahead so that even before we write the code, the Marketing plans are underway.

What else can we be doing? Send us a tweet we would love to hear from you!

—Irina

Sr. Lead Product Manager

Product Emails Need a Focused Team

I recently talked with the teams at a couple SaaS businesses who are responsible for the notifications and other emails their products send. It was eye-opening to hear how they think about the infrastructure and business requirements for app-generated email.

Naturally, many aspects of the approaches they’re taking are specific to their particular apps. But one issue they shared was an understanding of the key roles on their product email team. They identified a core group of responsibilities for getting welcome and onboarding messages, user invites, activity notifications, and account management and security alerts specified, implemented, and delivered.

Your Product Email Team’s Starting Lineup

Here’s what that “email dream team” for SaaS products looks like.

  • Product Manager. Even a dream team of all-stars needs a captain. The product manager defines the requirements for a product email team for a very simple reason: the most successful SaaS businesses treat email notifications as a core product feature. For large SaaS platforms, it’s even likely that the product manager’s entire focus may be on developing an app notification service that includes email along with other channels such as SMS or push.
  • Technical Lead. In the most effective product email teams, the technical lead works the product manager to design and build the technical foundation for triggering, generating, and processing data for email notifications. This architect will work a team of developers to implement the framework and functionality needed for product emails. As such, she or he’s responsible for ensuring that issues like reliability and scalability of product emails are addressed.
  • Growth or Product Marketer. Working hand-in-hand with a product leader, these marketers should lead the messaging, design, and cadence of app emails—as well as work with the rich data these emails generate. In many ways, understanding how to drive user action by connecting the content of product emails to the app’s value proposition is the ultimate distillation of their core business responsibility.

Like the classic three-legged stool, these three roles are necessary to support email notifications in just about any SaaS app. The good news is that these roles already make up the core of your product team.

The Product Email Team’s Bench Players

In combination with a cloud email delivery/infrastructure-as-a-service provider that handles the backend message generation, delivery, and data, these leads might actually be all you need. But if your business still operates its own infrastructure, the email team also needs to include some specialized “postmaster” roles that can be challenging to fill.

  • Infrastructure Admin/Ops/Security. The real and opportunity costs required to administer systems in a data center are well understood today. Email servers are especially susceptible to scalability, security, and downtime challenges—even more so when dealing with the performance characteristics needed for product email notifications. It’s important that a product email team understand the trade-offs between managing this themselves vs. relying on an email API.
  • Deliverability Manager. To be honest, email deliverability is a role most product teams are surprised to learn they need. After all, it’s natural to assume that email “just works” once it’s sent. But the reality is that getting messages to the inbox is surprisingly complex. (In fact, recent figures say 28% of all email is undelivered or lost in the spam folder.) Really experienced email deliverability managers are hard to find, but that expertise can make a huge difference for notifications strategy. Having it delivers a lot of value (and peace of mind).

One thing that stands out about this product email team is how much more cross-functional it is than most email marketing groups. But that makes sense—notifications and other app emails serve a different business need and have a completely different technical architecture than classic campaign-based email marketing.

In fact, I was struck that this email dream team looks a lot like the growth teams that have driven social networks and other big B2C platforms. I don’t think that’s a coincidence, when you consider how product emails affect user engagement, conversion, and retention—the key factors that drive growth.

Nearly every SaaS product sends email—does yours? If you’re on a SaaS product team, I’d love to hear how you handle these needs and roles. Ping me on Twitter or leave a comment below. I’d love to chat.

—Brent
@brentsleeper