Product Managers in Parks Having Pints

Good afternoon, ladies and gentlemen. Thank you for tuning in to Product Managers in Parks Having Pints. I'm your host, Garrett Galow. I'm a product director here at Cloudflare. I'm really happy to be doing the first episode of this segment where I meet up with product managers around the world, virtually, of course, and we, over a cold pint of some sort, we discuss pertinent issues, topics, skills, and things in the world of product management. So I have, here I have my pint, which is a non-alcoholic sparkling tonic. That's what I'm gonna be enjoying today. I'm not gonna actually say what park I'm in. If you are watching, I invite you to try and figure out the park that both myself and my guest, Simeon, are in. Send an email to livestudio at Cloudflaretv.com and see if you can guess the park we're in. We'll, at the end of the segment, we'll tell you more about that. I'm happy to be joined here today by a dear friend of mine, Simeon Jung, and he, I will turn it over to him to introduce himself and what he's drinking today. Hi, folks. My name's Simeon Jung. I am currently a product manager at Pinterest. I've been working there for a few years now. My pint of the day in a Windows Azure glass is Care Package from our lovely friends at Tennis Ball Brewing. It is a hazy pale with a mosaic and zip code. Nice, that sounds good. Why don't you tell us a little bit about how you got into product management from the start? Yeah, so I, like probably a lot of PMs, have a technical background. So I originally went to school and studied electrical and computer engineering at UT Austin, and over the course of study there, I found myself fortunate enough to be involved in some startup activities and other kind of exposures to product development and product thinking. And when the time came to look at full-time opportunities, I was, again, fortunate enough to be matched with a couple of PM interviews that really found a good affinity for those skills and ended up getting my start as a PM at Microsoft, working on messaging and email and exchange. Nice, nice, very cool. So today we're going to, so every segment, we want to talk about a specific topic in the world of product management. So in terms of, we were talking a little bit before this about what should we discuss, what do we think is pertinent? And I think one that is really critical to the core job of product managers that maybe isn't talked about as much as maybe things like KPIs or other things that we'll probably talk eventually on this segment is customer conversations. To kind of introduce that topic for those that may not be product managers, may not be familiar with it, a core part of product manager's job is understanding what kind of features or product we should be building in order to best serve our customers. And one of the really critical ways to do that is to actually talk with your customers. There's no better substitute for that. And so in that sense, it's really important that that's a very core skill that a product manager builds up. So I mean, before we really dive into some questions, I'd ask, what is sort of your take on how the customer conversation skill sort of fits into the holistic view of product management? Yeah, definitely. I think you mentioned customer empathy as being like a really important role in our job. And I think customer conversations are really the core building block or our best way of building that empathy with the customer. Conversations can kind of happen in a wide variety of ways. Sometimes they're like directly face-to-face where we're able to talk at depth about how our products fit into like the daily workflows or daily lives of our users, or sometimes they're a little bit indirect when we do things like surveys or user research or interaction research with the customers reacting to the new ideas or new products. But I think in general, it forms this foundation of awareness on really what mind space and what circumstance our users are in and help shape all of the behind the scenes realities of what our customers face when using our products. So it's not as straightforward just to solve a problem, but to realize like all the little details about how that problem exists and how that problem can be best solved knowing kind of the details of a user's everyday life. Yeah, I think you touched on a few things that we'll go into. I think, you know, I don't think I said the word customer empathy, but I'm glad you did. I think that is a really good summation of the idea. And I think, you know, promotes a much more sort of service-based approach versus sort of like authoritarian or like decision-based approach to it of really understanding the what and why of what a user is trying to do, what their problems are. Sort of want to focus on that for a moment and sort of how do you, you know, I think the typical thing we see a lot of in a lot of cases, whether it's feedback from people at the company or even customers directly, is they sort of give you the like statement of like, I want you to do X, right? I want, you know, if only you built X, then, you know, my problem would go away. And, you know, I think, why don't you talk a little bit about why maybe that's always not always the best approach to product management and figuring out how to solve problems for customers. Yeah, it reminds me of a quote that we actually have prominently on a wall at Pinterest in one of our home rooms. And the quote's a Henry Ford quote. That's, if I asked users what they wanted or asked people what they wanted, they would have said, ask for horses instead of an automobile. And I think we take that to heart pretty frequently. I think one of the unique roles of a PM is to help tell a complete story, not just about what the user is telling us, but about kind of the mental state and psychological state that a lot of our users are in when using our products. And oftentimes it's hard to communicate the depth and the kind of complexity of those circumstances when you're asking a user, like, what kind of problems do you have or how can we make this product better? I think a lot of the underlying assumptions in that statement is that it has to look a certain way or it might have to do what a competitor is doing, or it might have to meet the workflow that a user is used to rather than maybe designing a new workflow or a new system to solve problems. So in the advertising space where most of my efforts are focused, there's a lot of incumbent and historical ways of doing things that I think we commonly get requests to emulate or to kind of copy what our competitors are doing because it's very easy to ask to have a consistent workflow or a consistent way of solving problems across different marketing platforms. And what we've often found is that generally doesn't work super well when the platforms themselves aren't perfectly the same. If the underlying assumptions or business realities of those platforms are different, then it can be challenging just to build exactly the way a competitor might do it. And so what we typically try and understand a little bit more is the core workflow or even the core problem that's being solved beyond the user. And in the case of marketing, often the user might be multiple different people or multiple different organizations cooperating together to plan and buy their marketing budgets. And what we often find is when we talk to users directly, they might ask for something that might make their job easier, but they often will struggle to articulate or ideate on things that might make a new idea possible or to make a workflow across teams more effective. Yeah, I think you make a really good point that so many of like sort of product feedback or discovery discussions that we might have with customers kind of get focused around like a specific ask from the start, right? I know that I've had many conversations where I'm made aware that a customer wants X, Y, or Z and sort of the precursor of the conversation is that statement, which is very limiting sort of because it's sort of, it hones in on a very, in some ways a solution already, or very specific workflow. How have you, what kind of methods have you found effective for sort of being able to pull the customer when you're talking with them sort of out of that mindset, get them to think more openly about other ways this could be done or related things that might be relevant information, right? Because I can say that like, I've had conversations with customers where I'm trying to ask them questions and sort of you get to the dead end of like, you know, if you just, yeah, just do this, right? Just do this, just do this, just please just do this. And, you know, they're not wrong, right? They're correct to say that, but it makes it really hard on the product side to really understand, you know, the environment that you're working in and what assumptions you should be making when you go forward. So, you know, what things have you found effective to kind of open that conversation up? Yeah, there are a couple of tactics that come to mind depending upon the format of the conversation. I think one really good practice that I picked up pretty early on in my career is to ask why a lot. And I think when anytime a customer would say like, just build it this way, or like just copy some other existing feature, I think understanding why that feature is so appealing and what really delights or excites the user about the availability of that feature is really gonna get at the core decision factors and maybe buying factors that would motivate them asking for this feature. And oftentimes you get away from the nuts and bolts of what the feature does and more about like how it fits into the daily life or daily workflow of that customer. And you'll start to get more into some more emotional statements about maybe the daily life of your customers is plagued with lots of interruptions or lots of urgent conversations or lots of kind of timely challenges. And so a lot of the features they ask for are built around set in time or built around making sure they make fewer errors or fewer mistakes in their processes or their daily jobs. And getting closer to that emotional state of understanding like what keeps them up at night or what really motivates them or excites them to get in the office or get into their seat in the morning, I think is a big part of what we dig into and why we ask the questions why. And I think the other side of that, once we've gathered these why's and understand their workflows really effectively, we often will use frameworks that try to capture that circumstance. You've probably used user stories in your role, jobs to be done as another common framework that helps capture these realities that are beyond just the actual use of a feature or use of a tool. And I love these because you can often capture the circumstance that helps understand the motivation on why people are excited about accessing a new feature or getting a new product launched. And it usually gets to a very emotional and human element of it, even in products that might be as commercial or maybe as business focused as marketing or edge computing. Yeah, I think if you do any sort of user study or you don't even have to do a user study as a user of your own of other products, if you get very frustrated in a workflow very quickly, it becomes very emotional. Why won't this thing just do the thing I want it to do? Why do I feel like I'm fighting the tool? Which is a classic instance of something was wrong in how the requirements and the expectations of what had to be done were built. You brought up a good point around frameworks and we don't need to get into sort of like the nitty gritty of like, what's the right product framework and this isn't the right conversation for that. I think they all have their place. I think one of the things that I always think about when we're working on new products or ideas is how do I actually balance like the use of frameworks? Because at the end of the day, you take a conversation, right? Which even to the extent you can record a conversation with a customer, they agree to it obviously and have that like raw input. At the end of the day, someone somewhere is distilling like those elements into whatever it might be, right? If you're a PM, you write product requirements, or they use jobs to be done or some other system. How do you really balance, what are your thoughts about how you balance it? I know like from our perspective, what I think about at Cloudflare is, we do use some of those different frameworks. Jobs to be done is one that we use a lot more, especially recently. But there's still elements of like, we will put customer quotes from, whether they can be both paraphrased quotes or sometimes actual literal quotes from customer conversations, right? To try and like give life to what it is we're trying to do. Because I think an element of like, PMs we have the pleasure and the opportunity to actually hear directly from the customer, but not everyone, like it's not just a PM building a product, right? There's engineers, there's designers, there's marketing people, there's a ton of other people that go into the process, right? And so like, how do you actually try and translate that emotional level that you keep talking about, right? Into what ends up being a Google Doc or Google Slides or some sort of written down word, right? How do you get that sort of emotion across to the rest of the team, so that they sort of feel the same thing that you felt when you talked to the customer? Yeah, definitely. I think the things that come to mind are a couple of different strategies. I think the first is really to try and eliminate that gap or that kind of isolation between the rest of the cross -functional team and the customer if possible. And that usually includes having pretty big calls or pretty big exposure sessions when talking to customers and including folks who might maybe normally not be included on those calls to just get that customer experience. And I think, especially in the ads world, it's a pretty big focus for us to dock good and to use our own tools and to really kind of explore the emotional side of what we hear and kind of go back to the lab and say, like, let's try their workflow and see what it looks like, which might often include cutting and pasting a bunch of data from some of our tools into tools like Excel and then providing more analysis on Excel. And as you start doing it yourself, you start realizing the actual fatigue of pressing Command C, Command V 80 times to complete a task and realizing that maybe our tools could help make that problem a little less time -consuming or error-prone. And I think that's a very good start. When you talk about frameworks, I think frameworks are, in a lot of ways, a tool for us to simplify some of the communication or to scale our communication when we're talking about a pretty complex or maybe heterogeneous working environment. And so often frameworks for us help shape the overall landscape of a complex assortment of customer opinions and circumstance into a more, I would say, digestible view. If you imagine the customer landscape at Pinterest, we have a wide swath of customers from small SMBs serving local businesses to large Fortune 500 companies. And I think it can be challenging to appropriately measure and weigh the relative value of each of those voices or customers across our business strategy. And it can be even more so to understand where the ideas or the customer needs begin to diverge across those segments. And so a lot of the jobs to be done in frameworks or documentation that we write really helps focus not just the raw empathy and understanding of the reality of the customers, but how that circumstance fits into our broader strategy. And I'll find myself writing a lot of documents that describe not just why these problems exist and why they might be interesting to solve, but how they're also strategically important to our business to solve them in this particular order or to solve them with a specific set of complementary features or priorities that makes sense for the business. Yeah, I do just wanna reiterate one of the things you said to any other product managers listening to the call, the idea of including more than a broader swath of people in the interview or research process whenever you're talking with customers. I think that's actually a really, really critical thing that I think some people don't, they think like, oh, I can't do that. Like, is it okay? Or am I wasting maybe some of that person's time by having them involved in that conversation? And I think that's like, that's not at all the case. I think as much as I think less of PMs as the conduit through which all things flow through and more like the way of bringing two things together, bringing customers closer to the entire process of product development. So I think that's actually a really good point that I wanted to double down on a bit for anyone listening in. Totally agree. One of the things, and actually another thing you mentioned is sort of like the diversity of customers. At Cloudflare we serve, again, from the Fortune 500 to people running a blog for free on the Internet. And so that's a constant thing we come up against is how do you both capture those requirements, those needs from varying customers, even for a similar type of problem in a way that we can then provide services and solutions that meet the needs across all of those different areas. Across the board. There's no perfect way to do that, right? It's a constant challenge. Sort of on that note though, and you can tell me how much this comes up at Pinterest. I think it probably does. How do you effectively structure or get this sort of customer conversations or feedback when you have varying sort of types of customers? So the example to speak to Cloudflare is basically we have enterprise customers who are a certain type of customer. Those customers typically have customer representatives at the company, right? Customer success managers, solution engineers who are assigned to their account, right? So not only do they have a voice inside the company speaking for them, but because there's less of them, smaller number, I can go directly speak to them anytime, right? I can reach out to a customer success manager and say, hey, I saw this feature request for this customer. I'd like to really talk to them and explore that idea more. Whereas for our pay as you go customer business, people that sign up free on our website or pay with their credit card, they don't have that same voice inside the company. There's obviously millions and millions of them in our case. So it's obviously can't go talk to every single one or nearly as high a percentage of them. So how do you, especially in that case, right? How do you really try and get an as accurate as possible representation of that voice in order to better understand what you could be doing there? Yeah, I think a couple of tactics come to mind in the previous conversations you mentioned like having direct user quotes in a lot of your documentations. And I think that we've taken to a pretty deep level, including having like our executive staff go on what we call like a creator's caucus to better understand what content creators need and the realities of what it's like to create content on Pinterest and we've done similar things for some of our small to medium businesses that have, again, like you're mentioning like a smaller sales footprint or engagement footprint with the broader organization. And a couple of things like really shine when you have that really high touch model, at least for a small group of folks is that you come across a few things. One is the problems that they face are often easier to identify when you meet them face-to-face, but often you become more attuned to how you can find similar circumstances by looking at data. So we might find that our users struggle with creating lots of content at one time. And we can kind of go back and test whether that's a pretty common or widespread problem across this SMB segment by looking at our data and saying, yeah, like very few of our SMB users are creating more than 10 or 20 or 30 ads at a time, while the enterprise users might have more sophisticated tools or workflows or specialized staff to make that easier. So I think it starts with, again, going to the human element and having those conversations to help seed the ideas and follow-up analysis that you might do to help paint that picture. But then again, like showing that this isn't a outlier opinion or a single point case, but it's actually a pre-representative of a large swath of customers, which in the case of a lot of businesses make up a potential for a big segment of revenue that often could be prioritized equally or even more so than some of the maybe niche demands of a higher tier or a larger customer. Yeah, I think that's really interesting, taking first-hand accounts, first-hand information and sort of matching that up against the data that you might see in product usage or other elements. There's a, I'd have to go look it up. I can't remember where I read it. There was an article someone wrote. It was about product user research, sort of this is more in this stage of where you're less of trying to understand what the problem might be, but sort of getting direct feedback on, here's a design, a mock-up that we might have. And it sort of talked about like, how many interviews do you need or how many people do you have to talk to to get an understanding? Because the unfortunate reality is you can't talk to everyone. And actually, to approach actually significant results, you only had to talk to like five to 10 people. And basically the idea was like, every single person you talk to after that, more and more of what they say is going to be the same kind of feedback on your mock-up or your demo or your design. And so each one is giving less new information. And so actually after a handful reiterating a bit and then going to the next group of people with that information, then actually gives you more insight into, it allows you to learn more much faster without having to carry through a hundred conversations, which could take months to schedule and do, right? I think Clever, we're very lucky. It's very easiest for us to reach out to even our self-serve customers. They seemingly are more than happy to speak with us and it's not true at every company. So we're very fortunate in that regard. I sort of wanna pivot a little bit still in the realm of customer conversations. But a lot of what we said, if you're a product manager listening, or even if you're an engineer listening, like you can pull out a lot of things from this that you might be able to apply. But customer conversations don't happen in a vacuum. They aren't just the PM and the customer talking, right? There's obviously often designers or UX researchers or engineers, but there's also sort of the customer representatives, especially in the case of talking with enterprise customers, right? There's a solution engineer, success managers, other sort of supporting folks that have a role in that customer success. What do you think those people in those kinds of roles can do to help facilitate customer conversations in a better way? Because their goal is to do right by their customer, give them the best experience possible. How can they help facilitate better conversations, more meaningful conversations to drive action that solves the problems their customers have? Yeah, I think one thing that comes to mind, and I think it'll probably come to mind for a lot of PMs who've experienced businesses that have maybe a few outlier customers or have a few customers that have a large percentage of their business share is really giving context about how the problem isn't just the customer specific problem, but is really a problem that might span across multiple verticals or customer bases or workflows. And again, like thinking of it less about a transaction, like it's not just let's solve a problem to get this much in revenue or this much in new business, but to talk about like the overall value and strategic element of solving that problem for the business as a whole and a broad set of customers within that business. It's not uncommon, nor is it like accidental that a lot of our sales teams and account teams have transitioned across multiple accounts or even multiple parts of the business over the years. And we do that kind of intentionally to help stitch together some of the common needs and foundational requirements across a large set of customers. And what that usually does is push some of the feedback that we get coming in as more strategic in nature and less about kind of a fire drill need of fixing a customer issue right now because it's mission critical and more about how we can help shape both the internal product as well as the customer's understanding of our strategy and kind of keep them in lockstep. Yeah, I think that last part is really good. I've noticed that when you are open, as open as you can be with even customers about how we're thinking about things, like why it may take less or more time than the customer might expect to solve a problem, they're actually very receptive to those ideas. I mean, I'm somewhat biased because at Cloudflare, most of the people, customers I talk to are technical folks of some sort themselves. So they sort of understand the process of building and shipping software. That's a luxury that maybe you or other PMs may not have to the same extent. But I think everyone understands that doing things can be hard or take time. So I think that's a really good point. Sort of switching gears as we sort of approach the end of our time, one of the things we're gonna do in all of these segments with our guest is ask the question of, as a product manager, what is the hill that you'll die on? So the typical phrase, like, I'll die on this hill. What is an opinion you hold so strongly that you will fight to the death over that opinion? So Simeon, what is your hill? What is my hill? Yeah, I think a common maybe misconception or belief that a lot of folks, especially maybe folks who aren't PMs have about the role of PM is that I think folks see them as the ultimate decision maker and kind of the CEO of the product or feature, if you will. And I think that takes a little bit away from what a lot of us see as our core role as product managers. And for me, I look at some of the skills and the tactics that we use, like customer conversations as something that isn't really unique or limited to the PM discipline, but should be kind of adopted and broadened to the broad cross-functional team and really anybody who's involved in helping our customers succeed. I think a lot of folks might see that PM is like the pilot in making all the decisions, but in reality, as we scale up and as our scope increased, it's really challenging for us to have that context and make every single call ourselves. And so it really relies on us to trust our team to have the awareness that we help set to understand the customer, understand the business and make those calls on the ground that are quite numerous and ultimately really important to get right as we execute. So yeah, my hill is that the distributed awareness and distributed product thinking is critical. And as a PM, I think we often try to grade ourselves on how well the broader team understands the product and how it fits into the competitive environment and less on like the quality of every decision that we've made and trying to check off the box of where we made all the right decisions at a given feature. Yeah, I mean, I personally hate the idea of the product managers, the CEO of the product. I think it totally gives the wrong impression to how that process works. So I completely understand the hill you're on and I think I would be on the same hill with you. As we wrap up, Simeon, I wanna thank you again for taking the time to come and speak with me on this topic. I really appreciate it. It's been really good. I've learned some things. There's always more to learn as a product manager. Before we go, in case someone couldn't figure out, Simeon, where you happen to be meeting us from today, what park is behind you? What park are you in? Yeah, so this is Central Park in Manhattan. It's a pretty high view of it. So you probably don't get to see this if you're a tourist, but hopefully it's a good scenic landscape for a Zoom background. Yeah, and for those, mine might be a little bit harder to figure out. This is actually Enchanted Rock, which is a park in Texas, west of Austin, a few hours. Great place, really nice area. So thanks again, everyone, for tuning in to Product Managers in Parks with Pints. Tune in again for the next episode.