Recently, I met David Krauza, VP of Enterprise Data Strategy and Products & Governance at Comcast, at the 2026 CDOIQ symposium, and after chatting for a bit, he agreed to come on the show to talk about how he, as an enterprise buyer, thinks about B2B software purchases in the age of AI. As vibe coding makes internal development more accessible, David explains why the buy-versus-build decision isn’t simply about whether a company can build a solution itself. Leaders need to weigh long-term roadmaps, maintenance, integrations, and whether they want to take on the responsibility of becoming a software company. The real question is not just what can be built, but what makes the most strategic sense to own.

David also highlights an important consideration vendors frequently overlook: the data their own products create and the possible importance of that to an enterprise data leader. This is particularly true when the product’s primary intended purpose is not analytics itself. In a complex sales environment, which may include a senior data leader as a champion or decision maker, product metadata, or what you might currently be thinking of as a byproduct, might actually be a primary decision point in an enterprise purchasing conversation. David then outlines the pre-implementation work required before any of this can be evaluated: establishing shared definitions, explicit success metrics, and a documented “before-picture” you can run at renewal time to understand the ROI of the product.

We also explored the hidden costs that can undermine an otherwise compelling product. A polished UI may still create UX friction if users have to constantly move between systems, while complex data integrations can introduce additional labor and operational burdens. This friction should be considered during the evaluation rather than discovered after development. David says vendors can stand out by demonstrating that they understand where a customer’s business is headed and how their roadmap supports that direction. He also dropped some real gold about the difference he sees as a buyer when being pitched by a founder vs. a B2B salesperson—and what the latter is missing when they pitch him.

• Why buy any products when AI allows you to build them yourself? (2:03)
• Allowing use cases and goals to dictate the adoption of internal solutions (4:03)
• Making data capture, accessibility, and ecosystem fit part of the buying decision (5:54)
• Is data missing in sales conversations due to a lack of marketing or of results? (8:36)
• Comcast’s method for deciding to renew when the intelligence is invisible (11:22)
• The importance of pre-post analysis when making a renewal argument (14:02)
• Where David sees the most time being wasted in the pitch process and why vendors who did _____ win more often (16:36)
• The hidden costs that often go undiscussed during the sales process (20:07)
• How Comcast evaluates UX friction (back-and-forth of switching between applications to accomplish work) (22:22)
• Other hidden factors that can prevent your sale from closing (25:13)
• Differences David sees between founder-led sales and sales-led sales (26:41)
• David’s advice for founders selling in the analytics and data space right now (28:14)

• David Krauza’s LinkedIn
• David Krauza’s Substack

I'm talking to Nishkam Prabodh of Venture Guides, an early-stage venture capital firm focused on infrastructure software, cybersecurity, and data. Nishkam explains why strong technology alone rarely determines whether a startup succeeds. Many technical founders struggle when transitioning from founder-led sales to a repeatable go-to-market motion because the founder's deep customer understanding often does not translate into a scalable sales process. The challenge isn't just building better technology, but connecting technical capabilities to clear business outcomes.

Nishkam breaks down the communication gap that often appears between technical products and enterprise buyers. Rather than focusing only on technical outputs, products need to demonstrate business value through experiences designed for different stakeholders, including end users, executives, compliance teams, and budget owners. Whatever ROI the product shows has to relate back to improving revenue, reducing cost, or reducing risk. Nishkam also discusses how AI is changing product organizations, with execution-focused tasks becoming increasingly automated while judgment, domain expertise, and strategic decision-making become more valuable.

On buy versus build, he notes that two-thirds of the failures in the MIT study on enterprise AI deployments were internal builds, while the successes skewed toward buying. While traditional advantages like proprietary technology and architecture still matter, he believes the strongest defensibility increasingly comes after deployment. Products that learn customer context, retain institutional knowledge, improve workflows, and generate organization-specific intelligence can create compounding value over time. AI models may become commoditized, but the surrounding product layer of memory, retrieval, context, tooling, and governance will determine long-term differentiation. He closes with the discipline that makes all of this possible: pick one customer, one industry, one revenue band, and build repeatability there before worrying about coverage.

Highlights / Skip to:

