The SaaS Distribution Course #14: How Nebulock Turned 90 Interviews Into a Six-Week Enterprise Close

TL;DR: Nebulock founder Damien Lewke says 90 customer interviews in 90 days stopped him from building the wrong architecture. Those conversations created a warm pool of design partners; weekly design work trained a one-month POC that required about two customer hours; and mapping budget, legal, IT, and procurement before the proof ended helped one Fortune 500 engagement close in six weeks. The result is founder-reported, but the mechanism is unusually explicit.

The warning is just as useful. Earlier POCs dragged for three to six months even when the product worked. A champion liked the result, but the company had not fixed the timeline, purchase gate, data-processing paperwork, or procurement path. Nebulock did not solve distribution with one channel. It linked discovery, product development, proof, and enterprise buying into one system.

What you will build

You will build a discovery-to-procurement distribution system for a narrow, high-value B2B product. It has six connected parts:

1. a qualified interview graph built from direct and second-degree relationships;
2. a discovery worksheet that tests priorities, spend, architecture, and buying process;
3. a weekly design-partner cadence for the strongest problem-buyer matches;
4. a fixed POC with a time box, customer-effort budget, proof event, and purchase gate;
5. a stakeholder map covering the champion, executive sponsor, legal, IT, and procurement;
6. a feedback loop that turns every proof and objection into the next product and sales decision.

The output is not “90 calls.” It is a repeatable path from an uncertain product thesis to a procurement-ready proof. Your pass condition is that each stage produces the input for the next one. If interviews do not narrow the product, design partners do not improve the POC, or a POC has no defined purchase path, stop and repair that handoff before adding volume.

Who this is for, and who should not copy it

This model fits technical B2B products with high ACV, a complex incumbent stack, and a buyer who needs proof before signing. Security, data infrastructure, compliance, finance, and enterprise AI are natural candidates. It also assumes the founder can reach credible operators directly or through second-degree introductions.

Do not copy the full motion for a €49 self-serve tool. Flights, weekly partner calls, DPAs, and custom proof work will destroy the economics. Do not copy the reported 70% response rate into a cold campaign either: Lewke says he mapped his own and friends' LinkedIn networks and often asked for warm introductions. The channel and trust context created the number.

Case snapshot

Stage	Nebulock action	Founder-reported evidence	Limit
Discovery	Mapped warm security leaders and ran 90 interviews in 90 days	Response rate above 70%	Warm and referral-heavy, not cold outreach
Product correction	Replaced the original integration assumption	The intended architecture was wrong	No public technical before-and-after
Design partners	Asked for 30 minutes every week	Every design partner converted to paid	Denominator and retention undisclosed
POC	Productised the repeated work	One month and about two customer hours	Later playbook, not the first attempt
Failure	Ran open-ended proofs without a complete buying map	Several POCs took three to six months	No win-rate data
Enterprise result	Found a material issue, secured budget, ran procurement in parallel	One Fortune 500 close in six weeks	Unnamed and not independently audited

The model: use learning to reduce the next distribution cost

Customer discovery is normally treated as product work, design partners as customer-success work, and procurement as sales administration. Nebulock made them consecutive distribution stages. One interview did four jobs: it tested the problem, mapped budget, exposed the existing stack, and earned a route to another operator. The best matches became design partners. Their repeated work became a POC protocol. That protocol created a proof a senior buyer could use while legal and procurement moved in parallel.

The causal chain is: qualified conversation → corrected product → warm design partner → repeatable proof → procurement-ready close → stronger references and higher ACV. A broken link raises the cost of every stage after it. More leads cannot rescue the wrong architecture. A brilliant POC cannot rescue absent budget. A strong champion cannot approve a DPA alone.

Step 1: define a problem with budget before defining a campaign

Lewke entered with deep security experience, but he did not treat experience as validation. His interview opened broadly: the operator's role, top three priorities, current investments, tools, people, and the relative rank of the problem. Only after those facts did he ask what a useful solution should look like. Later calls added pricing, budget ownership, and whether a new product would replace or augment existing spend.

Build a four-column problem sheet: priority, present cost, current stack, purchase authority. Reject a segment when the problem stays below the buyer's top three, no owner controls meaningful budget, or every company requires a different architecture. The goal is not compliments. The goal is a problem that can survive a budget conversation.

Output: one narrow problem-buyer statement and a list of disqualifiers. Pass condition: ten interviews repeat the same priority, current workaround, and likely budget owner. Stop condition: interest is high but nobody has changed behaviour or allocated spend.

