64 / Managing User Feedback to Prioritize Your Product Roadmap
About Keith Frankel
Keith Frankel is a startup founder, community builder, and full-time dad to two weird dogs. Based in Boston, he was formerly the Head of Creative & Design at HubSpot (IPO) and Chief Product Officer at Firecracker (acquired). Currently, he is the CEO of Parlor.io, a venture-capital-backed startup focused on transforming the way software companies engage their customers to build better products.
Rework, by Jason Fried and David Heinemeier Hansson.
In This Episode
Product leaders need to be astute prioritizers. That means we have to say no – a lot. To the sales rep begging us to build “the next big thing.” And to the customer account rep pleading for a flashy new feature. Our response to these cries for help is, “Make your case. Tell me why. Show me the user feedback for why we should reprioritize our long-term roadmap.”
In this episode of the Product Momentum Podcast, Sean checks in with Keith Frankel, co-founder and CEO at Parlor.io, the widely popular feedback management system for SaaS teams. Gathering and analyzing that user feedback is key, Keith explains. As a product leader at HubSpot and chief product officer at educational technology startup called Firecracker, Keith recalls telling his reps, “I will prioritize anything that you can prove to me will have a material impact on this business, but I just cannot chase after every shiny new object.”
Faced with competing business cases and insufficient budget to do both (or either), Keith and his team created Parlor – a product designed for product people. It engages users at multiple levels and serves as a “tie-breaker” of sorts that drives decision-making wisdom through customer insights that align product and customer-facing teams.
Listen is to get Keith’s inside scoop on a super-interesting experiment he’s running that completely rethinks the role of internal meetings and their impact on workplace productivity in a remote-first environment.
Finally, be sure to catch Keith’s three paths to innovation. Cool stuff, indeed.
Sean [00:00:19] Hello and welcome to the Product Momentum Podcast. This is a podcast intended to entertain, educate, celebrate, and give a little back to the product leadership community.
Sean [00:00:31] Hello, everyone. I’m excited to share this interview with Keith Frankel from parlor.io. He’s built a really cool product for product leaders. This is a really cool interview. Keith talks about leading product teams. He gives us a lot of great insights and I’m excited to share this content with you. So let’s get after it.
Sean [00:00:51] Well, hello and welcome to the pod. Today we’re here to meet with startup founder, community builder, full-time dad who also has two weird dogs, Keith Frankel.
Keith [00:01:01] Hey bud, it’s great to meet you. Thanks for having me.
Sean [00:01:03] Thanks for being on. Let’s hear about those dogs real quick.
Keith [00:01:05] I’m a dad of two dogs. Those are the only children I have. I’ve got two whippets. They’re a brother and sister pair of whippets. Whippets are these, like, weird medium-sized greyhounds. So people like to raise them, but they’re just two couch potatoes for us. We don’t make them leave the couch if they don’t want to.
Sean [00:01:23] All right. What prompted me to reach out to you for the pod was that you are the founder of this super interesting company that’s transforming the way software companies engage with customers to build better products. So, like, dead set in the center of our space. How are you doing that? What prompted you to come up with the idea for parlor.io, and let’s hear about the product a little bit and what problem you’re trying to solve.
Keith [00:01:44] Yeah, great question. So I’m obviously CEO of Parlor, but prior to Parlor… We’re the parlor that actually knows how to spell it, not the free speech social media network; we’re the ones with the actual trademark. So in an after-dark podcast, we can talk about how painful that experience has been. But in the meantime, let me talk a little bit about parlor.io. So prior to Parlor, I’ve actually been a product manager my whole career. So primarily at Boston-based startups, I was a director at a company called HubSpot up until its IPO in 2014. And after that I was Chief Product Officer at an educational technology startup in Boston called Firecracker, which was acquired a few years ago. The reason I start with that is because Parlor was actually just an internal set of tools we built at my last company, Firecracker, to help us solve all these internal problems we were dealing with there.
Keith [00:02:30] So essentially the back story there is when I joined Firecracker as head of product, I was held accountable to the roadmap like every product person is. But pretty much immediately upon joining Firecracker, I found myself in essentially instant conflict with all of our customer-facing teams. So every single day, a sales rep would come knock on my door and say, “Hey, if you don’t build this, I won’t close this deal.” Every other day, a customer success rep will come to my door and say, “If you don’t build this, we’ll lose this customer; they won’t renew; they’ll turn; they’ll have negative NPS.” Every day a customer support rep would come over and say, “this is the thing I’m hearing about most this week; we have to build it.”.
Keith [00:03:05] And I just kept finding myself saying the same thing over and over and over again: “I will prioritize anything that you can prove to me will have a material impact on this business, but I just cannot chase after every shiny new object, like, I need you to make a business case, I need you to make a business case.” And so that was sort of the back story. Prior to Parlor, I would have never probably admitted this having been a product person. But now at Parlor, I think it’s safe to say that I’ve realized that our customer-facing teams are kind of the empathy team like they tend to be the good people where product people like me tend to be curmudgeons from time to time.
Keith [00:03:37] And so at Firecracker, the customer team was thrilled to try to make a business case. They’re like, “oh my gosh, yes, what do you want to know?” I was like, “listen, we have to focus on the most important stuff: what’s the most commonly requested product enhancement from our highest paying customers who have a renewal date in let’s say 90 days, and the decision-maker at those accounts are at risk.” Maybe they’re inactive in the product or they have low NPS scores. So most important customers, most important users in those accounts, some proven sense of urgency, and some material impact on the business. And it was literally impossible for them to answer that question. And we used so many damn point solutions to help us do our jobs at Firecracker. We had everything from Salesforce on the CRM, the entire Atlassian suite for engineering, task management, and roadmap management; and all kinds of point solutions in between from ticketing systems to live chat tools to QVRs, you name it. And we couldn’t answer the question. And so the backstory of Parlor was essentially us trying to build an internal set of tools to align our product and customer teams around the needs of our users and then use that information to actually dictate the long-term roadmap of the business. We basically came up with this out of necessity. We needed it ourselves and that led us to build it.
Sean [00:04:48] Super interesting. And these are the critical problems that product leaders historically have had to figure out. I have a theory about the core of visioning for any good product team is about keeping in line, like, who are we here to serve and what problems are we going to solve for them? And the third is how are we going to measure our success, both strategically and tactically. But when we don’t have clarity on those dimensions, we can’t prioritize. We can’t prioritize well so we end up doing our poker planning and throwing bunch of things at the wall and guessing and then hoping that we’re going to get back some good feedback or actually deliver results without knowing. So what you’re trying to do is take an incremental step here to making better predictions about what’s going to work in the wild.
Keith [00:05:28] Yeah, it’s so interesting. Parlor’s the first product I’ve ever built that I use. So HubSpot was a marketing automation toolset. Eventually, we added a CRM there. I was never going to be a marketer or a salesperson, right. So HubSpot was never going to be a product that I was a first-order user of. Firecracker, we built basically adaptive learning platforms for US medical students and medical schools. As much as my parents would have preferred, I was never going to be a doctor. And so I was never going to be intimately related to the actual firsthand experience of using Firecracker.
Keith [00:06:00] But Parlor was a tool for me, and it continues to be a tool for people like me. And that has had such a fascinating outcome as the primary user and builder of that tool. And what we find ourselves internally, the way we talk about Parlor is so interesting. Parlor is not the decision-maker, right. All the smart people we hire to do this work, the customer people, the product managers, the engineering team, like these are the decision-makers. But what Parlor provides is evidence for decision making. It’s essentially the tie-breaker. So what typically happens is all these different stakeholders from different teams representing different needs and prioritizing different atomic units come to the table and we all argue using different sets of evidentiary support.
Sean [00:06:39] Sure.
Keith [00:06:39] But what Parlor almost does is it provides the baseline set of evidence that we can all get united around to make the decision. So it’s been so interesting to actually be, what are those like old like shave commercials where it’s like, “I’m not just the founder, I’m a user.” Like, that’s almost like Parlor. I’m not just the founder, I’m a customer. And so, yeah, it’s been really interesting to see how we can use it internally to basically break the tie between our internal teams.
Sean [00:07:05] Right. Well, one of your key hypotheses I think you’ve taken on with this product is that it’s not just about product leaders engaging with their users, it’s also about users engaging with other users and that the secret sauce lies in there somewhere. I’d like for the audience to hear a little bit more about that and your theories on users engaging with each other and how to extract the real value out of that.
Keith [00:07:27] I would frame it slightly differently. I think those are important inputs, but I would say that my hypothesis is there’s no silver bullet for any of this. So when you look at most organizations, like, what’s the extent of this kind of work they do? It’s highly one to one through like customer support tickets or live chat tools collecting the inputs and then some support or customer success team has to go in and, like, try to manually aggregate those. But it’s a very one-to-one, reactive process.
Keith [00:07:53] You have some companies that think NPS is like the gold standard metric that you run and that answers everything you need to know, which is completely absurd, right. Or you have the new age of tools like this that basically allow for Reddit-style voting on feature ideas, right. So you tend to have people really focus on one of these approaches. Some organizations may do two of them, like frontline one-to-one support and NPS scores, and some of the more progressive companies do all three. But what’s really interesting to us is that all of these provide evidence for decision-making. These are just inputs into the equation, which I think has been one of the most compelling takeaways for us is that ultimately what we want to do is we want to provide the vehicles through which a team can capture the insights that they need. And sometimes those insights are better captured one to one, sometimes those insights are better captured one-to-many, and sometimes those insights are better captured many to many through just being an observer of how users interact with each other.
Keith [00:08:53] So, yes, we have all these mechanisms in Parlor that allow me as a product manager to proactively engage my users during their natural use of the product to learn something specific. So maybe I want to survey a user population as soon as they complete onboarding to say, “Hey, customer effort score, how difficult was it for you to complete onboarding?” That’s critically important information that will help me understand a very specific thing I can do as part of my job to improve the product experience. Maybe I want to have a user interview with a user and I want to invite them the fifth time they engage in a feature so that I can have a conversation with them about their thoughts of that feature because clearly they’ve shown me that they are intimately familiar with it. That’s all great and those are important inputs, right.
Keith [00:09:35] But there’s also this really fascinating user-to-user layer that I think is largely untouched or unexplored by most organizations. And so let me talk through what I mean by that. The closest we have to this is really focus groups. That’s like the old-world version of this. I recruit ten people to get in a room, I offer them pizza, and then I have a moderator ask them some questions and expect them to have these real conversations. But what’s been so fascinating about us is that we tend to cater to customers, our customers, who have an intrinsically motivated user population. What do I mean by that? Think about Salesforce. Salesforce customers are businesses that desperately rely on Salesforce the software to work appropriately in order for them to do their jobs. If Salesforce were to shut down, hundreds of thousands of marketers and salespeople and success people would all be out of luck. They’d be freaking out. That intrinsic motivation is almost entirely untapped by most product and UX teams I’ve ever encountered.
Keith [00:10:36] What’s the alternative approach we tend to take? Providing some extrinsic motivator like an Amazon gift card or a Starbucks gift card or a free month subscription if you help answer this question. But there are user populations in almost every product, in particular, B2B, the entire user population of B2B software products is intrinsically motivated because they need it to do their job. And you can actually harness that intrinsic motivation and drive a really fascinating amount of almost like collaboration, not just between people on both sides of the product, those building it and those using it, but also just among the users. So when we build Parlor, we have mechanisms that are deliberately designed for specific use cases: one to one, one to many, or amongst the many.
Keith [00:11:19] And so harnessing that intrinsic motivation that a user has to try to influence the direction and ongoing improvement of the product because they care about the product and need it to do their jobs, that’s something that the community layer can do that is truly unique, versus like a one to one or one to many, which can be difficult. And so ultimately, the way we think about it is user-centricity is what’s ultimately important. And you don’t always have to be in the conversation. Users can be in the conversation with each other and all of these are just vehicles for collecting the inputs or insights that help our teams ultimately make the decisions about how to move forward. None of them are better, inherently, than the others. But together, the cumulative value is that you have a much more exhaustive picture of what’s at play here rather than, “I run NPS once a quarter.”
Sean [00:12:09] Sure. I don’t necessarily agree with you that one isn’t better than the other. I think the context dictates what’s more important, and that’s the key. Every product ecosystem is very different. You have different users with different concerns. And to pull on a point you said earlier that I do agree with, these are all valuable and it’s the product leader’s job to figure out how to extract the most value from each of the different forms of gathering feedback and insights.
Keith [00:12:32] I think that’s right.
Sean [00:12:34] In my opinion, there is a hierarchy to it, though. I think the most gold can be derived from the direct feedback that your best users actually actively go out and give you. When they drop something in and they take the time to tell you how your product screwed up their day and what you can do to fix it, you can’t take all of that advice as gospel, but certainly, they’re using the product, they care about the product, you messed up their day. So that’s where the gold is.
Keith [00:12:56] The interesting side note there is Parlor is unique in that we are actually not used by product management teams in a vacuum. Parlor is much more like slack than it is like Jira. If you sit down an organization, you say, “everybody raise your hand if you use Jira,” you’re going to get the engineers and you’ll get some product managers and maybe there might be a smattering of individuals outside of those teams that use it. Similar with Salesforce. If you sit an organization down and you say, “who here uses the CRM?” All the salespeople are going to raise their hand as the prospect closing tool and some customer success teams might raise their hand if they’re forced to manage their accounts in the CRM as well.
Keith [00:13:30] But when you sit a team down and you say, “who uses Slack?” everybody raises their hand. OK. Parlor is almost more like that. We have primary users, OK, so primarily customer success managers and product managers log into Parlor on a daily or weekly basis. But then we have a whole host of secondary and tertiary users. The secondary users can be the engineering team or the customer support team, and they don’t log in to Parlor, but they use Parlor via the tools they already use. So Parlor is used via our Jira integration by the engineering team. It’s used via the support team through integration with Zendesk, something like that.
Keith [00:14:05] That has had a really fascinating impact on the way I think about a lot of this stuff. Having originally been a product person and sort of thought about Parlor originally as a product for product management teams in a vacuum, my thought was always what you’re getting at. So how do we get the best insight from the user? And so I would think a lot about, like, the insight is what matters. But what I’ve noticed since supporting sales and customer success teams, in particular, is that not just the insight is important, but the perception the end-user has about how seriously you consider their insight is almost more important. Right? We will have customers who don’t churn because they feel like they’re being heard and have a voice and have a long-term influence in the ongoing evolution of the core experience that they spend time and money on. That is more important for us as an organization or our customers’ organization than the one-off feature request, even if it came proactively from a power user. And that has been, I think, really the most fascinating thing about this. It’s almost allowing an organization to weaponize product discovery for churn prevention.
Sean [00:15:15] Yeah, I love that. In my workshop, one of the frameworks I have is around advocacy and how do you create advocacy? One of the things I say is, simply demonstrate that you actually listen to the people taking the time to give you the feedback and you just put a nail in that coffin for sure.
Keith [00:15:28] I think there is a new type of power user that in the future people will start talking about, which we colloquially refer to inside of Parlor as the collaboration qualified user, basically CQU. So you’ve got regular users, you have active end users. Maybe there’s an extra layer of monthly active users that we could refer to as engaged users. But then I think there’s this extra layer. Not just how do we get someone to use the product, how do we get them to become a power user, but how do we get them to become a collaborator in Parlor? It’s almost more like the kind of experience loops or breakdowns you see with wikis online. You’re probably familiar with ninety-nine-one as a behavioral breakdown of how people engage with wikis. 90 percent of the population are consumers. They basically read the wiki articles. Nine percent of the population are authors and one percent of the population are editors. Like, I think there’s probably something similar that’s yet to happen in a lot of software, almost every software product, where there’s going to be this whole different layer of power user, which is like the advocate, or however, the influencer. But instead of influencing other users, they influence you. And I think there’s something really compelling there that is completely untapped for most industries as of yet.
Sean [00:16:39] Brilliant.
Keith [00:16:42] I spend a lot of time obsessing about this if it is not clear.
Sean [00:16:47] I love that. So I think we can probably spend an hour talking about that, but we don’t have so much time. Let me ask you another question, take you a little bit on a sidetrack here. What’s got you excited these days? What are you reading or what kind of content are consuming that you think would be useful for other product leaders to share?
Keith [00:17:00] Rather than content, we could talk about that as well, I can talk to you about an experiment we’re running at Parlor that might be interesting. This is the thing I’m most excited about out of anything we’re doing at Parlor is an internal experiment we’re running about how we manage our time. And I’m so compelled by some of the early results of this. The data set is limited as of now, so this is still mostly anecdotal, but I’ll give a little back story. The basic idea here is in a remote-first world, which Parlor still is, and this probably is applicable even in a colocated world as well, how do we manage meetings?
Keith [00:17:35] So let me give a little bit of backstory about what led us to run this experiment and how we’re running this experiment. I think it’ll be interesting to people. So basically, Parlor’s based in Boston or I guess we were based in Boston and our lease was up for renewal the same week that all non-essential businesses in Boston were shut down. So we got really lucky and we had an out. So I said, “well, let’s go this whole remote-first thing, let’s just give it a shot, and let’s do it.” So we moved one hundred percent remote and I was convinced for the first six months of this that the average employee was far more productive working from home than working in an office. Now, there’s caveats there. If you have young children, it can obviously be a very different story, especially when those children were homeschooled or basically doing remote learning. And you could just, like, my co-founder, Jason, our CTO, you can just see it in his face. He has two young girls and he’s just beaten down from it. But for most employees, I was convinced people were more productive.
Keith [00:18:26] The real challenge for us was actually employee burnout. People were not taking time off. There was no escape from the job. It was just bleeding into everything, right. We used to have the commute where some of us could travel from work to home and that was a mental trigger to switch off. And that was gone. And so what we started to see is that people were not working remotely, we were living at work and it was just draining the organization. So I started getting really interested about sort of the future of work. What are ways we can make this work? Force people online? We did summer Fridays, we did four day work weeks. We tried all sorts of things. But what I started to realize is it wasn’t sort of these big overtures that I felt like were draining people, it was just the amount of lost time that people were spending during the day.
Keith [00:19:12] So I started digging into my own meeting schedule and so what I saw was that the way that we were dealing with meetings internally at Parlor is the same as every organization I’ve ever worked at and I felt like I was completely broken. So here’s basically the story. Every day I’d have some external meetings with potential customers or customers or investors. Those are all fine. Those are work. But then I would have a good four hours of internal meetings. Now, those internal meetings almost never were about work getting done. They were about talking about work getting done. And then we would leave those meetings and then we were essentially having more meetings in between those meetings but those meetings took place in Slack.
Keith [00:19:47] So I started saying, “well, like, what is the point of Slack? Is Slack a notification system for us or is it a meeting channel?” And it was a meeting channel. We were having conversations in Slack, so I had meetings that were broken up by meetings but in another channel, and on top of those meetings, I still had ad hoc phone calls and emails. Then what I noticed is every one of those meetings took about 50 percent more out of my day than what was originally scheduled. If you have a meeting and then there’s a 30-minute block and then you have another meeting, nobody can sit down and immediately start producing top-notch work. No one can sit down and write the next American classic in literature in 30 minutes. You can’t even get the first page done.
Sean [00:20:24] Can’t even get into the flow.
Keith [00:20:25] Good creative work is like REM sleep, right. It takes the average adult 90 minutes to get to the first REM cycle of sleep. And if you get woken up, let’s say your neighbor’s dog starts barking and you wake up out of that REM cycle, you don’t just magically go to sleep and hit back in that REM cycle, you have to essentially start over. And good, productive, conceptual, creative work is the exact same way. I have to sit down and work at it and marinate at it to go from a bad idea to an average idea to an interesting idea to a good idea to a great idea. And so ultimately what I found is when I looked at my calendar, large chunks of the day were spent with internal meetings where we talked about work getting done. In between those times, I didn’t do work because it was like, “oh, there’s 30 minutes, I can’t get anything good done or maybe I could just send some emails or I’m going to go get a cup of coffee, take my dogs outside.” In between those times, we were having meetings in Slack.
Keith [00:21:13] And so ultimately what ended up happening was I was doing like an hour and a half of actual work every day. And I know that was happening across the organization. Again, I’m focused on internal meetings. So we decided to run an experiment. We’ve been running this for the last month. I’m convinced this can work for most organizations, some version of this. So here are essentially the rules we set in place. Rule number one is there are two dedicated meeting blocks every week, Monday morning and Friday morning. Those are the two dedicated meeting blocks and we do it from 9:00 a.m. to noon. So no internal meetings can happen out of 9:00 a.m. to noon Monday or 9:00 a.m. to noon Friday. OK. The second thing, basically, principle or rule we set in place, was that no meeting could be longer than 30 minutes. That forced people to be super deliberate about how they spend that meeting time because you only get a 30-minute block.
Keith [00:22:00] Now, what’s interesting about that, when you take three hours on Monday and three hours on Friday and you break it down into 30-minute blocks, guess what? Everybody’s allotted 12 meetings a week. That is more than enough for almost every team or person I’ve ever worked with, 12 meetings a week. And we’re just front-ending and back-ending them. So we’re basically bookending the week with these meetings. The next thing we did is we outlawed all recurring meetings. This is like the shocker for most people. Recurring meetings, it’s important for us to get people together that work together. But what I mostly see happen with recurring meetings is people get complacent about them. We hop in, someone who’s meant to lead it kind of finds things to talk about, and eventually they come to a conclusion. And maybe 30 percent of all those recurring meetings are people just shooting the shit. So we outlawed recurring meetings. And instead, what we want to do is, if you want to have a meeting, you have to be deliberate about scheduling a 30-minute block and putting an agenda on the calendar invite. It takes five seconds to create a meeting invite, but what it does is it makes people be incredibly deliberate about what they schedule.
Keith [00:23:00] And so we’ve been running this for the last month, basically two three-hour blocks for meetings Monday morning, Friday morning, maximum meeting length is thirty minutes, no recurring meetings. And that alone has completely changed the organization. So we ran this for like two or three weeks and there’s more Slack chatter, but there was always a lot of Slack chatter. So it’s changed nothing there. And in fact, what it’s done is it’s made people much more deliberate about just quickly getting the answer. So what we’ve seen is even the Slack messages people write each other, they’re much more thoughtful. It’s like, “I’m not going to have a chance to speak with this person, so I’m actually going to pay attention to this and participate in it,” rather than like kicking the can down a road, which so many Slack conversations end up being. So Slack has actually become a weapon for us rather than a distraction, the number one productivity distractor.
Keith [00:23:46] And the final thing that we’ve realized that’s been really interesting is the number one thing people complain about in the system is just not enough togetherness. And they don’t mean togetherness in terms of working together to solve problems. They just mean human to human togetherness. So now what we’ve done is we’ve basically taken Friday afternoon and that is either offline time, so we basically have a four-and-a-half day work week now, or you can spend that time with your coworkers doing anything you want. And it’s basically company-provided time to do anything you want Friday afternoon. If you need to go to the DMV to renew your license, go. Don’t take time off. You have Friday afternoon free to yourself. All right. But if you want to spend that time doing team yoga or playing board games with the team remotely or whatever, you have that.
Keith [00:24:31] And we are actually more productive as an organization because we’ve taken Monday afternoon, all day Tuesday, all day Wednesday, all day Thursday, and there is no distraction. So there’s none of this code-switching that happens in a typical work environment where someone’s looking back and forth and I’ll go, “I have thirty minutes, I’ll just get a coffee, I won’t work,” and then before, you know it, the end of the day’s happened and you’ve done an hour of real work and thirty minutes of emails.
Keith [00:24:53] So that’s, by far, if you can’t tell, it’s the thing I’m most excited about because it’s the thing I’m sitting around and deliberately auditing on a day-to-day basis, thinking about, “how do we work together in an environment in which the most precious resource we have as a startup is time and we are just wasting it on each other in totally unnecessary ways.” So anyway, that’s the thing I’m most excited about right now. Way different from content, but hopefully that’s helpful or interesting.
Sean [00:25:18] Well, that’s interesting. We’ll see how that pans out for you over the next couple of years. I think this Zoom thing has exposed the inefficient way in which we run a lot of parts of our organizations, for sure. I see it all over the place, so…
Keith [00:25:29] So there’s actually fascinating it’s not new, but if anybody’s familiar with Basecamp, I’m sure your audience is and the 37signals guys, years and years ago, they wrote a book called Rework. I mean, this is a decade ago, more than that great book. And if anyone has not read it, they should. But one of kind of the core premises in this is, why do people go to the coffee shop to do work? That’s crazy, right? And it’s because of meetings and managers is a huge reason.
Sean [00:25:57] Right.
Keith [00:25:58] Yep, meetings and managers. So I read that book years and years ago and now a decade later, or however long it’s been, it’s now the number one thing I’m thinking about on a day-to-day basis. How do we organize our internal resources to do better work while still making people feel connected and part of something greater? Not just, “I’m sitting in my pajamas working on my couch again and actually feel like I’m still part of something exciting, but I’m hyper-focused on the work that needs to get done.” So anyway, we’ll see how this plays out. But early inputs are exciting.
Sean [00:26:31] That’s neat. These are good insights. I mean, from a guy who is running a company that’s basically all about product, this is an interesting problem for product leaders to solve. So thank you for sharing.
Keith [00:26:41] For sure.
Sean [00:26:41] And we’ll have to check back and see how that’s going for you.
Keith [00:26:43] That’s right. Yeah, that’s right. Either I’ve lost all my employees or we are just zooming. Yeah, we’ll see what happens.
Sean [00:26:51] One last question for you. How do you define innovation?
Keith [00:26:54] Oh, interesting. That’s great. OK, I’ll do my spin on this. The first thing this makes me think about when you ask this question is, basically as a startup founder, when we were working on Parlor, the question I asked myself is, “how does a young, resource-strapped company enter into a space with a lot of large incumbents and actually disrupt it?” When you say innovation, I immediately think disruption. And historically, there’s been like three ways to do this. There are basically three paths an organization can take to disrupt incumbents.
Keith [00:27:24] The first is to build something ten times better. Now, what’s fascinating is we all think what we have is ten times better than the incumbent. But the reality is it rarely is. And better can be defined as easier, literally more performant, whatever you want. But one path is to be ten times better than the incumbent. Another path is to basically cater to a segment of the market that was ignored by the incumbents. That’s basically what HubSpot did. HubSpot was actually kind of a blend of some of these, but HubSpot came out and sold to SNBs. So there were a million other marketing automation tools: Marketo, Eloqua, Pardot, Constant Contact. Adobe had one, Microsoft had one.
Keith [00:28:00] Why was HubSpot so successful? Part of it is because they built this movement around inbound marketing versus marketing automation, which I could talk about. But part of it was because they said, “no, we’re not going to worry about the enterprise; there are more small and medium-sized businesses that need tools like this to do their job.” They weren’t brand new. They weren’t ten times better than Marketo, but they were 10 times better for a specific segment of the market that was previously ignored. So basically, you can be 10 times better. You can cater to a segment of the market that was ignored, or you could be something brand new. That’s really the approach.
Keith [00:28:34] Now, when you actually look at any super successful company, there’s typically some combination of two or three of these, which is really interesting. And so ultimately, when I think about innovation, what I’m really thinking about is disruption of preexisting methods for carrying out the same task or work. So you can disrupt incumbents in a market, you can disrupt behaviors. That to me is what I think about when I think about innovation. It’s disruption. And so what are ways I can disrupt? I can create something that’s ten times better, easier. I can create a brand new way to think about this, or I can just create a thing for people that have been ignored. And I think when you look across the space, most folks or companies doing anything interesting are doing one or a combination of those items. And it is completely OK to take an idea that’s being deployed somewhere and deploy it elsewhere. That’s still disruption for the people receiving the value, the end-user or customer. So that’s ultimately how I think about it.
Sean [00:29:35] Well, Keith, this has been awesome.
Keith [00:29:37] Great.
Sean [00:29:37] I feel like I’ve learned a lot. I’m going to walk away a slightly better product leader, so thank you for sharing.
Keith [00:29:42] Hopefully that’s true. And if any of it was boring, I appreciate you yawning off-camera for me because I never saw it directly.
Sean [00:29:50] Well, we will definitely post a link to Rework. And we’ll post a link for parlor.io for product leaders to learn a little more about your product and what you do and what you’re up to and wish you nothing but the best, sir, thank you for joining us.
Keith [00:30:01] Thanks, bud. I appreciate you having me. Hopefully, we can do it again in the future after we run this experiment a while.
Sean [00:30:06] Sounds good.
Keith [00:30:07] All right, bye.
Paul [00:30:11] Well, that’s it for today. In line with our goals of transparency and listening, we really want to hear from you. Sean and I are committed to reading every piece of feedback that we get, so please leave a comment or a rating wherever you’re listening to this podcast. Not only does it help us continue to improve, but it also helps the show climb up the rankings so that we can help other listeners move, touch, and inspire the world, just like you’re doing. Thanks, everyone. We’ll see you next episode.