Vinay Kapoor, CPO and Interim CTO at Expana, discusses splitting product and technology for sustainable growth

‍Host: Lucas Hendrich, CTO at Forte Group
Guest: Vinay Kapoor, Chief Product Officer and Interim CTO at Expana

Introduction

Lucas Hendrich: Welcome to the CTO to CTO podcast, where chief technology officers dig into the challenges and opportunities leaders face every day at the intersection of business and innovation. I'm your host, Lucas Hendrich, CTO at Forte Group. In this episode, I'm talking with Vinay Kapoor, Chief Product Officer and Interim CTO at Expana, a leading provider of commodity price data, forecasts, and market intelligence. We'll discuss the role of the CPTO, the intersection of technology and product leadership, and leveraging AI in a continuously changing business environment. Here's the conversation.

Hello, this is Lucas Hendrich, host of the CTO to CTO podcast. Today I'm with Vinay Kapoor from Expana, who is the Chief Product Officer and Interim Chief Technology Officer.

Vinay Kapoor: That's right. Hi, everyone. As Lucas mentioned, I'm Vinay Kapoor, Chief Product Officer and Interim Chief Technology Officer at Expana. Happy to be here, and I look forward to the conversation, Lucas.

The Rise of the CPTO

How Vinay came to the dual role

Lucas Hendrich: Wonderful to have you. Let's jump right in with your title. It's a theme we've discussed in other episodes, and I believe it's a general trend. My thesis is that the Chief Product and Technology Officer role is becoming more common as it gets easier to develop products rapidly. Technology isn't diminished, but it has certainly changed from keeping the lights on and making sure everyone has a working laptop.

I'm curious about two things. First, what's your view on that shift, and do you see a similar phenomenon? Second, how did you get here? What was your journey to this hybrid role?

Vinay Kapoor: Absolutely. This is my second stint in this kind of dual role. In my previous job, I was also Chief Product Officer, and for a period until I left the company, I was also the CTO. There, I was much more of a CPTO than an interim CTO. Here, I've been interim CTO.

In both cases, I ended up in the role because the business needed a CTO function for one reason or another. The details aren't important, but the business needed a CTO to step in. In one case the board asked; in the other, I raised my hand and said I was happy to do it.

But in both cases I was very clear — and this leads into your second question — that I only wanted to do the role in the interim. There are important reasons for that, and some philosophical ones too.

The case for a CPTO

Vinay Kapoor: So yes, there's definitely a trend toward the CPTO role, and there's a time and place for organizations to have one in-house. The pros: a CPTO is one person covering both functions, which simplifies your organizational structure. Conway's law comes into play somewhat here. You can build true value-stream-driven structures without silos, and shape the organization the way you want. And the CEO has one person to go talk to, which is great.

It works in certain situations: where the business isn't very tech-heavy, or in early-stage companies where the founder is stepping away from the product role. In a small organization, the founder should be playing the product role. I don't believe in having a separate CPO at that stage. But once the founder is ready to move on…

Lucas Hendrich: And you need to scale something.

Vinay Kapoor: Exactly. When you start to scale, it's a good idea to bring in someone who can do a bit of both, rather than two executives, and so on.

The case for a dedicated CTO

Vinay Kapoor: However — and the irony is that I've held both roles a couple of times — I believe that at scale, in tech-heavy businesses and real technology and engineering organizations, such as a SaaS product, the CTO has a very important role. That role is to set the strategy and vision for the technology and engineering function beyond what the product function dictates.

Good product people are very close to the user and the customer. They can prioritize and set the product vision. But a CTO brings a technology perspective beyond that: How should the business scale? What if you acquire an organization, or are acquired? What if you want to bring in different types of data? What about scale, security, and compliance if you're in a regulated industry? You need a proper vision for all of that.

Yes, AI and technology have reached a point where you can automate many technology functions. But the strategy piece is where a CTO really brings value and helps an organization.

