The First 100 Customers Course #1: How Omni Turned 100 Demos and 5 Lost Deals Into a Sales Engine

TL;DR

Omni did about 100 demos, reached five verbal commitments, and lost every deal. The company did not solve this by adding more leads. It stopped selling for two months, reduced product failures, returned through a trusted podcast audience, and says it won the next four unaffiliated trials at roughly $15,000 to $20,000 each.

This course turns Omni's full early distribution system into something you can run: choose a market where you have earned insight, define the minimum product required to replace an incumbent, operate demos as a research system, diagnose losses, fix the constraint, reactivate trusted demand, and build a partner channel. The objective is not to copy Omni's network. It is to reproduce the decisions that made the network useful.

What you will build

By the end, you will have five working assets:

1. a one-sentence market wedge and narrow initial buyer;
2. a replacement checklist separating table-stakes features from differentiation;
3. a demo ledger that captures reactions, objections, commitments, and next actions;
4. a stop-or-continue gate for deciding whether to fix product, message, or pipeline;
5. a 30-day founder distribution plan combining relationships, signals, and small partners.

This course is for you if

• you can build quickly with AI but prospects do not convert after demos;
• you are entering a market with established software and switching costs;
• you have domain experience, former colleagues, users, or partners but no repeatable motion;
• you sell a product expensive enough to require trust and founder involvement.

Do not use it if

• you have not spoken to a real user yet and want automation to choose the problem for you;
• your only plan is to send thousands of generic messages;
• you interpret compliments, signups, or verbal interest as customers;
• you are unwilling to pause acquisition when the product is the bottleneck.

Case snapshot: what actually happened

Stage	Action	Result	Evidence extracted
February 2022	Former Looker and Stitch operators start Omni	Immediate credibility and about $26M raised across seed and A	Team-market fit bought time, not customers
Months 1–9	Build and demo an incomplete product	First user was a former Looker PM	Trusted users tolerated rough edges
Months 9–12	One user and an angel-investor company use Omni in real work	Only 1–5 daily users, but clear differentiated workflows	Usage showed value hidden behind reliability problems
Around year one	About 100 founder demos	Five verbal commitments, then five losses	The replacement threshold had not been reached
Next two months	Reliability sprint	Errors moved from constant to occasional	The repeated sales objection became product work
Following four weeks	Founder appears on a relevant podcast	Four unaffiliated trials won at about $15K–$20K	Strangers now paid and liked the product
After product-market fit	Scale LinkedIn, outbound, organic, practitioners, cloud partners, events	No single magic channel	Distribution compounded as a portfolio

The model: evidence → readiness → trust → leverage

Omni's system has four loops. Evidence comes from demos and daily usage. Readiness means the product can replace the incumbent without its negative differences overwhelming the positive ones. Trust moves buyers across the risk of adopting a young vendor. Leverage arrives when partners, employees, and customers carry that trust into accounts the founder cannot reach alone.

AI compresses building time inside this model. It does not remove the replacement threshold, switching risk, buyer politics, or the need for trusted proof. That is why an AI-built SaaS can have more features than Omni had in 2022 and still have fewer customers.

Step 1: choose a market where you can judge weak feedback

Omni's founders had spent years inside business intelligence. Colin Zima had met thousands of Looker customers. The team knew what enterprise BI did well, where it was inflexible, and which product decisions were expensive to reverse. Omni's founder history confirms that the core team came from Looker and Stitch/Talend.

This did not guarantee product-market fit. It gave the team a way to interpret ambiguous evidence. When users hit errors but still reacted strongly to a workflow, the founders could distinguish a valuable product hidden under defects from a product receiving polite feedback.

Your worksheet

• Market: We understand ______ because we have personally done ______.
• Incumbent strength: Buyers keep it because ______.
• Structural weakness: The incumbent cannot easily change ______ because ______.
• Narrow buyer: The person who feels this weekly is ______.
• Why now: A technical, organizational, or behavior shift makes change possible because ______.

Pass condition: you can name five real buyers and predict the workflow they will compare. Stop condition: your thesis is only “the incumbent looks old” or “AI can build it cheaper.” Those observations do not explain why a buyer will switch.

Step 2: define the minimum replacement product