• • The pattern Nishkam Prabodh sees in B2B and data companies that stall at founder-led sales handoff (4:46)
  • Challenges in translating technical complexity into commercial clarity (7:58)
  • The two fall-off points in a deal, and why the cheaper one is the bigger one (12:19)
  • The importance of communicating value to the executive buyer, not just the user, as early as you can (13:24)

• Why a stalled deal might be a product design problem, not a sales problem (17:22)

• The only three things ROI is allowed to reduce to: revenue, cost, risk (19:41)
• What skill sets Nishkam thinks are essential for product teams (20:11)
• The three shifts in product hiring: later, more judgment, domain over generalist (25:37)
• The importance of judgment in preventing unmet needs from derailing sales (26:32)
• What Nishkam believes are strong moats for data products (31:13)
• Why a buyer's failed in-house build still costs you sales cycle and ACV (33:37)
• Showing the value of a product on day thirty, not just day one (36:45)
• Why the buyer never sees the work that makes the simplicity possible (41:20)
• Nishkam Prabodh’s closing advice for technical founders of analytics and data products (44:46)

Links

• Nishkam Prabodh’s LinkedIn
• Venture Guides website

I’m talking to Bhaskar Sunkara, CEO of bicycle.AI, which provides an AI analyst product designed to monitor revenue-critical KPIs, investigate the business and technical drivers behind KPI changes, and take a “governed next step.” Bhaskar explains why analytics products often fail when they overwhelm users with telemetry instead of focusing on the signals that matter. Drawing from his experience as founding CTO of AppDynamics, he shares how his team moved from low-level technical monitoring to business transactions like logins, checkouts, and bookings. The key lesson? Start with the right metric at the right level of granularity, then use deeper technical analysis to explain why something changed.

Bhaskar also breaks down how bicycle.AI serves multiple audiences inside an enterprise. Business leaders want measurable outcomes, KPI owners need answers about what changed and what to do next, and data teams require trust, governance, and traceability. He explains how, in order to support these different users, Bicycle separates product experience into four core surfaces: pull features like dashboards and chat, and push features like alerts and data stories. Alerts further help operational users respond quickly to KPI changes and data stories provide executives with strategic narratives around trends, causes, and business impact. During our chat, Bhaskar also draws a line most AI products blur: be explicit about which findings are deterministic and which are only a theory. He connects this directly to my CED framework, separating the conclusion from the evidence from the underlying data, and argues that how much you automate should be governed by one question: how costly is being wrong?

I also probed Bhaskar about their moat. He’s learned that enterprise adoption requires winning over both executives who care about revenue impact and analytics teams that need confidence in the system’s recommendations. Bhaskar also explains why their long-term advantage comes from the DEAL framework: Detect, Explain, Act, and Learn. By continuously incorporating validated decisions, business context, and customer-specific knowledge, the platform becomes more useful over time. We finish up with his advice for fellow analytical AI product founders, including why AI makes user experience more important, not less: it is the connection between agents, decisions, humans, and accountability.

Highlights / Skip to:

• Making the invisible feel urgent enough for customers to buy products (2:41)
• How to avoid creating the ‘metrics toilet’ when the system can do so much (6:56)
• Designing for the end-user versus the buyer, especially during the POC phase (12:20)
• Thinking about the product’s design in a way that ensures Bicycle’s business value is obvious (15:38)
• How bicycle.AI’s “push” and “pull” features help stakeholders see value (20:54)
• Getting their first 20 customers (25:19)
• What Bhaskar got wrong: over-rotating on the business buyer vs. the analytics team (32:23)
• The homework a build-anything horizontal platform imposes on customers (and Bicycle’s vertical antidote) (34:30)
• Bicycle.AI’s moat: compounding institutional knowledge (36:08)
• DEAL: Detect, Explain, Act, and Learn (40:46)
• How they designed the UX to reduce time-to-value during onboarding/setup (44:51)
• Bhaskar Sunkara’s advice for other analytical AI founders (and why AI makes UX even more important to address) (47:47)

Links

• bicycle.ai
• Bhaskar Sunkara’s LinkedIn
• My CED framework for advanced analytics products that Bhaskar references in this episode