Lucas Hendrich: I think it also depends on whether it's a true SaaS company or a technology-enabled services company, which gets very blurry.

Vinay Kapoor: That's correct.

Lucas Hendrich: One benefit of unifying the roles, whichever discipline you come from, is that it may bring some impartiality to decisions. If you ask a surgeon whether you should have surgery, what will the surgeon say? Nothing against surgeons, but that's typically their function. If you're building your own technology and it's an important part of the company, a CTO is critical. But if you're making decisions in a landscape that's more about integration than building, a combined role might remove some of that bias.

Vinay Kapoor: That's a great way to put it. If you segment the needs — now I'm speaking product language — of who should consider a CPTO versus really investing in a CTO function, it's a useful lens.

If you're not spending much time building novel technologies, and you're mostly using existing platforms and integrating them, what you need is almost more of an IT function. You're not doing true engineering, and there's a big difference. If you're not doing true engineering — or only at small scale to connect things — and you're a services organization or someone using technology as an enabler, a CPTO simplifies your life. As a CEO, your life will be easier.

But if you really are a technology function building technology, you need to ask yourself when the right time is, and think about bringing in a good CTO. Good CTOs can be transformational for businesses, for many reasons.

Lucas Hendrich: I guess you could say that if your moat is the technology, then absolutely.

Vinay Kapoor: Absolutely.

Expana: a data-driven business

Lucas Hendrich: And right now you're an interim CTO. Where does that evolve? Do you see it going in that direction?

Vinay Kapoor: Absolutely. Expana is a very data-driven business. We have a lot of proprietary data and invest heavily in it, with a very large data function. We also have a Chief Data Officer, my peer Luana.

For us, the technology we build on top of that data is a real differentiator. We have a feature-rich platform and product that people use to gain market insights in the agri-food space where we operate. If a customer wants to improve margins and reduce costs by analyzing the basket of goods and commodities they buy, they're using our features, and a lot of engineering goes into that.

So yes, absolutely. It's the prerogative of the board and our CEO, but I definitely see it evolving into a proper CTO function at some point. That's why I describe myself as the interim person, and that's fairly well known in the organization.

AI Strategy and Data Foundations

Why your AI strategy will fail

Lucas Hendrich: That's an interesting point. If it's a data-driven business, where acquiring data and what you do to transform it creates your competitive edge, it's really not the same as a SaaS platform anymore. It's totally different. That leads to a question about data. I believe there's an awful lot of hype around AI and data in general. There's a lot of promise, but there's a gap — at least I've observed one — between where companies actually are with their data today and this bright future of models for everything. What's your view? Is that too pessimistic of me?

Vinay Kapoor: No, no. I love the question, because it's absolutely true. I'm laughing because we could talk about this for hours. I actually blog on Medium, and one of my posts…

Lucas Hendrich: Tell us about the blog — get it out there.

Vinay Kapoor: Shameless self-promotion, then. One of my recent posts was titled "Why Your AI Strategy Will Fail."

AI has been a transformational technology for decades. But with generative AI specifically, the barrier to entry for organizations to use AI for real use cases is now very low. You can use Vercel's v0 to code something and deploy it, or use Claude Sonnet with a Copilot in VS Code to start building prototypes. You shouldn't put those in production, but you can get pretty far.

So a lot of people look at that and think, "I can just build an AI product and launch it." The problem is that the fundamentals never really go away.

Start with the why

Vinay Kapoor: AI is transformational when done right. Being the product person, maybe I'm biased, but you always need to start with the why. What are you trying to do, and what value are you bringing to the end user?

That could be an internal user and an efficiency use case: maybe you have many people who write a lot, and you want to cut the time they spend, leading to cost savings and better margins. Or it could be external: your users are looking for unique insights they haven't been able to get from your product and data. Either way, start with the why.

Invest in data, governance and ethics