Step 2: build an interview graph, not a giant lead list

Before sending asks, Lewke reviewed his LinkedIn network, then the networks of friends and former colleagues. The message was short: he was building in the space, wanted early feedback, and offered the prospect a chance to shape the idea. At the end of useful calls, he asked for one relevant introduction. He reports a response rate above 70%, but the warm graph explains why.

Start with 30 names across three rings: ten direct operators, ten second-degree operators, and ten cold controls. Keep the ask to 15-30 minutes. Give the introducer a forwardable paragraph. After every call, record the problem rank, budget signal, architecture, next introduction, and design- partner fit. Do not mix the rings when measuring response.

Output: an interview graph with provenance and next edges. Pass condition: each five completed interviews produce at least two qualified second-degree names. Stop condition: referrals grow, but the same urgent problem does not repeat.

Step 3: make discovery expensive enough to kill your favourite assumption

Nebulock's clearest discovery win was negative: the original system integration was wrong. Without the interviews, the team would have built against the wrong part of the security stack, burned capital, and later hard-pivoted. The sprint created a roadmap before a larger engineering team amplified the mistake.

Add an assumption register beside the interview notes. For each architectural or commercial bet, write the evidence that would kill it. Review after calls 10, 20, and 30. A founder who only adds confirming quotes is not doing discovery. A useful sprint should delete features, segments, or integrations.

Output: a keep/change/kill decision for each major assumption. Pass condition: evidence changes at least one material product or GTM choice. Stop condition: the team cannot name what evidence would change its mind.

Step 4: turn the strongest matches into weekly design partners

Nebulock did not begin with a legalistic POC. Early partners were asked for 30 minutes every week. The cadence created continuity: the team could show a change, watch the operator use it, and define the next proof. Lewke says every design partner eventually paid, but does not disclose how many partners there were. Treat that as evidence of a tight program, not a conversion benchmark.

Use three phases. In architecture, test data access and workflow. In evidence, define the event that would prove the product useful. In commercial transition, ask what else must be true to justify a proposed price. Do not promise permanent discounts before value is clear. Do not accept partners who skip the weekly work; their logo cannot teach the system.

Output: a six-week partner scorecard. Pass condition: the partner supplies access, attends weekly, and agrees on a paid outcome. Stop condition: feedback remains general and nobody owns implementation.

Step 5: productise proof before scaling sales

Repeated design-partner work trained Nebulock's later POC: one month, about two customer hours, defined value, and a known cadence. In the highlighted Fortune 500 case, the platform surfaced a significant issue in about a day and a half. The finding reached the CISO, helped create budget, and the deal closed in six weeks from POC start.

Write the POC as an operating contract: duration, customer-time budget, required access, three success events, weekly review, named buyer, and a purchase decision date. The success event must connect to a top-two priority. “The product ran” is not enough. For an AI workflow, the event might be a verified reduction in analyst time or a high-value exception found with an auditable trail.

Output: a one-page POC charter. Pass condition: the buyer confirms that meeting the events creates a purchase decision. Stop condition: the prospect wants unlimited exploration without a budget owner or decision date.

Step 6: sell through the anti-champions

Nebulock's early POCs did not drag because nobody cared. They dragged because the company had not mapped the path after technical success. Legal redlines arrived late. Procurement had its own obligations. IT and security requirements could block an early-stage vendor. The champion could advocate but could not remove every control.

Before kickoff, map six roles: user, champion, economic buyer, executive sponsor, technical approver, and procurement owner. Ask for the vendor-security checklist, DPA, MSA preference, purchasing calendar, and required approvals. Run paperwork in parallel when the buyer allows it. Treat legal, IT, and procurement as stakeholders with real jobs, not enemies to bypass.

Output: a mutual close plan with owners and dates. Pass condition: the executive sponsor and procurement path are known before the proof midpoint. Stop condition: only the day-to-day champion can explain how the company buys.

What failed, and why

Failure	Type	Repair
Wrong planned integration architecture	Invalid product assumption	Broad discovery before engineering scale
POCs lasting three to six months	Undefined execution	Fixed timeline, scope, customer effort, and success events
Successful proof followed by procurement delay	Incomplete buying map	Budget, sponsor, DPA, legal, IT, and procurement in parallel
Potentially expensive founder travel	Structural limit	Reserve it for qualified, high-ACV accounts

Your 30-day implementation plan

