It goes without saying that product management is a pivotal role. Perhaps less apparent, is that when you have multiple product managers, keeping everyone on the same page can be a challenge.
Each PM may be responsible for a different aspect of the product or a different target market, and in the fast-paced world of software, those areas of responsibility are often fluid or overlapping.
Here at Hugo, Customer.io is a tool we use every day for email automation. If you aren’t familiar with the product, their mission statement says it all: “People use Customer.io to automate and gain efficiency, but automation is usually cold and inhuman. We strive to make automation human and valued by the people on the receiving end of it.” The remote-first company has more than 2,300 corporate customers and continues to grow and innovate.
In this interview, we had the opportunity to speak with Brendan Fortune about his role at Customer.io as a Principal Product Manager. Brendan walks us through how Customer.io structures the Product team such that they are able to immerse themselves in the customer’s challenges and desires, rather than just “represent” the voice of the customer.
Brendan leads one of three “squads” in Product at Customer.io. While each squad has a specific objective, there is naturally some overlap, so the team uses a mechanism of “intent documents” that trickle down from upper management down to each IC. This concept was derived from The Art of Action.
“You have to fit in the information everyone needs to know, and then communicate the right context, while still giving some freedom for people to operate within reasonable constraints, Intent documents are slightly different than OKRs. They don't usually get to the level of definition where you specify the key result and deadline. We do that in other ways, but the squad intent documents are meant to be shorter statements of intention."
In practice, this means that the CEO writes up a high-level intent document and distributes it to each of her direct reports, who in turn, create their own version of the document and share it with their reports, and so on.
This means that the company ends up with a set of short statements on the intent of each team. If there’s any overlap, it can get resolved as soon as possible. Generally, the intent document process operates in 3-6 month cycles.
Keeping on track on a regular basis happens in weekly product management meetings. During the initial 15 minutes of the meetings, product managers contribute updates and relevant agenda items to a rolling document, then they launch into a “Roses and Thorns” session to talk about what is going well lately and what isn’t.
Unlike others, Brendan finds it important to create the agenda together rather than in advance. “It helps to drive focus for what you want in the meeting, and in the end it is more efficient than filling that out in advance. It definitely reduces the stress related to updates.” says Brendan.
Another area which helps product teams coordinate harmoniously is the idea of having the product team immerse itself in how the customer thinks and the problems they are facing. “One thing that I have found that does not work very well is when a product manager or one person on the squad acts as the voice of the customer and everyone else asks that one person what the customer wants, and they act as the authority,” says Brendan.
He recommends an approach where everyone on the team dives deeper into the problem and looks at it from different angles.
In order to achieve this, his team uses customer anecdotes, discussions, prototyping and a Slack channel where they share as much information as possible on what comes from customers. “There are many ways to approach this, but what’s most important is that everyone has customer empathy and the sense of ownership that has people take actions, not just pass tasks to someone else,” he adds.
Throughout the interview, Brendan gave numerous examples of how the team immerses itself in problem-solving and looking for creative solutions:
"At one point, I created a task where everyone had to create their own fake product and build a landing page and figure out how to get people to sign up to hear more. We did some Facebook ads and some Google retargeting of these fake products, and their goal was to try and actually get some leads and generate a story. It was fascinating to see back-end engineers’ approach to doing that vs. the designer vs. myself vs. the front-end vs. QA person. Everyone chose different tools, and we all grew in that space of creativity."
Creating this kind of activity is fun for the team and allows them to see different perspectives, as well as taking ownership for the product.
One remarkable tip that Brendan provided is the way Customer.io handles feedback from the users. Most companies will respond to customer requests by politely thanking them and letting them know it’s being handled according to a priority list which is, of course, opaque. By contrast, the Customer.io approach is transparent:
"Whenever a customer asks for a feature, whoever in the company receives the request has the option to give a list of the top five things that we are working on right now and asks where they would rank that feature request versus the current priority list. The customer then gets the opportunity to say, hey, this is less important or maybe it’s around number three — or even tell us they don’t need any of those top five.
Everyone knows their company is far from perfect, but how do you ensure your team is consistently improving? One common answer to this question is with scheduled feedback or retro sessions. Atlassian has created a culture where inefficiencies are continuously identified and improved.
You don’t need a pandemic or natural disaster to face a crisis as an organization. Unexpected events happen, and sometimes you need a rapid response. In fact, the skills needed for rapid response translate well to a lot of projects.