Vinay Kapoor: On top of that, you really need to invest in data. If you don't have clean data and good data practices, and you don't invest in your data function, you're building a house of cards. AI reflects what it's fed.

LLMs are trained on huge bodies of text — the entire internet, Encyclopedia Britannica, and so on. But you're giving the model context: building a RAG system and feeding it contextual data. If you're not doing that — if you're just writing a ChatGPT wrapper — you need to stop, because you have no moat. At the very minimum, you're giving it context, so that data becomes very important.

Then there's one more layer before launching a product: tools, practices, and governance. How will you evaluate the LLM? If you're using traditional AI models for classification and the like, how will you prevent model drift and make sure it doesn't go off on tangents? How do you make sure it isn't hallucinating? You need tooling for that, and the right people.

And you need to think about ethics. There are examples of recruitment tools that developed a bias toward men, and other tools that have shown all sorts of problems and biases because the data fed to them was biased. So ethics matters.

You need to think about all of this when you go to market with your AI product or strategy. You don't need to think about it all while prototyping. It's great to get a prototype out, talk to the board and the CEO about the business case, and show all the good things it can do. But before you release it into the wild, ask yourself: Am I using the right data?

Embracing AI as a productivity superpower

Lucas Hendrich: I think that's spot on. A lot of confusion gets generated in these early adoption cycles for things like LLMs. Ten or twenty years ago, when I looked at machine learning use cases, the only viability question was really the computing horsepower we had at the time.

Now we have generative AI, and in some ways it's eating the world the way Excel did. All of a sudden, it's the productivity tool for everything, which I think is a great advance. It gets us there faster and it's great for prototyping. But without the right principles in place, it also injects a ton of risk.

And what a big distraction it is for product people. If the discipline is about saying no to features, now you have a whole landscape you can't shun — you have to embrace it in some way.

Vinay Kapoor: And I think you have to embrace it. That's the short message. Everything I said earlier was to highlight how important it is to work on the foundations. Having said that, it's also extremely important for any product person or engineer to dive headfirst into what's going on and empower themselves, for two reasons.

First — forget the end user for a minute — it's what you mentioned: the productivity gain. That's very powerful. It's a superpower. I'm encouraging my team to look at tools. How can you write better user stories? Can we use coding tools and copilots to prototype better? There's a ton of potential, especially for product people. So much work that used to be manual can now be automated. If you use these tools day to day, you can get 20–30% more done.

And you're not just more productive; in some cases you get better output. Maybe it's because you can spend more time on higher-level thinking and strategy, or because you have a copilot or LLM to work with that, in some cases, actually performs better than a human — but let's not go there. It's the augmented intelligence piece I like to talk about, and it really helps.

Lucas Hendrich: I totally agree, especially with the first part. It lets me connect ideas — across disciplines, technologies, and paradigms — much faster than if I had to write it out or code it.

Vinay Kapoor: Yes.

Lucas Hendrich: Those leaps are really important. But at a very practical level — what am I doing this sprint? — if I have three very complex, algorithmic stories, that's not where it shines.

Vinay Kapoor: Yes.

Lucas Hendrich: But if I have a spike that says, "Figure out whether we should use a different front-end library for this"…

Vinay Kapoor: Exactly. It goes back to what I said earlier: the fundamentals don't change. As a product person, your job is still to prioritize based on what's most valuable to your end user. Everybody has a backlog a mile long, so you constantly groom it. And product leaders need to think about both short-term and long-term strategy, and about the value users are getting. None of that changes.

You can look at AI in one of two ways. Either it's an enabler: How can I prioritize better? Or, for end users, by building AI tools and features: Am I doing something fundamentally transformational that helps us cross-sell, upsell, bring in net new logos, or enter new markets? Can we open up new markets or dig deeper? What's the value of that? You still have to do the ROI math.

Doing the ROI Math

Lucas Hendrich: One of my best mentors in product — a true product person — has a great ROI framework I learned from. I think part of today's gap is that I don't know how much real ROI analysis is being done on all these use cases. That discipline also applies to internal AI use.