Omni's differentiation was not “better charts.” It inverted a central BI workflow: analysts could explore first and turn useful work into a governed semantic model later. But a buyer could not use that advantage until Omni also provided dashboards, permissions, connections, and the ordinary features required to replace existing BI.

Zima's estimate is a useful mental model: in foundational software, you may need to reproduce about 80% of the established category before the 20% that is better can matter. Omni internally felt differentiated by September 2022, but it did not look like a credible BI replacement until dashboards arrived around January 2023 and demos matured around March.

Build a two-column replacement checklist

Table stakes: must not fail	Differentiation: must create a “wow”
Core workflow completes without founder intervention	Buyer can do something materially difficult or impossible today
Security, reliability, export, permissions, and integrations meet the buyer's stage	The difference appears in a two-minute demonstration
End user accepts daily usage	Value is tied to money saved, better decisions, or work removed

Pass condition: a relevant stranger can complete the main workflow and independently describe why it is better. Stop condition: buyers admire the feature but refuse to replace the tool. Continue building the replacement layer before adding pipeline.

Step 3: turn every demo into structured product research

Omni started demos while they were still bad. Zima kept a spreadsheet of around 100 names. He showed the product to almost anyone in his network who understood data, learned discovery, and tested whether the proposed difference was enough to make someone remove an existing tool.

Use one row per conversation:

Field	What to record
Trigger	Why this person would change now
Current workflow	Tool, frequency, cost, workaround, and switching risk
Wow moment	The exact action that changed their attention or questions
Blocker	Product, trust, price, timing, authority, or no real pain
Commitment	Next meeting, data access, trial, contract, payment, or nothing
End-user verdict	What the person who will use it daily actually did

Do not optimize only for booked demos. Track the progression from reaction to behavior. Omni learned that a Fortune 500 CIO saying “interesting” was evidence of differentiation, not evidence of a sale. Five verbal commitments were stronger evidence, but still not revenue.

Checkpoint every 10 demos: count repeated wow moments, repeated blockers, trials started, and payments. If no unique moment repeats, revisit the wedge. If one blocker repeats among buyers who want the outcome, fix it before increasing volume.

Step 4: create a design partner who uses the product, not a friendly advisor

Omni's first user was a former Looker product manager who had started a company. Another early customer was connected to an angel investor. Zima effectively operated as its data team: he set up data infrastructure, answered questions, and used Omni to deliver the answers.

This concierge work showed the product doing real jobs. It also exposed an important distinction: founders could see through a full-page error because they knew what was underneath; unaffiliated users could not. Daily usage separated the valuable core from founder tolerance.

Your output: recruit one design partner with a recurring workflow, real data, a named end user, and a weekly deadline. Do the setup manually. Observe usage. Pass condition: they ask for more because the existing value matters. Stop condition: all activity requires you to remind or operate the product, and the buyer would not pay without the relationship.

Step 5: classify losses before deciding to sell harder

Omni's five lost deals shared a pattern: the company looked young, the product felt close but not ready, and end users did not love it. At an attempted $15,000 ACV, buyers were not purchasing an experiment. They were selecting a vendor expected to support years of analytics work.

Classify each loss into one of four queues:

1. No pain: change ICP or problem.
2. No differentiation: change the wedge or demonstration.
3. Product readiness: pause acquisition and fix the repeated operational blocker.
4. Trust or timing: build proof, references, and a follow-up horizon.

Omni chose queue three and spent two months eliminating bugs. This was not an engineering detour. It was the next step in the sales system. The team reported moving from failures every few minutes to roughly one a day.

Decision gate: when three qualified buyers independently name the same blocking product risk, freeze new top-of-funnel work for one sprint. Retest the same workflow afterward. Do not rewrite the email when the product is failing in the trial.

Step 6: reactivate demand through concentrated trust

After the sprint, Zima appeared on a podcast with sales operator Sam Blond. It produced roughly four unaffiliated trials, and Omni says it won all four over about four weeks. The podcast borrowed trust, gave the founder enough time to explain a complex product, and selected listeners interested in the problem. Reliability converted that attention.

Omni also used LinkedIn as a relationship database. Zima had around 6,000–8,000 connections and contacted former Looker colleagues, customers, and data practitioners. He says known former colleagues could answer at rates near 90%, while a scaled BDR motion might receive around 3%. He printed his connections, marked relevant people, tested messages, and found short, honest requests worked best.

