CHAPTERS
- 0:00 – 2:31
Why big enterprise deals feel like a “black box” to founders
Dalton and Michael frame why six-, seven-, and eight-figure deals are confusing for many startup founders: most have only experienced self-serve SaaS purchasing. They contrast the simplicity of charging $10/month with the unfamiliar mechanics of enterprise procurement and sales cycles.
- •Most founders understand self-serve buying because they’ve done it themselves (Stripe + credit card).
- •Very few founders have ever bought six- or seven-figure software, so the process feels opaque.
- •The fear comes from not having seen big deals done up close.
- •To build a huge company, many businesses eventually need some form of large-contract selling.
- 2:31 – 4:18
Enterprise buying is comparison shopping—don’t “break their brain” with pricing
Dalton explains that big-ticket software is often purchased by evaluating a small set of comparable vendors. Startups increase close rates by fitting into the customer’s existing mental model for pricing and packaging, rather than inventing quirky, founder-centric pricing schemes.
- •Customers typically shortlist 3–5 vendors and compare price/features side by side.
- •If your pricing resembles category norms, buyers can quickly understand and approve it.
- •Odd pricing models (the “pay with seashells” analogy) add friction and kill deals.
- •Don’t price from “fake first principles” based on your internal costs; match how the market buys.
- •Study how adjacent incumbents position, price, and sell—then look comparable.
- 4:18 – 4:34
Competing with incumbents: look like a normal vendor and deliver reliably
Michael highlights a practical advantage: a small startup can win against a huge incumbent if it looks like it belongs in the same vendor set and can deliver. Enterprise buyers want something that fits procurement expectations and doesn’t introduce extra cognitive or operational risk.
- •Enterprise deals are easier when the buyer feels they’re buying a familiar category product.
- •Matching common contract structures helps a small company compete with a 1,000-person vendor.
- •Being “priced the way the market is priced” can unlock bigger contracts for startups.
- •The buyer’s goal is to reduce uncertainty and make a safe choice.
- 4:34 – 5:36
Tools vs outcomes: why selling the CEO’s incentive pays more
Michael argues that developers often want to sell tools to other developers, but CEOs are motivated by business outcomes like revenue and enterprise value. Vendors that help translate product usage into business results can charge far more than those who just hand over a tool.
- •Developer-to-developer tool selling is the “easiest world model,” but not how big budgets are allocated.
- •CEOs are incentivized to drive revenue/stock price; outcomes connect directly to that.
- •Two philosophies: ‘outcomes are the customer’s problem’ vs ‘outcomes are the vendor’s responsibility.’
- •Owning the outcome (or implementation) is a core driver of large contract sizes.
- 5:36 – 6:16
Palantir as the archetype: pay for impact, not headcount
They use Palantir stories to illustrate outcomes-based economics: customers pay for the value created, not the vendor’s internal effort. If a vendor can reliably produce high-impact results, the price can be a fraction of the value delivered and still feel like a win to the buyer.
- •Example framing: “we send 10 people, you pay $1B over 4 years because it makes you $10B.”
- •Customers don’t care how many engineers it took if the ROI is enormous.
- •Tool-only delivery (‘here’s software, you figure it out’) limits pricing power when adoption fails.
- •Outcomes selling requires reducing the customer’s execution risk, not just shipping features.
- 6:16 – 7:15
Engineers care how it works; buyers care that it works
Dalton explains a core mismatch: technical audiences often want implementation details, while outcome-oriented buyers want speed and reliability. He draws analogies to consumer marketing shifts (specs vs experience) to show how messaging changes with the buyer.
- •Engineers optimize for understanding internals; non-engineers optimize for achieved results.
- •Detailed explanations can be a negative for outcome buyers (“Don’t tell me—just do it”).
- •Analogies: camera megapixels vs iPhone experience; PC specs vs Mac simplicity.
- •Selling to solution buyers requires reframing from features/specs to results/time-to-value.
- 7:15 – 7:48
The trap: thinking big vendors ‘just sell tools’ because you used self-serve
Michael and Dalton address a common founder misconception: assuming companies like AWS or Stripe are purely tool businesses. They argue that self-serve is only one channel; large revenue comes from enterprise sales motions that look much more outcome- and service-oriented.
- •Many ‘tool’ companies also have large sales teams and massive enterprise contracts.
- •If salespeople aren’t talking to you, your experience may be unrepresentative.
- •Stripe for a side project is not Stripe for a company processing billions in volume.
- •Brand narratives formed in early years can mislead founders about how scaling revenue works.
- 7:48 – 8:57
A practical test: sales teams, quotas, and $10M+ customers reveal the real motion
Dalton offers a heuristic for identifying outcome/enterprise behavior: look for sales org size, quota/commission structure, and very large customers. This is a fast way to sanity-check whether a market expects enterprise-style selling and contracts.
- •Questions to ask: Do they have big sales teams? Quotas? Commissioned reps?
- •Do top customers pay tens of millions per year? That implies enterprise selling dynamics.
- •Self-serve usage doesn’t define the entire go-to-market model.
- •Researchable signals can prevent ‘lazy thinking’ about how winners actually make money.
- 8:57 – 10:00
AI era framing: outcomes get more profitable as models improve
Dalton summarizes a popular argument: AI commoditizes code and makes “selling software” less defensible, while selling outcomes can become more profitable. If AI boosts internal productivity, outcome vendors keep prices tied to value while costs fall, expanding margins.
- •If AI drives code cost toward zero, pure software feature differentiation can erode faster.
- •In outcomes-based businesses, AI improvements reduce delivery cost while value stays high.
- •This creates a positive feedback loop: better models → cheaper delivery → better margins.
- •They note the framework is insightful but not universally applicable to every startup.
- 10:00 – 10:48
How to promise outcomes without knowing every business: ask customers and copy comparables
Michael raises a fear: outcomes selling seems to require deep understanding of every customer. Dalton’s answer is pragmatic—start from competitor norms and directly ask customers how they define and measure success, letting them teach you the evaluation criteria.
- •Start with how competitors/comparables define and sell outcomes in the category.
- •Ask customers explicitly: how do you evaluate success, and what does failure look like?
- •Use ‘phone-a-friend’—customers will often explain their decision process.
- •Outcome definitions can be co-developed through discovery, not guessed in advance.
- 10:48 – 12:45
Big customers aren’t infinite: your top accounts can be huge, and patterns repeat
Michael argues the problem is often simpler than founders assume: there may not be thousands of unique “important” customers. Enterprise businesses frequently rely on a limited number of very large accounts, and learnings transfer across similar customers and industries.
- •Not all customers are unique; playbooks often generalize within industries.
- •Some markets have few truly large buyers (e.g., ‘how many Walmarts are there?’).
- •Vendors also gain horizontal insight across customers that any single buyer lacks.
- •You may need expertise in ‘how customers use your product to make money,’ not their org chart.
- 12:45 – 13:58
More examples of outcomes selling: hyperscalers and packaged ‘custom’ solutions
They broaden beyond Palantir: hyperscalers often sell services and bundled solutions to large, non-software companies rather than simple usage-based pricing. Large vendors package repeatable components to look bespoke, aligning their offering to customer processes and outcomes.
- •Hyperscaler enterprise sales looks unlike self-serve pay-per-API pricing.
- •Large deals often bundle services + components into a solution tailored to the buyer.
- •The ‘custom solution’ is frequently standardized building blocks assembled expertly.
- •Workday is referenced as another example of flexible, process-aligned enterprise selling.
- 13:58 – 14:47
How startups actually land seven-figure contracts: keep selling up-market and iterate
Dalton describes the real path: repeated attempts to sell up-market, learning from ‘no,’ and changing product/process until the deal becomes possible. Big contracts rarely happen on the first try; progress compounds over many cycles.
- •Advice: consistently try to sell up-market, even if it fails at first.
- •Seven-figure wins typically come after many iterations and lessons from rejections.
- •Teams adjust product, implementation, security, pricing, or process based on feedback.
- •It can take 1–2 years of persistence to reliably close large contracts.
- 14:47 – 18:12
Balancing fast growth with slow sales cycles: run big deals in parallel
They close by addressing a common anxiety: YC-style growth expectations versus long enterprise cycles. Michael reframes slow cycles as a gift—you can manage multiple deals simultaneously during inevitable gaps, reducing dependence on any single difficult prospect.
- •You must hit growth goals while also building capability for deals that won’t work initially.
- •Enterprise cycles include downtime (vacations, procurement), enabling parallel pipelines.
- •Founders fear the mental load of many prospects; use calendars/pipeline discipline.
- •Talking to 10 prospects creates leverage—drop bad-fit buyers and compare learnings.
- •Don’t lie to yourself: many iconic companies rely on enterprise sales and big sales teams.