Say you get a force-multiplier effect because suddenly you don't have to write unit tests. What a great case; no one can argue with it. But when someone tries something more complex, it takes several prompts or iterations. Sometimes you get 85% of the way there on the first attempt, then refine it and lose ground. That's a 1.2x — or even 0.8x — multiplier on your productivity.

Doing that analysis and incorporating it into your operating model is an important step. I don't know that we have a model for it. I'm an economist by background, so I like to model everything, but I don't know how many organizations are really modeling the impact of the tooling.

Vinay Kapoor: Not enough, is the short answer. That's what differentiates people — I'm talking about product, but really anyone working on a use case and making a pitch, so to speak. Good product people always have this in the back of their minds. The best product managers have an economics and finance background, or a deep understanding of which metrics matter and how they move the top line, the bottom line, EBITDA, and so on.

At the end of the day, when you talk to the CFO, the CEO, or the board, yes, they get excited about technology. But they want to know the ultimate impact. You can measure it through product metrics like DAU, MAU, stickiness, and retention. But ultimately, as a product person, you need to speak the board's language.

And you can start simply. Say you're deploying a tool: estimate how many minutes or hours it saves per person and how many people will use it. Multiply by the number of working days and an average hourly rate from the CFO. It takes less than an hour to collect that data and put it in Excel, and you have a simple ROI calculator. Someone on your finance team can then work with you to refine it. Later you can get more sophisticated: above and below the line, EBITDA impact, and so on.

There's no real reason people shouldn't be doing this. As a product person, if you can, it's a huge force multiplier for the organization. It's also great for your career. If you want to go from individual contributor to product leader, start speaking the language of the business, the CFO, and the board, and people will want to talk to you.

Lucas Hendrich: Here's a confession. A few years back, I read a book called Financial Intelligence — a real primer. I wanted to understand the balance sheet and the mechanics of it.

Vinay Kapoor: Yes.

Lucas Hendrich: It was invaluable.

Vinay Kapoor: It is. Not enough people take product metrics the last mile. As product people, we spend a lot of time and energy obsessing over product metrics, as we should. We bring in third-party tools like Pendo, Mixpanel, or Amplitude to build product analytics, and a lot of energy goes into that.

The work is the last mile after that: connecting those metrics to financial ones, whether that's top-line ARR growth, EBITDA impact, or retention, which leads to net revenue retention or gross revenue retention. To be clear, for anyone listening and rolling their eyes — "Yeah, sure, fine, done" — it's not easy. But we're not here to do easy things. We're here to do powerful things.

Finding the North Star metric

Lucas Hendrich: And the result can make it easier for others. Here's where I sometimes see confusion. Take a traditional services company that started on paper, transformed to digital, and is now somewhere in the middle. What it offers looks like a SaaS platform, but it's really a service. These are interesting companies: many are mid-market and growing, but carry a lot of technical debt. They have a product function that's very consumer- and market-focused, but it's a real challenge to understand the key metrics. What does good look like?

I always use this example — anyone who's heard me before, my kids included, knows I repeat myself, because I'm old. Whatever you think of Elon Musk, what's the key metric for SpaceX? Reducing the cost per metric ton to space. Everyone thinks about it, and it clarifies every decision: Does this small feature move the needle or not? The job is to get to that simplicity so you can create alignment.

Vinay Kapoor: Yes. It's a bit of a tangent, and I won't spend too long on it, but it's also very important for product people to nail down the North Star metric: the one metric the organization stands behind. It's so important. Then it's easier to connect the last mile, because you're looking at one metric the organization has agreed on, factoring it into your process and planning, and connecting it to the ultimate business impact.

Why the Roles Should Eventually Separate

It's not about capability

Lucas Hendrich: As an interim CTO — and I'll preface this by saying I don't know that any definition of a CTO holds anymore, because it varies so much. As you've described, it's usually a blend of responsibilities and skills.

