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!


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.


best practices customer onboarding

This is going to sound familiar to many product managers. And founders. And product marketers, developers, and….

You spotted a market opportunity, figured out what your customers need, built your product, did some marketing or other promotion. Or, to put it more bluntly, you spent time, you spent money, and you spent a huge dose of blood, sweat, and tears. And—amazingly—you find that people are downloading your app or signing up for an account.

Woot! What a good feeling. But then you realize they’re trying it once and not coming back. Or your conversion rates are uncomfortably low. Now that feeling’s a sinking one. What’s going on?

It might be all about first impressions. And I don’t mean just the bling. Getting started—effecting change to entrenched habits or processes—often is the hardest part.

The first few interactions a customer has with an app or a cloud service—the onboarding experience—arguably make up the most important chance you have to win a customer’s buy-in and engagement. Onboarding profoundly influences a customer’s views of a service, and it can make or break an entire customer relationship.

The discipline of user experience design (UX) in software is focused on usability, affective and emotional aspects of the product, making certain desired user activities intuitive, and so on. Designing the onboarding experience is a big part of that. In-app cues, incentives such as gamification, and triggered emails are all major drivers of the onboarding flow.

Most of these best practices apply to both B2C and B2B contexts. But what happens when requirements for getting started go beyond a user’s interactions with an app? For B2B services like SparkPost that power real-world business processes or that integrate with other business systems, onboarding encompasses broader considerations than getting through a series of steps in the app.

At SparkPost’s recent Insight user conference, our own Clea Moore was joined by a panel of customers who discussed their experiences with onboarding in the enterprise context. These professionals shared their (sometimes hard-won) advice about how to hit the ground running when moving business processes to a cloud-based platform. The discussion was wide-ranging and delivered a lot of insight into how to make migrating to the cloud a reality.

Here are some of the take-aways:

  • The cloud allows the businesses to focus on their strategic differentiators rather than managing commodity infrastructure. On this, the panelists were whole-heartedly in agreement. Seth Weisfeld of Pinterest observed that “cloud infrastructure is a strategic choice for Pinterest. It allows us to focus on our real value in content and experience.” Jonathan To of fashion retailer Tobi agreed, “To be able to focus on our customers and their engagement rather than infrastructure is just so great and so important to our business.”
  • Scalability and elasticity are big wins from an technical operations perspective. Travis Wetherbee noted, “I don’t have to worry about adding IPs, adding boxes, adding drive space to deal with peak volumes or to store and bounces.” Jonathan To added, “We’re not a huge company. We’re trying to stay lean. The cloud is a major win for time to market.”
  • Specialized expertise—for example, SparkPost’s deliverability services team—makes a huge difference among cloud providers. For mission-critical processes, cloud providers have got to back their technology with hands-on account management and real operational and onboarding expertise. Seth Weisfeld described, “It’s really huge to be able to trust our provider on issues like deliverability. We couldn’t always rely on that in the past.” Travis Wetherbee concurred, “Beyond the pure technology evaluation, services like deliverability expertise was a big criterion in our decision-making.”
  • Planning ahead makes all the difference for minimizing the risks of unexpected impacts or disruption. That includes technical legwork—Travis Wetherbee called out making sure DNS changes and suppression lists were managed systematically—as well managing the transition from a business perspective. Jonathan To added that “Thinking about the data you want to store means looking ahead and making conscious choices—even if you can’t use it today.” Seth Weisfeld described the importance of looking at the migration as a process, not something that can be done in one fell swoop. His advice was to begin with small, less critical mail streams and then gradually ramp up to the most strategic pieces as the system is proved out.

Learning from customers always has been the most rewarding part of my job. And, of course, getting information about how people actually use technology to solve problems in the real world is essential to every software or cloud product marketer. So, I was really thrilled to hear what the professionals on this panel had to say about their experiences moving their email infrastructure to the cloud.

By the way, in the coming weeks, I’ll be discussing the role of implementation and services teams in the onboarding experience. What do you think it takes for successful onboarding in the enterprise? Let me know—I’d love to hear about your own real-world experiences.



Like this post? Check out some other Insight 2015 session recaps:

Zillions Guide Blog Footer

There are times when it feels we’re like a golden age for user-centered technology. I mean, how easy is it to download a personal quantification app that a friend recommended to you, or to bookmark a great new productivity web site to investigate when you have some downtime? Easy-peasy, my friends!

But if you’re anything like me, it’s also awfully easy to forget those downloaded apps and saved bookmarks. Maybe I’ll log in once, then get back to whatever I was working on, thinking to myself that I’ll check out this great tool a little later. Or perhaps I’ll get intimidated by a complex setup process for which I just don’t have time at the moment. Or, worst of all, the basic workflow for a site will be lost on me, and the payoff for figuring it out seems to just not be worth the effort.

Unfortunately for the teams behind these apps, each of these scenarios is a potential death-knell for my engagement with their products. Every time I delay taking a step with an app or service, it becomes decreasingly likely that I’ll become an active, paying, and profitable customer. That’s why the onboarding experience is so crucial—the first few moments with an app can make or break an entire customer relationship.

Welcome On Board!

Onboarding is a multi-faceted occurrence that encompasses a range of functional and qualitative experiences. It spans the very first welcome screen, account creation, introduction of features, and alerts that prompt specific tasks in a workflow. When done right, each of the steps represents an opportunity for increasing user engagement—but if poorly implemented or introduced with little forethought, they become hurdles that risk turning a customer away for good.

No wonder, then, that product teams put a good deal of thought into optimizing each aspect of the new user experience. The most successful apps find a balance that makes it easy—seductive, even!—for users to incrementally increase their engagement in a way that feels natural and self-paced, all the while capturing data and other indicators that feed behavioral models that identify profitable audience segments.

While there’s no magic bullet to solving the onboarding challenge, there are best practices that have emerged over the past decade and that reflect a combination of expert insight and empirical evidence.

One of the best of these best practices is the onboarding email. Once relegated to a simple transactional message that essentially said “hey, you joined, here’s a confirmation of your username,” the onboarding email has since matured into a fundamental piece of a product team’s toolkit. Today, the most successful onboarding emails are designed as a series of carefully-timed and triggered messages that help to accomplish several key goals, including:

  • Serving that original functional need of confirming account creation.
  • Reminding the user of key steps required to complete registration.
  • Validating the user’s email address (and, by the way, enabling double opt-in for email marketing).
  • Introducing key concepts in the features or workflow of the app or service.
  • Encouraging active engagement with and investment in the site or product.
  • Establishing brand voice and personifying the relationship a user has with a product.

Over the next few weeks, I’ll be honing in on each of these aspects of the onboarding experience and featuring emails that do a good job of meeting each need. Until then, what’s worked (and what hasn’t) for your product team’s onboarding efforts? I’d like to hear from you.