Speaker 1: Hey there, Product Lovers. Welcome to the Product Love Podcast, hosted by Eric Boduch co- founder and chief evangelist of Pendo and super fan of all things product. Product Love is the place for real insights into the world of crafting products as Eric interviews, founders, product leaders, venture capitalists, authors, and more. So let's dive in now with today's Product Love Podcast.
Eric Boduch: Well, welcome Lovers of Product. Today, I'm here with Ben Golden who runs the product organization at Stream. Ben, why don't you kick this off by giving us a little overview of your background?
Ben Golden: Sure. Yeah, absolutely. So I am a software engineer by education. I went to CU Boulder here in Colorado and got my degree in computer science. When I was going to school, I knew that I wanted to work in technology, but I never expected to really be writing code eight hours a day. But at the time going to school in like 2005 to 2010- ish, I didn't really appreciate that product management was a field at all. So I didn't at all expect to be doing what I'm doing today, but here I am a circuitous path to get there, but started as a software engineer worked for several years, turned into an engineering manager, worked closely with the product manager and then a weird, just timing issue we had some staffing changes and I wound up leaning into the product side for a little bit to help out. Realized that I actually really liked doing product management and so applied for a full- time gig and made the switch over to product management.
Eric Boduch: So what did you like about it?
Ben Golden: Yeah, I mean, I think the first thing that I really liked about it, I mean, there's lots of things about program management that I've come to love. But the first thing that really caught me was just the like force multiplier effect that you can have as a product manager. Like as an engineer, you write some code, the code is done, it gets shipped and cool customers can do things now, right? But the way that a good product manager can facilitate the ability of that team to get more done with less like less time making things clear for the team. So they have less questions, less interruptions and just Streamlining that whole software development life cycle was just really appealing to me. I just felt like I could add so much more value than I could as just an individual person contributing code.
Eric Boduch: Awesome. So got into product management because of that and I've never looked back, right?
Ben Golden: Yeah, exactly.
Eric Boduch: Tell me about the process of getting to Stream and the big problems you're solving there.
Ben Golden: Sure. Yeah. So I worked for a company called SendGrid for a very long time. I think nine years in total. Well, I guess, technically eight years for SendGrid and one year for Twilio after SendGrid was acquired by Twilio. So I'd been there for a long time, started the company when we were like 20 people, grew to something like 400 while we were still SendGrid and then when we joined Twilio, we were thousands suddenly. So much different company when I started than where I got to and I definitely enjoyed the whole ride, but towards the end there, I started thinking I'd really like to get back to a smaller company and have a little bit less process or bureaucracy and a little bit more just getting stuff done, being nimble, like exploring new opportunities, all that sort of stuff. So found my way to Stream. Stream is a much similar product to what I was used to working at with SendGrid and Twilio. API solution that empowers people to build things faster, the way we talk about it as cloud components. So these components that lots of different businesses need that it's silly for people to build themselves and instead they can purchase and integrate with an API and get much more value for much less effort by just purchasing something rather than building a whole tech stack for say, sending email or building chat, et cetera. So this latter part of your question, that's really like what we're trying to solve now is to carry this journey forward of building cloud components. You've seen this with companies like SendGrid, Twilio, Stripe that are building these components that so many businesses need and it becomes less and less efficient for developers to build their own billing system, to build their own email system, et cetera. So Stream has two products. One is a feeds API. So if you're building like a social feed or a notification feed, something like that, you don't need to build all that backend to like manage it, fan out activities to different users, all that sort of stuff and then Stream second product is just a chat API. So you want to build chat into your application, we'll manage all that. The storing your messages, users, channels, all that sort of stuff. And really those are just the way we see it, just the first two that we've started with. We think of ourselves as a cloud component company that's really going to continue to build these API building blocks that allow customers to serve their customers more efficiently by focusing on their core competencies and not worrying about the communication technology and other very repeatable technology that pretty much every business or a great many businesses have to build.
Eric Boduch: Yeah. I see more and more people taking subsets of the functionality of an application, right? And in your case, it's very much API driven. Why are we seeing that more and more and how do you see APIs continuing to be used in the future?
Ben Golden: Yeah, very interesting topic, very close to my interest. I mean, the way I think about it is actually like Legos, right? So we all played with Legos growing up and the nice things about Legos is that they've created the standard mechanism by which you can build, right? There's this category stick little circle block that you connect things on. And because of that, you can have Legos of all these different shapes and sizes and create all sorts of creative, interesting things. And I think APIs are fundamentally just like that same connection or contract that allows software to be so much more than it could be otherwise. I think the further we get as a human society of building more and more technology, the more we can stand on the shoulders of giants and leverage the things that people have learned before us. And API are like just a huge enabler in that space that allows us not just to take ideas and reuse them, but take actual software and reuse them and save ourselves tons of time by not building the same things over and over again, but rather just connecting the right pieces together to create something new and different out of a bunch of different pieces that would have taken maybe years to build but now maybe only takes months.
Eric Boduch: Yeah. Acceleration of this trend?
Ben Golden: Oh yeah. I would definitely say so. I mean, I think the companies that are doing this stuff are having lots of success. I mean, obviously it's variable depending on what sort of solution that you're building. But I think there's lots of monolithic companies that, Twilio for example, had so much success as a company doing this with several different products. SMS, acquiring SendGrid with email and all sorts of different connectors for communication technologies that people just then don't have to rebuild themselves. And I think you're seeing like more and more competition in those spaces, more and more people just building those same building blocks that can be reused and more and more things becoming potential candidates for those building blocks and becoming API services that we wouldn't have thought of before. I mean chat's a great example with what Stream's doing. If you'd thought about building chat as an API solution that you can just plug into your application, say, I don't know, five years ago, it probably would have been like, well, that seems like a little bit far- fetched like, that's quite complex thing to just have as an API that you connect in your product, but we just get better at APIs and get better at integrating and more accustomed to SDKs and all of the tools that allow us to do these things. And I think, yeah, absolutely. It's accelerated.
Eric Boduch: How does it fit with the no- code movement or how do you think it fits? Do you see some merging of this in the future?
Ben Golden: Yeah, totally. I mean, I think they're really just the same movement, but with different personas. The whole drive behind APIs like I was saying before, it's just like the concept of reusing things, standing on the shoulders of giants. Like making more with less and I think a lot of the stuff that you're seeing on the no- code side of things. Stuff like there's a lot more value that people can access if it becomes increasingly simpler and there's less barriers of entry to connect things together. So you get tools like if this, then that and Zapier and stuff that are making even the gluing of APIs together accessible to people who don't write code. And I think you're going to continue to see that sort of stuff and as this API market accelerates, eventually it it'll slow or maybe not like slow, but get almost like replaced by how do we make this so simple that anyone who's capable of using a computer can connect these things together and build new and different things, not just software developers.
Eric Boduch: Yeah. That's interesting. I've been thinking about that a lot lately being more prescriptive in how we help people accomplish tasks, do things.
Ben Golden: Yeah.
Eric Boduch: You mentioned COVID, right? When you were talking about your stop before Stream. Talk to me about how you see product management being affected in the time of this pandemic. Have you guys seen your North star metrics or roadmaps change a lot and how has that caused or not caused any pivots?
Ben Golden: Yeah, I mean, I think it's super interesting. One of the things that I've observed not just myself, but also with product manager colleagues is how much it varies. Some businesses have actually been quite propelled by the pandemic like digital communication services have just become all the more important and relevant and so some business, Stream is certainly one of them that's like, there's just more opportunities, there's more businesses looking for the kinds of solutions that we're providing. On the flip side, there's businesses use. If you're in the hotel industry, for example, I'm sure you're just struggling to keep the growth rates up as people just stop traveling. And so that's really interesting. I mean, I think it varies based on product, but certainly for myself at Stream, we've had to think more about more complex use cases than we might've considered before. There's been a massive shift of conferences onto digital platforms. So rather than going to the Mosconi or whatever, and having an in- person conversation, stuff's happening online. And so the features that we're exposing in our chat are trying to keep up with the more complex and more creative features and solutions to taking those interactions from the real world into the digital world. So that's like super interesting, exciting. I mean, I'm sure it varies. There's probably companies that haven't felt any sort of push like that. As far as like metrics and that sort of thing, I think for us as Stream, it hasn't changed a ton but I think we're also on the nicer side of the COVID impact, right? For companies that are a little more squeezed by the changes, I would imagine and I've actually anecdotally heard from colleagues that this is a thing that one of the big changes is having more cash on hand, if you're a growing startup to make sure that you can weather the storm. And so thinking more carefully about how you're spending resources, obviously you still want to be growing, but you also don't want to run out of money before, whatever it is that you depend on that is no longer as prevalent when the economy comes back.
Eric Boduch: What metrics do you guys use being an API company? I'm curious about what guides your product adoption, your engagement, specific goal, what metrics your product team uses?
Eric Boduch: So talking about the different platforms, what is gaining in popularity?
Ben Golden: Yeah, I mean, I think Flutter is actually doing quite well. Flutter Dev Conference, March 3rd, coming up here and I think attendance of that is pretty high and going to be quite interesting to see what the Flutter team announces there. Flutter is basically a framework on top of the Dart language and like fairly young, but I think growing rapidly. We're seeing like a lot of popularity in that space. So that's very interesting. I mean, I think we also see a lot of usage of the native mobile applications as well. So I mean, I don't think we're going to see them disappear in the next year or two or anything like that. But definitely there was some significant momentum building with those kinds of build once deploy to both devices, options for mobile.
Eric Boduch: Yeah. I would expect that. I'm interested too. You're talking about SDK adoption, right? Are customers generally behind, what do you guys say?
Ben Golden: Yeah. I mean, it varies, but yeah definitely. That's like one of the hardest things about having an API product. Whether you're versioning on an SDK or even just versioning your API directly, you create this contract of how your API is going to interact. And then as your product evolves, you inevitably are going to hit a point where you want to change something, where there's a feature you'd like to introduce that will require you to release some sort of breaking change. And the best solution that the software community has come up with is versioning, right? So like, all right, you stay on this version we'll release a new version that breaks whatever you're using, but you just don't upgrade and so you can carry on just fine. But that makes it very hard for the person managing the API or the SDK, right? You've now got multiple versions to maintain and you have to do this balancing act of how far back do you try and fix things to keep customers satisfied with older versions of things and how much do you coax them or use the carrot to entice them, to upgrade to newer versions and all that sort of stuff. It's also like that's a challenge that spans not just development of product, but also well into marketing and customer success teams as well. Lots of interaction and thinking through communication strategies and all that sort of stuff to make that as seamless as possible for customers, but as productive and progressive as you can for your own business.
Eric Boduch: Yeah. I think it's interesting and I'd love to dig deep on your insights. Obviously, anytime you're doing an SDK for mobile, you have some of these issues, right? So what are your policies? If I'm an entrepreneur out there thinking about starting a company that has any SDK, I'm going to have to deal with these same issues, right? What advice would you give him?
Ben Golden: Yeah, I mean, I think the biggest piece of advice I give is just communicate early and often with your customers, right? If you're going to deprecate an older version, you want to give customers as much advanced notice as you can, and really create some sort of cadence to communications to keep it on their radar as the clock ticks down.
Eric Boduch: And what's the good amount?
Ben Golden: Yeah. I mean, I think it depends on the depth of the change, right? Like there's some breaking changes that are maybe like a one line code change to like update two. And so you can be like a little more aggressive, maybe give a few weeks or a month, but we've just recently released a major version bump of our iOS SDK and basically the entire way that you interact with the SDK has changed. So if you were going to go from version two to version three, you would have to invest some days, maybe even weeks to upgrade your integration with our SDK to go from one or the other. And so we want to give people as much advanced warning as possible and in that instance, we have no plans to deprecate V2 of our SDK. I mean, we won't necessarily deprecate it, but we won't support it anymore. And so we just want to make sure we announced that and communicate it and provide good resources to make that transition. So we've build a guide for upgrading from 2.0 to 3. O and just specifically highlight the way things changed and how you can update your code interactions to catch up to that latest version. So I think like so many things, it's just like communication is like the best solution, which can be tough, but well it worth it.
Eric Boduch: So let's talk about deprecation. What advice would you give people out there about deprecation? Because now we're not just talking about giving them a heads up that you can move from 2. 0 to 3. 0, but if you're giving them a heads up that X old version is going to be deprecated. You talked about what I would say is an interim step, maybe a permanent interim step, but nonetheless an interim step, which is like I'm not supporting this old version. Talk to me about how you manage that process from a product standpoint and what advice you'd give to PMs out there.
Ben Golden: Yeah. I mean, I think it's still all about communication fundamentally. I think we actually are currently going through a process of releasing a new version of the dashboard for the Stream application and we are definitely going to deprecate V1. It's just like maintaining it as just like more effort than it's worth, but we wanted to make sure we did as smoothly as possible. So first what we did there use UI as opposed to an API, but I think the strategy is fundamentally the same. So we introduced like the new version of the app, which is just like a banner at the top of the UI saying like, here's the new thing. You can go check it out. Kept the V1 around so users can hop back if they're missing some functionality or like an interaction better in V1. But it's just like there and available and we also included right there that call to action, a like feedback form that you can just like submit stuff. And we watched that closely and like tried to see if customers found things that were missing and of course they did. And then we'd like close those gaps as we got that feedback and then we hit a point where we swapped the order. So rather than V1 being the default and you can try out V2, we made it so that V2 is now the default and if you need to, you can revert back to V1. Still of course have that form and nothing's going away, but just one step there. And then we waited until we stopped getting feedback requests or like feedback that things were missing. Once we had gone like a month without any feedback that anything was missing, we said, " Okay, cool. The green light to start the process." And so now we're sending a communication to customers saying, " All right, we're going to deprecate this in a month. So please let us know if there's anything you're missing." Basically just try and place a little bit more urgency around giving us feedback for any apps. And then we'll go a month see what we get. And then we'll probably actually do a fake removal, right? Just like take away the V1, but not like actually deprecate all the services and stuff. Be able to just add the flip of a switch, put it back if we need to, because sometimes all this communication, even though you're trying to be as thorough as you can, people just don't respond to you maybe. And so I would say, and I've been on the other side of making that decision incorrectly where I've like deprecated something and then realized after the fact that we're missing something and now some big customers super upset and you're now in a scramble to try and add a feature in like short order that they really need. So don't do that. Learn from my mistakes. I would say go through as gradual as a process as you can and when you finally make that final step, make sure that you have a rip code to go back to returning that thing that, that you've removed, if you need to temporarily to ease the pain.
Eric Boduch: Yeah. I mean, I guess the big difference in the API or the SDK would be that in the dashboard, you're really giving them information, visibility data that they need, but you're probably giving it to them, hopefully in a new better way, maybe missing some stuff they want. I understand working through that process. In the API SDK case, if it's deprecated their app doesn't work or a portion of their app doesn't work. So anything on timeframes as you think about that? Like knowing people are going to have to rewrite code, if you deprecate something. Any advice on timeframes for the PMs out there?
Ben Golden: Yeah. I mean, I would say generally my rule of thumb is like, if you're going to deprecate something major that well break apps in significant ways and take significant time to repair, you should give customers as close to a year of lead time as you can. I've deprecated products in the past where we've done exactly that. We'll say like, a year from today, this is going away and then we like just gate communications throughout that time period, encouraging people to give us feedback, even soliciting customer interviews with users who we can go talk through it with them and make sure there's nothing that we aren't missing in some of the more lower fidelity communications of like texts. So yeah, I would say shoot for a year. Sometimes it's not feasible just due to business constraints. I've been in that situation as well, but if it's something substantial, like deprecating an entire product, for example, I think the right thing to do is to give your customers plenty of notice so that they can work that into a roadmap.
Eric Boduch: So the other thing that's interesting obviously is PMs for those of us who are used to an office culture, the majority of us at this point are remote. Talk to me about how that's affected you in managing the product org.
Ben Golden: Yeah. I mean, it's interesting. I'm probably not the most interesting person to speak on this topic because Stream is already like a fairly remote company. Our two founders are Dutch and Italian respectively. And so we lived in Amsterdam before they moved to the States and started Stream. So we actually have both a Boulder office and an Amsterdam office, and we have a lot of engineering out of the Amsterdam office. So we've already been doing the remote thing even before the pandemic. But it's definitely like one step more, right? Now everybody's like calling it from their homes, not from their respective offices and even the pockets within the two offices have a harder time communicating and all that sort of stuff. So, I mean, I think two things that I would say are... the first is just like the value of, of course, you've got to have Zooms and continue to communicate that way, but also the value of trying to enrich the other types of communications that you have. We have very lively Slack channels that Stream. People are very engaged in off topic channels as well as just like in the actual getting the work done channels. Our gift game is quite strong, our custom Slack emojis are plentiful. People are like finding ways to communicate with each other a bit more creatively and like have the nuance that you would normally have with facial expressions and tone of voice and all these sorts of things, but through digital mediums. So I think that's something that's really worked well for us and I encourage people to do just like embrace the meme culture of the 21st century and make the digital communication as fun as you can. And then conversely, there's no substitute for actually talking to people. So we've tried to be creative in how we have social events even though they're digital. So before the pandemic Stream would do team lunches where we'd all just go down to a restaurant on Pearl Street in Boulder and have lunch. Obviously we can't do that now anymore, but we just do the next best thing. We give everybody a stipend to expense some door dash, and then be at their desk and do some fun, like lunch Zoom call stuff to keep some social interaction going. Just the other day we did a thing where everybody uploaded a childhood picture of themselves and then the person facilitating would just go through and show the picture. We'd all try and guess who it is and laugh about the awkward family photos of them all. We've done several events like that where we're just trying to be as creative as we can about getting people on a call and having some fun and spending some time together, even though it's on a Zoom.
Eric Boduch: What's the remote stack look like. I mean, you mentioned Slack, you mentioned Zoom. What else are you guys using to facilitate remote? I mean, both pre- pandemic and post pandemic.
Ben Golden: Yeah. Zoom, Slack. I mean, obviously it's like so many engineering organizations we use Jira to track tickets and all that sort of stuff. I think that's pretty much the base of our stack. Like fairly simple. We've also experimented with other tools, in fact, some of our customers. So we're building chat APIs and a lot of our customers are using those APIs to integrate into live event platforms. So we've played with a lot of live platforms, like Hopin and Run The World for some of our team events, which are like very engaging and interesting, right? Like mixes up the features that I mentioned this in a topic we were talking about a little earlier where we have to be a little bit more creative and thoughtful about some of the features in our chat API as the needs of digital interaction evolve. So these platforms that have video conferencing, but also like dynamic breakout rooms, but then also rich chat experiences where you can initiate coffee chats, I think is like one of the platforms calls it where you can like just be chatting with someone and then quickly do a breakout video call. Things like that. I would say we've more like dabbled in some of that. Like we'll have events on some of those platforms for some of our company stuff. And we've also even talked about that we haven't bit the bullet of doing this. Thought about building our own internal chat product for our communication. Like dogfooding our own API APIs, rather than using Slack, we use our own home rolls chat solution, but Slack is a big company who has obviously put a lot of time into building their solution. So building that whole rich UI is maybe more investment than we're after at this particular moment.
Eric Boduch: Yeah. Well, let's talk a little bit about hiring. All these PMs we're always interested to hear and what hiring managers and product look for. What do you look for in a PM?
Ben Golden: Yeah, so I mean, at a company like Stream where our products are APIs and SDKs, it's fairly different. All of my job titles are technical product manager because I definitely have to look for people who are technical product managers. And I think that most of the synced way to sum up how technical, I mean, when I talk about technical product managers is that you have to be at least technical enough to use your own product, right? You can't manage a product effectively if you can't at least use that product and understand what it's like. Obviously, you are not necessarily the target user, but you need to at least be able to walk a mile in the shoes of your customer in that regard, at least that's my opinion. And so we've got to hire a technical product managers who may not have been software developers in a full- time capacity or something like that, but can write code at least as functionally, right? Like in the way that maybe I could say that I speak French, not actually fluent and comfortable in these programming languages, but they're good enough at it that they can muddle their way through tutorials and figure out how to use the SDK and look at what function calls are available and what API responses look like and where attributes are missing or like strangely formatted or formed to understand inaudible and all that sort of stuff. So that is definitely the bar for any company like Stream that has an API or SDK product, I would say. So that the technical component is something that I look for definitely, but actually the more important side of things for product managers when I'm looking for candidates for hiring positions, to me is actually that customer interaction side of things. Technical stuff is somewhat easier to teach than the softer skills of like being good at interacting with people and the really more nuanced skill of like pulling information out of customers and interviews or even like Slack conversations, emails, all that sort of stuff. So that's actually the thing that I think is somewhat harder to find for me I mean, particularly because I have to have this technical side of thing, finding that marriage of that with customer interactions, experience and skill. So I really love candidates who have some background in customer success of some kind. Either doing a direct frontline support role of some sorts or account management or some sort of direct interaction with customers, I think is like an amazing place to start as a product manager. Particularly, I think that's actually also a really common way that I've seen people get promoted up into a product management role within an organization. If you're doing customer support, you get so familiar with the product and so familiar with understanding what it is that customers are having a hard time with, have pain around, et cetera. You actually are super well- suited to make that jump into product management. It's part of how I got into product management. I didn't really mention this part when we were talking about overview, but while I was working in college, I did a year doing like phone tech support for a small internet service provider in the town where I grew up Durango, Colorado. So talking to people sometimes that live in the sticks who are 70 years old and having a horrible time trying to get their internet to work. That is a really humbling experience and makes you really patient and really good at just like listening to people who are having a hard time with stuff, even if it's not necessarily your products fault. I think that is so important for product managers that you have to be... You can't take product feedback personally, right? That is like rule number one for me is you have to be able to listen to someone complaining about your product. And even if you feel like a inaudible situation problem exists between keyboard and chair, the person's may be using your product wrong or something. You have to have the humility to hear them out and not like just take that stance of you don't know what you're doing, or you're doing it wrong or things like that. So that customer success background is a huge one for me that I really look for in candidates.
Eric Boduch: What about growth in their career? So what advice do you have for PMs that are looking to grow and get promoted?
Ben Golden: Yeah, sure. I mean, I think it's fairly trite, but I think one of the things that I think bears repeating is that getting out of your comfort zone is a huge value, right? Except those opportunities that you're intimidated by that you're not quite comfortable doing. You'll probably have a more stressful few weeks while you're working on whatever project that is, but I think it's worth it. You always grow in those situations. That's just how humans work. So somewhat a trite, but I think worth it. The other thing I'd say, like one thing for me that I think was a really interesting turning point for me, it's a very subtle thing, but I think there's like broader implications in the way that you think if you embrace this notion, which is that I try and avoid using the word, but, and use the word and instead. If you look at the structure of language or sentences, I think you'll actually find that in a lot of cases where we as humans use the word but you can actually use the word and, and the meaning is effectively the exact same, but it takes a much less adversarial or confrontational approach to the statement. So for example, you say like, " Oh, product manager, I want feature X." And product manager responds and says, " Well, I'd love to give you feature X, but we have to do these other things first." You can say that same thing and just say, " I'd love to give you a feature X and we need to do these things first." The meaning is effectively the exact same, but you create less of a no response and more of a, " I will try and help you accomplish this thing," response. I think product managers by definition of the fact that we are setting priority and the whole reason you set priorities is because he can't do everything at once. You are in a situation where you're telling people no a lot. And if you're not careful about the way you're doing that, you can really erode people's confidence in the product, even confidence in your decision making, their positive attitude about why the prioritization is correct and what makes sense and all that sort of stuff. So I think that's a subtle shift I would really encourage people to make is don't use but use ant. I think that helps a lot.
Eric Boduch: Yeah. It's interesting. I mean, we're talking a lot about communication skills, influence skills, empathy as mechanisms for advancement, right? Even though we need to have your technology background so that they understand the product in your case, an API or how you write APIs probably more appropriately, but a lot of the promotion aspects aren't stronger technical skills. It's how well can you work inside an organization? How well do you communicate with customers? All that stuff.
Ben Golden: Yeah. 100%. Absolutely.
Eric Boduch: Talk to me, one of the things I wanted to drill down on the thread is you like people coming out of CS, you like people interacting with customers. How often do you tell your product managers they should be talking with customers?
Ben Golden: Yeah. Great question. I mean, I think maybe even more so true in the pandemic. Maybe this is actually another way in which COVID has been helpful to our profession, but even that aside, I think the level of digital communication that we have in the world at this point, there's no excuse for not talking to customers at least on some level on a daily basis. So one of the things I really like that we do at Stream is that for our larger customers where the investment makes sense to us to like use enough time from people to do this, we have a shared Slack channel from their organization to ours. And so they can just ask us questions and we respond. We can ask them questions to get feedback on product changes that we're considering and things like that. And so yeah, I'd say I talk to probably, I don't know, five or six customers a day, at least in some small interaction. And I think I would very much encourage all product teams, people on my team, certainly to be doing that. You've got things like Slack to communicate with people, email is like very quick and simple to have side conversations with people. Another one that I would stress is you can't ever underestimate the value of doing actual live interviews as a product manager. It takes a lot of time. You've got to like schedule these things, recruit people for interviews, actually conduct the interviews, prepare scripts for the interviews, do some sort of debrief to summarize what it is that you've talked about and make sure that it's actionable and useful for you. It's a big investment but I think you, while you can't do that every day, certainly you never have enough time for the other things that you need to do if you are doing interviews every single day, but you definitely can't ignore that. You can't become complacent that Slack and email are an adequate substitute or surveys is another one that I see people make the mistake. These digital non- interactive forms of communication or minimally interactive forms of communications can never fully take the place of customer interviews and so I would encourage people to keep doing customer interviews and probably try and do at least, I don't know, 10 a quarter or something like that, depending on where you are in the phase of software development life cycle and whether you're kicking off new products and all that sort of stuff varies but I would say even at the lower end, you're probably doing 10 customer interviews a quarter. And also on top of that, doing some of this lighter touch digital communication, email, Slack surveys whatever makes sense for your business. But yeah, I would say always be talking to customers. Product manager, I guess is the short answer.
Eric Boduch: Yeah. I think that's great advice. The one thing you mentioned in the beginning when we were talking about metrics and I want him to go back to his NPS, just from a stand point of I know it's something you watch, it's a business metric that's important to you. Who owns it in your organization? Is it owned by product or is it owned by CS?
Ben Golden: Yeah. At Stream, product owns NPS. We also like track NPS based on categories and stuff. So we segment out the verbatim feedbacks that we're getting based on whether customers are talking about sales or CS or particular product features, that's the case, all that sort of stuff, but yeah, product ultimately owns it. It probably varies a lot by company. I can imagine a company where that wouldn't make as much sense, but so much of how our customers see us as a business and/ or whether they're willing to recommend us to their friends it ties back to the product, not just the core functionality, but the broader experience, right? Products is also responsible for documentation of all these APIs ultimately. We're doing collaborations with our go to market teams. So how marketing shows up has a lot to do with product while we're not doing a lot of the execution, the marketing team is doing. Those teams are not technical enough to understand the value of some of these features or the nuances of what things they should highlight and those sorts of things. So product is still even responsible for helping those teams find success and sales enablement as well, doing trainings for those teams, all that sort of stuff. In an organization like Stream, the NPS, that real satisfaction metric really does funnel back to products ultimately and so I think it does make sense for us to own. It's a Spider- Man thing, right? With great power comes great responsibility. You owe a lot to all these organizations to make sure that they're well set up for success, because if we are seeing a trend where NPS is very low with customers who mention customer success in their verbatims, right? You can't just lump that on customer success. You as a product organization also have to think about what role you play in customer success's ability to serve customers and make them happy and what things you can change to enable them to help improve that score and thus improve customer satisfaction.
Eric Boduch: Awesome. Thanks. What's your favorite product?
Ben Golden: It's a good question. I have a hard time coming to a favorite because there's a lot of different products that I really like appreciate and admire for a lot of different reasons. One that's been top of mind for me lately, like in the pandemic is Slack honestly. I found it interesting how some people actually really hate Slack. I like didn't appreciate this until I don't know a few conversations a few weeks ago, but the Slack and chat in general certainly get Stream as part of this as well. But it's just becoming a richer and richer platform for communication. It's like one of the most dynamic and changing and evolving digital communication mediums that we have. Email is fundamentally the same. I mean, Google is starting to draw an amp and so we're getting a little bit more interactivity and there's companies like Movable Ink and Rebelmail that have tried to create a lot of creative interactivity and email. But for the most part, email is just like paragraphs of texts with images embedded and it has been for 20 years, 30 years, whatever. And like text message is the same, phone calls, like Zoom's starting to do slightly more interesting things, but fundamentally looking at video of each other and talking with audio, but chat is really interesting to me and there's so much opportunity for it to become more dynamic and interesting. You have like message threads, you have a similar concept of like quoting a message. You've got reactions. You've got embedded gifts, like unfurling of links. The richness of that communication medium is just like really exciting and interesting to me. And also just like, I depend on it so much for how I actually just do my job day- to- day. Reminding myself about messages, marking messages as unread. Like all sorts of little nuance features that even 10 years ago we wouldn't have expected in any chat, but now that's almost table stakes for any place. Even LinkedIn messages have a mark as unread feature, which just can't not have it these days. So just the complexity of Slack as a product and the feature set and stuff is very favorable to me.
Eric Boduch: So Ben final question, three words to describe yourself.
Ben Golden: Oh man, that's a toughie. I guess ambitious is maybe a good one or I like driven a little bit more. I'll say driven. I like to think that I'm humble and that I certainly value that in how I think about good professional showing up. And I think maybe the last word that I would choose is clarity. I think clarity is so much of what good product managers do and what I care about professionally and something that as we get more and more information in our world, we have to think more and more about how we keep it clear and concise.
Eric Boduch: Thank you, Ben. Appreciate your time.
Ben Golden: Yeah, no problem. Thank you, Eric. It's been very fun to chat.