Skip to Content

91 / Capacity to Learn: A Skill All Top Product Managers Possess

Hosted by Sean Flaherty & Paul Gebel

Listen

About

karthik-suresh-podcast-guest

Karthik Suresh

Ignition

Karthik Suresh is the Co-Founder of Ignition,which is a collaborative hub for marketing & product teams to plan, execute, and measure the go-to-market side of launching. He is a product and a technology leader with experience as a founder, an early startup hire, and a key player in defining product strategy — and finding a market fit. Karthik has extensive experience building products in consumer, enterprise, and the data domain across early-stage and established companies such as Facebook, Craft, KCG Holdings, and Morgan Stanley. Karthik is a graduate of Carnegie Mellon University and London Business School.

“It depends.” A two-word answer that might seem overly safe. But is the only honest response to the question: “What does it take to be one of the top product managers?” Among dozens of dependencies, the PM role depends on whether you’re at a startup vs. a large, well-established company, says Karthik Suresh, co-founder of Ignition and a product leader with extensive experience as an early start-up hire and a key player in defining product strategy at Facebook.

“It’s like two completely different roles,” he adds. When at a startup, Karthik realized that product managers worked with limited resources, so much of the role was based on how well you hustle just to get things done. At Facebook, his role focused more on stakeholder management and collaboration than product strategy.

One skill that all top product managers possess – regardless of specific role or circumstance – is the capacity to learn. Particularly helpful when things don’t go according to plan. As Henry Ford once said, “The only real mistake is the one from which we learn nothing.”

This holds true even when that mistake cost a company $400 million in just 30 minutes! Be sure to listen in as Karthik Suresh shares a story about an algorithm gone wrong – and the important takeaways not only for a company, but also for an entire industry.

Paul [00:00:19] Hello and welcome to Project Momentum, where we hope to entertain, educate, and celebrate the amazing product people who are helping to shape our community’s way ahead. My name is Paul Gebel and I’m the Director of Product Innovation at ITX. Along with my co-host, Sean Flaherty, and our amazing production team and occasional guest host, we record and release a conversation with a product thought leader, writer, speaker, or maker who has something to share with the community every two weeks.

Paul [00:00:43] Hey everyone, Paul Gebel here. Sean and I are about to get into it with Karthik Suresh. He’s the Co-founder of Ignition, which is a platform for helping product managers put together a go-to-market strategy. We talk about audience position, message, channel, and how they all compromise that go-to-market strategy. We also unpack one of Karthik’s product failures, which turned into a really interesting learning experience that he still applies today. Hope you enjoyed what we put together today.

Paul [00:01:11] Well hello and welcome to the pod. Today we’re excited to be joined by Karthik Suresh. He’s the Co-founder of Ignition, the collaborative hub for marketing and product teams to plan, execute, and measure the go-to-market side of launching. Karthik is a product and technology leader with experience as a founder, an early start-up hire, and a key player in defining product strategy and finding a product-market fit. He has extensive experience in building products in consumer, enterprise, and the data domain across early-stage and established companies. Karthik, thanks so much for taking the time to join us today.

Karthik [00:01:39] Thanks for having me on the show. I’m excited.

Paul [00:01:41] Absolutely. So just to jump in, you know, just reading your bio and listening to some of the things that you’ve talked about, you’ve been a product leader in many different types of environments: Silicon Valley, Fortune 100, Facebook. And I was curious, you know, what are some of the observations that you’ve made as a product leader in these different environments? What shapes do you think different product leaders take as they grow their careers and perhaps take different roles across organizations?

Karthik [00:02:05] Yeah, yeah, that’s a very good question. So I think one of the common misconceptions out there is, you know, if you’re a really good product leader in a top large company like Facebook, then you automatically are a great product leader for a startup and vice versa. Probably, from what I’ve seen, it’s like almost two completely different roles. It’s almost apples and oranges. When you’re working in a startup, you know, it’s basically you’re working with very limited resources. A lot of your skills have to do with how you can hustle to get things done. You’re basically writing sequel queries one day, you’re talking to the users, and then you’re designing the product road map, sometimes even running the sprint yourself with the engineering team. And then a lot of the time just goes to understanding, “OK, how to do I get to product-market fit, especially in early-stage startups?” You know, what does it mean to like, you know, make sure that the product will have good retention and also making sure the product appeals to a larger segment of the target audience and even, are we even targeting the right people? So those kinds of questions are the ones you constantly deal with in an early-stage startup.