Reproduce the motion without a famous network

1. Export former colleagues, customers, community peers, podcast guests, and people who wrote about the problem.
2. Score for role, current trigger, problem evidence, and relationship strength.
3. Split known contacts from strangers. Never compare their response rates as one channel.
4. Write one direct sentence: what you built, why it fits them, and the real ask.
5. Show the product, capture the result in the same demo ledger, and follow progress over time.

Pass condition: at least 20 qualified conversations reveal a repeated buyer and workflow. Stop condition: high replies from friends create no trials. Your relationship message is working; the offer is not.

Step 7: recruit small partners before large platforms care

The cloud and data giants knew Omni's founders, but they did not send meaningful business to a tiny company. One- and two-person analytics consultancies did. These practitioners served several clients, selected tools, implemented them, and put their own reputation behind the recommendation.

Omni sometimes paid a partner about $5,000 to implement a customer. That payment created product knowledge and service revenue for the partner. A successful implementation then made the partner more willing to recommend Omni elsewhere. The partner was both delivery capacity and a distributed trust node.

Partner qualification template

• They repeatedly serve your narrow ICP.
• They influence tool selection and perform implementation.
• Your product makes their service better or more profitable.
• You can guarantee responsive support for the first shared customer.
• One implementation teaches them enough to repeat it.

Pass condition: one partner completes a successful implementation and introduces a second qualified account. Stop condition: the partnership begins with a logo swap, webinar, or marketplace listing but no shared customer workflow.

Step 8: scale a portfolio, not a mythical channel

After early fit, Omni expanded founder LinkedIn into BDR outbound, programmatic enrichment, organic inbound, practitioner partnerships, relationships with Snowflake, Databricks, Amazon and Google, and later events. Zima's conclusion was unsatisfying and useful: there was no channel waiting to be turned on. The company did more of several ordinary motions.

The order matters. Founder evidence came before mechanized outbound. Small practitioners came before large ecosystem leverage. Events arrived later. Scaling all channels from day one would have hidden the product problem and exhausted the team.

Your 30-day implementation plan

1. Days 1–3: complete the market wedge and replacement worksheet. Select one buyer and workflow.
2. Days 4–7: build a list of 30 qualified people: 10 known, 10 signal-led strangers, 10 practitioners.
3. Days 8–14: run 10 diagnostic demos. Complete every field in the ledger.
4. Days 15–17: cluster wow moments and blockers. Choose no pain, differentiation, readiness, or trust.
5. Days 18–24: fix one repeated blocker or rewrite the wedge. Do not do both at once.
6. Days 25–27: retest with five unaffiliated prospects from one concentrated audience.
7. Days 28–30: recruit one implementation partner and define the first shared customer outcome.

Lead Scorer lab: rebuild Omni's motion today

This is where Omni's story becomes an executable distribution system. The MCP is the execution surface: the same sequence can run from Codex or Claude when the Lead Scorer MCP and skills library are connected. Use it for a high-consideration B2B product with a narrow buyer, visible switching triggers, and enough deal value to justify research. Do not use it to scale acquisition while three qualified prospects keep reporting the same product-readiness failure. In that situation, copy Omni and pause the campaign.

Phase 1: encode the wedge before finding leads

Start with $icp-offer-context. Create one product with create_product, then an active flexible rubric with create_scoring_config. The rubric should score the evidence from the course, not generic firmographics: current BI stack, number of data consumers, migration or hiring trigger, need for governed self-service, implementation capacity, and the cost of staying with the current workflow. Add disqualifiers for tiny teams without a recurring analytics job, students, consultants seeking a free tool, and buyers with no authority or migration window.

Use $icp-offer-context. Build the product and scoring rubric for a governed analytics platform sold to data leaders replacing a rigid BI workflow. Return the rubric, disqualifiers, and evidence required for scores 8-10 before creating anything.

Output: one product, one active rubric, and a definition of a qualified conversation. Pass condition: two operators score the same sample account within one point.

Phase 2: keep three acquisition motions separate

Create three product-linked lists with create_list: warm relationships, visible problem signals, and implementation partners. This separation matters because Omni's founder reported close to 90% replies from real relationships while a scaled BDR motion could produce about 3%. Combining them would hide whether the offer works or the relationship simply earned a reply.

