S2 Ep. 7: How Do You Work With Customer-Facing Teams in Product Discovery?
Subscribe: Apple Podcasts | Google Podcasts | Spotify | RSS
Hope Gurion: Customer discovery is the lifeblood of product teams to identify the most important customer needs to solve next. Often it's the Product and UX members of the trio who take lead on facilitating this discovery. But what about other customer-facing teams in an organization? How do product teams best partner with these teams to understand customers’ unmet needs and decide which needs to address next? In this episode of Fearless Product Leadership, we learn how product teams should effectively partner with customer-facing teams from deeply experienced product leaders when they answer the question ““How do you partner with customer-facing teams in product discovery?”
Welcome to the Fearless Product Leadership podcast. This is the show for new product leaders seeking to increase their confidence and competence. In every episode I ask experienced and thoughtful product leaders to share their strategies and tactics that have helped them tackle a tough responsibility of the product leader role. I love helping emerging product leaders shorten their learning curves to expedite their professional success with great products, teams and stakeholder relationships. I’m your host and CEO of Fearless Product, Hope Gurion.
Product teams who value discovery crave first-hand understanding of what matters to customers. They use this insight of unmet needs that become problems to solve and opportunities for delight and competitive advantage in their products. However, some organizations have friction in their processes when there are already so many, often much larger organizations in headcount continuously having conversations with customers. For example, at B2B companies, sales meets with prospective customers. Marketing may organize customer and prospective customer events. Newly sold customers work with implementation/onboarding teams try to get the most value out of the product quickly after purchase. Existing customers work with account management on training and troubleshooting. Dissatisfied customers reach out to customer support teams for issue resolution. All of these customer-interactions and teams represent both opportunity and challenges for how product teams should engage with customers as part of how they practice discovery.
In this episode you’ll learn from 6 product leaders at B2B and B2C companies who partner with their customer-facing teams while they share how they:
Prioritize customer problems to solve
Ensure customers can benefit from solutions in discovery and development
Effectively message to customers when their wishes and feedback isn’t immediately actionable
Navigate discovery discussions with customers when sales/support wants to limit access to an account
Involve engineers and other members across functions to deeply understand customers’ needs
At the end I’ll share the 3 techniques I find solidify partnership among these teams in discovery and product delivery to benefit customers.
Fearlessly tackling the question “How do you partner with customer-facing teams in product discovery?” are:
Marc Abraham, Head of Product-Engagement at ASOS, former CPO at Settled
Ben Newell, VP Product, CBRE, former VP of Product at RewardStyle
Rachel Obstler, VP of Product at PagerDuty, former VP of Product at Keynote Systems
First Zabrina Hossain describes how the product and support teams partner during development and post-release to identify and address what customers need most and develop a “Care Package” to ensure customers will quickly benefit from how the product has evolved.
Zabrina Hossain: So working with customer facing teams in discovery and actually through every phase of product development is incredibly important. Like I mentioned before your user and their needs should really be the North Star of your product group. So I get my teams to be very close to our customer facing teams, especially our support team. Through all stages of the product lifecycle. In the discovery phase, our support team joins our initial scoping and ideation sessions, because they have a ton of great merchant feedback. And that information helps us to develop our hypothesis and overall plan throughout the development of any product support stays very close to the product team to provide feedback and understand how we're designing and building it. And this enables them to actually create a care package with the overall team support. And that care package is used to train the broader support team and ensure that everyone has a really good grasp of what was built and how to help us users through any questions they may have. The process of creating the care package actually often helps us to suss out if there are any in product changes that we can make pretty Actively to ensure that users actually have the most seamless process possible. Once launched, the support team works with our merchants on beta and also through to full general availability. And then post launch, they gather feedback, and they aggregate numbers and different issues and challenges and feedback from our merchants. And they bring that to us. And that helps us to understand what's going well and what could be better. And that information is used to grow the product and start the cycle again, if needed. And so this process has been used on every single product I've launched at Shopify, so that would be like Instagram product tagging and the BuzzFeed affiliate tool and all of the channels that we work on and support.
Hope Gurion: I love that you call it a care package like I think that's that's a smart way to to position it can you just add a little more color array like how that process came to be like did you always use it from the get-go was it well-established did you evolve into it and I missing me have quite a large support team so I'm assuming not a hundred percent of the support team participates all the time right how do you sort of shoes or getting the representative feedback by but yeah enable the teams to move quickly and and not be burdened by having like to hear from every single person in support?
Zabrina Hossain: Right. So we actually have many layers of support. And personally, I think Shopify has one of the best support teams around. And so there's one support team called the product support network. So there are PSM team, and your product has a PSN person usually assigned to it. And that's how it's worked for me. And that PSN person deeply, deeply understands the product that we're working on, again, and they're the ones aggregating the feedback and taking it to the broader group of support because again, we have over 1000 people and support if not more than that, right. So what they do is they they create this quick care package, we all review it together, we have the videos included, we have screenshots included. And so really it's a step by step of how the product works. And then training sessions are held with the broader support group via video, some in person, and then questions and or come back from them. And that's kind of how we refine that as well.
Hope Gurion: And this is something that happens from the get go or did this Did you evolve into this care package process?
Zabrina Hossain: So we did have when I started three years ago, we did have this concept of a care package already. It was a process that was fairly well established. I would say every time we work on a new product, we iterate maybe a little bit on how often to be involved or what to do, but overall, the process is fairly well defined.
Hope Gurion: Next Marc Abraham describes why it’s important for product teams to embrace the treasure trove of data available by partnering with other customer facing teams in sales and support through every phase of the product development lifecycle.
Marc Abraham: Yeah, so in terms of you know how teams I've been part of I believing I, they work with all their customer facing product teams, days days, a natural order can be a natural tension there where, you know, you both want to look off to the customer and do good by the customer. But who does want and who owns what and I say that in inverted commas? I think my first answer to question sounds very cliche, but I think it's very true, which is that it's about building a relationship with those other teams that interact with the customer on a daily basis. And you know, that's what we do at the end of the day as product people is building relationships, and influencing without authority, and particularly with those teams or those people, whether it's in sales or customer support, who are at the coalface in a way, Jose interacting with customers on a daily basis in here, their pains, and their enjoys, hopefully on a on a daily basis, I think we need to be conscious of that as product people and have a certain level of humility towards that where we do listen. And we do take the feedback that we get from those teams very seriously and really engage with them early. And often. You know, it's very easy to make the mistake of thinking, I'm the product person, I do a few kind of, you know, very smart, lean type discovery tests, and I'll find out what the customer problem is. But you'd be sitting on heaps of data already, or people who really can tell you not only just the common themes of the kind of common requests or complaints that they get, but also give you a bit of a nuance in the background again, and it's it's such a treasure trove of information that we easily forget about and particularly if you're let's say your customer call center is elsewhere, it's very easy to forget about it's not you know, that happens right and in my current role, I'm really encouraging To spend much more time with customer facing teams, you know, I like to sit with customer agents and just sit and see how they when they have phone calls or what kind of queries they get via email via live chat. It's really important and then tweaking those customer facing teams as an I'm not the biggest fan of the word stakeholder, but you know, they have skin in the game, right? They want customer success, as much as we call it, people product teams want customer success are really treating him as a true stakeholder, meaning that from beginning to end, and back again, you involve with those customer facing teams being being at the very discovery phase where you where you really work closely with them to understand customer pains and start assessing potential solutions to every time you roll up, you make sure that customer support teams are fully aware of what's coming up and being trained up if necessary. So again, they feel an integral part of that product development lifecycle, if you like rather than just you know, a bit of an afterthought.
Hope Gurion: Now Audrey Cheng partners with the customer-facing teams at Pushpay using “customer office hours” and how she practically navigates when the product teams are not able to immediately act on all feedback based on inevitable prioritization and allocation of finite resources.
Audrey Cheng: When I think about discovery, one of the key partnerships that we have is actually working with our customer facing team, you know, previously, we were hearing a lot like, Hey, I have this feedback from this customer, these customers want this feature, but what it really didn't give us what's the why. And so what we decided to do was to really start to partner with our customer facing teams. And that was with our customer success team and actually with our sales team, to actually try and incorporate coorporate them into our discovery practice, and to actually work alongside them as we actually go to build out our product as well. So it's really a real true partnership, not just like, Hey, we have a meeting. We inform people, we actually bring them on the journey. And actually get them to be participants in our journey. And so with our customer facing teams, what we may do is we may partner with them. In our, we have something called customer office hours, which is probably a mixture of generative and evaluative research. And so some of it is a little bit like, Hey, you know, what things are keeping you up at night? What are the challenges that you foresee? We're trying to look for trends. The other part might be a little bit more about our product, what's going well, what's not going well for them and why? And then trying to then taking those insights and really trying to figure out do we see any patterns here? And in that research, what we do is actually we partner with our customer facing teams, they're often invited to be observers in our research, we share our findings with them, we discuss like, hey, here are the things that we saw what are the things that you're seeing did some of this resonate with you? What we don't want to do is ever dismiss the feedback that they get when they're on their visits. But we also know that sometimes those are, you know, a little bit more bias on the sales call side right? When you're, you know, there's that saying that if you're selling you're always Selling, right? And if you're researching and researching, and I think we feel the same way, and we don't want to dismiss the feedback that comes in from our customers from through those teams, we also want to look at them and say like, Hey, where's their bias introduced? And hey, if we think that these are potential areas or problems or some insights, key insights that we have here, could we go and evaluate them further and really determine whether they are, in fact insights or whether they were things like false objections.
Hope Gurion: Just a follow-up question on that when you are working with customer facing teams and you end up inevitably having feedback that you can't immediately act on doesn't hit the priority doesn't align to a goal not feasible to smallest but whatever the reason is how do you manage that expectation with either the sales team or the customer success team or the customers who shared that feedback that you can't immediately act on?
Audrey Cheng: When we think about you know, the feedback that will we get from our customer facing teams, you know, they're really and I what I really love about them is they're really championing our customers really trying to put them at the front of the queue, and in the front of our minds when it comes to product development, but sometimes what that means is that we're always making trade offs, different customers need different things. And when we're looking, and even, you know, our forward market needs different things, potentially, to our existing customers. And so when we look at that base as a whole, I think that's the challenge of product management is trying to figure out what the right mix is, how do we best serve all of our customers? How do we best you know, serve new customers? And what are those elements that go in there? And I think that is the challenge of, you know, creating where your resourcing is going to go the challenge of product management of discovery and I think some of the things we talked about in terms of investment, which areas will we invest in, that is sometimes it can be a bitter pill to swallow for our customer facing teams. They want everything for their customers and you know rightly so. But you know, product development is not A infinite resource. And I think what we're trying to achieve is what can we do? What what what decisions can we make that actually best serve everybody with the resources that we have. And so sometimes there are hard decisions. But what we do try to do is to share what our plans are. And because our roadmaps are really centered around customer problems that we're trying to solve, we can really demonstrate, you know, hey, we're trying to solve this problem, that problem, the one that you've raised, kind of falls outside of where our focus areas right now, we're working on this, and if there's a stronger impact that that problem can make, and we start to see that trend. Well, we look at it and see where that might come into our roadmap. But right now, we're focused on this and you know, even only the near term stuff is I do the stuff that we're really confident that we're delivering everything else is like, we think we're going to do this, you know, but we may not depending on, you know, what the outcomes of what we're delivering are, what the change in the landscape in the market is and where we feel that we can best deliver value to our customers. So sometimes we are having those discussions and often We want to have those discussions together. So quite often I'm having those discussions with both our CS teams and our sales teams in the rooms together. Because what we want to do is partner with them. You know, the thing about product management is even though we're responsible for the success metrics of our product, they're responsible for being able to sell them being able to support them. And what we want to do is make sure that they feel equipped that they they're getting the right things to be able to succeed in their in their respective areas, too. And sometimes that does take a bit of like, compromise on all of our sides to figure out what's the best thing that we can achieve for the organization. And I think that focus on the overall goal is probably the most important thing to align on. And then all the decisions, not that they're easy, but they kind of fall out of that and people can reason that Yeah, actually that makes sense like that we can actually best serve our customers in this way. And yes, we can. Those are the best decisions for our business.
Hope Gurion: Ben Newell shares how customer facing teams participated in product development using the “Big Pitch,” a week-long accelerator to vet customer needs and how to solve them using product discovery and validation methods
Ben Newell: So one of the most interesting things you asked about and something I've spent a lot of time with is how to involve the customer facing teams. It's maybe your account management, your sales teams in the discovery process. And I, I think this is an extremely important thing to consider for product managers. I think too often we think we're potentially all knowing, and that all the tests and all the work should come from our teams. And when you think about how much interaction these teams have with actual clients versus you as a product manager, it can be a pretty big gap. I also managed the support team, in my time at reward style, and I often asked my head of support is like, how many customers Did you talk to today? It's a I don't know. 50. Like how many you think I talked to you today? Usually the answer was 00. Though I knew it shouldn't have been zero. And despite all my best efforts, obviously, they were spending way more time with our clients than I was. And so tapping into those teams is critically important. And it's harder than just saying, oh, we're going to put out a suggestion box, and hope that these teams, you know, oh, you can email me anytime and offer different ideas that That, to me just doesn't really work as well. It also doesn't give an appreciation for kind of the challenges of a product manager, and all the things that you have to think through when there's a new idea. So to help in this, every workshop, we set up an event that we called the big pitch. And this was kind of in response to our hack day for engineering teams. But this was only participated by our customer facing teams, account management, sales, and our support teams. And we asked them on the first day of the week, we presented Hey, this is the kind of work that we would do as product managers to that an idea So we presented in our case, we use the lean Canvas as an easy way to say, Hey, here's the canvas. Here's the kinds of questions you'll have to ask. And so at the start of the week, we want you guys to get into teams come up with your ideas, obviously, we expect them to be ideas you've heard over time, they might be new ones. But we imagine there are lots of things you've heard, take them through that process. And then you're going to present those back to the product and engineering teams at the end of the week. So kind of using that template and understanding what you have to think through, present those ideas back to us. And we found this event to be really, really successful. The teams got really into it. They enjoyed pitching their ideas, they got very creative about what they wanted to do. And we had a lot of fun with it. But I had two other outcomes, which I think are really valuable when you think about including those customer facing teams. One it gave them an understanding of what we go through as a product team of Yeah, that's an interesting idea, but now that I thought about what it would take to maintain It or grow it or launch it or the kinds of customers and how much we'd have to charge for it to be successful, maybe it's not such a great idea. Now, things that happen to us often in products, you get a great idea. And by the time you think it through, you know, 80% of them aren't worth you continuing to pursue. And secondly, which was somewhat unintended, but was interesting was that, as we presented it back to the engineering teams, and the product teams, a lot of the engineers were like, Oh, that's actually not that hard to do. And that's a really interesting ROI. And we were able to take some of those ideas and roll them into our hack day. And the engineers were able to take some of those and work with their counterparts on the customer facing teams, which was a nice set of collaboration, again, that was unexpected. And it gave us an opportunity to vet those ideas a little bit more. In fact, a couple of them, we actually turned into production ideas, and were able to create, you know, small tools or some of the other kinds of things that are pretty straightforward to achieve some of these ideas, and it was a really great way to bring the organization Together help everybody understand what's involved and include those teams in the discovery process.
Hope Gurion: Now Rachel Obstler shares the differences between the types of discovery product teams initiate around a particular need vs happen at the account level from sales and support and how they navigate “do not call” requests for particular customers when requested by sales or support.
Rachel Obstler: When we're doing discovery, one thing I'll say about the place I'm currently at Pagerduty is that we have a great customer base and they're so willing to spend time with us. And so we do a lot of customer facing discovery. People don't do it always the same way. Typically, it is the product manager and the UX designer some most the time they do it together. Sometimes they do it separately to divide and conquer. And we do typically do it directly. A lot of times, we will We'll let the sales person or the customer success person know that we're doing it, we may invite them to the meeting, they can attend if they want to a lot of times they don't. I mean, the salespeople have obviously other things to do. But some of them do want to attend for various reasons, which is totally fine. And so, you know, what I find is that a lot of that discovery ends up being pretty specific. So you know, when you have a person, like a customer success person, they're really thinking about the entire account, not like a specific feature that you're thinking of building. And so for that reason, discovery is not always interesting to them in this way, when we're doing very specific discovery, about something we're thinking of building. Now on the other hand, the customer facing teams spend a lot of time with the customer and they get a lot of feedback. And the feedback they get is very much from the customer's perspective. Like I was trying to do this or I want to know if you're planning to do that. A lot of times it is less related. to future functionality, but it's more related to things like administration or, you know, things that that they're trying to do, or they can't quite do that the way that they want to. And so those teams will take enough feedback. We've a lot of different ways that you can ask product for things, File feature requests. For some of our largest customers, they'll actually keep a running list of all the things and will provide feedback. So but I view those modes as being somewhat different, right? One is that you're specifically looking at doing something and you want discovery around it, which is separate from the customers using into the, to the point of using, they're not necessarily thinking of like a brand new functionality. They're thinking of what they're using right now what is not working with it. So we take feedback from both of those, but I think they're very different modes of operating. I have not seen a lot of if any real friction with the customer facing teams. There will be occasional times when a salesperson will say look, we're in the middle of a deal. Can you not touch the account right now until we get this resolved, or there's an issue right now maybe don't reach out for this period of time, it doesn't happen that often. Some of the reason for that is that the person that you are working with who may be signing a deal is probably entirely different than the person who can give you feedback on a function anyway. So it does not happen that often. But if it does happen, I mean, as I said, we have plenty of people to talk to, and we're very happy to not get in the way of something and not reach out at that time.
Hope Gurion: Do you have a system like is this managed through Salesforce or a CRM where you know like there there's a preference not to reach out to this customer at this time or how do you practically manage that so your team's want slowed down by trying to do those checks and balances based on where a deal is or where a customer might be having issues?
Rachel Obstler: It depends. So one way is like when we're specifically doing a beta around a feature, we will often ask the sales teams or put together like just simple Google Sheet and say, Hey, this beta is going to start, if you have customers that you would like to submit or recommend that you think would be interested, please put them down. That's the easiest way to do it. And then beyond that, if there's specific people that we want to reach out to, I mean, if we have relationships with them, we're not necessarily going to wait or check, right? Because there's a relationship. If it's not a relationship, you're looking for someone for some reason that customer you think is a good target, or you want feedback from that customer for some reason, but you don't know the person already. And that's the time when you would proactively ask the salesperson, hey, I'm gonna reach out to those customers or someone you would recommend I talked to, and then that's when they would say, Oh, don't call them right now. So that's a situation where I think that would come up. I think that as we get bigger, we're going to need a much better system than that. So we recently moved to making these beta spreadsheets standard to always having the same information and then Having them all live in the same place to make it easier. And then we've also moved towards getting customers now that we're a public company, we want customers to sign a beta agreement, we used to have to have them sign up for everything. And now they just signed it once. And we're also including it as part of our regular agreements, so that someone signs once then from then on, they're on this list. And then all we have to do is say, Hey, we have a new functionality. Are you interested in trying it? Yes, great. And we go. So we are moving towards, you know, trying to make it a little bit easier to get these beta set up. They are a lot of work to get customers feedback. And of course, actually, that's betas. There's a whole other realm of customer feedback. That's user research. It's a lot more open ended. Right? And then we use a research team. And they also use a similar list. So someone who said I'm willing to give feedback, it's still a good candidate for user research. And so when we get these lists of people that have said, I'm open to giving you feedback As they like to do it, they get a lot of love from us.
Hope Gurion: Finally, Nate Walkingshaw describes the level of commitment to cross-functional teams participating first-hand in discovery at Pluralsight, and how they involve the Go-To-Market teams reviewing the earliest ideas in discovery so as they start to take shape they are able to test viability for customers to accelerate velocity.
Nate Walkingshaw: How to product teams or non customer facing teams, you know, involve themselves in, in discovery. So the philosophical approach, right we use, we use a process called directed discovery, it's not a process just think of it like mile markers. And the mile markers kind of consists of three components to us. One is voice of the customer. The second one we call CPT customer preference testing. The human language is just prototype observation. And then the last one is customer confirmation test, which is qualitative, you know, research and and the reason why this matters so much is that You can listen to customers, you can prototype what you hear them say, but the second you kind of ship something or give it the Viking send off, you actually have no control, like no control of how they interact. And so, you know, we wanted to shape or build a ton of muscle around, like how this actually works, not just inside experience, the experience organization, but across the business. So one, Product Management, user experience design and engineering, you know, they'll do roughly 60 customer calls per week. If an engineer can't make that call, we actually cancel the interview. So we want the entire team to be present for those interviews. And there and you can imagine maybe why that matters so much, just one, when you have a technical mind, you know, trying to solve a product problem there most of the time is probably a technical solution that we could get to quicker than some designed solution or some managed solution. So you know, you get a lot of you know, tail winds, by Making sure that you have those groups of people. Other people, we add, like our core competencies content. So a lot of the content organization is on those calls as well, data science, data engineering, DevOps sec Ops, and we try and involve as many, you know, folks that are involved holistically, you know, with the creation of of our product, but I think one thing that's important here is, I, you probably think I'm crazy. So the the go to market teams, so sales and marketing, we do something, you know, every other week, where everything that's in discovery, like we have, you know, we have low confidence when our discovered like probably sub 20%. Like this is a new idea. We have no idea what's going to be viable. So everything that's in discovery and everything that's in delivery every two weeks we share with the entire go to market team. The reason why that's so important to us is that I have learned in order for product market fit to have the best odds is that you want as many voices in the middle of the discovery process to find out if it works. Could be viable in market before we ever get there. And if it's not, we want to know that as early as possible. And, you know, the the problem with that in the past, right is is granting trust. I mean, I haven't, I haven't had those concerns. But yeah, at companies that I've been at, you know, they never want to show futures like, they would never want to show future roadmap, you know, it's like taboo to say, hey, like, I want to keep this really quiet. And then I want to do the big reveal behind it. And, and that that feels awfully doesn't align for the way that I that I see product leadership is that I actually want them in the process. And here's the main takeaway is it takes like three or four times for a rep to see something in discovery, go talk to a customer about it way too early, only to find out that we iterated that concept 80% and then they have to go back in front of the customer and say hey, so it actually isn't like what I told you, it actually is like this, and you know, they they they will go through that experience a couple of times and find out Like, hey, they didn't have the level of confidence. I talked about this a little too early, this actually ended up biting my reputation. You know, I'm gonna wait until you start to see the product mature into a higher confidence interval and then we'll go discuss it. And we actually do want that behavior because the second we get confident and they see like the products probably starting to harden itself, we actually want them to go test it with the customer to find out what they actually pay for my dad and then our former CFO gave me the best line. He's like, “you don't start selling until someone says no.” And the faster we can find out if someone's going to say no to the product that we're trying to engineer and build, like, the better off we are. And it's like just a cost me a massive cost savings game, you know, to speed up velocity, speed up knowledge transfer, and then speed up product market fit.
Hope Gurion: I find new product leaders introducing discovery practices to a company are met with resistance because the work feels either duplicative, e.g. “we talk with customers all the time, we already know what they want!” or threatening e.g. “I want to control which customers you speak with so your learnings reinforce what I want.” Product leaders need to diffuse these concerns by demonstrating their desire to learn quickly and prioritize objectively how to best meet the needs of customers that achieve their desired business outcome.
The product leaders we heard from today shared many great techniques to effectively partner with these teams to learn quickly what matters to customer and turn that into action for the product teams. When I’m consulting with product leaders and teams that do not yet have this partnership well-established, I immediately employ 3 techniques that I find help with shared understanding and also take full advantage of their independent customer conversations to expedite the cross-functional team's collaboration. Check out the show notes for this episode to see examples of these techniques.
First, have a weekly cross-functional meeting reflecting the customer journey. This is a core working group where they're sharing what they're learning in their functions and with different types of customers on the spectrum. In a B2B company:
Sales shares barriers to sale for different segments, personas and use cases.
Onboarding/Implementation shares barriers to getting clients successfully implemented to begin using the product.
Customer success/account management shares where they see barriers to adoption or the intended value that motivated them to purchase in the first place.
Product Marketing shares how they’re supporting sales and product to drive new customer acquisition and any barriers to effectively telling a believable story and building confidence to accelerate the purchase decision.
Product shares how they’re discovering and resolving prioritized needs and what they’re working on for future value creation.
Having a core team, one person from each function, reflect, resolve and learn from each other for 1 hour every week what’s happening at each moment in the customer journey from their expert perspectives helps accelerate learning to successfully drive customer adoption and satisfaction.
Second, create visuals to align around the customer and our goals helps everybody stay focused on customer needs, the desired business outcome, and the decisions or unknowns that need to be addressed in discovery in order to meet those needs and outcomes. Of course my favorite technique for visualizing our potential paths to our desired outcome is using an Opportunity-Solution tree because it helps keep track of what the cross-functional team seeks to learn in order to make decisions to expedite achieving that outcome. It's often important to illustrate in a shared customer journey visual from moment of need for the target customer persona, what info they rely on to make decisions about your product versus alternatives that they could be using to solve for that need, how they practically trial your solution, when and how might they churn out of the product experience, and the moments that turn them into passionate advocates to help accelerate new product sales and adoption. These shared decision-making and customer-journey visuals align product, sales, marketing and support teams so they know exactly where they and the product intervenes in the customer’s experience to make the best decisions to benefit customers.
source: Engaging Stakeholders with Opportunity Solution Trees: 3 Tactics to Try | ProductTalk, https://www.producttalk.org/2019/06/engaging-stakeholders/
Third, first-hand understanding of customers needs. Now, ideally we would all have first hand understanding about the various customer insights we're trying to learn but speed and reliable information in discovery is the lifeblood for product teams. We want to get just enough information so that we can make an informed decision. Realistically, each member of the product team and other customer-facing partner teams can't all participate in every customer discussion firsthand. The next best thing to do is to make sure that you're capturing that evidence in a way that keeps integrity, and trust in the team within the team members. If you've Gong recordings from sales calls, if the product team is doing customer discovery interviews, try to get video recordings and/or capture and share meaningful quotes. Or screen replays of their interactions with your products prototypes or alternatives. All of these build trust and confidence across the cross functional team that it's not just an opinion, it is actually grounded in real evidence, to keep trust high, but it also expedites progress and integrity in your decision making.
I want to say thank you to our senior product leaders, Zabrina, Marc, Ben, Audrey, Rachel and Nate for sharing their expertise on this episode.
If you’re a product leader seeking to build stronger collaborative discovery partnerships with your Sales, Marketing and Support organizations, I’d love to be of help. Contact me on Linkedin, Twitter or schedule an initial consultation with me using the Contact Me page https://www.fearless-product.com/contact.