Karthik [00:03:01] In larger organizations, it’s a completely different role because you have all the resources you can, like for example, at Facebook, my team had a designer, had a researcher, had a data scientist, a set of amazing engineers. So a lot of my role was more on stakeholder management. It’s also just more about unlocking my engineers, getting the buy-in from other teams. It’s like, “Hey, you know, we came up with this roadmap,” which requires the buy-in of this other team at Facebook. So my job was just going and talking to the other team, making sure they have space in their roadmap and they can allocate resources to us and then communicating the same message to different people at different levels. To execs, to managers, to the different teams, to different stakeholders. So I would say 80% of my job was just communication, stakeholder management, you know, collaboration. And only 20% of my time was actually like having, like, a product strategy discussion, you know product roadmap, which would probably happen at the beginning of the quarter or the half. But as in a start-up, again, you’re probably directly talking to the CEO every other day. You’re probably talking to the exec team. So it’s less of that. It’s more of like, “Can you hustle?” It’s almost being like a jack of all trades. I would say.

Paul [00:04:06] Yeah. If I heard you correctly. It’s like when you’re at the smaller end of the company size, when you’re at an early-stage startup, for example, you’re sort of chief cook and bottle washer. You’ve got none of the resources and all the responsibility. And then as you scale up in organization size, you’ve got all the resources and I won’t say none of the responsibility, but leading through influence more than actual authority and having the ability to, you know, gain access to the stakeholders is really the currency that you trade in.

Karthik [00:04:31] Exactly. And, you know, one of the things I would say, for example, when I moved from startup to Facebook, one of the things I really learned was being able to communicate at different levels. Taking the same exact message, taking the same exact roadmap, and being able to communicate to different stakeholders on at different levels, which I never had to do in a startup, right?

Paul [00:04:49] Yeah.

Karthik [00:04:49] So yeah, I think it’s very different skills. I mean, being biased here, it’s probably like if you’ve been a startup, it makes it easier to go work for a larger organization. But the other way around, it’s very hard.

Paul [00:04:59] Interesting.

Karthik [00:05:00] Like to be a product leader in a large org, it’s actually way harder for you to go back to a very small firm because you’re being like pampered with all these luxuries and, you know, you have a cushy job and then you’ve been thrown into this like, “okay, figure it out” stuff. So, yeah.

Paul [00:05:14] Exactly. I want to get into the go-to-market strategy challenges that you’ve talked a lot about. But before we get there, I just want to ask a more general framing question. A lot of the listeners of this are going to be product leaders in organizations, product owners, product managers, writing roadmaps and backlogs and user stories. And not a lot of time has been spent around framing this difference between a product manager and a product marketing manager. In real high-level terms, could you share with our audience, what do you see the difference being between those two roles?

Karthik [00:05:45] I think like these days and one of the reasons [inaudible] Ignition as product marketing manager as a role is something which is coming into focus and that’s one of the fastest growing jobs, especially in the Valley. And a lot of the companies are realizing the value of having a PMM, and even at early stage. Typically you would bring on a product marketing manager, like, after 50 people and that’s when you would bring on a PMM. And before that, the PM is pretty much doing the job of a PMM. The most important part of PMM starts with customer research, trying to understand, you know, what are the needs of the customers, who we want to target. Then after that, being able to understand how do we message the value prop of the product so that it appeals to this target audience? How do we position the product? Like what channels do we use to bring this product to the market? And then being able to understand effectiveness and bringing all those insights back to the product team so we can help build a roadmap.

Karthik [00:06:36] So those are like the main functions, but in reality, it’s like, in early stages, the PM or the founder is probably doing a lot of these functions themselves. One of the clichés in product management is like distribution is sometimes more important than the product itself. Like, a lot of the focus, especially a lot of the founders are ex-PMs or ex-engineers and they tend to think that, “Hey, I just do a production release, maybe send an email to my customers, and then ‘Hooray, it’s a launch, let’s go party.'” Right, that’s not a launch. You actually need to invest in a proper go-to-market strategy and you need to think about like, “okay, first of all, identifying really clearly who my target audience is and how do I position the product? How do I clearly make sure the value prop resonates with that audience? And then what channels do I need to use to actually reach those audiences?” Like also having multi-channel marketing in place and then making sure, for example, train the salespeople, train the customer support people, train the customer success people to make sure they can then sell this new feature. So it’s an entire process and PMMs are the ones typically, like, driving this process in a company. And recently it’s becoming more and more important for folks to hire and expand the product marketing functions across an org.