Vinay Kapoor: Yes.

Lucas Hendrich: And I think it's almost an industrial, factory mindset to assume the CTO is the person with all the depth across all the technology in the enterprise. That's outdated, especially now that depth is augmented by large language models. So given that, what would need to change for the CTO role to become more like a CPTO? What's the gap? Why can't it be one role?

Vinay Kapoor: I think it's not about capability or competence as such. Yes, it's very hard to find someone with both a product mindset and deep technical knowledge and vision. And there are gaps: I'm not a deep technical expert, and I don't pretend to be.

What I bring to the interim CTO role is that I know how to scale organizations. I like working with people, and I know how to spot talent. That means hiring the right people, finding the gaps in the organization, and hiring people who tell you what to do rather than the other way around. It's about building a strong technology function led by technology leaders, not pretending to lead it yourself. We have great leaders in engineering, and our VP of engineering is a very talented technology leader. That's how you fill the gaps.

So, to answer briefly, it's not about competence or capability. But there are two reasons why, in certain situations — especially if you're technology-led, and the larger you get — it's important to have two separate people.

Reason one: checks and balances

Vinay Kapoor: The first is checks and balances. Product people, by definition, prioritize product backlogs. We have a tendency to chase the user, as we should. We prioritize what's good for the user, and we feel the need to ship faster and be incremental: How can we reduce cycle times?

You can very quickly end up accumulating tech debt. Either you're not aware of it, or you are but you ignore it, because that's where your skill gap is and you don't understand what it will lead to. At some point, that debt shows up on the balance sheet as an investment you have to make, in technology or people, to pay it down — because things aren't scaling, or whatever it may be.

An independent CTO can say, "Hold on a minute. We're about to bring on a lot of users, and our current technology can't scale. We took on some debt, and we need to pay it down." Or, "Our authentication function and SSO carry a ton of tech debt. Let's pay some of that down." Prioritizing the right things from a technology perspective is the first reason.

Reason two: staying current

Vinay Kapoor: The second is that with everything happening in the market, especially AI, it's very hard for anyone to stay up to date.

Lucas Hendrich: That's absolutely right.

Vinay Kapoor: You need more eyes on it. A CTO stays current with what's happening with your cloud providers and in AI, while the product function keeps an eye on what's happening from a product perspective. That's very important.

Architecture as a decision in time

Lucas Hendrich: I agree. At the end of the day, when you're defining architecture — which, in my view, is where the real risk lies, and I mean architecture in the broadest sense — it's a decision made at a point in time that affects the foreseeable future. As soon as you define it, you start reducing your options.

Vinay Kapoor: Yes.

Lucas Hendrich: There's a lot of skin in that game.

Vinay Kapoor: That's true.

Lucas Hendrich: It's not fair to put that on one person. Yet it often happens, or it's the only choice, because you're a technical founder and you've got to get to market. Even then, you get a pass. Someone will invest and say, "OK, time to unwind that and scale it."

Vinay Kapoor: Yes.

Lucas Hendrich: I guess that's where the two roles become very important.

Knowing the organizational patterns

Vinay Kapoor: What we haven't talked much about is organizational patterns. A CTO who's really been out there — who has delivered across startups and scale-ups, zero to one and one to ten, multiple products, different cloud vendors, different kinds of products — has seen organizational patterns and knows what works and what doesn't. The same is true on the product side: replace "technology" with "product" and you get exactly the same outcome.

That knowledge lets someone say, "We need to organize the team this way. We need a platform team." Or, "No, we don't need a platform team right now. We need vertical stack teams." Whatever it looks like — it's different for everyone. Having someone who knows those patterns, has seen them, and can be with you on that journey is very important.

Lucas Hendrich: Absolutely. I keep going back and forth on this. It's almost about having a dialogue. How do you maintain that dialogue? Maybe in the future it'll be you and the model, right? Who knows?

