The Technical Founder's Go-to-Market Playbook for AI Products
A practitioner's GTM playbook for AI SaaS founders — ICP definition, positioning, pricing model selection, sales motion, and a 90-day sprint framework.
Whether you're looking for an angel investor, a growth advisor, or just want to connect — I'm always open to great ideas.
Get in TouchAI, startups & growth insights. No spam.
TL;DR: AI products fail in market not because the technology is bad, but because the GTM motion is designed for the wrong buyer, the wrong moment, and the wrong sales context. This playbook covers everything I've learned from founding AI products and investing in dozens of AI startups — ICP definition, positioning, pricing architecture, sales motion selection, the 10 design partner playbook, channels that actually work in 2026, and a 90-day sprint framework you can run immediately.
I've reviewed hundreds of pitches from AI founders over the last three years, and the single most common strategic error I see is founders applying a traditional SaaS GTM playbook to an AI product. The two are fundamentally different markets, and treating them as the same is expensive.
Here is the core difference: traditional SaaS GTM is about demonstrating feature parity and workflow fit. AI GTM is about demonstrating trustworthy output quality in the buyer's specific context. These are not the same problem.
When a buyer evaluates a CRM, they want to know whether the fields match their data model, whether the API integrates with their existing stack, and whether the workflow matches how their team operates. These questions have deterministic answers. A demo that works in a controlled environment transfers directly to confidence in production.
When a buyer evaluates an AI product, those questions exist too — but they are secondary to a more fundamental question: "Will this actually produce good outputs when it's working on my data, in my domain, with my edge cases?" That question has no deterministic answer in a controlled demo. And buyers know it.
This creates three structural differences in AI GTM that every founder needs to internalize:
Demo-ability is harder. A traditional SaaS demo is replicable — you set up a demo environment that looks like the customer's environment and walk through a scripted scenario. An AI product demo looks great in controlled conditions and may fail unpredictably on the customer's actual data. I've seen deals fall apart in production pilots that sailed through demos. The gap between "impressive demo" and "reliable production behavior" is the single most important thing to close before you scale sales.
Trust is the actual product. Buyers of AI products are not just evaluating whether the product works. They are evaluating whether they can trust the product to work consistently in their environment. Trust involves explainability (can they understand why the model made a decision?), auditability (can they review outputs before they have consequences?), and recoverability (when the model fails, how bad is the failure and how quickly can they catch it?). Founders who treat trust as a checkbox rather than a core product investment routinely lose deals to inferior products that have done the trust work.
Integration depth determines switching costs. Traditional SaaS switching costs come from data lock-in and workflow dependency. AI switching costs come from the same sources plus one additional factor: the time and expertise required to validate that a new AI system produces equivalent or better outputs across the customer's specific distribution of cases. That validation is expensive and slow. Companies that have built deep integrations into customer workflows and accumulated validation data from production usage have switching costs that pure-play SaaS cannot match.
| Layer | Traditional SaaS GTM | AI Product GTM |
|---|---|---|
| Value proof | Feature demo + reference customers | Domain-specific pilot results + validation data |
| Sales motion | Discovery → demo → trial → close | Discovery → pilot design → supervised pilot → results review → close |
| Trust signals | Reviews, analyst reports, case studies | Model accuracy benchmarks, audit logs, error rates, escalation paths |
| Pricing model | Per-seat or flat subscription | Usage-based or outcome-based (matches value delivery) |
| Buyer evaluation criteria | Feature checklist + integration fit | Output quality + error behavior + explainability |
| Competitive moat | Features, integrations, brand | Training data advantage, fine-tuning quality, domain accuracy |
Understanding this stack is the foundation of AI GTM. Everything else in this playbook builds on these differences.
Standard ICP frameworks use firmographic filters: company size, industry, geography, revenue, and budget. These filters work for traditional SaaS because within a given firmographic segment, most companies have similar needs and similar decision-making processes.
For AI products, firmographic ICP is necessary but insufficient. A 200-person fintech company and a 200-person logistics company both fit a "Series B tech startup" ICP, but their readiness to adopt an AI product, their capacity to handle AI output variability, and their ability to integrate AI into existing workflows may be completely different.
I've developed three additional ICP dimensions that are specific to AI products:
AI readiness is the degree to which an organization has the technical infrastructure, internal expertise, and organizational appetite to deploy and use an AI product effectively. It is not the same as technical sophistication — a technically sophisticated company may be extremely risk-averse about AI adoption.
AI readiness breaks into four components:
Data maturity: Does the customer have structured, accessible data in the format your AI product needs? An AI product that requires clean historical transaction data to function is only as good as the customer's data quality. A customer with scattered, inconsistent data will have a poor experience regardless of how good your model is.
Technical capacity to integrate: Can the customer's technical team integrate your product? This includes API fluency, the ability to handle asynchronous outputs, and the capacity to build error handling for cases where your model produces low-confidence outputs.
Organizational appetite for change: Is there internal support for AI adoption, or will the product face internal resistance from the teams whose workflows it changes? I've seen enterprise AI deals collapse not because the product failed, but because the operations team successfully lobbied against adoption after a successful technical pilot.
Existing AI footprint: Does the customer already use AI tools? Organizations with existing AI adoption are dramatically easier to sell to than first-time adopters — they have already developed internal practices for validating AI outputs, they have champions who understand the technology, and they have managed at least one AI integration project.
| Level | Description | AI Adoption Profile |
|---|---|---|
| Level 1: Raw | Data scattered across systems, inconsistent schemas, manual entry | High implementation risk; likely poor initial results; avoid early |
| Level 2: Structured | Data in systems, accessible via API or export, inconsistent quality | Manageable with good onboarding; expect 60-day ramp before value |
| Level 3: Governed | Data governance practices in place, consistent schemas, clean histories | Ideal early adopter; fast time-to-value |
| Level 4: Analytics-ready | Dedicated data team, BI infrastructure, data quality monitoring | Sophisticated buyer; high expectation; high NPS potential |
Early in your GTM, target Level 3 customers almost exclusively. They get fast results, become your best references, and help you develop the case studies that unlock Level 2 customers at scale.
This one is harder to measure but it is arguably the most predictive factor for AI product adoption success. Change management capacity is the organization's ability to modify internal workflows when a new tool changes how work is done.
The fastest proxy question I use in discovery: "Tell me about the last time you rolled out a new tool that changed how a team did their daily work. How did that go?" The answer tells you almost everything about whether the current opportunity will succeed or fail for non-technical reasons.
The single most common reason AI products fail in production after a successful technical pilot is not model quality. It is that nobody did the change management work to transition the team from the old workflow to the AI-augmented workflow. This is a GTM problem, not a product problem.
I am a technical founder. I've built products, written APIs, trained models. And I can tell you honestly that my technical background was both my biggest GTM asset and my biggest GTM liability.
You can go deep in sales conversations. When a prospect's CTO asks about your model architecture, data residency approach, or fine-tuning methodology, you can answer without deflecting. This builds credibility faster than any case study or analyst report. In AI sales, where technical trust is a core buying criterion, being able to go deep in technical conversations is a genuine competitive advantage.
You can identify real integration complexity early. Non-technical founders often make integration promises in sales cycles that the product cannot keep, or that require engineering work the team has not scoped. Technical founders understand the integration constraints from first principles and can design sales cycles that surface technical blockers before they become closed-lost reasons.
You can build the demo the right way. Technical founders instinctively understand why a canned demo is dangerous for AI products, and they have the capability to build sandboxed environments that actually reflect how the product behaves on realistic data. The best AI sales demos I've seen were built by technical founders who took the trouble to pre-process a realistic dataset and run it through the model before the demo.
You understand the product roadmap credibly. In AI sales, buyers often evaluate not just what the product does today, but what it will do in 18 months. A technical founder who can credibly discuss the model improvement roadmap, the data flywheel strategy, and the accuracy improvement trajectory gives buyers confidence in making a multi-year bet on the product.
You optimize for technical buyers and miss business buyers. The technical founder default is to lead with how the product works, not with what outcome it produces for whom. Business buyers — the VPs of Operations, CFOs, and CEOs who often control AI budgets — do not care about your architecture. They care about how many FTEs this replaces, how many errors this catches, how many hours per week this saves. Technical founders who lead with technical details in business buyer conversations lose these deals.
You underinvest in trust signal infrastructure. Technical founders tend to believe that if the product works, people will adopt it. This is false for AI products. Trust signal infrastructure — case studies with specific accuracy numbers, audit trail capabilities, explainability features, escalation paths for low-confidence outputs — feels like "non-product work" to a technical founder. It is actually a core GTM investment.
You underprice because you know the marginal cost. Technical founders often know that their inference cost per query is $0.002 and price accordingly. The correct AI pricing framework has nothing to do with marginal cost and everything to do with value delivered. If your product saves a customer $50,000 per month in labor costs, pricing at $500/month because inference is cheap is leaving enormous revenue on the table.
You build features when you should be shipping use cases. The technical instinct is to make the product more capable. The GTM instinct is to make the product more focused. For early AI GTM, a product that solves one problem exceptionally well beats a product that solves ten problems adequately every time.
Positioning for AI products has two macro decisions: horizontal versus vertical, and workflow replacement versus augmentation.
Horizontal AI is a product that serves multiple industries with the same core capability. OpenAI, Anthropic, and the API layer are horizontal. Most horizontal AI plays struggle in enterprise sales because they cannot develop deep domain expertise, cannot build domain-specific training data, and cannot speak credibly to the specific accuracy requirements of any vertical. Horizontal AI is a viable GTM for developer tools (where the buyer is technical and evaluates on benchmarks) and for productivity tools (where the value is obvious and individual). It is extremely difficult for enterprise workflow AI.
Vertical AI is a product built specifically for one industry or one workflow. A document processing product for insurance carriers. An AI coding assistant for embedded systems engineers. A revenue forecasting product for e-commerce operators. Vertical AI has stronger positioning, clearer ICP, faster sales cycles, and higher pricing power — because it can demonstrate accuracy benchmarks specific to the vertical and build references within a defined community of buyers.
My strong recommendation for early-stage AI founders: go vertical, then expand horizontally after you've established a dominant position in the first vertical.
Workflow replacement means the AI product replaces a human workflow — automating a task that a human previously did. The value proposition is efficiency: fewer FTEs, faster cycle times, lower error rates. Replacement positioning is high-value and high-resistance. High-value because the ROI is quantifiable (X FTEs times Y cost per FTE equals Z annual savings). High-resistance because the people whose work is being replaced often have organizational influence and will resist adoption.
Augmentation means the AI product makes an existing human workflow faster, better, or easier — without replacing the human. The human is still in the loop, but the AI handles the heavy lifting. Augmentation positioning is lower-resistance and often faster to deploy, but typically has lower pricing power because the value narrative is softer ("saves time" rather than "eliminates cost").
| Dimension | Workflow Replacement | Workflow Augmentation |
|---|---|---|
| Value clarity | High (quantifiable ROI) | Medium (productivity gain) |
| Sales resistance | High (role threat) | Low (tool adoption) |
| Buyer champion | Finance/Ops sponsor | End user |
| Pricing power | High | Medium |
| Time to close | Longer | Shorter |
| Implementation complexity | High | Medium |
| Churn risk | Low (deep integration) | Medium (easier to swap) |
Most early AI companies I advise start with augmentation positioning and transition to replacement positioning as they develop the reference cases and accuracy data to support it. This is the right sequencing — get the customer using the product, demonstrate accuracy in production, then have the conversation about what the product enables them to do with the FTEs who are now freed up.
AI products have three viable pricing models, and each has specific tradeoffs that are more pronounced for AI than for traditional SaaS.
When it works: Per-seat pricing works when each individual user gets clear, quantifiable value from the product and when usage per user is relatively consistent. An AI writing assistant for sales reps is a reasonable per-seat product — each rep gets value, usage is similar across reps, and the value is tied to the human.
When it fails: Per-seat pricing fails when value is tied to automation rather than to individual human usage. If your AI product processes 10,000 invoices per month and the team that would otherwise have processed them is now down from 5 people to 2, per-seat pricing gives you a declining revenue curve as you deliver more value — which is structurally broken.
AI-specific caveat: Per-seat pricing for AI products risks under-capturing expansion revenue. If the customer gets 3x more value from the product in month 12 than in month 1 (as the model learns their data and the team becomes more productive), but you charge the same per-seat fee, you have missed the expansion opportunity. Usage-based pricing captures this; per-seat does not.
When it works: Usage-based pricing works when value delivered correlates closely with volume of AI processing — API calls, documents processed, queries answered, predictions generated. It aligns incentives between the vendor and the customer: the customer only pays when they are getting value, and revenue scales naturally with customer success.
When it fails: Usage-based pricing creates revenue unpredictability that is particularly acute for AI products because usage patterns are often spiky (customers process batches, not steady streams). It also creates "value anxiety" — customers hesitate to use the product more because they can see the cost counter ticking up. This actively undermines adoption in the early usage phase when you need customers to build the habit.
The mitigation: The best usage-based AI pricing I've seen uses a hybrid model — a platform fee that provides a committed usage base (removing value anxiety for normal usage) plus usage fees above the committed tier (capturing expansion). Vercel's model is the template here: a base commitment with burst pricing above it.
When it works: Outcome-based pricing — where you charge a percentage of the value the AI delivers — is the most powerful alignment mechanism available to AI founders. If your product identifies $500,000 in fraudulent claims per month, charging $25,000/month (5% of value) is a compelling proposition with obvious ROI. Outcome-based pricing requires a measurable outcome that both the vendor and the customer agree on in advance.
When it fails: Outcome-based pricing is extremely hard to operationalize if the outcome measurement is complex, contested, or cannot be instrumented within your product. If you are charging 2% of revenue lift attributable to your product, you immediately face an attribution problem: what portion of the revenue lift is the product versus the sales team versus the market tailwind? These disputes are expensive and they damage customer relationships.
| Pricing Model | Best For | AI-Specific Advantage | AI-Specific Risk |
|---|---|---|---|
| Per-seat | Individual productivity tools | Simple, predictable | Doesn't capture value of automation |
| Usage-based | API, batch processing, consumption | Scales with value delivery | Revenue spikiness; value anxiety |
| Outcome-based | Clear ROI use cases | Maximum value capture | Attribution complexity; measurement disputes |
| Hybrid (base + usage) | Most enterprise AI workflows | Removes value anxiety; captures expansion | Complexity in contracts |
My recommendation for most early AI GTM: start with a simple usage-based model with a minimum commitment floor. The minimum commitment removes the vendor revenue risk from usage variability, the usage-based component creates natural expansion revenue, and the simplicity keeps early sales cycles short.
There are three viable sales motions for AI products: product-led growth (PLG), self-serve with sales assistance, and sales-led. The right choice depends on your ICP, your product's value clarity, and your technical buyer profile.
| Factor | Favors PLG | Favors Self-Serve + Sales Assist | Favors Sales-Led |
|---|---|---|---|
| ACV | < $5,000 | $5,000 - $50,000 | > $50,000 |
| Time to value | < 15 minutes | Hours to days | Days to weeks (pilot required) |
| Buyer type | Individual / developer | Team lead / manager | VP/Director or above |
| Integration complexity | Low (no IT required) | Medium (IT awareness) | High (IT approval + security review) |
| Output sensitivity | Low (low-stakes outputs) | Medium | High (regulated outputs, consequential decisions) |
| Data requirements | No customer data needed | Bring your own data | Deep data integration |
| Competitive intensity | Commodity-like | Differentiated | Domain-specific moat |
PLG works for AI products when the value is demonstrable without a sales conversation, the product works without customer data (or can achieve first value with minimal setup), and the output stakes are low enough that users are comfortable trying without formal evaluation.
Cursor is the canonical example. A developer can download it, use it on their existing codebase, and see meaningful value within 20 minutes. No IT approval, no data migration, no configuration. The output stakes are moderate (the developer reviews AI suggestions before accepting them). PLG works.
Where PLG fails for AI: when the product requires integration with customer data systems (which requires IT approval), when the output has regulatory or legal implications that require formal vendor evaluation, or when the product's value only becomes clear over weeks of production usage rather than in a single session.
For enterprise AI products with ACV above $50,000, the sales motion should be structured around a supervised pilot with defined success criteria established at the start of the sales cycle. The stages:
The pilot-first motion is slower than traditional SaaS sales but has dramatically higher close rates on qualified opportunities — because by the time you reach the commercial close stage, the customer has already seen the product work on their data, in their environment, against their specific use cases.
Design partners are not customers. They are co-development relationships — organizations that give you access to their data, their domain experts, and their production environment in exchange for early access, significant input into the product roadmap, and typically a deep discount or free access.
I've run this process twice as a founder and advised it dozens of times as an investor. Here is the playbook that consistently works.
Before you recruit a single design partner, write down the three to five most important product decisions you cannot make without external validation. For an AI product, these typically include:
Your design partner program is a research program, not a sales program. Treat it as such.
The best design partners are not your five closest friends with startups. They are people who have the exact problem you are solving, have enough sophistication to evaluate AI output quality, and have enough organizational influence to implement feedback effectively.
Where to find them:
The design partner pitch is not a sales pitch. It is a research collaboration pitch. The framing:
"We're building [product] for [ICP], and we're in the phase where we need to work intensively with two or three [target companies] to make sure we're solving the right problem in the right way. In exchange for your time and domain expertise, you'll get [free access / deep discount / significant roadmap influence]. I'm not asking you to buy anything — I'm asking if you'd be interested in shaping the product."
This framing works because it is accurate, it is respectful of the buyer's time, and it appeals to the ego of domain experts who genuinely want to influence product direction.
Not everyone who says yes is a good design partner. Use this filter:
| Criterion | Minimum Bar | Ideal |
|---|---|---|
| Domain fit | Has the exact use case you are targeting | Has the use case AND is considered a sophisticated practitioner |
| Data availability | Has data that matches your model's requirements | Has well-organized, clean data in the right format |
| Internal champion | One person is committed to running the engagement | A VP or Director with organizational authority is the champion |
| Feedback quality | Willing to provide specific, critical feedback | Has experience evaluating AI/ML systems and knows what good looks like |
| Reference potential | Willing to be a reference after success | Willing to be a public case study |
| Competitive profile | Not already committed to a competitor | Has evaluated alternatives and selected you on merit |
Set expectations in writing before the engagement starts:
Design partner engagements that lack written structure almost always drift into non-engagement. The customer deprioritizes it when they get busy. You end up with access to no data and no feedback.
The best design partner I've ever had was a company that had a full-time person assigned to the engagement. They provided weekly feedback on model outputs, flagged every error with context, and held biweekly working sessions with their domain experts. That one design partner produced more product insight than the next four combined.
The channel landscape for AI products has shifted substantially in the last two years. Here is what I've seen work consistently versus what sounds good in theory but underperforms.
For B2B AI products, distribution through integrations with existing tools in your buyer's workflow is the highest-leverage channel available. If your buyers already use Salesforce, Notion, Slack, or Zapier, building an integration that surfaces your AI capability inside those tools means you appear at the moment of need — without requiring the buyer to change context.
Integration channel GTM requires:
I've seen AI companies get 30-40% of their signups from integration channel partners at mature stages. The integration is the acquisition channel, the retention mechanic, and the switching cost all in one.
The buyers of AI products are increasingly active in practitioner communities — Slack workspaces for ops leaders, Discord servers for developers, LinkedIn communities for finance professionals. Publishing deeply specific, technically honest content about AI in these communities builds credibility faster than any other channel.
The content that works is not product marketing. It is genuine practitioner insight: specific accuracy benchmarks on real tasks, honest comparisons of different model approaches, use cases you've seen fail and why, metrics from production deployments. This content builds trust precisely because it demonstrates the kind of technical honesty that buyers are trying to assess in their vendor evaluation.
This is not a channel in the marketing sense, but it is the most important GTM motion for the first 12-18 months. The founder closes the first 10-20 customers personally. This is not because the founder is better at sales than a sales team — it is because the founder needs the feedback that comes from direct customer conversations to continue improving the product and the positioning.
Founders who delegate early sales often end up with a product that has been optimized for closing deals rather than for delivering value — and this creates churn problems at 6-12 months.
Paid search and paid social work for AI products at scale, but almost never at early stage. The problem is that the keywords with commercial intent for AI products are dominated by large, well-funded players who can sustain CPCs that are economically unviable for an early-stage company. You will spend $50,000 testing paid acquisition and get 20 trials, none of which convert, because your product has not yet proven it can convert traffic into revenue.
Save paid acquisition for after you have proven conversion rates through organic channels and direct outreach.
Sites that compare AI tools attract buyers in the early research phase who are far from a purchase decision. The conversion rates from AI comparison review sites are consistently below 1% for B2B AI products. The time investment in maintaining profiles and generating reviews on these platforms is rarely justified relative to the return.
| Channel | Early-Stage ROI | Scale-Stage ROI | AI-Specific Notes |
|---|---|---|---|
| Founder-led outbound | Very High | Low | Critical for first 10-20 customers |
| Integration partnerships | High | Very High | Build this early; compounds over time |
| Practitioner communities | High | High | Requires authentic, non-promotional content |
| Content/SEO | Medium (slow) | High | Long-term asset; 6-12 month lead time |
| Product-led (if applicable) | High | Very High | Requires low setup friction |
| Paid acquisition | Low | Medium | Validate conversion before scaling |
| AI comparison sites | Low | Low | Low-intent traffic |
I've seen these patterns enough times to call them patterns.
The AI demo is seductive because AI products are genuinely impressive when the input is curated and the task is straightforward. It is easy to build a 20-minute demo that makes everyone in the room believe the product is ready for production. It is harder to build a product that performs reliably on the customer's actual data distribution.
Founders who over-rely on the demo win early sales conversations and lose early production pilots. The fix is to include realistic failure cases in every demo, to set explicit accuracy expectations before pilots begin, and to design pilots with clear success criteria that the demo performance is validated against.
Trust signals for AI products are the category equivalent of references and case studies for traditional SaaS — but they require more specificity. A case study that says "Company X reduced errors by 60%" is fine. A case study that says "Company X, which processes 15,000 insurance claims per month in the P&C segment with an average claim value of $8,500, reduced erroneous denial rates from 7.2% to 2.9% using our model over a 12-week supervised pilot" is a trust signal.
The specificity is what builds credibility. Buyers know that vague outcome claims can be fabricated or misattributed. Specific operational metrics from named companies are much harder to fake and much more persuasive.
I have already touched on this, but it is worth reiterating because it is the most common pricing error I see. AI founders who know their infrastructure costs price their products based on a margin above those costs. This is irrelevant to the buyer. The buyer does not care what your inference costs are. The buyer cares about what value the product delivers relative to the price charged.
Every enterprise AI deal has a potential anti-champion — a person in the buying organization who has reasons to block adoption. This is typically the person whose role is most directly affected by the AI product (the manager of the team that will use it, the compliance officer who has to approve AI outputs, the IT security team that has to evaluate data handling). Ignoring anti-champions is the single most common reason enterprise AI deals die after successful pilots.
Many AI founders see PLG as the endgame and rush to build self-serve infrastructure before they have figured out why enterprise customers convert. Self-serve requires you to understand what motivates conversion well enough to encode it into a frictionless onboarding flow. That understanding comes from doing manual, high-touch sales first, observing why customers buy, and then systematically removing the friction from that process.
This is the framework I give every AI founder who is starting GTM from scratch. It is not a marketing plan — it is a structured learning plan with commercial outputs.
The goal of the first 30 days is not to close deals. It is to validate that your ICP definition is correct and to generate enough demand signal to fill a 30-person prospect pipeline.
Activities:
Output: A scored list of 30 prospects, 5 design partner candidates, and a revised ICP definition based on what you learned
The goal of days 31-60 is to launch 3 design partner engagements and validate your positioning messaging against real buyers.
Activities:
Output: 3 active design partner engagements, a positioning scorecard based on message testing results, and a community presence in one practitioner channel
The goal of days 61-90 is to convert design partner success into first paying customers and validate at least one scalable demand channel.
Activities:
Output: 2+ paying customers, 1 published case study, 1 integration partner conversation in progress, a channel attribution model in place
| Metric | Day 30 Target | Day 60 Target | Day 90 Target |
|---|---|---|---|
| Discovery calls completed | 20 | 35 | 50 |
| Qualified prospects in pipeline | 15 | 25 | 40 |
| Active design partners | 0 | 3 | 3 |
| Paying customers | 0 | 0 | 2-3 |
| Published case studies | 0 | 0 | 1 |
| Community content pieces published | 2 | 5 | 8 |
| Integration partner conversations started | 0 | 1 | 2 |
The 90-day sprint is designed to be run by the founders, not by a hired marketing or sales team. The signal generated in these 90 days — who buys, why they buy, what objections come up, what the aha moment is — is the foundation everything else is built on. Delegate this work too early and you build a GTM motion on assumptions instead of evidence.
The right pilot length is determined by how long it takes to accumulate a statistically meaningful sample of outputs in the customer's specific use case. For high-volume, lower-stakes use cases (e.g., content generation, data enrichment), a 2-4 week pilot with 500+ outputs is usually sufficient. For lower-volume, higher-stakes use cases (e.g., medical coding, financial analysis), pilots of 60-90 days with 100-200 outputs per type are more appropriate. The key principle: the pilot length should be defined by the output volume needed to validate accuracy, not by an arbitrary time period.
Yes, always. Free pilots attract low-commitment organizations that will not invest the internal time to make the pilot succeed. A paid pilot (even at a significant discount) forces the customer to assign resources, create internal accountability for results, and treat the engagement seriously. I recommend charging at least 20-30% of the expected first-year contract value for a pilot. If a prospect refuses to pay anything for a pilot, that is a strong signal they are not a serious buyer.
This objection is actually a positioning failure — it means you have not differentiated your product from using the underlying model directly. The correct response is not to argue against ChatGPT but to show specifically what your product does that the raw API cannot: domain-specific fine-tuning, validated accuracy benchmarks on the customer's use case, integration with their existing workflows, audit trails for compliance, error handling for production use, and ongoing model maintenance. If your product does not have clear differentiators on these dimensions, the objection is correct.
When you have closed at least 5-10 customers using a repeatable process — meaning you can write down, step by step, what you did to close each deal, and the steps are similar. The first salesperson's job is to execute the repeatable process you have developed, not to discover what the process is. If you hire before the process is repeatable, you will spend 6 months and $150,000 watching a confused salesperson fail to close deals because the product, positioning, and sales motion are still being figured out.
Analyst coverage matters significantly in enterprise AI sales with ACV above $100,000, where enterprise buyers often use analyst reports as part of their vendor shortlisting process. For SMB and mid-market AI products, analyst coverage is largely irrelevant — buyers in those segments make decisions based on peers, community recommendations, and their own product trials. For early-stage AI companies, analyst briefings are worth doing because they inform the analysts' market maps and quadrant research, but paying for Gartner advisory relationships before you have $5M+ ARR is rarely justified.
The right first GTM hire for a technical founder is not a VP of Sales — it is a customer success and solutions engineering hybrid who can manage design partner relationships, translate technical capabilities into business outcomes, and act as the bridge between the product and the customer. This person typically has a background in consulting, pre-sales, or customer success at an AI or technical SaaS company. They extend the founder's capacity to run high-touch customer relationships without replacing the founder in the sales process — which should remain founder-led until the repeatable process is established.
Value-based pricing discovery: conduct 10 discovery calls focused specifically on the economics of the problem you are solving. Ask prospects: "If this problem were completely solved, what would that be worth to your organization per year?" Ask them to walk you through the calculation. Use the median answer as your reference point, and price at 10-30% of that value (depending on how complete your solution is). This approach consistently produces pricing that is 2-5x higher than cost-plus pricing and dramatically improves unit economics.
A practitioner's framework for positioning AI products — the 4 traps to avoid, April Dunford applied to AI, messaging hierarchy, and how to test and iterate.
Comparative framework for the 5 core growth channels — CAC, ceiling, and founder-fit scoring — and a channel sequencing playbook built for AI products.
A practitioner's playbook on PLG for AI products — cold start problem, aha moment engineering, onboarding design, team-led growth, PLG metrics, and a 12-week readiness audit.