Paul [00:07:42] Great, thank you.

Sean [00:07:43] I don’t want to let you go without at least us talking about one of the stories you told in the pre-call, because it just engaged me incredibly. So one of the growth stage companies you worked for early on in your career was Knight Capital Group. And you told the story about the biggest single-day loss on Wall Street ever.

Karthik [00:07:59] Yes.

Sean [00:08:00] So as a product leader in that environment, I’d love the audience to hear your take on that story and some of the lessons that you learned in that process.

Karthik [00:08:07] Yeah, thanks for that. Yeah, that was definitely one of the things I wanted to share. And this is more on, I would say, the wide range of responsibilities you have as a product leader. So this was about a time when I was like a VP on the algo trading team at one of these trading firms called Knight Capital Group. It no longer exists and I’ll tell you why. And there I was a product leader, also an on the engineering leader. Typically, in a lot of these financial services firms, you don’t have like a dedicated product manager, like, the engineering manager kind of doubles down both as a product leader and as an engineering leader. And they interface directly with either the traders or the salespeople.

Karthik [00:08:42] So this was me back in 2000, I think 11 or 12. There’s a Wikipedia article I’ve done, it’s pretty much public. So I was in the team called algorithmic execution. So what we used to do is basically execute a portfolio of trades from various hedge funds and buy-side clients. At the same time, we also used to make markets for various stocks. So by making markets, I mean making the bid and asks. So you need to have both buyers and sellers and that’s how we can ensure smooth execution of trades on an exchange. So it was a market-making team. And on this day, one of the algos, we had a bug and the algos, I think they started buying and buying more and more positions, sort of buying and selling and buying and selling. They just started accumulating and accumulating. And unfortunately, we ended up with something like a $2 billion portfolio that the whole market cap of the company was just 1 billion dollars, which means that obviously we were bankrupt. And we then had to flip then portfolio to Goldman Sachs for a huge discount. And then we took a $400 million hit on our balance sheet, and this whole saga lasted for 30 minutes.

Karthik [00:09:46] So, yeah, we lost $400 million in 30 minutes and I was a part of this team and that’s like the largest loss ever. And yeah, I was probably not so proud to share the story, but there’s a lot of learnings here in this case. And then what happened after that is like obviously we didn’t have money, we were kind of bankrupt, so a bunch of companies came and bought us and then from Knight Capital Group then became KCG Holdings and now KCG Holdings is now acquired by another company.

Karthik [00:10:12] So I think there’s a bunch of learnings there. One, there was not a lot of like really good testing kind of culture, I would say, in the company. So it was a more of like a, “let’s keep pushing to product, like let’s keep testing,” that kind of mantra. Which is not bad. For example, Facebook has the exact culture where they really believe in like really pushing stuff fast. But it’s one thing to be Facebook, which is social media. Nobody’s gonna lose money. It’s another thing to be like a financial services firm where you are actually dealing with money. And this reminds me of, I don’t know if you guys know this meme where it states, like, “I don’t test in dev, but if I test, I only do so in production.” So that was like the ask. And then yeah, as a product leader there, it was like very devastating to see all of these things happening because I thought we were building a pretty good product. This comes back to that, like, if your end feels like financial services and fintech and crypto, the process you need to follow is very different from like a SaaS product. Like SaaS product, even in Ignition, if push something, there’s something broken, like, you know, probably I get a message and then we fix it as a hotfix and then everyone moves on. But you can’t have the same exact process, like a deployment process to launch process in different industries. And let me pause there.

Paul [00:11:22] Yeah, absolutely.

Sean [00:11:24] But tell me about the engineering culture on that team and like maybe what was missing there.

Karthik [00:11:29] Yeah, I think it’s less the engineering culture, but just the culture in the entire company. Or, I would say, the Wall Street culture. Which is more, uh, and not big banks, because I think big banks are the other way around right now. Big banks move so slow that they’re getting disrupted left and right by fintech companies. But this is more on, I would say, the culture in more top trading firms, you know, the hedge funds. There, I think it’s two things. One, at least then, the engineering teams were not almost as resourced as they should have been. There’s probably like one person doing the job of three people because like all the founders, the owners were all like traders and bankers. I don’t think a lot of them really understood technology.