Vinay Kapoor: Maybe the models will have this chat in the future — the podcast too. "Let me know when you reach consensus."

Lucas Hendrich: Exactly. Then we'll just tell the board.

Working With Vendors

The pitch that makes him cringe

Lucas Hendrich: Here's the fun question — particularly fun because I work for a services provider and you're a consumer of services. So, gloves off. You deal with all kinds of vendors. What's the vendor pitch that makes you cringe the most? The one where you think, "Oh my God, I can't believe another one of these companies is pitching this. What are they trying to sell me?"

Vinay Kapoor: When someone comes in talking about cost savings — the standard "I'm going to help you save money" pitch — I start thinking: Do you know what I'm trying to do? Do you really understand? Maybe what matters most to me is staying close to my customer.

Cost savings is just an example; it's not the ultimate cringe. The real cringe is when a vendor delivers a pitch that's clearly prepared in advance, without taking the time to understand the business and ask questions. That's when I start to wonder whether it's the right vendor.

I much prefer a vendor who comes in with an open mind and says, "Let's have a conversation. What are you trying to achieve? What's important to you? What value are you after, and how can we help?" That conversation matters much more to me than a prepared pitch where you can tell: this vendor focuses on cost savings; this one focuses on "We'll build these AI tools for you." Well, do you know whether I need AI tools? Maybe I already have an internal machine learning team and someone who's really good at generative AI. So that's the short answer.

Lucas Hendrich: It's an interesting space. Having been on both sides, it's unfortunate that you sometimes have to cut through so many layers to get to the value-creation conversation.

Vinay Kapoor: Exactly.

Lucas Hendrich: There's specialization and trade in services too. At the right time, you need someone who knows the reference architecture, because hiring for it would take months. But that conversation can be really hard to reach from the buy side. Who do you choose? It's the biggest TAM you can imagine.

Vinay Kapoor: Yes.

Lucas Hendrich: With all these options, even if you're looking at cost savings, you're weighing increments across regions and tons of trade-offs, and each vendor is an expert in its own offering, not in evaluating across the board. So what should be an easy decision becomes death by a thousand cuts, because any organizational change is hard — unless it's a pure greenfield capex "let's run with it" situation.

Vinay Kapoor: Right, and there's a time and place for that. It's great to have.

Lucas Hendrich: Exactly.

The right vendor for the right reason

Vinay Kapoor: It's great to have as an option. And just to clarify, I used cost savings as an example. Of course there's a time and place when you want and need to entertain it. My point is that pre-prepared pitches, from people who haven't taken the time to understand your business, your model, and what you're trying to achieve, are where you run into problems.

To be open: I'm a huge fan of using the right vendors for the right use cases and needs. I think it's very important, even for technology organizations where technology is their moat. You won't always have the right skill at the right time for the right thing. And you don't always want to invest all the time and energy it takes to bring someone on full-time. Finding the right people takes time, and you may not even have the right people to hire the right people.

Say you're trying to build a data lakehouse on Databricks, you've never worked with Databricks, and nobody in your organization knows it. How do you know how to hire the right people?

Lucas Hendrich: That's a wonderful example, because learning how to do that organizationally and incorporating it is a huge shift.

Vinay Kapoor: It's a huge shift. So maybe work with an expert vendor who's done it before, and ease into it. That gives you flexibility. You can see whether it's the right fit, try the technology, and learn about it. Over time, as you get more confident and it becomes part of your organization's fabric, you bring it in-house.

That's just one example. Whether you're after a specific skill set, a specific pattern, or genuinely cost savings, there are different reasons to use vendors. I'm a big fan of using the right vendors for the right reasons in the right place.

Lucas Hendrich: I think that's spot on. It's partly true that cost is still a driver, but there's a big equilibrium effect that will continue: as talent becomes more distributed, costs level out over time.

Vinay Kapoor: Yes.

