The Sarah Bernard Hypothesis: Customer-Centric Companies Uncover the Most Impactful Solutions
In this episode of the Product Science Podcast, we cover how machine learning can give you a better understanding of your customer, how teams can become customer focused, and how to create cross functional solutions for customers.
Holly Hester-Reilly
Sarah Bernard is currently the Chief Customer Officer for Greenhouse Software. She has held executive positions as COO with Crisis Text Line, VP, Officer of Product with Walmart’s Jet.com, and earlier in her career General Manager, SVP and VP of Global Product with Expedia’s Hotwire. Ms Bernard helps B2B SaaS and Internet companies grow valuations by transforming their product and customer success operations so they can hit the next stage of growth like start up to scale, accelerating growth in late-stage companies, and helping companies achieve profitability post acquisition.
Ms. Bernard is also one of the producers of The Product Leader Summit; an annual invite-only gathering of 120 founders and product leaders to connect and learn from one another through keynotes, workshops, round-table peer learning discussions. She is most proud that Product Leader Summit achieves equal ratios of men and women for not just attendees, but also speakers, which is a rarity for Tech events.
In this episode of the Product Science Podcast, we cover how machine learning can give you a better understanding of your customer, how teams can become customer focused, and how to create cross functional solutions for customers.
Subscribe for the full episode on Apple, Google Play, Spotify, Stitcher, and more. Love what you hear? Leave us a review, it means a lot.
Resources
- Follow Sarah on Twitter
- Follow Sarah on LinkedIn
- Crisis Text Line
- Follow Holly on Twitter
- Follow Holly on LinkedIn
Questions We Explore in This Episode
What is Crisis Text Line? How did Sarah get involved with Crisis Text Line? Where was Sarah in her career when she decided to join Crisis Text Line? What types of events would Crisis Text Line try to assist with? Who were “customers” that Crisis Text Line was servicing as a product? How was Crisis Text Line able to journey map their customers journey through their product? What unmet customer needs was the journey map able to reveal? How was Crisis Text Line able to increase engagement and combat churn on their platform? Did volunteers at Crisis Text Line have supervisor support when handling calls? How did Crisis Text Line empower their volunteers with the experience of the supervisors? How did their supervisors receive customer support training? How did Crisis Text Line gear Sarah’s career in product and customer operation roles?
What insights was Crisis Text Line able to uncover through its use of big data? How did Crisis Text Line’s response and triage algorithm affect wait times? What were the industry standards for wait time for crisis lines? How did data help Crisis Text Line choose what words and strategies helped people in crisis? How was Crisis Text Line able to offer their data to academics to study? How were volunteers trained to tag conversations for data analysis? What is the secret to creating good data for machine learning?
How did Sarah get involved with Greenhouse? Why did Sarah transition from product to head of customer success? What are shared skills between product and customer success? What is Greenhouse’s method of removing bias from team communications? How does Greenhouse use data to identify instances of bias and how to address it? How can customer success run experiments for product? How can customer success help test features? How does customer success help refine data for product? How can customer success be used to incubate ideas? How can customer success prioritize what customers need?
How can customer success refine the volume of customer data? How does Greenhouse handle tough issues in a cross functional way? How do you keep multiple teams engaged with the customer? How can customer support help test platform improvements? How do teams share their insights across an organization? How do you share customer feedback across teams in an accessible way? How do you share customer research across an organization?
How is product a customer focused role? How do product managers validate their own work? How do you know if you’re doing product management correctly? How can a data focused customer strategy help your business scale up? How do teams utilize the product team to remove obstacles? How do later stage companies change their customer strategy? How effective is user testing in waterfall? How can agile teams be introduced to a waterfall environment? How can you transform an organization from waterfall to agile? How can other teams do their own form of customer testing? How can any team be customer focused? How can any team benefit from engaging with the customer?
What was it like working at Hotwire? When Hotwire switched to agile, how much training did they offer? How long did features take to build before Hotwire switched to agile? How long did features take to build after Hotwire switched to agile? How does agile promote being more customer centric? How can customer success help prepare you for a career in product?
Quotes from Sarah Bernard in this episode
I think every product manager feels like they’re making it up to some degree, but chances are you're really doing it right.
If you're doing everything together, it equalizes the intelligence. And the collaboration around the solutions becomes that much stronger because everybody has seen, touched, felt the same data set.
If different teams have the same motivations, we start to design together and create customer solutions together and it's just that much more impactful.
Transcription
Holly:
Well, I'm excited to talk with Sarah Bernard today. Sarah, welcome to the podcast.
Sarah Bernard:
Thank you, Holly. It's really nice to be here.
Holly:
So, Sarah, I first heard about you when you were interviewed about Crisis Text Line, and I'd love to dive into that. So, tell me a little bit about how you got involved with Crisis Text Line.
Sarah Bernard:
Sure. Crisis Text Line was a COO role for me after about a 15-year career running global product teams and doing large transformations, and I had been in customer operations prior to moving into product and also had general manager roles, and so Crisis Text Line was interested in an operator to come in and manage engineering, their product team, as well as their whole coaching organization, which managed the 25,000 volunteers that they had, working the text lines of Crisis Text Line, and it was an incredible service. So, do you want me to give you a little background on the service?
Holly:
Yes, because our listeners might not know.
Sarah Bernard:
So, Crisis Text Line is a service that lets people text in when they're in crisis, and crisis is defined as any kind of experience that somebody might have where they're not behaving as normal. So, it could be a very stressful period of time for a kid in high school who's got a bunch of tests all the way to somebody who is contemplating suicide. So, it's a pretty wide span of issues, but texting is this amazing medium for crisis management because it goes very slow. The conversation can have pauses in it. The volunteer can think about how they're going to respond before responding. The person who's texting in, it's totally anonymous, and they can do it from anywhere. So, we had experiences of kids texting from the school cafeteria when they were being bullied. So, it's just this wonderful medium that lets people go from this very hot situation to a cool calm, and the crisis counselors are trained in somewhat of a formula that works that I'm happy to go into.
Holly:
Awesome.
Sarah Bernard:
But it's just this amazing service where people can be trained in about 40 hours and receive calls on a daily basis from anywhere.
Holly:
Yeah, so walk us through your experience. What was it like joining the team there?
Sarah Bernard:
Yeah, so it was really interesting to me because it was a bigger experience than just product. So, the product team was really excited to have me because they had been reading books like Marty Cagan's book or Jeff Patton's book about story mapping and they were doing all the right things, but they weren't convinced that they were real product managers or doing it right. So, I came in and they were doing it right. They were absolutely doing it right, but they just needed to be validated in that way, and I think every product manager feels that way to some degree, like they're making it up, but chances are you're really doing it right. So, anyway, they were doing testing and learning with the platform, but what was really interesting was we had all these coaches who would first of all vet volunteers and make sure that they got through the admissions process and then they were responsible for training and getting the volunteers started on the platform, and they would work very closely with product to make sure that the platform was intuitive and that the training program, which was also all virtual that that worked for the volunteers, and essentially, the volunteers were more our customer than the end user of the person in crisis. So, I spend a lot of time getting grounded in the fact that the volunteers were our customer first and foremost, and then we started to ideate between product and the coaches this journey that volunteers go through. They go through first admissions and then they went through a training process, which was about 32 hours, and it had a funnel of people that made it all the way through and people that fell out and so we wanted to understand why people fell out and then once they were active on the platform, we wanted to see how often they were taking shifts, if they had a particularly difficult shift with, say, a call where somebody was very upset and we had to get 911 involved. That was a very important moment to re-engage with the volunteer the next day and make sure that they were okay. So, it was very much about journey mapping the experience for the volunteers and making sure that we were intervening with either the product or a human being throughout the journey to keep the volunteers engaged. So, I'll leave it at that. Any questions?
Holly:
Yeah, well, you mentioned story mapping with Jeff Patton, and so I'm curious if you used that technique there.
Sarah Bernard:
We did. In fact, when Jeff found out that I was working at Crisis Text Line, he was incredibly moved I had brought him into Hotwire, as well as jet.com, and he was so enthusiastic about the service of Crisis Text Line. He said, "Let me figure out a day that I'm going to be in New York for other engagements and I would love to just come by and donate my time with the team to participate with them," and he did his incredible conversation with the team about being truly customer-centric and focused and he pointed out all sorts of things that we were doing where we were asking the volunteers to do things our way or not actually listening to what they were telling us, and I don't know if I'm going to remember specifics about any big changes that he made, but really, we ended up with a room full of Post-Its and drawings of his that further validated the journey that the volunteers went through.
Holly:
That's wonderful. Yeah, I had the pleasure of having him come into a place that I worked at and it was so much fun, and so I'm grinning as you're talking about the room full of Post-Its and his drawings because-
Sarah Bernard:
Yeah, his drawings are beautiful and it really is how he communicates. He is talking the whole time, but the way that he draws engages the audience and the pictures are so much fun to see the way that he brings the customers to life with stick drawings to some degree, but it was a really great experience and everybody felt like they learned a lot from him.
Holly:
Yeah, that's awesome.
Sarah Bernard:
So, the other thing that I'll say about Crisis Text Line that was really interesting was because we had these volunteers that were going through this journey and our goal was to keep them engaged and give them a good experience, it very much led me to B2B SaaS customer success leadership because we had this population of volunteers that we needed to onboard, engage, and keep working on the platform, and if somebody stopped taking shifts for 90 days, say, we considered them a churn. So, it was very much a precursor to the way that B2B SaaS thinks about their recurring revenue and keeping customers engaged and retained and always working towards this renewal phase. So, it was definitely a step to this current role that I'm in, which is chief customer, which when I think about customer success, it's so much an extension of the product and so it was a big consideration to me to go from product to operations to now a customer success role, but I had always been a very operational product leader and because it's an extension of the product, and you're running large teams of people, it made a lot of sense as a career move.
Holly:
Yeah, interesting. I like how you say how you liken your experiences there to B2B SaaS. I mean, I think there's definitely a lot in common. Before we go into talking more about your current role I did want to ask if you could speak a little bit about the role of data at Crisis Text Line, because I know that that played a big role.
Sarah Bernard:
Oh sure. Yeah. So, data had a couple of different roles. It had on the one hand a very operational role for the management of the texting platform, and then it had a second role of the intelligence that we could glean from it about mental health. So, I'll talk about both of those things. The first way that we use data was to understand what people were writing in about and the level of severity of the crisis, and so when texter texts in, there was a bot that would ask a first question of what's happening today or how are you feeling, and based on that answer, we would put the text in a place in the queue, and we got so smart about the severity level of text that we could answer. 95% of them were answered within five minutes, which is actually an incredibly strong service level. When you call into an 800 number, like a suicide hotline, the wait times can be up to two hours. So, that's the speed at which we could intervene with somebody who was in a very severe crisis was a huge benefit of the platform and so we were using data actively in basically queue management and queue theory type things and so that was a very operational way that we use data. The other way that we use data was to understand words that worked or didn't work in taking somebody from a hot to a cool calm. So, we had a set of words that we called strength IDs, and we incorporated this into the training for the crisis counselors, and we learned things like if you use the word brave or courageous like, "Holly, it was so brave of you to pick up your phone and text me today, and I really want to thank you for doing that." It makes the person feel like you get them and you're on their side. So, it builds that trust at the beginning of the conversation. The other types of words that we would use are emotional words where if somebody said, "My mom is driving me crazy because I have all these tests tomorrow and I'm really tired and I really just want to take a nap and she's yelling at me." You could up the level of their emotionality by saying, "Wow, that sounds totally overwhelming and awful," and you've gone one level higher than what the texter was in, and again, they feel like you get them. It drives that empathy for them. So, we got intelligent about these strategies because we could analyze the content of the text messages and that's the type of analysis that is much, much harder if you're doing it through recorded phone calls. So, the texting really paved the way for that kind of thing, and then the other thing that we could do is anonymously, of course, and it was all aggregated data. It really allowed us to partner with academics in different fields of psychology or language and just get more and more intelligent, and because we are a non-profit, I think there was just a desire of that kind of partnership to do the text analysis. So, it was super exciting. It was really meaningful work, and I have to say that for the volunteers who were working the passion that they brought to the experience and the absorption that you could get from that kind of volunteer experience was just incredibly unique.
Holly:
I love hearing that story. It's one of the main reasons that I wanted to reach out to you because the idea of using so much data for good and actually helping humans with it is just really appealing. Must felt good to work there. I'm curious a little bit about the mechanics of that. Did the volunteers have to categorize what had happened in the calls in order to make the learning smarter or how did that work?
Sarah Bernard:
Yeah. That was, I always say, the dirty little secret of data and machine learning and using data in your products is that it really helps to have some sort of manual process to start out and so yes. We had a couple of forms, and I haven't thought about all this in a few years, so I'm thinking about the different ways that we tagged. So, we would initially tag the contacts as the different level of severity as we evaluated it. So, there was that initial tag and then the volunteers could tag the conversation throughout the text because there were a lot of different categories, like somebody might be texting in because they have financial stress, but they're also experiencing a high degree of anxiety, and they also might be long-term very depressed and so we had lots of different hierarchies that we would use for the tagging, and while I was there, we actually simplified it because it had built up over the years similar to product features and anything else that you build where we had just continuously added on and added on. So, we cleaned out and got a little bit more simplified and the volunteers appreciated that a lot because the tagging system that we used really needed to make sense to them intuitively for it to be effective. So, always, whenever we would go out with features or changes like that, we would bring groups of volunteers in and test it with them and make sure that it made sense to them before we would roll it out to the whole platform.
Holly:
Yeah. Oh, very cool. Yeah, I think people don't always realize the manual role that comes when you're doing work like that. So, it's interesting to hear about it.
Sarah Bernard:
Yeah, yeah. The other group that worked on the platform that's important to understand is we had supervisors who were mental health trained specialists. Many of them had master's in psychology or social services, and they were supervisors on the platform and they would monitor the conversations that the volunteers were in so that they could intervene and coach while somebody was texting, and if we believed that we needed to do an active rescue, which was to contact 911, the supervisors did all of that work between the emergency services and the volunteer. So, there were flags that the volunteer would flip and then the supervisor would start actively watching every line of that conversation. So, there were lots of built-in supervisory roles that could be played, and I used to talk about the supervisors. They were the emergency room nurse where if they got actively involved in a conversation, they would be giving instructions to the volunteer that the volunteer would have to follow, and it was a tricky role for the supervisor to play because on the one hand, the volunteer was volunteering and they were doing this out of the goodness of their heart, and they were very much a customer of ours and on the other hand, they had to follow the instructions of the supervisor. So, we did a lot of work with the supervisors to work on customer service skills as well as these very important emergency management skills.
Holly:
That's interesting. So, it sounds like that did lead fairly naturally towards the direction of the customer success work that you're doing now.
Sarah Bernard:
It did, but at the same time, it was very much an outcome of my years in customer operations general management and product, where I started out my career working at the front desk of a hotel, and you learn very quickly working face-to-face with customers what kinds of things work and what doesn't. So, when I got into the technical world, I had developed this philosophy of being very principle-based and there's principles of service and it applies to building websites as much as it does to call centers or a texting platform. So, yes, it's very much helped in the world of B2B SaaS and customer success, and I've taken it with me throughout my career in product roles as well as customer operations roles.
Holly:
So, tell us what happened next? How long were you at Crisis Text Line?
Sarah Bernard:
I was there a year, and during that time, we created their first ever strategic plan, and we raised about $50 million in funding. They run themselves very much like a tech company and so I had set them on a path of building for the long term, towards this long-term strategic plan, and I had also connected with John Strauss when I was living in New York. I'm actually from California, but had been living in New York over a five-year period and that was when I was at Crisis Text Line and Jet and Greenhouse Software, which is a hiring software platform. They were looking for a customer success person, and John and I had been networking around the product community in New York because I was looking for Silicon Valley type product leaders and he had really created a nice community around himself as the head of product at Greenhouse, and he was trying to network for customer success roles, and he thought I might know somebody because I had been developing my network in New York with women in product. When he told me about the role, I said, "John, you realize this is like my dream job because it's a little bit of product and a lot of customer, and I love that kind of role. Let's talk," and then I think I immediately said, "Is this career suicide to go from product to customer success?" He said, "No, no, no. We want this to be a really strategic role because we really believe that proactively developing the relationship with the customer is the way that you ultimately retain customers." So, true to form, Greenhouse had an absolutely excellent hiring process, and I enjoyed every moment of it and about a month later, I started as their head of customer success.
Holly:
Awesome. So, what has that journey been like?
Sarah Bernard:
Well, the groups that report into me are support, customer success, and professional services, and Greenhouse... Just to give you a little bit of background on Greenhouse, Greenhouse is a hiring platform that helps companies get good at hiring, and the philosophy was in business, we all want to make decisions based off of data in general, but in hiring for some reason, it's to say go with your gut and it's ridiculous because hiring somebody should be a commitment for years, and if you're truly creating an experience for your employees that builds employee lifetime value, this is one of the most important and strategic decisions that you can make. In fact, if you ask CEOs, what are they the most worried about? They'll often say talent, and then if you follow up and say, "How's your hiring practices?" They'll say, "Oh, actually, we're really bad at it." So, Greenhouse Software is meant to help people and the concept behind the software is to create a structured process that candidates go through and that structured process ensures that you identify key attributes and capabilities that you're looking for the role. You interview against those key attributes and you have a structured process that scores people against those attributes. The scores that we use are literally thumbs up, thumbs down or sideways because a number scale really doesn't make sense. Your four is going to be different from my four, but your thumbs up that they have a skill like communication is we're both going to agree that thumbs up means they can communicate well. So, that structured process lets you make the decision based on data, and the outcome of that is that you start to remove bias from the process. So, the initial software was very much about creating the structure, so that you could collect data and then we added on some DE&I products where you get pipeline reporting to show how candidates are flowing through the process, and if there's bias, you can see that some people make it through the process easier than others, and that could be based on gender. It could be based on race and you can see all that very transparently. Other parts of that hiring experience that we feel strongly about are that you have a great candidate experience. So, we have candidate surveys that the candidates can fill out you can get feedback about your process and improve it on that, and the whole idea is that decision making gets better and it's valuable to the company because making a hire is the most strategic thing that you can do for the success of your company. So, anyway, I love the product and the success role. I went into the role thinking that we would be an extension of the product and help customers adopt and use it well, and what I'm learning is, yes, we do all those things and we can also start to try things with customers that product might not want to build right off the bat. So, for example, we have a ton of configuration in the product right now that customers can configure it exactly the way that they want with different permissions in the recruiting org or with hiring managers, and we've almost given them too many choices. So, we're starting to play with customer success, laying out for customers a good, better, best set of configurations or some configurations that, look, if you're this type of company, these configurations work really well for you versus if you're a really small company, you might want to configure it this way. So, we're going to play with some manual configurations that are just preset, and if it starts to work with customers, and we can reduce the number of decisions that they have to make to get up and running faster, we'll totally work with product and hand that over as an initial spec. That product can then continue with their research and start to build in an automated way.
Holly:
Yeah, that's interesting. So, it sounds like the customer success team is really helping to incubate ideas as well.
Sarah Bernard:
Totally, and it's a funny story. They were so excited when I started because they said, "Oh, this is so great. You're going to help us get product to do all the things that we want them to do because they talk to customers all day long," and I said, "Actually, you're not going to like this, but we need to leave product alone so that they can build and they can do their own customer research," and that totally confused my team, but product was like, "Thank you. This is good," and where it's really led is it's super important that we have a close relationship with product and that we're communicating and sharing each other's insights, and I've really stressed with my team that we've got to go to product with a strong point of view and that, of course, product is not going to be a feature factory and they're not going to build exactly what the customer says, but if we can do some of the homework to gather all the disparate ideas that our teams are hearing and give a hierarchy of needs over to the product team, it's such a better message than just 100 random requests.
Holly:
Yeah, that sounds really great. How do you go about making sense of all the things that the customer success people hear and see?
Sarah Bernard:
We do a couple of things. One is we use user voice to collect feedback, and it was implemented... I would say we're still a pretty immature user of it, but we implemented it originally through the product team, and in using it, customer success began running their own reports and developing their own point of view from the data in that, and that was good because the first thing that we saw was that we weren't using it equally. So, the first time that our enterprise team ran the report, we said, "We'll take it back to an enterprise meeting and say this is what the report is saying," and everybody perked up and said, "Well, that's not true. That actually isn't highlighting the big issues for us," and it turned out a bunch of people weren't logging the data in ways that they could be and so in a way, it got the team to clean up their tagging and feedback points. So, that was a good healthy outcome. Now, they're running those reports on a monthly basis and giving it over to the product team. The other thing that we do is a little bit more of hands-on process where we do a weekly meeting where anybody can bring a really tough customer issue to a cross-functional team, and Greenhouse is super interested in their customers and so this meeting is actually if there's a relevant topic, the CTO will attend. John, the founder, who's essentially our chief product officer will attend. Our VP of product is often there. We'll have sales people there. Anybody who has a relevant stake in the customer issue will show up and so we talk about those customers and people volunteer to help solve the problem, and what I think systems like that do is it keeps people having hands-on experiences with customers and seeing what works and what doesn't work, and then they're high enough level that they then apply that experience with the one customer to system improvements or process improvements that they can implement throughout the rest of the team, and then product has its own, products like Heap, and ways to do the analysis of product usage that any product team would do.
Holly:
Yeah, so I'm curious how the insights are shared within the organization because it sounds like you guys are pretty focused on gathering data and making sense of even the qualitative conversations, and I know that a lot of times, some organizations, it ends up with insights living in people's heads rather than being shared across the organization. So, do you have any tips on how to really get that out of people's heads and into something that everyone can understand?
Sarah Bernard:
Well, I think my tip would be ultimate usage. Understanding ultimate usage and having shared transparency across the organization of that. So, there's a couple of different ways of doing that. One was... Well, let me start with Greenhouse and then I'll work backwards to earlier times of my career. So, at Greenhouse right now, we have new data about the adoption of key features of Greenhouse and that adoption data can guide how we design our services as well as how we design our product. So, it's really important that the cross functions are working off of the same data set, and we're doing that at Greenhouse. So, for example, I talked a little bit about candidate. Candidate surveys are a great feature where the recruiting team can send out a survey after somebody has gone through a set of interviews. They might have gotten the job. They might not and you get feedback about the hiring experience, and you can build based on that feedback so that you get better and better experiences. Customers that implement that feature with us tend to implement more features. They tend to renew at higher rates. It's a valuable feature of Greenhouse. If the product team and the services team have the same motivations of upping the number of surveys or the number of customers that are using those surveys, we start to design together and create customer solutions together and it's just that much more impactful. So, I would say shared common data sets are super important, and then transparency across the organization. At Snapfish, I had a design team who did their own research with customers, and it was they would do a lot of deep research, watching customers use the website, and then they would present to the organization solutions of what to do about it, but the organization didn't get the experience of seeing what the customers were experiencing of how the website was tripping customers up the way that the design team was. So, they would throw up all over the designs. That design would recommend the very early stages of usertesting.com. That was a really easy remote way to watch users together. You would videotape the user using your website and so we got into this really cross-functional set of ceremonies as we were designing products where we would get the engineers, the designers, the product managers into the room. We'd bring the CEO in if we thought he was going to be opposed to an idea, and we would watch customers together. I did that with listening labs for years, with product teams, and the idea is if you're doing everything together, it equalizes the intelligence and the collaboration around the solutions becomes that much stronger because everybody has seen, touched, felt the same data set, and when there's pockets of the organization that has intelligence that other pockets don't have, that's when things start to break down in terms of your build or ability to really collaborate towards a solution. That makes sense. I think it's particularly interesting to hear that you did it with both the data that you're looking at and the qualitative conversations that you have when you're doing user research that just bringing people together to be a part of the witnessing helps drive that alignment.
Sarah Bernard:
Yeah. I'm a big fan of public dashboards and everybody agreeing on the data that's important and looking at it consistently or just being available for people to see.
Holly:
Yeah, so I guess I'm also curious. Do you see yourself staying in customer success now that you're there?
Sarah Bernard:
First of all, I think product is very much a customer role.
Holly:
Yes, yes, it is,
Sarah Bernard:
But they're all very interconnected, and when I look back at all of my different roles and when I think about the commonality between running operations for a website or being the general manager, responsible for the P&L of a website, to running a large product group and transforming the way that you do product between engineering, design and product, and now, to customer success roles, the commonality is I help companies get to their next stage of growth. So, with any one of those operations, I've taken companies from startup to scale, from late stage to re-acceleration, and also maybe from startup to profitability post-acquisition, and the way that I've done all of these things in product roles as well as customer success is through a data-focused customer-centric operation, and as an operational leader, your role is often to remove barriers for the teams to be successful. That might be an engineering team that is getting tripped up with technical debt. It could be a customer team that is tripped up with bad systems or data about the customer. In many ways, I've applied the same operational leadership to these large teams, and for me, it's really looking at the company and saying, "What stage of growth are they in," and what's the thing that we would have to solve to get them to the next stage of growth? That's what I think is really exciting. So, whether it's a customer operations role, a COO role or a product role, I think I would be looking at the company's situation more than anything.
Holly:
Yeah, that's cool. It sounds like you've really had a breadth of experience in terms of different company stages.
Sarah Bernard:
Yeah.
Holly:
We didn't get to talk so much about the transformation. I'm curious if you have any interesting stories there about how you help an organization that's maybe later stage reignite their customer centricity.
Sarah Bernard:
Sure. Yeah, so I did this at Hotwire. Hotwire is an amazing service. It's a website that sells hotels and you roll the dice with your hotel. It's called opaque selling, and basically, they had a list of hotels that would come up in search, and you didn't know the name or the exact location of the hotel before hitting the buy button, and then it would tell you. So, customers would make their decision based on price or ratings and general location or neighborhood, but they wouldn't know exact, and you hope for the best based on the data that you have. So, I came into Hotwire at a time that they were still somewhat waterfall, and they had not employed rigorous customer testing. They often did customer testing right before launching products and so it was too late. They would know before the product went live if there were going to be potential issues, but it was too late to change anything and so the best that they could do was try to mitigate it with help screens or something, but it was not good because they actually were launching some products that were hurting the business. So, what that transformation looked like was first doing an Agile transformation where we started out with the organizational structure, which is generally what I did, and I would try to dedicate teams to specific areas of the product. In Hotwire's case, we had individual products like the hotel business, the car rental business. Hotel was really their cash cow product. So, we had a front-end team and a back-end team, but two separate Agile teams, and the idea was to give a team full ownership of as much of the code base as you could, and then we did deep training around the philosophy of Agile and test and learn product development. A lot of this was like Marty Cagan, philosophical types of training, getting them bought into it, getting a tops-down group bought into it. So, at Hotwire, the CEO and I met every two weeks for months with a set of Agile coaches who were helping the teams work in a net new way, and I can't say enough about the tops down commitment. That is important. The CEO that I had at Hotwire was amazing for the commitment that he had going through this. The CTO was also very committed with me. So, he and I had a very close partnership in this because he was asking his teams to work in a completely new way at the same time that I was asking product and design to work in a new way, and then the last thing that we did that was probably the biggest game changer was we set up customer labs that were there for any team to use on a weekly basis, and it was pretty low-tech. We got two meeting rooms side by side. We had our exec admin recruit the customers every week, and any product manager or Agile team that needed to show a set of designs or concepts or prototypes could watch customers all day long, use their prototypes and then bring it back. The teams were so committed to it. They figured out other ways to do the customer testing, like our mobile team was going to the Apple stores all the time and showing phones to customers. Our car team rode the buses out at the airport, going to car rental agencies. It was really awesome.
Holly:
Oh, that's so clever.
Sarah Bernard:
Yeah, but ultimately, what ended up happening was the teams realized that these projects that they thought... What had been holding Hotwire up was every time they wanted to make a significant change to how the hotel product or airline product or car product worked, in the waterfall world, it looked like it was an 18-month project, and it was just not going to do anything for the business and then at the end of 18 months, it would be outdated whatever solution they were building. So, the Agile approach allowed them to break things into very small pieces, and they did some projects that literally got new ways of connecting with big hotel inventory systems. They could test the data connections in ways that were so much smaller than if they had built a great big project. We were able to add huge amounts of inventory in three to six months that would have taken with waterfall like 18 months, and it started literally with an Agile coach saying to the backend team, "What would it take to trade a single piece of data with the backend hotel inventory system that was a third party?" They figured it out and then when they figured out that one piece of data, they added on the next set of data and they added on to that and then all of a sudden, it fed this aha moment where they really realized that they could start to test rapidly.
Holly:
Oh, that's really cool. It sounds things definitely got more customer-centric while you were there.
Sarah Bernard:
Yep, yeah, and smaller, like smaller leads to bigger in such a big way.
Holly:
Yep. Think big. Start small. Yeah, I love that. Well, I think we're about out of time, so I always to ask people what their advice is for aspiring product leaders. So, what would one piece of advice you'd have for them be?
Sarah Bernard:
I think my advice would be how much do you love watching customers and are there things that you can do in your job now that lets you get close to your customer? So, many of the product team at Greenhouse are actually people who came out of customer success and were working with customers. I'm going back to very early days of Greenhouse, but they literally saw where the product wasn't working for customers and had conversations with engineers and got close to why the product needed to work that way, and then John saw that interest that they had in both the technical and the customer and started coaching them and helped them learn how to be great product managers.
Holly:
Yeah, that's great. Well, where can people find you if they want to learn more?
Sarah Bernard:
They can find me at greenhouse.io, sarah.bernard, and I'm always interested in having career conversations.
Holly:
Oh wonderful. Well, thank you so much. It's been such a pleasure to talk with you today, Sarah.
Sarah Bernard:
Thank you, Holly.