# Why Product Memes Are More Important Than a Product Roadmap Why Writing is the Essential Skill for Product People, How AI Changes The Role of Product, Big Mistakes Founders Make When Hiring Product Teams with Kevin Niparko, VP Product @ Twilio 20Product · Sep 29, 2023 · 46 min · 8,666 words Speakers: Kevin Niparko, Harry Stebbings Source: https://www.996.fm/episodes/20vc--ep-944302c3/ ## Cold open **Kevin Niparko** [0:00]: The faster you ship, the faster you learn all of the ways in which you were wrong. I think there are really two hiring mistakes when it comes to hiring product people. I see writing as really this forcing function for thinking, for testing these ideas. **Harry Stebbings** [0:14]: This is 20 product ## Intro **Harry Stebbings** [0:15]: with me, Harry Stebbings. And this is the monthly show where we sit down with the best product leaders in tech. And I'm so thrilled to welcome to the hot seat today, Kevin Niparko, VP of Product at Twilio. Kevin joined Twilio through the acquisition of Segment, where he spent an incredible eight years in numerous different roles including as head of product. Before entering the world of product, Kevin was a management associate to the world renowned Bridgewater Associates, a discussion we have stay on his incredible lessons from there. But before we dive into the show today, ## Sponsor read **Harry Stebbings** [0:43]: and speaking of tools we cannot live without, I need your input on the '20 v c Miro board about new guests we should feature for twenty v c in 2023. Just head on over to miro.com/20vc. Miro is a tool I consider to be truly game changing. It's a visual collaboration tool packed with the right tools, tech, and templates to help you think of and create that dream product. That means you can brainstorm the perfect product with your team, vote on the best ones, and explore with your customer journey road map all on a Miro board. Whatever you need, Miro's infinite whiteboarding capabilities help you get there. It acts as your team's single source of truth. And now I'm using it to hear from you. Go ahead and add your suggestions for 20 VC guests on our Miro board at miro.com/20vc. And finally, you have to try Epo, the next generation AB testing and feature management platform designed to help you run reliable and powerful experiments. EPOS saves you time across the entire experimentation workflow. Planning tools help run experiment scenarios beforehand. Best in class diagnostics mean you spend less time debugging issues. Their cutting edge status engine helps you reduce experiment run times. Plus, Epo sits directly on top of your data warehouse and your North Star metrics. So it gives you this real confidence in the experiment performance and the ease in conducting follow-up deep dives. No more extended analysis cycles to understand results. And that's why companies like DraftKings, ClickUp, Momentive, and Cameo all rely on Epo to power their experiments. Get access today at getepo.com. That's getepo.com. You have now arrived at your destination. ## Conversation **Harry Stebbings** [2:22]: Kevin, I am so excited for this. As I said, it's so unfair. I hear so many stories about you before, but I'm so ready for this. So thank you so much for joining me first. Thanks for having me on. Not at all. But I wanna start with your beginning because you started as an analyst. How did you make the move from analyst to product? Let's start there. **Kevin Niparko** [2:41]: Yeah. So I actually started as Segment's first data analyst. So I was really helping the early team figure out the business model, product direction, and go to market strategy through our own internal data. I joined right around the Segment Series A, and being the lone data analyst at a very small data company means you're often the internal customer who's using the product every day, sort of the frontline tester for a lot of the new ideas, the dog eating the dog food. And so I developed this perspective on how the product should work, specifically geared towards analysts, business intelligent use cases. And so I had really formulated a perspective on the opportunities that were sitting around the data that Segment was helping our customers collect. And as Peter and the CEO and co founders were formulating the product team made the hop over to product from Analytics. Did you find it an **Harry Stebbings** [3:32]: easy transition to make? **Kevin Niparko** [3:34]: It's a great question. I like to think analysts make incredible product managers largely because you're forced to think broadly about the business, really dive deep into data, both quantitative and qualitative, and the signals that you can gather to really inform strategy. And so, you I felt like there was a great foundation there. I also think being in the early stages of a company, you end up playing a lot of different roles and seeing a lot of different parts of the business. So analytics took on the role of growth at times, of partnerships, of sales ops, and so you really get a unique lens across the business sitting in analytics. **Harry Stebbings** [4:10]: Before we dive into kind of products in the world of products, you're also at Bridgewater, which does shape so many people's perspectives in many ways. Calvin told me I had to ask this one. What are one to two of your biggest takeaways from your time at Bridgewater? **Kevin Niparko** [4:23]: Bridgewater is definitely a pretty special place. I don't know how many of the listeners know what Bridgewater is, one of the largest asset managers in the world, also committed to building an organization that's all about radical transparency, and honesty, and ruthless pursuit of the truth. I think there were really two interesting learnings here. The first is around trying to better understand how people think around you to sharpen your decision making. Especially in business conversations in the workplace, people are often talking about and debating opinions. Right? So like Harry believes option a is the best option. I believe option b, and we're going to debate option a versus option b to figure out which one is superior. But I actually think there's something more valuable, and the approach that is often taken at Bridgewater is really trying to understand how Harry got to option a. Right? What is the data that Harry is seeing? What is the mental model that Harry has of the world that is leading to that perspective? It's through understanding that way of thinking and processing that you can actually refine and sharpen your own decisions by really understanding those around you, and debating, and openly understanding how people are approaching their decisions. You know, I think the second big takeaway is actually pretty similar, which is how they approach their trading systems, which is highly systematic. Bridgewater is essentially some of the smartest people in the world encoding their market understanding in this giant prediction machine, and constantly refining that machine as new information is gathered, as feedback is collected from the markets. And so I think the reality of this is that, you know, most organizations, most teams are dealing with the things that are coming at them, not systemizing and building the machine that can help them solve future problems. And so that approach around being highly systematic and systemization in everything that you do can really help accelerate the team over the long run. **Harry Stebbings** [6:19]: If we think about I'm sorry. I'm jumping around, but fuck it. I love this discussion. If we think about like speed, efficiency, systematization, when we're doing product discussions, Gustav, the CP of Spotify said on the show, talk is cheap and so we should do more of it. I always find that a hard one because I think discussion actually can slow everyone down. Debate isn't always needed. Let's just go. How do you balance in your head in product between hearing everyone's feedback and input without losing velocity and speed? **Kevin Niparko** [6:49]: You know, I think there are probably two parts to that. The first is this trade off between speed and quality. People typically believe that this is a trade off, and you need to make a decision where you want to fall on the spectrum. I think one of the things that we've learned at Segment is that the faster you ship, the faster you learn all of the ways in which you are wrong, and all of the ways in which you can make it right. Reality and customers and procurement teams are very unforgiving. The faster that you get your ideas out into the market, the faster you're gonna learn. Moving quickly is I think really a key to unlocking that next level of quality. **Harry Stebbings** [7:26]: I I think the other thing is also like very rarely does something take a long time, but it was perfect because it took that longer time. Actually, you learn more when you just shipped it. Segment was an amazing journey. Yeah? Ended with an incredible exit obviously to Twilio where you are now. What are one or two of your biggest takeaways from the Segment journey that really impacted how you think about products? **Kevin Niparko** [7:47]: Yeah. Absolutely. So, you know, I think a really important part of the Segment story was that the founders, before anybody joined the company, had really struggled to find product market fit for a few years before landing on Segment. There was a really high bar internally and rigorous thinking around what it takes to achieve product market fit. You know, I had the privilege of being able to introduce Segment's second product. This was really introducing sort of the first customer data platform on the market. And we'd spend the first six months really sort of shaping the idea, researching this with customers, iterating on their feedback. But we were running into a ton of technical problems. Customers weren't really ripping this thing out of our hands. And Tito, essentially our product and engineering leader, the grown up in the room for a lot of Segment's story, sat us down and he essentially told us we had three months to make the project work, or the project was dead. It was the deadline that we needed, pressure that we needed. We ended up cutting a ton of the bells and whistles, and things that we thought we needed, and really simplified down to the product that customers were looking for. And there are a few takeaways from that. The first is you need to be rigorous and honest with yourself and your team when things are working, when they're not, and why they're not. But then I think the more important piece is that constraints can really breed creativity. Right? By shortening the runway, you can actually move faster, get to the right product faster. And so thinking about compressing that timeline and driving towards that creative approach when you have constrained resources. **Harry Stebbings** [9:25]: It's so funny. You say about the creative approach, and then you say about kind of compressed timelines. It makes me think of this challenging debate or balance for me in product, which I never know the answer to, which is is product art or is it science? You're stabbing Spotify, he was contrarian. He said that it's 99% science and we overestimate how much art there is. He's the only one that says that by the way. So my question, is it more art or science? **Kevin Niparko** [9:49]: You know, I think about product management is all about building great products that users love that are aligned with the long term interest of the business. And so if you break that down, right, you have building great products, which I think boils down to great discovery and really understanding customer needs. And there I do think that there is a highly scientific approach that you can take and repeated process that you can build around that. Then there is building things that users love, right? Taking those problems and actually translating that down into creative solutions given the technology landscape, where the market is at, and that is going to largely boil down to an art which sits somewhere between, you know, design, engineering, and product management disciplines. And then there's of course making sure that where you are heading is in the long term direction of the business, and that requires deep market understanding, understanding where competitors are at and where they're likely to move, and what their long term strategy is relative to yours. And so there, I don't think you can boil that down into a formula. **Harry Stebbings** [10:50]: Put a number on it. What's art? What science? **Kevin Niparko** [10:55]: 80% or 20% science. **Harry Stebbings** [10:58]: Oh, I like it. I always think it's actually a little bit like a jazz band. You can listen to a satisophonist on their own and it's nice. Just like you can pick up a product if you really look for it and it's good. But you need the growth, you need the marketing, you need the trumpet, the horn, whatever it is to come together for it to be a really successful entity. It's a great analogy. Thank you. I'm a podcaster for a living, so I'm pretty much this is my job. I remember, I'm in the arena cabin. Okay? So You said before that there's four states to product teams. What are the four states and how should founders think about this? **Kevin Niparko** [11:31]: So it's a pretty powerful model for thinking about the performance of your product teams and how you can get them to the next level. So if you just imagine this grid where you have shipping fast and slow, you have impact high and low as the other, you can really think about mapping where your product teams are relative to those two dimensions. And so over time, there are really only four states that a product team could be in. You can have a team that's not shipping, and there are a lot of reasons that can go into that. Maybe they introduced a feature that led to an outage, and so there's a lot of fear on the team. Maybe they got a lot of feedback from a last product ship, and so they're reticent to move the needle. Maybe they don't have a clear strategy, and so they're in tweaking mode, essentially. They're not delivering on the roadmap, but you really need to unlock this state, you really need to think about how can you get them into shipping mode, have them ship something really small, and then celebrate the heck out of it to really encourage that feedback loop to get into the mode of delivering for customers. The second state, you can have a team that ships, but they are delivering impact. And so here the pace of development is good. They're moving really quickly, but it's relatively low impact work. How do you as a product leader measure impact? At the end of the day, you need to be looking at customer outcomes for Segment and, you know, as customer data infrastructure. We really think about unlocking use cases around customer data. So what are the ways in which we are actually influencing end user and customer journeys to improve the product experience for our customers through data? Really thinking about what is the end value that you are delivering for your customers. Are you continuously achieving that? **Harry Stebbings** [13:15]: Okay. So in there, we're shipping fast with low impact. Not great. What's next? **Kevin Niparko** [13:20]: So finally, there's the good stuff, which is you're consistently shipping and you're consistently delivering high impact work. And teams in this state are generally going to be really high context. They're gonna be high trust across engineering, design, product. They're very high talent density. Right? So you have a lot of great people that are working there, and they're empowered to take risks. This is the bar that you want to set for your entire EPD org. When you have a team in this state, you want to figure out ways in which you can keep it intact and keep it going and really get the heck out of their way. By looking at product teams through this lens, you can really think about what are the different strategies that you need to take to get them to continuously deliver and continuously deliver high impact. **Harry Stebbings** [14:01]: If we're a founder listening to this, if this is the four states of product teams, I feel totally unequipped for this as a generalist founder. When should I hire a CPO to be on top of this? **Kevin Niparko** [14:12]: Great question. At Segment, we had a bunch of really technical founders. We also brought in product focused engineering leaders early on. And so we never really had a CPO in the traditional sense. I think the biggest consideration is where is your founding team at? What are the biggest gaps that you need to fill? Really thinking about a CPO as somebody who can play the role of up leveling the product organization, but needs to be complementary to the founding team. **Harry Stebbings** [14:38]: What's the hardest thing about bringing in a CPO, do you think? **Kevin Niparko** [14:40]: You know, I've made a lot of hiring mistakes over the years. I think there are really two hiring mistakes when it comes to hiring product people. The first is not really having a clear understanding of the role that you're hiring for. So there are a bunch of different archetypes that you can hire. Some product people really spike in strategy. Some really excel in culture building, and team building, and people management. Others specialize in go to market partnership, or product execution. Right? And so you really need to be crystal clear on what you are looking to hire for. And then the other, I think, is really being deliberate and committed to hiring for those set of spikes. Know, I think allowing dictate a hiring decision is never good. The hiring manager, the CEO in this case, needs to be empowered to make the decision, even if there isn't consensus among the hiring team. **Harry Stebbings** [15:35]: I do have to touch on the hiring process there. We're there. But first off, how do you stage hiring for new product hires? We have a first meeting. What do you want to achieve in that first meeting? Is it a get to know you? Is it a case study? What does that first meeting look like if we're running a process? **Kevin Niparko** [15:50]: You know, the hiring process really starts well before the first meeting. Right? So there's a lot of internal discussion, debate, and wrestling that goes into defining the role and the spec that we're looking to hire for. That is upfront work that will really pay dividends as you move through the process as a hiring manager. A good example of this, we're hiring right now. We're backfilling a director on my team. A lot of our conversations internally are what are the sets of qualities both in terms of leadership product leadership, but also the things that this person had brought to the team that we are looking to persist or continue on. And so this person was a sales engineer, had great relationships with our go to market team, was a technical expert internally on the product. While we're looking for a great product director, we're also looking for those sets of qualities that are maybe less directly tied to the role and more complementary to the entire team. That's really how we think about designing that role and spec that we are looking for. And then the challenge is going out and finding and testing for those spikes. **Harry Stebbings** [16:55]: Let's say we have three candidates that we're looking at. How do we structure that process? If you were to advise me as like an early stage founder, how would you advise me on how to structure that hiring process for product people? **Kevin Niparko** [17:06]: So that first call that we're gonna have, you know, it's gonna be talking about career or product experience, sort of a get to know you. And then we think about structuring the interviews in a few different buckets. First is around product strategy, which is talking about big bets and decisions that this person has led within an organization. You have execution, which is how do you take that large strategy, translate it down into an executable roadmap, and then actually deliver on it. You have people management for, you know, CPOs and product leaders. And then technical fluency, which is, you know, we do run a relatively technical product and we're selling to engineers. And so we do expect our product team to have a certain level of technical fluency. **Harry Stebbings** [17:52]: Why do most people fall down in that? **Kevin Niparko** [17:54]: Product strategy is probably the most difficult for candidates as they work through sort of their impact. I think it's really important to think about what is the overall direction of the business? Where is go to market at? How do you think about bringing together all of the needs of the business, balancing those into a cohesive strategy, and then being able to articulate that strategy and incept that into your organization. And so that's generally the hardest area to hire for, and I think it's one of the most amorphous to test for. Do you give case studies? Our strategy interview takes a few different forms. We cover both internal decisions that we are currently wrestling with. So sort of a live conversation and talk through how the candidate would approach it, as well as talk about the candidate's experience. But we don't give theoretical cases or external cases throughout the hiring process. **Harry Stebbings** [18:51]: You mentioned that committees maybe aren't the best way to hire. That's contrarian. Most people say an interview panel is quite useful. Why is a panel or a committee not a useful way to conclude a hiring process? **Kevin Niparko** [19:02]: Definitely value in getting a bunch of different diverse perspectives from your team on the quality of a candidate, and working through these different dimensions of a candidate's experience. But at the same time, at the end of the day, a hiring manager is the ultimate decision maker. I view the hiring team as really an input into the decision, which ultimately needs to be owned with the hiring manager. At the end of the day, that's the person who's going to be working most closely with this person, and so therefore they should be empowered to be the decision maker. **Harry Stebbings** [19:35]: When you review your hiring mistakes, my biggest is I've overweighted brand. I've seen that they've come from a big logo and I've gone, they must be brilliant, and they're not. What are your biggest hiring mistakes when you reflect on hiring for product teams? **Kevin Niparko** [19:48]: It's a great question. I think overweighting skills, specific domain expertise, a common one that I've fallen into specifically with hiring product people. The best product leaders within our organization are generalists, apply their craft to a bunch of different domains. And there are very few cases where we needed specific knowledge and skills to bring onto the team that was really the key input into a decision. More often than not, that is going to be something that somebody can learn on the job. And so you don't wanna overweight skills, instead really focusing on experience, the overall craft of product management, and making sure that they're at the bar there. **Harry Stebbings** [20:30]: It's interesting you said there about the specific skills. When I spoke to many of our mutual friends, they described you as a man of many talents. Meaning that you are an all rounder. You do lots of things well. How important do you think it is for product leaders to do a little bit of everything versus be much more specialist and work on the machine rather than in it? **Kevin Niparko** [20:50]: Great question. You know, I think it's tough to be a product leader in a product led organization because you're responsible for so many different things. Right? If the product doesn't sell, you're the one who's on the hook. If your team is flooded with support requests, generally product needs to go figure out what is wrong with the product. If you're misaligned on margins or the product doesn't scale, yes, that's a systems and engineering problem, but also at the end of the day, you're trying to meet your customers' needs. And so I think the beauty and the challenge of being a product leader in a product led organization is that you're uniquely positioned to solve these issues, even if they're not traditionally product problems. But I think what that really begs is, you know, somebody who can go out and learn really quickly a bunch of different disciplines, and then go solve the hardest problem within an organization, regardless of whether it fits into a product bucket or an engineering bucket or a go to market bucket. I think a great example of this was when we introduced Personas, which was a new product offering and add on to our core product within Segment. We really needed to spend the next year as the product team who was closest to the discovery and the customer needs, going out pairing with our sales team, and really delivering it to market. Essentially, spent a year in sales, figure out what needs to be solved, and go do **Harry Stebbings** [22:09]: You said there about really immersing yourself in sales. A big part of sales still stay as demos, showing the value of the product ahead of time. I heard you were incredibly talented when it comes to creating demos at speed. Calvin was like, get him to walk you through his process for creating demos. Would that be possible? **Kevin Niparko** [22:28]: Yeah. You know, one of the challenges with building product is you have to believe in this future state that better than today. That can be really hard for people because they don't necessarily feel it. They're familiar with the status quo. Change is really hard. Like, do you remember this example of Bill Gates going on Letterman and explaining why Letterman needed the Internet? I think it was like in '95 and like Letterman's just like completely confused by why anybody would need to listen to a baseball game on the internet when there's radio. You know, I think you run into these types of pushback both internally and externally when building new product. And I think demos can be a huge unlock here. Which is how do you pull that future forward, and really deliver that experience? How can I make Harry really feel how much better his life will be with the product that we're about to build, or the idea that we're looking to pursue? You know, I think it really ties back to your customer problems, the things that you wanna solve, and really being able to showcase that the thing that you are building towards is going to solve an acute high priority problem for your customers. I love weekly demos with my team. I think that's probably the way in which we can most shorten the feedback loop. There's not a ton of overhead or polish that's required. It's really about pull up the terminal, show me what we've built over the past week, and what is the end to end value that we are creating. Demos can be this great vehicle for that. **Harry Stebbings** [23:57]: If you were to leave a meeting with your team sad or angry post the demo, what are the reasons that you leave sad or angry? **Kevin Niparko** [24:05]: A key unlock here, which is you need to commit to your demo a week ahead of time. So you need to say, what are you going to deliver next week? And then you work backwards from that. The times in which we've had demos that didn't go well, it's generally because we hadn't really set the bar for what we were going to deliver the next week. You know, it's amazing how much the demo or the product gets built in the five hours before demos. That deadline is a really helpful forcing function for being able to go from wherever you're at to a way of showcasing and explaining what you've built. When do you do the demos? Thursday or Friday? Morning, afternoon? Generally in the afternoon. **Harry Stebbings** [24:47]: For me as an early stage founder that you're advising, what are the mistakes that you suggest I'd avoid when it comes to demos? **Kevin Niparko** [24:54]: It's a sort of two pitfalls here. The first is that they become too high stakes, and so people feel like they need to put a lot of polish and prep into their demo. They spend a good chunk of their week on overhead and polish, as opposed to the actual core components of the demo. And so that's why encouraging people to show docs that they've written, pull up the command line, really show off whatever that is that they've been working on in an end to end full value delivery, I think is really important. And then the other that I would say is not making it too performative. It doesn't need to be a ton of people, a huge group. It can be down to your product pod or a small team that's been working together. **Harry Stebbings** [25:39]: Does the way that you do demos change when product teams are remote versus in person? **Kevin Niparko** [25:45]: Yeah. We've definitely had to adjust through the pandemic. And now as a fully remote organization, think about how we construct this differently. We do have this concept of asynchronous demos as well to the extent that people are working in different time zones, aren't able to make demos, can submit a recorded version of their demo, which is just as good. We'll watch it, and everybody will give their feedback there. **Harry Stebbings** [26:10]: You mentioned that kind of a, kind of the asynchronous element there, but also maybe sharing stuff that you've written as well. I have what a brilliant writer you were. And you said before about the importance of product people learning to write. Why do you think it is so important that product people are able to write? And how do you advise them to learn? **Kevin Niparko** [26:27]: There's this great interview with one of the writers of The Onion. Ditto, The Onion. It's satirical I know the public information. Yeah. But there's this interview with the writers, and they go through the process in the writers room for coming up with headlines, and then the articles that they end up writing for The Onion. It's interesting because they come up with like hundreds of headlines every week. They eventually whittle that list down to, I think it's like 10 to 15 articles that actually get written. And the difference between all of the ideas that get generated in the room and what actually gets written is that there's no real substance to the joke that they come up with in the writer's room. Right? So they give this example of woman crying at the penguin museum. And it's like funny on the surface, but then you sort of ask yourself like, why is that funny? There there's no like, there's no meat to that joke. And I think ideas have this illusory nature, which is on the surface they seem really good. But when you force yourself to sit down and write the idea down and really unpack it, either they don't seem as good as they do on the surface, or by comparison to all of the other ideas that are out there, this one is not the highest ROI thing that you can be working on. And so I see writing as really this forcing function for thinking, for testing these ideas, and really understanding if that oasis on the horizon is actually filled with water or if it's just a mirage. **Harry Stebbings** [27:52]: I I totally agree with you. I find the same with actually investment memos. When you actually write about a competitive landscape, it really crystallizes, oh, shit. This is really fucking competitive versus just thinking about it. If we think about writing with regards to product and prioritization, crystallizing thinking, what does that mean that we do? I'm a product manager listening. What can I do? Help me understand. I should write what now? **Kevin Niparko** [28:15]: You know, I think a lot of the great product thinking gets encoded into this concept of a PRD or a product requirements document. These can take multiple forms, but I really think at the end of the day, the thing that you are trying to articulate is what is the customer need? What have you learned through the discovery process? What are the key problems you are looking to solve? And why is your team, your organization, your product uniquely positioned to solve those problems? It's not about solutions. It's not about how you can solve them. But it's more about what and why you are solving that problem. And so this concept of the PRD is really powerful. It creates structure for product teams to really be able to articulate and synthesize everything that they've learned from going out and talking to customers, And encoding that into a document that everybody can engage with, read, give feedback on, and iterate on. **Harry Stebbings** [29:09]: How do you create a habit in writing? How do you like demos where you said weekly enforcing that time constraint. How do you create accountability incentive structure to writing behavior? **Kevin Niparko** [29:21]: Yeah. Absolutely. That's where product reviews come in, which is really a forum to discuss product requirement documents and really go through them. And so being able to have a forum where product leads can discuss their learnings, share their learnings across the organization really creates that incentive in that forum to be able to get product teams to sit down and write and synthesize and work backwards from the product review conversation that they wanna have. **Harry Stebbings** [29:50]: Product reviews. Everyone does them very differently. How often do you do a product review? **Kevin Niparko** [29:54]: We've gone through a bunch of different iterations on product review over the years. At times, it's been sort of wildly centralized and seen as sort of a gate to projects before they get green lit. I think my view has evolved quite a bit here, is product review is really an opportunity for PMs to gather additional input and drive additional alignment across the organization. And so we run product reviews on demand as product teams are at a point where they want additional input. Flexible list of attendees who can attend. Generally, we'll include some folks from go to market. Product leadership, anybody who design and engineering, anybody who can really weigh in and help sharpen the thinking there. Empowering product teams to really own their own destiny. **Harry Stebbings** [30:37]: How do you drive outcomes from these product reviews? I find a lot is like discursive debate. How do you drive meaningful outcomes for product leaders and product teams to have tangible takeaways? What should they do? **Kevin Niparko** [30:50]: I think a key component of the PRD and the product review really comes down to a set of clear decisions that you're looking for the team to weigh in on. There'll be large questions that need to be answered, and really being able to pull that out of the folks that are coming to product review through a set of very targeted questions here. **Harry Stebbings** [31:11]: Do you send them ahead of time? Do you let the people that you're sitting down with prep? Or do you throw it on them in the meeting with the PRD? **Kevin Niparko** [31:19]: Absolutely. So prereads generally sent out twenty four hours in advance. If, you know, you're working up to the last minute of a product review, which happens from time to time, you'll create ten to fifteen minutes where everybody can sit down, read it, and think, and comment in the doc. And so we really wanna create the space not only for product teams to write PRDs, but also for folks who can really help sharpen the thinking to read it and weigh in on it. And so need to create the space and time to do that. **Harry Stebbings** [31:47]: How do people fuck up product reviews? **Kevin Niparko** [31:49]: To general mistakes teams will make, the first is going to be jumping too quickly to solutions. They have a great idea. They're sort of working backwards from the solution. That's one. And then the other is tying back to our conversation around demos. Not giving a clear feeling and experience that you're looking to deliver at the end of the day for the customer. What does it look like to actually solve this problem for a customer? Why is that experience going to be unique to our position and what we are building? And so I think those are probably the two biggest pitfalls. **Harry Stebbings** [32:26]: Speaking of interesting lessons, I I think one that I have from this prep session that I did was around your take on memes. And Calvin also told me to ask this. He said that you said before about product memes are more important than your roadmap. What did you mean when you said product memes are more important than your roadmap? **Kevin Niparko** [32:46]: With all the talk about how important it is to write as a product leader, I think at the end of the day, people are never going to read your PRD. Most people are not actually going to review your 20 page roadmap. And so product memes are this concept of really simplifying your thinking down into the shortest, simplest, most memorable perception of your product, and then distributing those ideas through the meme. If you think about memes, these are generally these distillations of really complex ideas and structures. It's about compression. It's about taking these different ideas and creating knowledge shortcuts for people. And so I think a good example of this is like memes gone wrong. Right? The ways in which memes can work against you. If you think about a sales team that has lost faith in the quality of the product that they're selling, that in and of itself is a meme. It spreads at the water cooler, over drinks at the end of the week. It not only hurts your sales, but it also becomes self fulfilling, and it spreads. This is sort of the dark side of the meme, and you can invert that, and think about ways in which you can control the narrative, and really build alignment around what you are building through exciting memes. You know, we had a few cracks at this at Segment over the years. So these could be big ideas and campaigns. **Harry Stebbings** [34:04]: What makes a good product meme versus a bad product meme? **Kevin Niparko** [34:07]: So I think simplicity is one. Accessibility for folks. And then memorability. The fact that it is actually something that you will remember, you will walk away from that conversation remembering. We had a big campaign for Segment which was called, you know, What Good is Bad Data? It's just sort of a catchy phrase which helps you understand data quality at the end of the day is going to be really important for your data strategy. I think they can also be really small. So we had this feature which was essentially self healing identity graphs. Obviously complex, very deep in the weeds. But we called the project Project Roomba after the beloved self driving vacuum cleaner. You know, that sticks with people. It allows them to understand what you're doing even if they don't understand the specific details of it. **Harry Stebbings** [34:51]: I think humor one and I also think how real time is really important. When there is a news cycle, make it funny. I find real time current affairs integration is one of the most important things for Resonance. **Kevin Niparko** [35:03]: Absolutely. **Harry Stebbings** [35:04]: Has your mind changed around like the seriousness of product? I know it sounds stupid. When you enter and you're young in your career, it's a lot more academic, I think, discipline than one approaches it with today, where you have an importance of product memes is quite central. **Kevin Niparko** [35:20]: Absolutely. And I think this gets back to the conversation on art versus science. When you start your career in product, there's a lot of learning and skills and craft that you can pick up by following the playbook. And then I think the reality is as you grow within product, science is a helpful start. But at the end of the day, it comes down to creative thinking and ways in which you can solve problems across the organization. And that doesn't always boil down into a template or a specific process. It can often be these really creative funny ways of getting people to understand the work that you're doing. **Harry Stebbings** [35:58]: Dude, I I if you invite across the organization, I feel so sorry for you from a resource allocation perspective. Because you have to like weigh up product that generates revenue today. You then have to also weigh up innovation, staying ahead of the game, how to introduce AI and every other, you know, exciting new technology into the existing product suite, and then just scaling and growth. How do you balance between core product, innovation and scaling as a product leader? **Kevin Niparko** [36:22]: I think those are the three buckets. Having that framework around the three horizons, I think is really helpful. What are you doing well today? What is emerging over the course of the next one to two years? And what do you need to do long term, three to five years out, that's gonna set your product and org up for success. You know, I do think that the allocation across those buckets are going to swing, especially in the early days at Segment would swing pretty wildly between ninety, ten, zero When we're going really hard at our core product. Really honing the quality of our core product in the early days. To really periods of innovation where we're trying to expand, build new products, and really solve new problems for our customers when it looked probably more like thirty, forty, 30 across those different buckets. Have you ever got that allocation wrong? One of the early challenges building Segment was around scaling our integration catalog. So we have, you know, hundreds of different tools and APIs we connect to. Customers expect a really high quality integration with a new tool. These APIs are constantly changing and emerging today on the martech landscape. I think there are like 10,000, 12,000 different marketing and analytics products that you can connect to. It becomes a really big challenge of building a cohesive and really high quality catalog for our customers. And so I think there were periods where we weren't investing the right focus in integration quality. I think that ended up showing up in some really hard conversations that we had with customers, and realizing that we had probably been too focused on expansion in new products and not investing sufficient capacity in really ensuring our core product was high quality for our customers. You have to make some really hard calls as a product leader when you're growing so quickly. **Harry Stebbings** [38:12]: Two questions for you. One, I'm an early stage investment of yours. How do you advise me, a CPO or a product leader, on when's the right time to do product two? **Kevin Niparko** [38:22]: I think waited a really long time at Segment to introduce our second product, which I think was a function of our core product was growing really quickly, and we felt like we had a lot of runway. Key piece to keep in mind is what does that growth rate look like one to two years out? I think that's probably the right time. When you see that flattening or starting to stall out, you know, one to two years out in the future, you really need to be ahead of that. I really encourage folks to stay focused on core product as long as possible, but also knowing that you need to be thinking about the long term and new products and second products take a while to build, hone, and deliver to market. And so you really probably need twelve to twenty four months to make that a reality. **Harry Stebbings** [39:05]: Sometimes you release a second product, it doesn't hit. How do you advise product leaders on when to give it more time? It needs a bit of tweaking versus Kevin, we got it wrong. We need to pull it. How do you balance between the two and how do you advise me? **Kevin Niparko** [39:18]: It's hard because there's a lot of sunk cost fallacy. Right? We spend a lot of time building this. We have a lot of large investment here. But I think the reality is if customers aren't ripping the product out of your hands, that is your signal, ensuring that you have thought creatively about ways in which you can deliver this product to market, have really tried and exhausted all of those ideas. But when you hit product market fit, you will definitely know. Been fortunate enough to experience that multiple times at Segment. Have also been on the other side where customers are not pulling this product out of our hands. And I think you need to look at those hard situations and make the call that it's probably not the right thing to be investing in if you are not able to really break through. **Harry Stebbings** [40:02]: Speaking of kind of when it works in the product market fit being very obvious there and then also pulling product. If you think about two reviews and then we'll do a quick fire. But it's one your best product decision. What was it and what did you learn? **Kevin Niparko** [40:14]: You know, one of the first products that I worked on at Segment was around data warehousing and what we called Segment Warehouses. This is helping our customers get direct query access to their customer data in their data warehouse. I think back in 2015, this was very early. Warehouses have played this key role across segment has really been a huge growth lever for the business. And I think the reality or sort of how we got there was we went out and we listened to some of the most advanced customers that were building things around Segment, and had actually built some very hacky workarounds to load data into a data warehouse from an s three bucket. And they helped us realize what the potential could be for data warehouses. And so I think the key learning there is go listen to your smartest customers, sit next to them, really learn what they are doing with your product, because that can really inform and give you early signal as to what's gonna be big. **Harry Stebbings** [41:08]: Flip side, everyone makes mistakes. What was the biggest product mistake? And how did you learn from that? **Kevin Niparko** [41:14]: You know, I think there are a few cases where we built instead of partnering. I think there is a lot of opportunity, more opportunity than product teams typically see to actually start with a partnership and really expand your product capabilities through what others are building. You know, I think on the surface, a lot of these products seemed really simple, but when you clicked a few levels deeper, there were a lot of dragons hiding beneath the surface, and it was a lot harder of a challenge than we had initially given it credit for. And so I would just advise founders and product people, don't fall into the build trap. Really put a premium on partnerships and go explore those, especially when you're thinking about areas that aren't necessarily your core competency. **Harry Stebbings** [41:59]: I always think about like Shopify and Stripe as a great example, which is obviously Shopify could build a Stripe internal. But actually, it's not cool, and they should focus on where their business is. I'd love to finish on a quick fire, Kevin. So I say a short statement and you give me your immediate thoughts. Does that sound okay? Let's do it. Tell me, when do you listen to users and when do you ignore them? **Kevin Niparko** [42:18]: Yeah. I'd say always listen to their problems, but rarely listen to their solutions unless they've built something that is a working solution and are willing to show you it. **Harry Stebbings** [42:27]: How does AI impact the future of product? **Kevin Niparko** [42:30]: My sense is that we'll see a rise of a product architect role, which combines the disciplines of product and design and engineering into one, and uses AI as leverage and an accelerant to really deliver new products to market. **Harry Stebbings** [42:44]: What one piece of advice would you give to a product leader starting a new role today? **Kevin Niparko** [42:49]: I would say go on a listening tour. Right? So when you're early, you can ask the most fundamental questions about your customers, the product that they're using. I think that's the best place to start. **Harry Stebbings** [42:59]: I'm a really early PM in my early PM career days. What advice would you give to me on what I can do to get promoted? **Kevin Niparko** [43:06]: Go solve real urgent problems for your customers. **Harry Stebbings** [43:10]: What in the product toolkit could you not live without? **Kevin Niparko** [43:12]: I would say Gong for sales intelligence. How do you use Gong? Yeah. So there are two use cases. One is searching for keywords specifically around roadmap and specific topics that we're looking to dive into. And then the other is for more quantitative research. How frequently are certain terms or products or features coming up in sales cycles? **Harry Stebbings** [43:34]: Final one for you. What recent company product strategy have you been most impressed by? **Kevin Niparko** [43:38]: Yeah. I would say retool moving from internal tools to a low code app builder. I think this is going to be incredible opportunity for product builders to be able to build with less technical tools, but be able to deliver on data informed apps. **Harry Stebbings** [43:57]: Listen my friend, I love doing this. I know we've jumped around, but I cannot thank you enough for me putting such a cohesive schedule together and it being so comprehensive. So thank you so much for being such a great guest. **Kevin Niparko** [44:08]: Really appreciate **Harry Stebbings** [44:09]: it, Harry. I just love that discussion. If you wanna see the full video of the discussion, you can find it on YouTube by searching for 20 v c. But before we leave you today, ## Sponsor read **Harry Stebbings** [44:19]: I need your input on the 20 v c Miro board about new guests we should feature for 20 v c in 2023. Just head on over to miro.com/20vc. Miro is a tool I consider to be truly game changing. It's a visual collaboration tool packed with the right tools, tech, and templates to help you think of and create that dream product. That means you can brainstorm the perfect product with your team, vote on the best ones, and explore with your customer journey road map all on a Miro board. Whatever you need, Miro's infinite whiteboarding capabilities help you get there. It acts as your team's single source of truth. And now I'm using it to hear from you. Go ahead and add your suggestions for 20 VC guests on our Miro board at miro.com/20vc. And finally, you have to try Epo, the next generation AB testing and feature management platform designed to help you run reliable and powerful experiments. Epo saves you time across the entire experimentation workflow. Planning tools help run experiment scenarios beforehand. Best in class diagnostics mean you spend less time debugging issues. Their cutting edge status engine helps you reduce experiment run times. Plus, Epo sits directly on top of your data warehouse and your North Star mattress, so it gives you this real confidence in the experiment performance and the ease in conducting follow-up deep dives. No more extended analysis cycles to understand results. And that's why companies like DraftKings, ClickUp, Momentive, and Cameo all rely on Epo to power their experiments. Get access today at getepo.com. That's getepo.com. As always, I so appreciate all your support, and stay tuned for an incredible episode this coming Monday with Finn Barnes at the general partnership.