1. Days 1-3: define one buyer, one top-three problem, five disqualifiers, and the assumption register.
2. Days 4-7: map 30 direct, second-degree, and cold-control prospects. Prepare one forwardable ask.
3. Days 8-14: run ten interviews. Capture priority, present spend, stack, owner, architecture, and referral.
4. Days 15-18: review the first evidence checkpoint. Kill or change at least one weak assumption.
5. Days 19-23: recruit up to three design partners with a weekly 30-minute commitment.
6. Days 24-27: draft the POC charter from repeated work, including customer effort and purchase gate.
7. Days 28-30: build the stakeholder and procurement checklist before proposing the first formal proof.

The month passes when you have a corrected roadmap, at least one committed design partner, and a POC draft tied to a buyer's real priority. It fails when you merely complete 30 conversations.

Lead Scorer implementation: preserve the warm graph and approval gates

Lead Scorer can reproduce the research, qualification, and drafting layer of this motion. It cannot supply Lewke's security reputation, conduct the discovery call, promise a custom proof, or approve enterprise paperwork. Use it when a high-ACV product has a narrow ICP and the founder can review every account. Do not use it to imitate a warm response rate with mass cold volume.

Phase A: define and separate the rings

Run the icp-offer-context skill with the problem, disqualifiers, proof you may claim, and current architecture assumptions. Create separate lists for direct relationships, second-degree introductions, and cold controls. Never merge them: provenance is necessary to interpret response.

Copyable prompt: Define the ICP for [problem]. Reject accounts where the problem is below the buyer's top three, no owner controls budget, or the required stack is absent. Keep direct, introduced, and cold prospects in separate lists.

Phase B: score before spending enrichment credits

Use sales-navigator-lookalikes or the available sourcing workflow to find the same role and company pattern. Run signal-research-dossier to require at least two dated, sourced signals per person. Score problem fit, authority, stack fit, and relationship strength. Enrich only keepers with lead-enrichment-pipeline; contact discovery remains an explicit credit gate.

Pass condition: score 8/10 or higher, two verified signals, and a known reason for this person to discuss the problem now. Stop condition: the only evidence is title fit or a generic company description.

Phase C: draft the ask, then let the founder listen

Use ai-authored-campaign to create drafts only. The ask is for 15-30 minutes of feedback, not a demo. Review every message with outreach-qa-audit. A human approves wording and sending. After each call, store the priority, present spend, stack, assumption changed, design-partner fit, and requested introduction. Do not let an agent invent these observations.

Copyable prompt: Draft one short feedback request per qualified lead. Mention the verified signal, state the narrow problem under study, ask for 20 minutes, and make no product-performance claim. Leave every draft pending human review.

Phase D: convert objections into the next audience

Use reply-triage to classify responses without sending automatically. Feed recurring objections into Content Studio as source material for a factual brief, then use signal-audiences only when people visibly engage with that evidence. This creates a controlled loop: research informs content; engagement creates a new warm signal; qualification still precedes enrichment and drafting.

The approval gates remain explicit: confirm credit spend before contact discovery, review every draft, never activate a campaign automatically, and let the founder decide which conversations become design partnerships.

Checklist

• One narrow buyer owns a top-three problem and meaningful budget.
• Direct, introduced, and cold prospects remain separate.
• Every interview records priority, spend, stack, authority, and next introduction.
• The assumption register names what evidence would change the product.
• Design partners commit to weekly work, not logo lending.
• The POC has a duration, customer-effort budget, success events, and purchase gate.
• Executive sponsor, legal, IT, data processing, and procurement are mapped early.
• Founder-reported conversion and cycle numbers are never sold as universal benchmarks.

Sources and evidence limits

The operating sequence comes from Damien Lewke's July 2026 interview on A Product Market Fit Show. The complete local transcript was audited from character 0 to 46,201 in seven contiguous windows. The publisher's companion essay preserves the 90-in-90, weekly design-partner, one-month POC, two-hour customer-effort, and six-week close details.

Nebulock's July 2025 launch announcement and June 2026 Series A announcement establish the public product and company timeline. Axios independently reported the $8.5 million total funding at launch, while SecurityWeek reported the $25 million Series A and more than $33 million total funding.

The private distribution numbers remain founder-reported. There is no public interview ledger, design-partner denominator, customer identity for the six-week case, audited ACV, retention, churn, CAC, or payback period. The company-reported 300 million investigations and 4,000 findings show platform activity, not audited customer ROI. Use the sequence as an operating model, not a promise that 90 interviews will produce the same close.