Lucas Hendrich: So what will matter is this: you need a thousand eyes on a problem and you only have ten. How do you scale that?

Vinay Kapoor: Exactly. Scalability is key, and it's why I love working with vendors. It gives you a great way to scale, and the flexibility you get is invaluable.

Lessons From Fencing

Lucas Hendrich: Last question. I love talking about my kids, and I assume you do too. I'm curious about your son, who's a national-level competitor…

Vinay Kapoor: Yes.

Lucas Hendrich: …as a fencer.

Vinay Kapoor: Yes, yes.

Lucas Hendrich: What has that taught you?

Vinay Kapoor: I have two boys, Tanmay and Krish, and they both compete in fencing. Tanmay is in college now, so he's taken a step back. They get to spar…

Lucas Hendrich: Once in a while, yes.

Vinay Kapoor: No fencing in the house! Both have competed at the national level. Before Tanmay stepped back from fencing for college, he was a Division II fencer and competed nationally in sabre, which is one of the weapons.

Lucas Hendrich: This could be a whole podcast…

Vinay Kapoor: A whole podcast about fencing, exactly. There you go.

Reset and move on

Vinay Kapoor: Watching my kids compete at that level, I've taken away a few things. The first is watching them go into bouts — and not all bouts go well. Without getting too deep into fencing, the way it works is that you first have pools: rapid bouts, boom, boom, boom. Then, based on how you do, you move to the direct elimination round, where you're out if you lose.

The pool round is hard because you have five or six bouts in a row. You might fence the number one fencer in the country and not do so well, and then you have to reset immediately and fence the next person. I've watched them pick themselves up and move on — not dwelling on what happened, but just, "OK, fine, it happened. Next bout, next bout." Watching that happen in rapid succession is fascinating.

I reflect on that as a leader. You go through difficulties, make hard decisions, and deal with all sorts of problems. How do you keep a mindset where you can reset and keep thinking about the future? There's a famous quote, I think from Napoleon: a leader is a dealer in hope. That's so important, and watching them do it is amazing.

Invest in the craft

Vinay Kapoor: The second lesson is preparation. It's a combination of physical fitness, practice, and nutrition — everything has to come together. It's investment in the craft, and the more you invest, the more you get out of it.

When Tanmay was competing nationally in high school, and now with Krish, my younger one, in high school, their schedules were very full, to put it mildly: three or four hours of practice two or three times a week, plus switching contexts to schoolwork. You have to invest in the craft. If you're not practicing, you're not getting anything out of it. It reminds me that I have to invest in my own craft — product, in my case, or working with engineering teams — and keep focusing on it.

Have fun along the way

Vinay Kapoor: Last but not least: have fun along the way. In the breaks between bouts, the kids are just having fun. The fencing community is fairly small, so they see each other at multiple competitions. They fence each other as competitors at one point, then go off and have fun together. Watching that reminds me to step back and have fun.

Lucas Hendrich: That's wonderful. There are so many metaphors there for things we face. It made me think of a book I always recommend, Thinking in Bets by Annie Duke.

Vinay Kapoor: It's a great book.

Lucas Hendrich: The analogy here is that you may lose a match, but you keep executing with the same technique. You don't improvise. There's an anecdote in the book about a coach who loses the Super Bowl after deciding to pass instead of run on a key play. The next day, he says he'd make the exact same call. Sure, he lost, but he'd execute the same way, because the probability of success was much higher.

Vinay Kapoor: Yes.

Lucas Hendrich: It teaches you to think in terms of probabilities rather than outcomes. I love that.

Closing

Lucas Hendrich: I think we're at time. Thank you for listening in. It's been great talking with Vinay, and I hope you'll join us again for the next episode.

Vinay Kapoor: Thanks for having me.

Lucas Hendrich: That's it for this episode. Join us next time for more real-world conversations between technology leaders. And if you liked what you heard, subscribe to CTO to CTO. See you soon.

‍