Karthik [00:12:08] And then they would probably have like, you know, basically a very not so well resourced engineering team take on like a mammoth task like actually running market making, you know, algo or like, I mean, at that time, I think they were making markets for 10% of all the stocks in the New York Stock Exchange or something like that. So it’s pretty huge, like billions and billions of dollars every day. And we had probably like a 50-person engineering team doing all of that, everything, infrastructure, frontend, backend, support. But I think really we probably needed like 500 engineers to actually do a good job. So that’s one thing.

Karthik [00:12:38] So second, what it led to is like the culture where, you know, there’s a lot of shortcuts, right? There’s like tons of shortcuts, whether it’s on code review process, whether it’s on the testing process, you know, all of those things where we were like basically taking shortcuts because that’s the only way you could actually meet the deadlines. There’s no way you could follow a code review process or follow a clear testing process and then still deliver, you know, within the deadline. Because the deadline also matters because the market conditions keep changing. If you have an algo, let’s say you make a tweak to the algo, it might be irrelevant in a month because the markets would have changed. So it’s also that you need to like move so fast in the environment.

Karthik [00:13:13] So I think the engineering culture, to answer your question, was basically like forced into being shaped this way because of the demands of the market and because of like I’ve say a not-so-good understanding of how the engineering should work from the senior management. But I think after this, what happened was there was a huge change, as you can imagine, across the tech landscape in Wall Street. I don’t know if you’ve heard of the term kill switch. So kill switch was first introduced in Nasdaq after this incident. Like, this led to kill switch. This led to like, you know, basically like circuit breakers. You can look up circuit breakers, you can look up kill switch. So basically if a stock trades beyond a certain percentage or there’s a volume beyond a percentage, the stock automatically moves into a suspended state so nobody can bid. All of these happened because of this one incident. So at the end of the day, yes, it was bad and one firm had to take a hit. But what it led to is a much more safe and secure capital market for all of us. So it was, I would say, like a necessary evil at the time.

Sean [00:14:13] All right. Well, can I take a minute to summarize what I just heard?

Karthik [00:14:17] Yeah.

Sean [00:14:18] Some of the key lessons you learned from such an incredibly impactful software bug, it sounds like it was like a single bug, really, that caused this cascade of effects that sunk the business and led to a 400 and some odd million dollar loss. But the team engineering culture is important, and the context is also determinant, like the context of the software product in this case should have had more guardrails in place. They were overworked and it sounded like there was a demand to ship over the demand for a high-quality product.

Karthik [00:14:47] Yes.

Sean [00:14:48] Which in this context just didn’t work. And the business leaders didn’t necessarily understand the actual technology, which was probably causing that demand to ship over demanding a high-quality software product. And it also led to these shortcuts. So I think as a product leader, the key lesson to take away here is, you know, given the context, you’ve got to stand up for your teams and you’ve got to find ways to make sure that your engineering team has a voice. Is that a fair assessment of what you just said?

Karthik [00:15:14] That’s a very fair assessment, yeah. You couldn’t have summarized this better. I think the most important part in there is the demand to ship. The demand to ship, it’s almost like, “I don’t care, take the shortcuts, I don’t care, do what you need to do, but I got to get this done by the end of this Friday.” Like, “we need to be ready for the markets on Monday,” without knowing what they’re truly signing up for. So, yes, you need to stand up for the team and also make sure, as a product leader, you can also, like translate the risks in a way that the business leaders can understand. So it’s like almost play a better role on both sides where, you know, when you get pushed from the business leaders, you can I think make sure you give a really good voice on the engineering team. At the same time, translate whatever the risks the engineering team is actually telling you to the business leaders to understand what the consequences could be. So yeah, both ways.

Sean [00:15:59] One of the product leader’s key jobs, especially in volatile and highly impactful scenarios, is to make sure that the business leaders have empathy for the engineering team.

Karthik [00:16:10] Yeah. That’s especially true in financial services, in Wall Street, and in banks. And this is one of the reasons why I also moved away from financial services into tech, because I always felt tech is treated as a cost center, you know, if you see the earnings of the banks and like It. It’s still called IT and the cost center. What do you mean IT and cost center? They’re literally the ones like they’re the future, you guys need to understand. And then in Silicon Valley the engineers are like worshiped and welcomed like that’s the culture here and that’s what makes innovation possible. I definitely think the culture is changing. I know it can see the Goldmans of the world really taking a more forward approach to engineering and technology. But at least when I was there, I would say the engineering teams were treated more as like, I mean, I guess it’s too harsh, but more as second-class citizens in the company.

