Our AI infrastructure demo was going perfectly.
The ML engineer was impressed. She loved our model training optimization, our GPU utilization efficiency, our support for cutting-edge frameworks.
Then the IT director joined the call.
He asked about enterprise security controls, compliance certifications, and vendor SLAs.
The ML engineer interrupted: "Those things slow down iteration speed. We need infrastructure that lets us move fast and experiment."
The IT director shot back: "We can't deploy infrastructure that doesn't meet our governance requirements. Security and compliance aren't negotiable."
The meeting ended with them arguing about priorities. We didn't get the deal.
That was my introduction to the fundamental problem in AI infrastructure GTM: you're selling to two completely different buyer personas with opposing priorities, and both have veto power.
ML engineers want speed, flexibility, and cutting-edge capabilities. IT/platform teams want security, stability, and governance.
Build for ML engineers and IT won't approve. Build for IT and ML engineers won't adopt.
After losing 12 deals to this buyer conflict, we rebuilt our GTM as two parallel motions—one for each persona—that converge in a way both buyers can accept.
Here's what we learned selling AI infrastructure to organizations where technical and business buyers have fundamentally different goals.
Why One GTM Motion Fails in AI Infrastructure
Traditional enterprise software has clear buyer hierarchies. You sell to procurement, they evaluate options, IT implements, users adopt.
AI infrastructure breaks this model because ML engineers have technical autonomy that typical end-users don't have.
An ML engineer can:
- Spin up cloud infrastructure independently
- Choose frameworks and tools without IT approval
- Deploy models to production in their own environments
- Bypass IT purchasing processes with departmental budgets
This means ML engineers act as both users and buyers. But they still need IT approval for enterprise deployment.
The result: two buyer journeys happening simultaneously:
Bottom-up ML engineer journey:
- Engineer tries your product independently (free tier, open source)
- Engineer validates technical fit
- Engineer champions your product internally
- Engineer needs IT approval for enterprise deployment
- Deal stalls because IT has different requirements
Top-down IT buyer journey:
- IT evaluates AI infrastructure options systematically
- IT prioritizes governance, security, compliance
- IT selects vendor that meets enterprise requirements
- IT pushes solution to ML teams
- ML engineers refuse to adopt because it doesn't meet their technical needs
Both journeys fail because the personas aren't aligned.
We tried to build one product and one GTM that served both personas. It satisfied neither.
Then we split into two parallel GTM motions with a convergence strategy.
The ML Engineer Motion: Developer-Led, Technically Deep
ML engineers don't want sales presentations. They want to validate technical capabilities themselves.
Our ML engineer GTM motion:
Entry: Open source / free tier
We open-sourced our core training optimization libraries and offered free tier for individual experimentation.
ML engineers discovered us through:
- GitHub trending repos
- Technical papers on arXiv
- Discussions on ML Twitter and forums
- Conference presentations showing benchmark performance
No sales involvement. Pure technical discovery.
Evaluation: Technical documentation and benchmarks
ML engineers evaluated us by:
- Reading our technical docs
- Running benchmarks against alternatives
- Testing on their own models
- Reviewing our code (open source)
We provided:
- Comprehensive API documentation
- Performance benchmarks (training speed, GPU utilization, cost efficiency)
- Example notebooks demonstrating common use cases
- Open-source libraries they could fork and modify
This self-serve evaluation mimicked developer tool GTM, not enterprise sales.
Adoption: Individual/team usage
ML engineers adopted our platform for their own projects without talking to sales.
They used our free tier or paid for individual/team accounts with credit cards. No procurement process, no contracts, no IT involvement.
At this stage, we generated low revenue but high usage. Engineers were building dependency on our platform.
Expansion: Enterprise need emerges
Once ML engineers were using our platform successfully, they hit limits:
- Free tier constraints (compute limits, storage caps)
- Need for team collaboration features
- Security/compliance requirements for production deployment
- Budget exhaustion on individual accounts
This created the trigger for enterprise conversation: "We love your platform and want to deploy it across our ML teams. But we need enterprise features and IT needs to approve."
This bottom-up motion generated champions who could advocate internally. But we still needed IT buy-in.
The IT/Platform Team Motion: Enterprise-First, Governance-Focused
IT buyers don't discover tools on GitHub. They evaluate vendors through formal processes.
Our IT buyer GTM motion:
Entry: Enterprise outbound or RFP response
IT teams found us through:
- Direct enterprise sales outreach
- Responding to formal RFPs for AI infrastructure
- Analyst reports (Gartner, Forrester)
- References from other enterprise IT organizations
Sales-led motion, not developer-led.
Evaluation: Governance and compliance validation
IT teams evaluated us on:
- Security certifications (SOC 2, ISO 27001, FedRAMP)
- Compliance capabilities (GDPR, HIPAA, industry-specific regulations)
- Enterprise features (SSO, RBAC, audit logs, SLAs)
- Vendor stability and support
We provided:
- Security documentation and compliance attestations
- Enterprise architecture diagrams
- Detailed SLA commitments
- Vendor financial stability information
This evaluation focused on risk mitigation, not technical performance.
Procurement: Formal buying process
IT teams bought through:
- Formal vendor evaluation
- Legal contract review
- Security and compliance assessment
- Multi-stakeholder approval (IT, security, legal, finance)
This took 6-12 months from initial contact to closed deal.
Deployment: Top-down rollout challenge
Here's where top-down motion failed: even after IT bought our platform, ML engineers resisted adoption if they hadn't validated technical fit themselves.
IT would mandate our platform. ML engineers would continue using their preferred tools.
We had contracts but not usage. Revenue but not adoption.
The solution: converge bottom-up and top-down motions.
The Convergence Strategy That Works
Neither bottom-up nor top-down alone drives successful enterprise AI infrastructure adoption.
You need both:
- Bottom-up to generate ML engineer champions and validate technical fit
- Top-down to secure enterprise budget and meet governance requirements
Our convergence strategy:
Scenario 1: Bottom-up → Top-down
ML engineers adopt individually → hit enterprise needs → champion internally → we help them build IT business case → IT approves → enterprise deployment.
Our role:
- Provide ML engineers with usage data showing value (cost savings, speed improvements)
- Create executive briefing materials ML engineers can share with IT
- Offer to present to IT directly to address governance concerns
- Structure pricing that makes enterprise tier attractive vs. continued individual usage
Scenario 2: Top-down → Bottom-up
IT evaluates enterprise AI infrastructure → we win based on governance/compliance → IT wants ML engineer validation before purchase → we facilitate technical pilot → ML engineers validate → purchase approved.
Our role:
- During IT evaluation, insist on ML engineer technical validation pilot
- Provide ML engineers with free access to validate while IT evaluates governance
- Ensure ML engineers have positive experience to endorse to IT
- Position as "enterprise-grade infrastructure that ML engineers actually want to use"
Scenario 3: Parallel convergence
ML engineers adopt bottom-up while IT separately evaluates top-down → both validate independently → we connect them → aligned purchase decision.
Our role:
- Track when ML engineers at the same company as IT evaluations
- Connect internal stakeholders when both are engaged
- Facilitate alignment conversation between technical and business requirements
- Structure deal that satisfies both personas
This convergence approach required sophisticated account management:
We tracked every organization where we had either ML engineer usage OR IT evaluation and worked to create the other motion.
If ML engineers from Company X were using our platform, we'd proactively reach out to their IT/platform team to discuss enterprise deployment.
If IT from Company X was evaluating us, we'd check if any ML engineers from Company X were already using our platform and connect them.
For teams managing dual buyer journeys in technical infrastructure markets, platforms like Segment8 offer multi-persona engagement frameworks that help coordinate bottom-up and top-down GTM motions for convergence.
The Product Strategy: Two Tiers, One Platform
To support both GTM motions, we built two product tiers:
Developer Tier:
- Free or low-cost individual/team accounts
- Full technical capabilities ML engineers need
- Self-service signup and usage
- Minimal governance features (engineers don't care)
- No enterprise support or SLAs
Enterprise Tier:
- Higher pricing with enterprise contract
- Same technical capabilities as Developer tier (critical!)
- Full governance features (SSO, RBAC, audit logging, compliance controls)
- Enterprise support and SLAs
- Professional services for deployment and training
The key insight: Enterprise tier must have same technical capabilities as Developer tier.
If we'd built "simplified enterprise version" with governance but reduced technical capabilities, ML engineers would refuse to adopt.
Engineers validated our platform on Developer tier, then insisted on same technical experience in Enterprise tier. IT approved Enterprise tier based on governance features.
Both personas got what they needed: ML engineers got technical capabilities, IT got governance.
The Messaging Split That Aligned Each Persona
We tried to create "one message" that appealed to both ML engineers and IT buyers.
It satisfied neither.
We rebuilt with persona-specific messaging:
For ML engineers:
Problem: "Training large models is slow and expensive. You're waiting days for experiments and burning GPU budget."
Solution: "Our infrastructure optimizes model training, cutting training time 40% and GPU costs 50%. Deploy in 10 minutes, works with your existing frameworks."
Proof: Technical benchmarks showing performance, GitHub repo they can inspect, examples from their preferred frameworks.
CTA: "Try free tier now" (self-service signup)
For IT/platform teams:
Problem: "ML teams are deploying AI infrastructure without governance, creating security and compliance risks."
Solution: "Enterprise AI infrastructure with security, compliance, and governance controls that ML teams will actually adopt."
Proof: Enterprise customer logos, security certifications, compliance documentation, case studies showing successful enterprise deployments.
CTA: "Request enterprise demo" (sales-led conversation)
Same product. Completely different messaging and positioning.
ML engineer messaging emphasized speed, performance, technical capabilities.
IT messaging emphasized governance, security, risk mitigation.
We ran separate marketing campaigns, separate content, separate landing pages for each persona.
When visitors hit our website, we asked "Are you an ML engineer or IT/platform team?" and routed them to persona-specific journeys.
The Sales Team Structure That Supports Dual Motions
Traditional enterprise sales: one sales team selling to IT/procurement.
Our AI infrastructure sales required two teams:
Developer Relations / Community Team:
Focused on ML engineer motion. Not traditional sales—developer advocates who:
- Engaged on GitHub, Twitter, ML forums
- Created technical content and benchmarks
- Spoke at ML conferences and meetups
- Ran workshops and training for ML engineers
- Responded to technical questions in community channels
Goal: Drive ML engineer adoption and create internal champions.
Compensation: Not tied to revenue (engineers weren't signing contracts). Tied to usage metrics (active users, model training volume, community growth).
Enterprise Sales Team:
Focused on IT buyer motion. Traditional enterprise sales reps who:
- Conducted outbound to IT/platform leaders
- Responded to RFPs
- Ran formal vendor evaluations
- Negotiated enterprise contracts
- Coordinated legal, security, procurement processes
Goal: Convert ML engineer champions or IT interest into enterprise contracts.
Compensation: Traditional sales commission on closed revenue.
Coordination between teams:
DevRel and Enterprise Sales had to collaborate closely:
When DevRel saw ML engineer usage at a target account, they'd alert Enterprise Sales to begin IT outreach.
When Enterprise Sales engaged IT, they'd alert DevRel to ensure ML engineers had positive experience.
Both teams shared account intelligence and coordinated on opportunities.
This required cultural alignment: DevRel couldn't feel "owned" by sales (engineers would sense it and disengage), and Enterprise Sales had to respect that DevRel was building long-term community relationships, not generating immediate pipeline.
The Pricing Model That Works for Both Personas
ML engineers expect: self-service, pay-as-you-go, transparent pricing, credit card payment.
IT expects: enterprise contracts, volume discounts, annual commitments, negotiated terms.
We built hybrid pricing:
Developer Tier pricing:
- Free tier: Limited compute (up to $X monthly usage)
- Individual tier: $X per hour of GPU usage, pay-as-you-go
- Team tier: $X per user per month + usage fees
- Self-service credit card payment
- Transparent, publicly posted pricing
Enterprise Tier pricing:
- Annual contract: $X based on committed usage volume
- Volume discounts for larger commitments
- Custom negotiated terms
- Invoice-based payment (PO process)
- Includes support and professional services
Conversion path: Engineers using Developer tier who hit usage limits got automatic prompts to consider Enterprise tier with volume discounts.
We'd show: "You're spending $15K/month on Individual tier. Enterprise tier would cost $10K/month for your usage level and include dedicated support."
This made the upgrade economically obvious while maintaining self-service simplicity at lower tiers.
What Worked: The Metrics That Matter for Each Motion
We tracked different success metrics for each GTM motion:
ML Engineer Motion metrics:
- Free tier signups per month
- Active users (training jobs per week)
- GitHub stars and community engagement
- Developer NPS
- Time to first successful model training
IT Buyer Motion metrics:
- Enterprise pipeline value
- Security evaluation pass rate
- Contract size and term length
- Time to close (from first IT contact)
- Enterprise customer logos
Convergence metrics (most important):
- Accounts with both ML engineer usage AND IT engagement
- ML engineer → Enterprise conversion rate
- Time from first ML engineer usage to enterprise contract
- Expansion revenue from Developer → Enterprise upgrades
The convergence metrics told us whether our dual-motion strategy was working.
If we had ML engineer usage but no enterprise conversions, our bottom-up motion was generating activity but not revenue.
If we had enterprise contracts but no ML engineer adoption, our top-down motion was generating bookings but not value.
Success required both motions working together.
The Uncomfortable Truth About AI Infrastructure GTM
AI infrastructure is one of the hardest GTM motions in B2B because you're serving two personas with fundamentally different priorities:
ML engineers want:
- Cutting-edge technical capabilities
- Fast iteration and experimentation
- Minimal governance overhead
- Self-service access
- Performance and cost optimization
IT buyers want:
- Security and compliance
- Governance and control
- Vendor stability and support
- Risk mitigation
- Enterprise features
You can't satisfy one without alienating the other if you try to build "one product" or "one GTM motion."
The successful approach requires accepting the complexity:
What doesn't work:
- Single GTM motion trying to serve both personas
- Prioritizing one persona over the other
- Enterprise-only approach (ML engineers won't adopt)
- Developer-only approach (IT won't approve)
- One pricing model for both segments
What works:
- Dual GTM motions (bottom-up for ML engineers, top-down for IT)
- Convergence strategy connecting both motions
- Product tiers with same technical capabilities but different governance
- Persona-specific messaging and marketing
- Two sales teams (DevRel for engineers, Enterprise for IT)
- Hybrid pricing (self-serve for developers, contracts for enterprise)
Our results after implementing dual-motion strategy:
Bottom-up motion:
- 15,000 ML engineers using free/individual tiers
- 2,500 active training jobs per week
- Strong community engagement and technical validation
Top-down motion:
- $4.2M enterprise ARR
- 35 enterprise customers
- Average contract size: $120K annually
Convergence:
- 80% of enterprise deals had prior ML engineer usage at the account
- 12% of high-usage ML engineer accounts converted to enterprise
- 6-month average timeline from first ML engineer usage to enterprise contract
The dual-motion strategy is operationally complex and expensive. We run two parallel teams, two marketing programs, two product tiers.
But it's the only approach that generates both ML engineer adoption AND enterprise revenue in AI infrastructure.
Single-motion strategies leave money on the table by serving only one persona and hoping to convince the other. Dual-motion strategies serve both intentionally and create convergence paths.
The companies winning in AI infrastructure are the ones willing to embrace this complexity instead of oversimplifying into one buyer journey.