Defining Success for Your Product

A cozy breakfast this morning with our friends at Robin, hosted by Product Managers Emily True and Shanna Gregory, in their new office in Seaport. Robin makes office automation tools that making room booking a breeze—now their challenge is in defining what success looks like for a “choose your own adventure” product. With many implementation options, different customer types, and device specific toolsets, how does the team know who’s having success with the app, and what to offer next?

Have your own definition of success, but leave room for it to adapt

Early on a valuable measure of success for Robin was the number of meetings booked, but after observing actual meeting patterns and learning from real user scenarios, their CPO and co-founder Zach Dunn shared two stats that eventually changed their thinking:

  • 70% of people at companies book zero meetings, they just attend
  • Most meetings are recurring, so that only counts as one booking

Every company uses rooms differently, so you can’t count time spent in meeting. The question becomes: how do you gain visibility into the types of users you have and their specific cases? Paul Heayn, PM at Runkeeper, is a fan of the persona-based product development model. Where talking to customers, building the product with those personas in mind, then intentionally marketing to people who fall into that persona bucket, has driven success for his team. Paul sites an idea from Build Better Products which is to talk to customers often, until you know how they’re going to answer your questions.

Talk to customers until you know how they’re going to answer your questions.

Ways to slice and dice

For a product like Robin’s where there are multiple points of engagement and platforms to choose from including calendar plugins, mobile apps, and dedicated hardware outside conference rooms, do you let customers choose their own adventure? Or do you direct them to use a specific, limited toolset to focus on one core activity? To figure this out, Anna Perko from Hubspot considers the difference between the buyer and the end user. Many SaaS companies run a playbook of establishing customer advocates within your user base to drive adoption, enabling easier renewals and greater upsells.

A key product marketing task is to empower champions within a company to promote and teach other employees—a “train the trainer” approach.

Emily and the team face an interesting challenge in that they have two different gatekeepers to please—IT managers and office administrators.

Another option is to look at your needs from a device perspective. Are people on the go, using the product in real time or does it require more focused attention that someone planning would prefer to do at their desk? Why would customers adopt one over the other?

Instead of trying to offer all features across all devices, Wayfair’s Rachel D’Agostino suggests using device limitation as a way to educate users about new ways they can interact with the product.

Think of it as a teaching and learning opportunity.

Success for the product and success for the business

Brian Swartz from Catalant pointed out that for any new feature being considered, PMs have to keep an eye on the business goals. How does success at the product level brings success to the business? “As a user my problems are solved. I need a room, I found a room. What else do you need to solve?” If a Robin user only has their Outlook plugin installed and uses it to book all her meetings, does it matter if she has the mobile app too?

Sometimes when you have a hammer, everything looks like a nail. Maybe building new features or flows isn’t the solution. If end users don’t know about all the features a product offers, you may have a product marketing challenge on your hands. You need to understand the full path a user takes from trial to purchase to activation to renewal, and then identify your blind spots and your opportunities for improvement.

You can’t tell your users what to do. In fact, you’re better off with the opposite—having users tell you what to do. When you build a product, you’re the expert, and you know everything it can do. It’s tempting to want to share that knowledge with your users, but it’s important to remember that they’re hiring your product to do a specific job, and that’s what most important to them.

Don’t tell the customer what to do

This post was originally published for Boston Product. If you enjoyed reading this, please give us some 👏 and check us out.