1. Warm: add former colleagues, customers, operators, and people who already know the founder.
2. Signals: use $daily-vertical-prospecting or create_audience_source on a relevant LinkedIn post, event, or people search. Enable prequalification against the product so weak profiles never enter the working list.
3. Partners: use $contact-discovery to find small analytics consultancies that repeatedly choose tools for the same buyer and can own implementation.

Output: 10 warm people, 20 signal-led prospects, and 10 candidate partners. Do not buy contact data yet. A LinkedIn profile and a documented reason for inclusion are enough for qualification.

Phase 3: score first, spend credits second

Load unscored people with get_leads_pending_scoring and save each verdict with submit_lead_score. Use 8-10 as the contact queue, 6-7 as the watch or content queue, and 1-5 as reject for this test. The score explanation must cite an observable fact: a hiring change, a migration, a complaint about the incumbent, a relevant role, or a partner's repeated access to the ICP.

Only then run $lead-enrichment-pipeline. Call enrich_leads with dry_run: true, review the credit estimate, and enrich the 8-10 group. Reserve find_lead_contact_info for people you genuinely intend to contact, again with a dry run before confirmation. This keeps expensive enrichment downstream of free judgement.

Stop condition: fewer than five of the first 30 prospects score 8 or higher. Rewrite the ICP or signal source instead of widening the list.

Phase 4: build two campaigns, not one template

Use $cold-email-first-touch and $follow-up-sequence, then persist each sequence with create_campaign. Keep warm and cold prospects in separate draft campaigns. Warm outreach can acknowledge the relationship and ask for a diagnostic conversation. Signal-led outreach must name the observed trigger, the workflow hypothesis, and one low-friction next step. Neither should pretend that a LinkedIn connection is a relationship.

Add only the qualified people with add_leads_to_campaign. Then call get_campaign_authoring_context, write every lead-specific message with the evidence already collected, and save it through write_campaign_drafts. Run $deliverability-preflight and $outreach-qa-audit. Every action remains needs review; a human reads the claim, approves the copy, and activates the campaign in the web interface.

For each score-8+ lead, use the campaign context to write one message around the verified trigger. Do not invent familiarity. State the workflow hypothesis, offer a short diagnostic demo, and leave every draft awaiting review.

Phase 5: turn objections into the next audience

After every reply or demo, tag the lead by outcome: no pain, no differentiation, product readiness, trust, timing, or implementation. Store the evidence as a note or research item in Content Studio. After ten conversations, count the objections. Three qualified buyers naming the same product risk trigger an Omni-style product sprint and a pause in outbound. A repeated misconception becomes a source-backed guide, not a rebuttal hidden in a sales call.

Keep that guide as a Content Studio draft, publish it only after review, then use create_audience_source on the people who react or comment. Prequalify them against the same product, score the keepers, and route them into a new signal-led list. This closes the loop: conversation evidence → product or content change → visible engagement → qualified outreach. Lead Scorer can run that loop faster. The founder still owns the replacement threshold, the pause decision, the truth of every claim, credit confirmations, and final approval before anything sends.

Saveable checklist

• One market where you have earned judgement.
• One buyer, one workflow, one switching trigger.
• Table stakes separated from differentiation.
• One design partner using the product weekly.
• Ten demos logged before changing direction.
• Verbal interest kept separate from behavior and payment.
• Three repeated product blockers trigger a focused sprint.
• One trusted audience retests unaffiliated demand.
• One small practitioner implements and introduces the next account.
• Only then scale outbound, inbound, platforms, and events.

Sources and limits

• Colin Zima on A Product Market Fit Show, episode published 10 August 2026. The complete local transcript was audited in contiguous windows from character 0 to 57,175.
• Omni: About, for founder history and product thesis.
• Omni's customer philosophy, for its current support model.
• Omni's August 2022 launch announcement, for early funding context.
• TechCrunch's March 2025 profile, for later customer and revenue context.

Demo counts, response rates, early pricing, trial wins, and partner economics are founder-reported. No public customer ledger proves which accounts were literally first. The evidence supports one early friendly user, five lost proposed deals, and four later unaffiliated wins. This is why the series teaches a route toward 100 customers without claiming that the episode documents Omni's exact first 100.