Building best-in-class relationships with customer-facing teams
The 2021 Product Excellence Summit brought thousands of product leaders, product managers, and other product enthusiasts together for two days of virtual dialogue. But as much as we all love our fellow product people, it’s also important to develop effective relationships with our customer-facing colleagues across the hall.
That’s why Scott Baldwin, Productboard’s Community Lead and Product Evangelist, led a discussion with three panelists from product-led companies to learn more about their strategies, success stories, and lessons learned: Arnita Curtis, VP of Product at Sprout Social, Agata Bugaj VP Product and Design at FullStory, and Anique Drumright, VP of Product at Loom (Editor’s note: these reflect panelist positions at the time of the summit).
Love this discussion? Join us in San Francisco or online for this year’s summit on October 4th!
How do you define a successful relationship between Product and customer-facing parts of your organization?
AC: One critical element is definitely starting at the base level of: “Do we understand each other’s jobs?” What we do is make sure that there is an introduction to both product development and product management for every new hire. We talk about our product development lifecycle, how a product is built, what the role of a Product Manager is on the team. This is really important for us, because we are a product-led company, that everyone at the company understands how products are built.
Then, for our product managers, we do a required introduction to Sales and introduction to Support, so they understand how those work. We get into details like how Sales gets compensated, what the Support team severity levels are. [This way] when a sales rep is reaching out to a product manager and asking for a feature, or support wants a fire drill call with a customer, they can empathize more and really understand what their day-to-day is like.
So we spend a lot of time upfront just understanding org structure, and we find that that base level understanding improves communication a lot and creates a more supportive and collaborative environment.
AB: One thing I would add is that, especially for a company like FullStory – and I’m sure this applies to so many of us in the room as well – we’re a fast-growing company. We are not the same size today that we were two years ago, or that we will be in two years. And so you have to continually do [all of these things] and really understand: when are the things that we’ve set up – the processes, the tools – when are they starting to break? When do we have to rethink how we do some of these things? Because when you were a 20% company and you were all sitting in the same room, that’s very different than when you’re 400 people.
That alignment and that communication and that clarity is so important — making sure that you’re constantly thinking about “is this still the right setup for us?”
AD: I would add, something really fun that we do at Loom is that for all major pilots, we have an inner team that’s working on [the pilot] for customer success, sales, product, and support. So [it creates] a habit of those four major groups learning how to work with one another.
I think the fun part of a startup is that every time you close a larger customer, like a lighthouse customer, you mature with that customer; it really is a partnership. And so it’s been pretty fun building that habit and ritual across the four functions, in addition to everything on the onboarding side.
Previous webinar guest Hope Gurion had a recent podcast episode where she talked about how “customer-facing teams are the lifeblood of product teams”. How do each of you like to partner with and bring those customer-facing roles into your product development lifecycle?
AB: I love the quote, it’s so true. We do a lot at FullStory to really strengthen the partnership between product and customer-facing teams. I’ll call out three that I think have been the most impactful.
- The first is around org structure: “pod squads” [are] cross-functional groups – PM, design, engineering – who are all marching to the beat of the same drum. That means we’ve got people outside of product who are in product meetings, have access to the notes, to all the assets, the documentation, et cetera — and so there’s this natural, organic mind-melding that happens. It really helps shorten the feedback loop and enable much more effective bi-directional communication between all these different teams.
- The second thing is that we use a lot of tools at FullStory, and it won’t come as a surprise that the tool that we use the most is FullStory [itself]. We’re a digital company, so we want to understand how customers are using our website or our application.
- The last thing is we’ve made it easy to provide feedback to Product. We’ve created a Salesforce feedback object, which enables anybody at the company to submit feedback on a customer’s behalf [and] that feedback also goes into Slack as soon as it’s submitted. The product team, which is living inside of Slack, will automatically see [it]. You can engage with it, you can ask “what did you mean? What was [the customer] trying to do?” You can follow up and you can ping other people. It’s a fantastic way for us to get this real-time feedback.
The other thing that we’ve done [to make it easy to provide feedback to Product] is really important because we’re a fast-growing company; our teams are constantly changing, we’re adding people, the names change. It can be hard to know, especially in a virtual environment, “who am I supposed to ping about this thing? Which PM actually needs to hear this feedback?” And so any chance we get, we let teams know: it doesn’t actually matter if you’re in the right place, what’s most important is the feedback gets its way into the product organization.
What’s really helped us be successful partnering with other teams is making sure we have a culture of transparency, collaboration, trust. If you’re going to have teams showing up to meetings that are in Product, you have to have those things to be successful.
AC: What comes along with [a SaaS product or a product-led growth company] is that customers are paying you recurring revenue on a monthly basis, and they expect continuous value. The teams that are talking to our customers directly on the frontlines have all of that information; it’s a goldmine.
[At Sprout] we also made it really easy for our internal and our customer-facing teams to submit feedback to the product team. We found that it’s easier to do that if you embed your feedback mechanism into their system of record. And so, similarly, we have a Salesforce case where they can submit feedback easily. We have a process that we set up within Zendesk, so our support teams can easily submit feedback. We made it easy for our customer marketing team to send survey information to us directly from Marketo.
In order to really get rich and deep feedback from customer-facing teams, it’s really important to understand their processes and be in their system of record. Because if you’re not, and you’re forcing them outside of their system of record into your system of record, you may not get as large a quantity of feedback or quality of feedback.
AD: In addition to meeting your cross-functional stakeholders where they already are working, our support team is unbelievably data-driven. They do a monthly digest that the whole company can read and absorb: Where do we need progress? Where we do not need progress? What are the top problems that our business is experiencing? And the sales team and customer success team does a similar thing.
The reason why I appreciate these synthesized views in addition to the raw data is that it puts them in the position of being the “owner” as well, really advising the product organization.
[Also], something that’s missing in raw data inputs is: what’s happening in the competitive landscape? How are they thinking about differentiation in value as they work through partners? And every quarter, I have [the other teams] put in their top three requests on a 100-point scale, because I think it gives us perspective on what they see as the most important and why.
The other piece that’s really great from a video perspective is we use Loom to capture key pieces of feedback and share it. That enables us to really see the quality of the conversation and the emotions and the context around it.
What rituals have you established between your product teams and customer-facing teams to ensure you’re both actively listening and contributing to really great customer experiences and outcomes for the business?
AD: The rituals look like monthly syncs with Support, Sales and Success. And then they are intimate stakeholders in the product planning process.
The other ritual that we have is more on the building side. What’s really fun about building products is, your core company is the most critical user and also the most passionate user, so their feedback is really great. We have a Slack channel [where] the PM synthesizes all the feedback and prioritizes it and shares what bugs have been solved every single day so that there is a closing of that feedback loop for all the feedback that we’re receiving from the company level.
In a product-led company, the product is the business, so we’re all building the product. I think it’s a great ritual to create that culture around the product and this idea of shared ownership.
AB: There are two things that I’ll add. The first is that when we’re doing discovery work, one of the most productive things that we do is we engage our frontline teams to really understand — are we solving the right problem? We’ll show prototypes, and [they] have been just fantastic, giving us really good feedback that really does shape the direction of what we’re building and how we’re building it.
The other thing that we do at FullStory is that we partner very strongly with our customer-facing teams on the information that’s valuable to the product organization. So for instance, if a customer writes in and they say, “we would love Feature X,” that’s good to know, but it’s not helpful.
What we really want to know is: what problem are you trying to solve? What outcome are you trying to achieve? What did you do before? What are you looking to do after? And really just honestly doing user research.
And so what I absolutely love is when we get feedback where all that information just shows up and our customer-facing teams are really digging in and partnering with the customer, to make sure that we understand what they’re really looking for — because it’s possible that what they’re asking for can actually be done already, but we just haven’t done a great job of explaining how to do it. If that’s not the case, and we truly do need to build something new, we can do it in a way that can really meet their needs, but potentially the needs of others as well.
AC: There’s a one-sentence question in our Salesforce feedback case. At first, it said: “What feature is the customer requesting?” We changed it to: “What problem are they having that they cannot solve now?” to see if that would change the type of feedback that we got and to have our customer-facing teams – in this case Sales and Success – think a little bit more about user journeys and customer problems. And it did help a lot, just changing that one-sentence question.
So that’s definitely critical — setting up the processes and the rituals so that they can think more about customer problems like you do on the product team.
The other thing I’ll add is that an important distinction is between rituals you have as a leadership team and rituals you also encourage your individual contributors to attend. We made a clear distinction between those two.
The other two levels to [rituals] are formal and informal. Things like recurring meetings or quarterly touch-bases, we’ll put in the formal category. Then there’s also the informal stuff, like when we have our Friday “high fives” as a team, maybe we’ll invite somebody else in from a customer-facing team, just as a guest “high five.” Things like that really help form relationships and bonds outside of the formal checkpoints.
On the quantitative data side, how are you working to make sure that teams have a shared understanding around user needs and a shared perspective that they’re building from?
AD: Generally, I believe that our data partners do one of two things: they help us to see opportunities that we don’t see or they’re mirrors of “you think this is successful, but it’s not as successful as you think,” or “this may have moved X, but it impacted Y and Z differently.” And so I see Data as critical, creative, and strategic partners to product managers. In just the way that you have a PM, an EM, and a designer, ideally you also have a data person as well.
How we organize it is, we have multiple PMs, but in every pillar, we have a data scientist or data analyst that’s actually specializing in that part of the business with the product lead.
I think [data is] such a critical stakeholder in keeping Product honest and also giving a fuller picture as to how our users are using the product: What are their characteristics? Are we focusing too narrowly on only a certain population of our users, or are we now paying deep enough attention to our power users in this feature?
I think ideally, what I hope our data team would say is that they feel like strategic stakeholders in the product direction, the same way a product manager and designer would be.
AB: I would say two things at FullStory. One, there’s the organizational aspect of it, so we do have some roles that are more just on the data side. These are individuals who can go super, super deep, regardless of the tool that we’re using. But also, our PMs, our designers — everyone does self-serve as well. That could be because we are building a tool that does quantitative and qualitative analytics, so organizationally we kind of have a perfect blend of both.
And then, from a tooling standpoint, we use multiple tools, but we do lean on FullStory a lot because you can get multiple types of inputs — qualitative and quantitative. Also, it’s a tool that’s very easy to use, so it really enables everyone in the organization to have a single source of truth. I’m sure we’ve all had experiences where you’ve got multiple teams in different tools, and you’re honestly just wasting time trying to tie things together.
So whatever the tool is, make sure that it’s the same one. It’s really, really important.
AC: We’re admittedly still working on becoming better at this. I will say we have a lot of tools that give us data. One thing that we’re working on improving and getting better at is how you operationalize those tools within all the teams’ day-to-day practices, because it’s one thing to have a lot of tools that give you data and measure event tracking, but the harder part is in integrating [that data].
The other thing I’ll mention is that I feel very passionately about taking the data that we all see and know, in terms of being in the day-to-day product usage, and getting that into our customer-facing teams’ hands. So it’s not only about looking at the data coming in, but also how can we take the data that we have in our purview and push it outward and have it really drive other teams’ day-to-day processes and practices, too.