Paul [00:16:58] Hm. Yeah. I think that’s probably a whole other conversation to have of how companies organize their infrastructure, their finance, their general ledger is almost a predeterminant of how their innovation path is structured. I would love to dig into that, but I do want to get to a question about what you’ve taken from this pressure to launch and how to strategize about micro versus macro launches and how do you, you know, employ structure into getting a product to market? Can you talk about how you’ve taken this really impactful experience and turned it into where you are today at Ignition? And what do you carry forward from Knight Capital to today that’s informing how you’re helping product managers take their products to market?

Karthik [00:17:38] Yeah. I think also a lot of the Knight Capital experience more about like processes, I would say, than engineering practices. On the launch side and go-to-market planning side, like now, like it’s more on like, how do you make sure you reach the right people you’re targeting? Like first of all, identifying who’s the right person for your product, or for your feature, and then, what are the different channels you want to use to reach them? And then what messaging or positioning are you going to use so that they appreciate the value properly?

Karthik [00:18:07] So I think, first of all, it all starts with having a process, like having a go-to-market process. If you look at a lot of the, especially the early stage companies, they don’t have a process, period. Like there’s no repeatable process. Like, you know, they will do a launch, they will just send an email and that’s it. And then maybe let’s say they have a new PMM and the PMM comes up with their own process and then if it’s a larger company, they are multiple PMMs, each of them has their own process, one is like a spreadsheet, they have a checklist, and then one is using Asana and they have like a task list. First, like making sure having a process and after that standardizing a process so that you can have a repeatable playbook to keep launching new features or even new products. I think that’s the fundamental thing which is missing. And then Ignition provides you like out of the box launch templates which you can just use and standardize across the company.

Karthik [00:18:51] Then second, once you do that, then making sure you follow a process to add to a go-to-market plan. I guess, as I mentioned, from making sure you’re talking to your customers, identifying who your target persona is, then coming up with basically like, you know, what’s the OKRs for the launch, you know, what is the messaging, what’s the positioning strategy, what are the channels you want to use to reach your target persona? Then making sure they have this launch plan before you hit the live button. Make sure everyone in the company is on the same page so that they can all talk about this product or the feature in the same way to all their stakeholders so that everyone’s on the same page. And then you train the customer support people, train customer success, train salespeople. And then you actually go launch, hit the launch button when everything is ready. And then finally after the launch, you also measure the success, like how many leads needs to you get, like what is the impact on revenue? Having a very clear way to attribute all the marketing dollars to some kind a tangible like revenue for leads. And that’s also pretty important.

Sean [00:19:45] I’m most fascinated interviewing product people that have their own product for product people. The GTM product, we’ll put a link to ignition in the podcast for the audience so they can check it out. But I’m curious, in building a product for product leaders, what have you learned about product people?

Karthik [00:20:00] Yeah, that’s a really good question. One of the things, I guess the way I look at it is, first of all, I think that product people or PMs, they perform, how would I say this? So I think again, going back to early-stage versus later stage, especially in early stages of the company, like they are the glue which holds all the stakeholders together. Like they are a single point of contact, which basically when you’re dealing with engineering, with marketing, with sales, with customer success, they are basically the one kind of dealing with all the stakeholders together and context switching all the time, which makes it a really hard problem. And in fact, then moving to later stages of the company, then that’s where the PMM comes in, because then what the PMM helps do is then once the product is launched, the PMM then becomes a center for marketing and sales and customer success, and then the PM becomes the center for designers, for researchers and engineers. So that’s kind of how it shapes up. So yeah, it becomes an incredibly hard part to play.

Karthik [00:20:48] Number two, it’s obviously that like product leaders, they are very focused on the usability of the product, the UX issues, you know, the user pain points and making sure that solutions actually work and solve the problems. But they forget about distribution. They forget about, how does it actually reach the customers? And also what kind of product? For example, if you’re creating a new category of product. You can’t use SEO because nobody is searching for your product. Then you need to invest in content creation, right? But if you’re going after a very crowded market, then, you know you can use SEO and more and it’s all about targeting the customers of your competitors and then getting them on board to your product.

Karthik [00:21:24] So I think that’s the second thing which we are learning is like a lot of the time, you know, you don’t focus on how your users get to your product or use your product. It’s more about, “okay, if I give it to one person, is it usable, does it solve the problem?” You know, go to the UX issues, watch the user videos, watch user research videos make sense. That’s great. But how do you get those users? And a lot of people don’t think about that. So that’s the second thing I would say. And then hopefully Ignition solves that.

Karthik [00:21:48] And then three, I would say, again, this is more obviously biased, but PMs are definitely becoming one of the most important functions in pretty much, not just in tech. I just saw like one of my colleagues, they became a Chief Product Officer of JPMorgan. So product people are gaining popularity and also, like, I would say, more importance in companies and functions outside tech, which is also fascinating to see.

Sean [00:22:12] Awesome. Just going to collect some thoughts for the podcast. I’m going to summarize this podcast in a couple of statements here. First, we talked a little bit about your extensive career in product and having worked for startups and mid-market growth companies and Fortune 100 companies. And you’ve got a lot of experience. And I think the key takeaway I got from that whole conversation was that if you’re just starting out in your career in product, it’s better to start with a startup than the other way around.

Sean [00:22:37] Second thing I captured is that someone needs to be paying attention to this PMM role, even if you don’t have an official PMM on the product itself. Like someone needs to be paying attention to how are we going to reach customers? How are we going to improve our value proposition? And that’s a problem you’re trying to solve. Number three, there’s a myth about distribution being more important than adoption, and we all know that that’s not really the case, like the value proposition has to resonate. And if you’re really only focused on distribution, you know it’s a short term problem because you’re not going be around for very long. You’re not solving real problems in the real world.

Sean [00:23:07] Number four, this, I think, was the most powerful takeaway for me that the entire community of product leaders needs to pay close attention to. Pay attention to your engineers and to figure out ways to build empathy for the things that they need in the product lifecycle with your stakeholders so that you build in the space that’s needed for your product, especially if it’s a product that really small mistakes can lead to big problems or big results. Number five is to make sure that you have at least a process for going to market. And lastly, number six is that the product leader is becoming more and more kind of like the central nervous system of the product.

Karthik [00:23:43] Yeah, you said it than me.

Sean [00:23:46] With that, I’m going to ask you a question here just because we like to poll our thought leaders for what they’re learning. So what are you learning these days? What are you reading? Do you have a book you’d recommend to the audience or a podcast that you recommend to the audience?

Karthik [00:23:58] Yeah. Yeah. A couple of things. One, I just started reading this book called Build by Tony Fadell. I think it is popular, a bunch of people are recommending it. I haven’t finished the book yet but it seems fascinating. I would definitely recommend it. That’s what I’m reading right now. Literally like yesterday night I was reading that. And other thing I’m fascinated with is the whole NFT space and Web3 space overall. I think there’s some fascinating innovation there and as the rules are being done, I think it’s just truly fascinating to see just various types of NFTs, whether it’s a profile picture, whether it’s a watch or a real estate, like Metaverse based on art, or gaming NFTs. Play-to-earn is becoming the norm these days. And I think that that’s definitely not a short-term hype or a short-term thing, like a gold rush, as some people put it. It’s, I think, here to stay and that’s something I would recommend to audience and learn more about.

Paul [00:24:47] Awesome. Before we let you go, I have one final question for you. What is your definition of innovation?

Karthik [00:24:52] Yeah. Innovation is basically, it’s nothing but change, right? Innovation, it’s just one word. Basically what happens is, whether it’s large organizations, large power companies, or in humans in general, I think are pretty, I would say light comfort zone, whether it’s like a cushy job, whether it’s a cushy life, they don’t want to change stuff. It’s like inertia. There’s always this inertia that tends to come in and pretty much whether it’s financial services, manufacturing, I think that really leads to a huge loss of human creativity and potential. So being able to open to change and making change a core value prop of the company culture is what gives you innovation. So innovation is basically being open to change.

Paul [00:25:32] Amazing. I love it. Well, Karthik, thank you so much for taking the time. It’s been a blast hearing your story, hearing your passion for product and product people. I really appreciate it. I’m sure our audience learned a ton.

Karthik [00:25:41] Yeah. Thanks a lot for having me, again. I enjoyed the conversation.

Paul [00:25:44] Absolutely. Cheers.

Paul [00:25:47] 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.

Like what you see? Let’s talk now.

Reach Out