Tag: forward deployed engineers

Old-School Selling Beats PLG in the AI Era: My GTM Playbook for 8‑Day Enterprise Deals

Old-school, in-person selling is having a renaissance in the AI era, and I’ve seen why up close. From leading product and go-to-market teams through hypergrowth, I keep returning to one lesson: enterprise buyers still reward the teams who show up, orchestrate change management, and own outcomes end-to-end. The tech has changed; the human dynamics haven’t.
Has the sales playbook changed in the AI era? The tools are faster and the surface area is bigger, but the core motion remains the same: “showing up” beats letting the marketplace decide. That’s why in-person enterprise rollouts still beat product-led motions, especially when the stakes include security, governance, and cross-functional adoption. You win by reducing organizational risk, not by assuming free trials will do the heavy lifting.
Great enterprise sellers collapse silos. They sell to engineers and executives in one motion, pairing deeply technical validation with crisp business narratives. In my org, that means every high-velocity pilot has a dual thread: hands-on, eval-driven proof for the builders and a value architecture for the budget owners. When those motions run in parallel, time-to-value plummets and procurement friction fades.
Selling to AI-native buyers who grew up on ChatGPT changes tempo, not fundamentals. The same seller, different tempo: 8 weeks vs. 8 business days. These buyers evaluate fast, expect clear ROI, and push for automation-first workflows. How AI-native buyers handle build vs. buy decisions comes down to build for differentiation and buy for acceleration. If you make procurement feel like product—frictionless, instrumented, and transparent—you’ll meet their bar.
Process matters, but humanity wins. Building a robust sales process that still leaves room for unscripted moments is where trust is formed. I’ll never forget the story of the rep who taught a champion’s son guitar over Zoom—an unscripted moment that cemented a partnership. The lesson: raise the floor without capping the ceiling. Equip every rep with repeatable plays, then celebrate the creative instincts that make champions out of customers.
In early GTM, why the three highest-leverage early sales hires aren’t sellers at all resonates with my experience. I prioritize a solutions engineer who can de-risk integration, a forward-deployed operator who can run the first rollout like a product manager, and a customer success lead who designs adoption paths from day zero. Together, they compress the value journey from proof to production.
Compensation design shapes your talent market. The case for outsized commission accelerators for star sellers — and the kind of person they attract is real: magnets for competitors who close complex, multi-threaded deals and thrive with ownership. But beware: why too much process narrows the kind of seller you attract. Over-script it and you filter out the very people who can navigate ambiguity with customers.
Under the hood, instrumenting the funnel from stage zero to close keeps the system honest. I track intent signals before pipeline, conversion by persona and use case, proof milestones, and time-to-value in production. The three pillars of GTM excellence for me are repeatable discovery, referenceable outcomes, and relentless enablement. And inside the leadership team, building peers who are 80% aligned, not 100% preserves healthy tension while keeping execution fast.
AI is expanding the definition of enablement—whether AI is changing what good enablement looks like isn’t a theoretical question anymore. I see world-class teams arming reps with retrieval-first knowledge bases, sandbox environments, and objection libraries that evolve weekly. Meanwhile, selling against direct and implied competitors at once is the norm: your battlecard must cover “do nothing,” internal tools, adjacent categories, and new AI entrants—while you still remember why in-person enterprise rollouts still beat product-led motions for durable adoption.
Planning horizons tighten in AI markets. How far out should a GTM leader be planning? I work a dual cadence: a rolling 6-week operating plan that’s ruthlessly tactical and a 2–3 quarter roadmap for coverage, enablement, and category storytelling. What a normal week looks like in hypergrowth blends customer time, pipeline triage, onboarding and enablement, deal engineering, and process tuning—always with one or two high-conviction bets that could bend the curve.
References: Ahead: https://www.ahead.com; Amazon: https://www.amazon.com; Anthropic: https://www.anthropic.com; Attio: https://www.attio.com; Augment Code: https://www.augmentcode.com/; Cognition: https://cognition.ai; Cursor: https://cursor.com; Dani McCabe: https://www.linkedin.com/in/danielle-mccabe/; Datadog: https://www.datadoghq.com; GitHub Copilot: https://github.com/features/copilot; HubSpot: https://www.hubspot.com; Jeremy Powers: https://www.linkedin.com/in/jeremypowers/; JPMorgan: https://www.jpmorgan.com; Matt McClernan: https://www.linkedin.com/in/mattmcclernan/; MongoDB: https://www.mongodb.com; Nicole Rettinger: https://www.linkedin.com/in/nicole-rettinger-23b20465/; Notion: https://www.notion.com; OpenAI: https://openai.com; Parag Agrawal: https://www.linkedin.com/in/paragagr/; Parallel: https://parallel.ai; Snowflake: https://www.snowflake.com; University of Chicago: https://www.uchicago.edu; Windsurf: https://windsurf.com
If you’re scaling an AI product today, pair a disciplined sales-led growth engine with the best of product-led growth: fast paths to proof, hands-on validation for builders, executive-level value mapping, and human moments that turn customers into advocates. That’s how you compress an eight-week cycle into five business days—and keep the expansion flywheel spinning.

May 21, 2026
From FinOps to Customer FDEs: How AI Agents and Platforms Unlock Smarter Cloud Spend

I see the rise of Customer Forward Deployed Engineering (FDE) as a pivotal bridge between FinOps engineering, AI strategy, and measurable customer outcomes. When we align internal platforms and agentic AI with real-world use cases, we don’t just reduce cloud costs—we accelerate adoption, de-risk deployments, and create durable product value that compounds over time.

"Hac Phan leads FinOps engineering at Amplitude, where he builds internal platforms and AI agents that help teams understand and optimize cloud spend. He now heads Amplitude's Customer Forward Deployed Engineering team." That evolution—from building internal capabilities to leading a customer-facing FDE function—captures a pattern I’ve seen repeatedly: the skills that tame complexity inside the company are exactly the skills customers need most at the edge.

In my experience, Customer FDEs thrive when they embed with strategic accounts to translate product capabilities into concrete outcomes: lower unit economics, faster time-to-value, and cleaner governance. They partner closely with solutions engineering, product management, and customer success, using platform building blocks and AI workflows to illuminate the cost drivers that matter—then engineering the shortest path to savings and scale.

The operating model is straightforward but disciplined. Set a clear mission (optimize cost-to-value while expanding usage), define a small set of leading indicators (time-to-first-value, cost per active workload, deployment frequency, NRR lift on FDE-supported accounts), and establish crisp handoffs with core product teams. When FDEs surface repeatable patterns, those insights should flow back into the roadmap as native features, guardrails, and in-product guidance—so every customer benefits, not just the lighthouse few.

Tooling matters. Internal platforms that unify telemetry, usage metering, and pricing logic give FDEs the levers to diagnose and fix issues quickly. Layering AI agents on top of that foundation enables proactive recommendations—think unit-economics dashboards, anomaly detection on spend spikes, and automated playbooks that right-size workloads. With agent analytics in place, we can measure the value of each recommendation and continuously tune the system.

I’ve seen this model turn tense, cost-focused conversations into strategic planning sessions. Instead of debating line items, we co-design architectures that scale efficiently, with platform scalability and governance built in from the start. Customers appreciate the candor and the engineering rigor; teams appreciate how those field insights sharpen product strategy.

For leaders considering this path, start small and design for leverage. Stand up a single FDE pod focused on 2–3 high-potential customers. Codify playbooks for cloud cost optimization, instrument agent analytics from day one, and publish a weekly learning loop back to product. Within a quarter, you’ll know which interventions to automate, which to turn into product features, and which require deeper solutions engineering support.

The broader lesson is simple: when we merge FinOps discipline with customer-embedded engineering and AI-driven insights, we create a force multiplier. Customer FDEs don’t just help accounts spend less; they help them achieve more—sustainably, transparently, and with the confidence that comes from a platform (and a team) built to scale.

Inspired by this post on Amplitude – Perspectives.

May 11, 2026
Cracking the Hardest Percentages: Turn Complex Support into Scalable, Trust-Building Automation

I’ve learned that the smallest slice of your support queue often dictates the majority of your operating cost, customer memory, and automation ceiling. In product reviews and CX ops deep-dives, I see the same pattern: the “easy” tickets pad your resolution counts, but the complex, multi-step queries quietly own your handle time and your brand trust. If you care about compounding impact, your customer support AI strategy has to target that hardest percentage first.

Complex queries are a small percentage of your queue, but they consume a disproportionate share of your team’s time.

Take a typical queue: password resets outnumber refund disputes ten to one, but a reset takes five minutes and a dispute takes thirty. The “rare” query accounts for over a third of total handling time. The same pattern holds for account investigations, subscription changes, and billing disputes.

How you handle complex queries is also what customers actually remember about their support experience. When someone is dealing with a damaged order or a billing dispute, the stakes are higher, and a fast, good resolution is what separates a forgettable interaction from one that builds lasting trust.

Most AI Agents automate the easy, informational queries well. The question for your automation rate is whether they can handle the hard ones. That’s where agentic AI and robust AI workflows make or break your outcomes.

We’ve gotten really good at informational queries – the hard part is what comes next. I’ve seen teams invest deeply here, and for good reason: it lifts containment quickly and cheaply. But to break through the plateau, you have to execute actions across systems, not just answer with text.

We’ve invested deeply in informational Q&A. We built Apex, a specialized customer service model trained on billions of support interactions, as Fin’s core answering engine. Beneath that sits a custom retrieval model, a purpose-built reranker, and a unified RAG pipeline, all trained specifically for customer service. Fin resolves issues at a higher rate than general-purpose frontier models, with fewer hallucinations and at lower cost.

But informational Q&A only covers queries where text is the answer. Most Agents can handle that. Far fewer let you configure complex, multi-step actions without a forward-deployed engineer setting it up for you, which creates a gap.

Every query your team handles falls into one of three categories:

Informational: “Can you ship transatlantic by priority next day?” Answered with text from your knowledge base.

Personalized: “Where is my order?” Requires data unique to that user.

Action-led: “My order arrived damaged, I need a refund.” Requires doing something: checking a return window, cross-referencing transaction data, making a judgment call – reading from multiple systems and acting across them.

From Jan to Apr 2026, the trend moves steadily upward, pausing briefly before a sharp late surge. A clear snapshot of momentum for customer service KPIs, finance results, and the impact of new procedures.

These complex queries, the ones that require multi-step processes across systems, aren’t edge cases; they’re the reason your support team exists. This is the gap Fin Procedures was built to close.

It works in practice, and the trajectory matters for product strategy and ops planning.

Procedures is live, it’s scaling, and the results are clear. Since launching in managed availability, Procedures has handled over 1.5 million conversations, and volume is doubling month over month across hundreds of apps in fintech, e-commerce, gaming, healthcare, and SaaS.

When customers hit complex, multi-step queries, the experience is dramatically better when Fin can do the work end-to-end. We tested this with a randomized 5% holdout – conversations where Procedures would normally run, but didn’t. CSAT was 28.93% higher when Procedures ran, a statistically significant result.

A product, not a services engagement. I’ve sat through too many “automation” projects that were really solutions engineering gigs: workshops, custom scripts, then a queue of change requests when policies shift. It’s fragile and slow.

The B2B AI industry has a consultingware problem. It’s not databases being forked anymore, it’s prompts. The economics of maintaining bespoke setups per customer don’t work. Either the application falls behind new models, or the vendor changes the model and quality degrades invisibly.

In my view, an agentic AI platform should be a product your team owns end to end: a natural language editor – literally paste your existing SOPs – branching logic, data connectors, and AI-powered simulations for testing. Your CX ops team configures this, iterates on it, owns it. If you need help, a forward-deployed team can assist, but they’re optional, not a dependency. You always have control.

And because it’s a unified product, improvement compounds. When the vendor optimizes a prompt, every customer’s Procedures get better. When they upgrade the model, they can A/B test across the entire customer base and know it’s better before rolling out. You can’t do that when every customer has a bespoke prompt. The consulting model isn’t just expensive, it’s structurally unable to compound.

Today, Fin Procedures is available to every Intercom customer – no waitlist or managed rollout, ready for all 8,000+ customers.

We’re iterating fast based on real customer feedback. Here’s what’s landed since the last major update, and why it matters for reliability and governance:

AI-powered Procedure review: Flags broken logic, missing references, and unreachable conditions before you deploy.

Kick off your journey with the #1 Agent—an AI partner designed to turn resolutions into real outcomes. Tap “Start a free trial” to explore faster, smarter customer service and see how Fin delivers value from day one.

Procedure failure reporting: A new reporting dimension that lets you drill into conversations where Procedures failed, so you can diagnose and fix.

Version history with rollback: Track every change, compare versions, roll back if needed.

Data connector health monitoring: See at a glance if your integrations are healthy, degraded, or failing.

Optional data connector parameters: Fin only asks customers for information when it’s actually needed, instead of prompting for every field.

Email Simulation support: Test how your Procedures behave across chat and email before going live.

Agent in the Loop (Beta) unlocks the next tranche of automation. Even with Procedures, two things hold teams back from automating their most complex queries: missing integrations and policies that require a human sign-off on sensitive decisions.

“Agent in the Loop” is built for both. Need Fin to check your internal admin tools but haven’t built a data connector yet? Put a human checkpoint at that step. Fin handles the conversation, gathers context, and pauses, surfacing a structured summary for a human agent to verify or act, then resumes. You get automation on the 80% that doesn’t need the integration.

For compliance – identity verification, high-value refunds – Fin does the legwork, a human makes the final call and then hands it back to Fin. This works natively in the Intercom Inbox and via Slack. Some competitors don’t have an inbox-native variant at all, meaning humans need to leave their primary workspace to review AI actions.

Procedures are also built to let you collaborate with all your teammates – both human agents and AI Agents. Fin can work with them directly inside a Procedure, using APIs and webhooks to loop in another teammate mid-flow, hand off context, and pick back up once they’re done.

Making it easier, faster. Procedures is already self-serve, but the next step is making Procedure creation, testing, and maintenance significantly more streamlined and easy to do, with less manual editing and more AI-assisted building and debugging. There’s a lot coming in this space over the next few months – and it aligns perfectly with a retrieval-first pipeline and stronger governance at scale.

The hardest percentages matter the most. The biggest unlock for your automation rate won’t be answering more FAQs, it will be handling the complex, multi-step queries that consume your team’s time and define what customers remember about their experience with you.

That means working with an Agent that goes beyond answering questions and executes processes. A product your team owns and configures, not a service you buy and hope gets maintained. And a platform where every improvement compounds across every customer. That’s Procedures. Available now, for everyone.

Inspired by this post on The Intercom Blog.

April 14, 2026
How Fast Is Fast Enough? Turn Deployment Frequency into a Durable Competitive Advantage

Every product leader I know wrestles with the same question: how fast is fast enough when it comes to shipping? Over the years, I’ve learned that deployment frequency isn’t just a DevOps vanity metric—it’s a direct lever on customer value, risk, and competitive advantage.

When I talk about deployment frequency, I mean how often a team puts code into production, per service or product, in a given time period. It sits alongside lead time for changes, change failure rate, and mean time to recovery (MTTR) as part of the DORA metrics—together, they tell a coherent story about delivery performance and reliability.

If you’re looking for a compass, here’s how I calibrate expectations. Elite teams deploy on demand—often multiple times per day—because they’ve engineered safety into their CI/CD pipeline and decoupled deploy from release. High-performing teams comfortably ship daily to weekly. Medium performers land in the weekly-to-monthly range. These bands aren’t moral judgments; they’re context-aware guideposts. The goal isn’t to copy someone else’s speed, but to reach the fastest sustainable cadence your business, architecture, and risk profile can support.

So what does “fast enough” look like in practice? It depends on your product’s blast radius, regulatory constraints, and architecture. Microservice-heavy platforms with strong automated testing, feature flags, and progressive delivery generally sustain higher cadences with lower risk. Monoliths and highly coupled systems can still move quickly, but they need disciplined trunk-based development, robust test pyramids, and strong release controls to avoid brittle deployments.

At HighLevel, we’ve moved products from a cautious weekly train to safe daily (and eventually on-demand) deploys without increasing incident volume. The breakthrough wasn’t a single tool—it was a system: smaller batch sizes, automated tests that actually fail when they should, immutable artifacts, canary releases, and feature flags that decouple deployment from exposure. The result was faster learning loops, fewer late surprises, and more predictable delivery.

If you’re not measuring deployment frequency yet, start simple. Instrument your CI/CD pipeline or GitOps tooling to count production deployments by service each day. Normalize for rollbacks and re-deploys to avoid inflating the metric. Visualize by team and product area so you can spot bottlenecks and trend improvements over time. Pair it with change failure rate and MTTR to ensure you’re not trading speed for stability.

Once you’ve got a baseline, focus on the levers that actually move the needle. Reduce batch size by merging smaller, well-scoped changes. Embrace trunk-based development to minimize long-lived branches. Accelerate feedback with fast, reliable unit and integration tests, contract testing for services, and ephemeral environments for preview. Use feature flags to control exposure, and progressive delivery (canary, blue-green) to verify in production safely. Automate change approvals where policy allows, and replace heavyweight gates with observable, auditable pipelines.

Watch out for common anti-patterns. Batching several unrelated features into a single deploy increases risk and slows learning. Heroic “release nights” mask systemic issues. Friday deploy bans are a smell; if you can’t safely deploy on Friday, you can’t safely deploy any day—invest in recovery speed and blast-radius controls instead. And never treat deployment frequency as a target in isolation; it’s only healthy when reliability improves or holds steady.

For strategy alignment, I tie deployment goals to outcomes, not outputs. If your objective is time-to-value or activation improvement, a higher cadence of small, measurable changes aligns perfectly. If your objective is stability for a major seasonal event, slow the cadence temporarily and increase release controls. The point is to let business outcomes set the tempo while engineering creates the conditions for safe speed.

Here’s a pragmatic 30-day plan I’ve used with teams: Week 1, baseline deployment frequency and map your current release process end-to-end. Week 2, choose two services and cut batch size in half while enabling feature flags for new code paths. Week 3, refactor the pipeline for faster test feedback and add canary or blue-green for one critical service. Week 4, publish a dashboard that shows deployment frequency alongside change failure rate and MTTR, and run a retrospective to decide the next bottleneck to remove.

Culturally, celebrate small, frequent, reversible changes. Reward teams for boring deploys, rapid recovery, and high-quality instrumentation. Build psychological safety around rollback and kill switches—confidence breeds cadence.

Track deployment frequency, optimize it, and watch delivery speed turn into a competitive edge. Explore how in this article!

Fast enough isn’t a number you copy; it’s a capability you build. When deployment frequency rises in tandem with reliability, you unlock faster learning, happier customers, and a durable advantage in your market.

Inspired by this post on Product School.

November 3, 2025
Go Hard Early: Enterprise AI Lessons That Built Serval’s Magical IT Automation Agents

Go hard early is more than a mantra—it’s a product strategy. When I study the most durable enterprise companies, I see the same pattern: you win by shipping fast, obsessing over the customer’s day-to-day pains, and delivering consumer-quality experiences to business buyers. That lens is exactly why Serval’s recent momentum caught my attention and why the lessons behind it matter for every product and IT leader building in AI.

Jake is the founder and CEO of Serval, an AI-driven IT automation and service management platform that just raised $47M in Series A funding this week. Before founding Serval, Jake spent over five years at Verkada, where he led multiple products from 0-1 and helped scale the company across hardware and software. His years at Verkada taught him that winning in enterprise means delivering consumer-quality experiences to business buyers — a lesson that shapes how Serval turns complex IT automation into something that feels magical.

From my vantage point, the most counterintuitive lesson here is the power of building “in existing categories.” Rather than inventing a new market, the better move can be to redefine expectations inside a known one—where buyers, budgets, and success criteria already exist. That’s how you compress sales cycles, build trust rapidly, and create a wedge for product-led growth without boiling the ocean.

Another playbook thread I admire: turning “hard mode” into a moat. The teams that lean into gnarly integrations, real workflow depth, and enterprise-grade reliability end up compounding an advantage that’s very hard for fast followers to copy. That mindset shows up in Serval’s platform strategy and, more importantly, in how they translate complex IT work into something that feels intuitive on day one and powerful on day 100.

Customer intimacy sits at the center of that strategy. The customer interview question that unlocked the IT buyer’s hidden pain points is the kind of move I try to operationalize across product trios and forward-deployed teams. When you ask not just, “What do you do?” but, “What do you do when everything breaks?” you surface the real constraints: shadow runbooks, brittle scripts, brittle processes, and the political friction that slows down response times. That’s where durable value—and competitive differentiation—lives.

How Serval’s automation builder uses AI to generate code-based workflows is a particularly smart architectural choice. Code-first doesn’t mean hard-to-use; it means source-controlled, interoperable, and shareable across teams—exactly what IT leaders want when automation moves from side project to system of record. Tie that to agentic orchestration and you get reliable automations with clear observability, safety rails, and the ability to scale without collapsing under edge cases.

I’m also a believer in redefining engineering and PM roles with forward-deployed engineers. When engineers partner directly with customers, discovery accelerates, prioritization sharpens, and product bet quality improves. You avoid ping-ponging requirements through layers, and you raise the hiring bar for true product creators who can think in outcomes, not just output.

Keeping the hiring bar high in an AI-native startup isn’t optional—it’s existential. The best teams screen for candidates who can reason from first principles, ship quickly with taste, and articulate the value proposition in plain language. The ultimate hiring litmus test is whether someone can improve the product on day one by clarifying a user journey, simplifying a workflow, or tightening a metric that actually matters.

There’s also Why there’s a “land grab” moment right now in enterprise AI. Incumbents are strong on breadth but often slow to re-architect for AI-native workflows. New entrants that show up with opinionated defaults, pragmatic security, and crisp buyer narratives can establish points of parity quickly while extending into true points of differentiation. That’s the window to seize—especially when building for mid-market and enterprise.

Here are the core themes I took away and how I translate them into practice across product roadmapping and sprint planning, product discovery, and go-to-market strategy.

Why building “in existing categories” can be more powerful than creating new ones. Use the market’s mental models, measure against known alternatives, and win by delivering a meaningfully better experience—not by forcing buyers to invent new procurement paths.

The lessons from Verkada that shaped Serval’s platform strategy. Treat UX polish as a strategic asset, make setup effortless, and let power users go deep without friction. Consumer-grade quality is not a veneer; it’s a trust accelerator in enterprise.

The customer interview question that unlocked the IT buyer’s hidden pain points. Go beyond happy-path discovery. Ask about the 3 a.m. moments, the panic buttons, and the messy handoffs—then design for those first.

How Serval’s automation builder uses AI to generate code-based workflows. Pair AI generation with reviewability, versioning, and safe rollbacks. Make it easy to see, test, and share what the agent is doing under the hood.

Redefining engineering and PM roles with forward-deployed engineers. Collapse feedback loops by putting builders where the problems are. It’s the fastest path to product-market fit lessons and real-world reliability.

Keeping the hiring bar high in an AI-native startup. Look for taste, speed, and ownership. Optimize for people who can both prototype with gen ai and ship production-hardened systems.

Why there’s a “land grab” moment right now in enterprise AI. Move quickly, but anchor on outcomes. Land with a wedge use case, expand with measurable value, and maintain clear points of parity while you deepen differentiation.

If you want to follow or explore the companies and leaders referenced, these links are a useful starting point.

LinkedIn: https://www.linkedin.com/in/jakestauch/

Twitter/X: https://x.com/jakeserval

LinkedIn: https://www.linkedin.com/in/brett-berson-9986094/

Twitter/X: https://twitter.com/brettberson

Website: https://firstround.com/

First Round Review: https://review.firstround.com/

Twitter/X: https://twitter.com/firstround

YouTube: https://www.youtube.com/@FirstRoundCapital

This podcast on all platforms: https://review.firstround.com/podcast

References:

Alex McLeod: https://www.linkedin.com/in/alexmcleodio/

Clay: https://www.clay.com

Cloudflare: https://www.cloudflare.com

Cursor: https://cursor.sh

Filip Kaliszan: https://www.linkedin.com/in/kaliszan/

Hans Robertson: https://www.linkedin.com/in/hansrobertson

Linear: https://linear.app

Okta: https://www.okta.com

Rippling: https://www.rippling.com

Serval: https://www.serval.com/

ServiceNow: https://www.servicenow.com

Verkada: https://www.verkada.com

Workday: https://www.workday.com

Timestamps and topic highlights for easy navigation and deeper study:

(02:25) Lessons from holding different product roles

(07:29) Turning “hard mode” into a moat

(10:49) The early days of Serval

(12:59) Scratching the founder itch

(14:57) Unconventional interview techniques

(17:47) Solving core interview challenges

(21:10) Planning the early product roadmap

(23:03) The surprising power of patience

(26:12) Serval’s impressive technical advantage

(27:35) Disrupting legacy incumbents

(31:13) Building for mid-market and enterprise

(33:35) Serval’s enduring roadmap

(36:08) How to sell to an existing market

(39:16) The evolving role software plays

(43:55) Building for AI that didn’t exist yet

(49:49) Serval’s forward-deployed engineers

(58:31) The hybrid PM-GM

(1:00:27) “You can over-prioritize”

(1:02:48) The unexpected value of panic buttons

(1:04:50) What Serval looks for in new talent

(1:07:01) The ultimate hiring litmus test

(1:13:59) Building out Serval’s go-to-market function

(1:16:31) The evolving IT market in 2025

My bottom line: build where budgets already live, ship with uncompromising UX, embed engineers with customers, and hold the line on talent. Do that, and you won’t just keep up with the enterprise AI “land grab”—you’ll define the standard others have to meet.

October 25, 2025
Why IT Must Lead Your AI Revolution: A Strategic, Cross-Functional Playbook That Wins

I’ve led and observed AI initiatives across fast-moving product organizations, and one pattern is unmistakable: “The AI revolution needs a departmental leader.” When that leader is unclear, pilots stall, risk mounts, and value gets trapped in proof-of-concept purgatory. When it’s clear, AI moves from demos to durable outcomes.

In my experience, IT is uniquely positioned to play that leadership role. IT sits at the nexus of data, identity, security, and infrastructure—exactly where scalable AI capabilities live. IT also has the vantage point to connect use cases across teams, manage risk, and operationalize change without derailing core systems.

Put simply, this is the promise: “Learn the key reasons why IT teams are uniquely positioned to be the strategic leaders of your company’s AI projects.” The reasons are pragmatic—access to systems of record, stewardship of data governance, ownership of integration patterns, and accountability for reliability and compliance—yet the impact is strategic.

Here’s how I frame the operating model. IT provides strategic leadership and platform stewardship; Product owns the outcomes; Engineering delivers services and integrations; Security and Legal codify guardrails; and Finance supports cost modeling. We establish tight collaboration through product trios (Product, Design, Engineering) that plug into an IT-led AI platform, enabling empowered product teams to ship safely and quickly.

Governance turns intent into repeatable action. I use outcomes vs output OKRs to force clarity on value, pair them with lightweight QBR cadences for course correction, and require architecture reviews that cover model/data governance, observability, privacy, and vendor risk. This ensures we can scale gen ai without surprise failures or compliance gaps.

On the delivery side, forward deployed engineers embedded with business units accelerate discovery and reduce translation loss. We leverage gen ai for product prototyping to validate desirability and feasibility early, then harden solutions on our shared AI platform. This keeps experimentation fast while maintaining an enterprise-grade backbone.

Roadmapping balances ambition with throughput. I tie product roadmapping and sprint planning to value streams, not just features, and I make stakeholder management explicit—especially with customer support, finance, and operations—so we design for adoption. For example, a customer support ai strategy isn’t a chatbot alone; it’s an outcome-driven service redesign, with training, playbooks, and measurable deflection and CSAT targets.

Success demands the right metrics. Beyond typical velocity measures, I track time-to-first-value, model quality and drift, cost-to-serve, and risk posture. These roll into OKRs that link frontline improvements (e.g., resolution time) to enterprise outcomes (e.g., gross margin, retention), giving executives confidence and teams a clear definition of done.

If you lead IT, this is your moment to step into strategic ownership and elevate AI from scattered experiments to a coherent platform. If you lead Product, partner with IT to align discovery, outcomes, and guardrails so empowered teams can move fast and responsibly. Together, we can turn AI from a buzzword into a durable advantage.

Inspired by this post on Pendo – Perspectives.

October 23, 2025
From Zero Customers to IPO: Eric Berg’s Hard-Won Playbook for the Messy Middle

I’ve been revisiting the hard-won lessons behind durable product companies, and Eric Berg’s journey is a masterclass. Eric Berg is the CEO of Fauna, which is an adaptive operational database platform. In joining Fauna as its CEO in the summer of 2020, he brought a wealth of experience as a product leader. Most recently, he was the Chief Product Officer at Okta, scaling the company from 10 employees and zero customers to its eventual IPO in 2017. He started his career in product at Intel, working under the legendary Andy Grove, as well as a five-year stint as a product leader at Microsoft.

From a product management leadership lens, the earliest chapters at Okta are a blueprint for zero to one B2B marketing and founder-led GTM. I break down his early go-to-market lessons and the keys to honing in on an ICP to get Okta off the ground, highlighting how tight product discovery, crisp problem statements, and ruthless prioritization turn ambiguity into product-market fit.

What stands out is the often-maligned “messy middle” — the stretch when traction exists but entropy expands. Eric’s moves on “moving upmarket” and evolving a “pricing and packaging model” are reminders that, when done well, takes a company to new heights. For SaaS pricing, I lean on value metrics tied to critical jobs-to-be-done, clear guardrails for discounting, and a win–loss feedback loop owned jointly by product and sales.

We then switch gears to team building and company building. The cultural patterns that stick with me: hire “folks up and down the org chart with the right ego to talent ratio” and operationalize a “disagree and commit” value so it’s not just a long-forgotten team motto. Practically, that means defining decision types (one-way vs. two-way doors), naming a DRI and approver for every call, time-boxing debate, and documenting the rationale so execution never stalls.

On execution mechanics, I’ve found that outcomes vs output OKRs paired with QBRs vs OKRs alignment creates a healthy cadence from strategy to delivery. When you layer in forward deployed engineers and structured customer advisory boards, feedback cycles compress without sacrificing focus — a powerful pattern in both product roadmapping and sprint planning.

Finally, the perspective shifts “as he approaches one year of sitting in the CEO seat” underscore the difference between building products and building a business. Capital strategy, talent density, and narrative become first-class product surfaces. As a product creator, I translate this into designing org APIs, setting explicit burn-to-learn budgets, and treating pricing, packaging, and GTM as core parts of the product.

If you’re navigating product-market fit lessons, wrestling with “moving upmarket,” or recalibrating SaaS pricing, this playbook maps the trade-offs from 0 customers through the “messy middle” and beyond. It’s a grounded field guide for product folks and operators who want to scale with clarity, strengthen culture, and accelerate learning without losing the thread.

Inspired by this post on First Round.

October 22, 2025
Ask Why It Won’t Work: Hard-Won 0→1 Lessons, Pre-Mortems, and Founder-Led GTM from Persona

I recently sat down with Rick Song, the co-founder and CEO of Persona, a platform that enables companies to create the ideal identity verification experience for their customers. Before founding Persona in 2018, Rick was an engineer at Square for 5 years, and an early team member at Square Capital. As someone who leads product teams and thinks deeply about product-market fit and go-to-market, I was eager to unpack the 0 to 1 thinking behind Persona’s trajectory.

Rick is at an exciting inflection point in his journey of building from zero to one — just last week, Persona shared that they’ve raised a $50 million Series B round. The company plans to double the team this year to keep up with revenue that’s surged more than 10x and a customer base that’s grown to include big logos like Square, Postmates, and Gusto. For anyone operating in B2B SaaS, that’s the kind of signal you can’t ignore.

In our conversation, one theme stood out: Rick is somewhat obsessed with the idea of pre-mortems, or figuring out why things might not work out. From all the ways a candidate might fail, to why a customer won’t want a product, to how a commonly-used framework might not be a good fit, he brings this mindset to every aspect of running Persona. I share that instinct — when we anchor on “why it won’t work” early, we surface edge cases, stress-test assumptions, and prioritize outcomes over output. It’s a product discovery discipline that keeps teams honest and accelerates product-market fit lessons.

Rick also shared counterintuitive practices that resonated with my own founder-led GTM experiences. His engineers sell and cold-email prospects, and he doesn’t try to convince candidates that Persona is a company that will change the world. That may sound unconventional, but it’s exactly the clarity zero-to-one companies need: tight customer feedback loops, direct exposure to objections, and authentic hiring that screens for fit over hype. In my experience, these choices reduce handoffs, sharpen messaging, and create a culture that learns faster than the market moves.

There’s a broader leadership lesson here for product management: treat pre-mortems as a muscle, not a meeting. I apply this to hiring scorecards, roadmap bets, and go-to-market plays — explicitly listing failure modes, customer objections, and “anti-personas” who won’t buy. When we teach engineers to engage customers directly, we’re effectively building forward deployed engineers who carry context from discovery to delivery to launch, closing the feedback loop and improving zero to one B2B marketing execution.

For founders, engineering leaders, and hiring managers, the takeaways are practical: start with the “won’t,” design for objections, and let builders meet buyers early. Pair this with a clear definition of success metrics and a bias for candid, frequent iteration. The result is a stronger compass for product management leadership and a far more resilient go-to-market motion.

You can follow Rick on Twitter at @rickcsong and learn more about Persona at https://withpersona.com/

Inspired by this post on First Round.

October 22, 2025
How I Build Highly Technical Enterprise Products: Hard-Won Lessons from CockroachDB and Nate Stewart

Building a highly technical enterprise product is as much about disciplined focus as it is about engineering excellence. When the stakes include mission-critical uptime, data integrity, and scale, the product decisions we make today compound for years. That’s why I’m constantly looking for patterns that help my team make fewer, better choices.

Recently, I sat down with Nate Stewart, CPO of Cockroach Labs, the creator of database product CockroachDB. Our conversation crystallized a number of principles that I’ve seen work in my own practice and that I believe every enterprise product leader should internalize.

First, focus starts with a brutally specific use case. Nate walked through how the Cockroach team narrowed the aperture on where their database would be irreplaceable, not just incrementally better. That clarity anchored the go-forward plan — which meant saying no to a lot of customers who didn’t align with the product roadmap. In my experience, this is the hardest muscle to build. I’ve found it helpful to articulate a one-sentence “non-negotiable” use case, followed by a short list of adjacent use cases we’ll explicitly defer.

Second, treat over-commitment as a structural risk. Nate dives into the tactical ways to avoid taking on too many customer commitments, which he calls tech debt for product teams. I track this debt explicitly: a ledger of promises, effort estimates, and the strategic rationale for each commitment. We cap the total “commitment points” per quarter, require a written business case for any exception, and sunset low-impact promises with transparent communication. This keeps the roadmap credible and prevents well-intentioned deals from silently hijacking strategy.

Design partnerships are the force multiplier in deeply technical categories — especially when working with conservative enterprise clients. Nate outlined different types of design partners and why you should have all of those represented in the early days of your startup. I map partners along two axes: ambition (visionary to conservative) and environment (startup to regulated enterprise). A healthy portfolio includes at least one of each: a visionary who pushes the frontier, a pragmatic mid-market partner who validates repeatability, and a regulated enterprise that stress-tests compliance, security, and operability.

To make design partnerships work, I rely on a simple operating contract: shared problem statement, measurable outcomes, and mutually agreed constraints. We align on exit criteria before we start, time-box pilots, and avoid bespoke code unless it is clearly on the critical path to the broader product-market fit. Executive alignment on both sides and weekly joint reviews keep momentum high and surprise low.

For product leaders stepping into a new role, nothing matters more than building a rock-solid partnership with a CEO as the first head of product. I’ve found three habits indispensable: a shared narrative (why we win), a living strategy doc (how we win), and a predictable cadence (when we decide). I send pre-reads before our 1:1, frame trade-offs in terms of risk and reversibility, and use disagree-and-commit to keep the organization moving. This creates trust, speeds decisions, and shields teams from thrash.

Finally, I’m intentional about how I solicit honest feedback across the executive team. I rotate a “red team” to stress-test critical bets, run brief anonymous pulses after major launches, and host cross-functional postmortems that focus on outcomes vs output. I also schedule regular skip-level interviews to uncover operational friction that might never surface in leadership meetings. These mechanisms create a continuous learning loop without slowing down the business.

In sum, the craft of enterprise product management lives at the intersection of clarity, constraint, and collaboration. Define a use case so sharp it excludes most opportunities. Manage customer promises like a portfolio of risk. Build a diverse, intentional set of design partners. And invest early in executive alignment and feedback channels that scale with your ambitions. That’s how we turn technical excellence into durable enterprise value.

October 21, 2025
How Retool Hit $2M ARR Pre‑Launch: My Playbook on Developer Focus, Product‑Market Fit, and GTM

I spend my days building and scaling B2B products, and Retool’s journey to $2M in ARR before launch is a masterclass in focus. It’s also a case study I revisit when coaching teams on developer evangelism and founder-led GTM.

Listening to David Hsu recount the early decisions made the strategy crisp: stay laser‑focused on developers, remove the boilerplate of internal tools, and earn trust with speed.

Retool, a low-code platform for developers building custom internal tools.

Today, Retool is valued at over $3 billion and has some of the biggest companies in the world building apps on its platform.

Early on, plenty of smart folks thought the idea for Retool would fail and that the product’s developer focus would sink the company. I’ve heard variations of this skepticism whenever a team doubles down on a specific persona—especially developers.

What struck me is the clarity around the target customer and the discipline to pursue language-market fit. When you get the words right for developers—their jobs-to-be-done, primitives, and constraints—you lower friction across product discovery, onboarding, and activation.

Equally instructive is how Retool nabbed its earliest customers (which includes Brex, DoorDash and a Fortune 500 BigCo) and the way the team prioritized creating incredibly tight feedback cycles with these early evangelists. That’s founder-led GTM at its best: sit with users, ship fast, instrument everything, and turn customer conversations into a roadmap.

On the surface, Retool’s path to product-market fit seems incredibly smooth. But as David tells it, there were plenty of bumps in the road — and he’s got tons of advice for early-stage founders that are finding their footing. I’ve lived those bumps, too; they’re signals to tighten the loop, not reasons to pivot away from your core user.

My takeaways for product leaders: start with developer empathy, not feature breadth. Use founder bandwidth to run high-frequency user sessions, shadow internal tool builds, and test copy until you hit language-market fit. Treat docs, templates, and examples as part of the product; they often outperform UI tweaks for time-to-value.

Operationally, stand up a lightweight, metrics-driven pipeline that connects discovery to delivery. I like a weekly cadence that pairs qualitative insights with activation, time-to-first-value, and expansion signals—classic product-market fit lessons that prevent local optimizations. When you see pull, lean into developer evangelism and zero to one B2B marketing, not paid acquisition.

If I were replicating this playbook today, I’d deploy a small, forward-deployed team to embed with design partners, capture real workflows, and ship improvements daily. Pair that with clear outcomes vs output OKRs so the team optimizes for customer outcomes, not just shipping velocity. That’s how you earn trust with developers and translate it into durable ARR.

Retool’s story reinforces a principle I teach often: conviction in the right user beats broad appeal every time. Focus wins, feedback compounds, and the market rewards teams that can turn skepticism into traction—especially when the users are developers.

October 21, 2025
How a 3-Time Founding Team at Pilot Unlocked Product-Market Fit Faster—My Proven Playbook

I’m often asked how elite teams compress the journey to product-market fit. One story I keep returning to is Jessica McKellar, co-founder and CTO of Pilot, which is the largest accounting firm for startups. For the past six years, she’s built Pilot alongside her two co-founders, Waseem Daher and Jeff Arnold — and what makes this trio extraordinary is that they’ve stuck together across three startups.

As repeat founders, the team learned a ton from their first two ventures, K Splice and Zulip, and both netted some positive outcomes. Yet there were mistakes that prevented those products from becoming an outsized success. From a product management leadership perspective, I see a clear evolution in how they approached problem selection, product discovery, and go-to-market.

With Pilot, they prioritized picking an acute problem and a huge market to tackle. That simple but rigorous reframing matters: identify a customer segment with a painful, high-frequency workflow; quantify the market; and ensure a compelling “why now.” This is classic founder-led GTM discipline and the essence of practical product-market fit lessons.

They also embraced a deliberately tedious build process for v1: looking over Waseem and Jeff’s shoulders as they manually did the bookkeeping for early customers, while she wrote code alongside them. In my experience, this “do the job, then automate” approach functions like forward deployed engineers for founders — embed with the real workflow, capture edge cases, then translate that knowledge into the system of record.

Even going back to the earliest days, Pilot had some really strong product-market fit signals, with customers agreeing to pull out their credit card and pay for the product right away when it was just an idea on paper and eventually pulling the Pilot team into expanding their product suite. That willingness-to-pay signal, coupled with pull-based requests for adjacent capabilities, is exactly what I look for before scaling zero to one B2B marketing or hiring beyond the founding team.

My playbook from this story is straightforward: choose a narrowly defined, acute pain in a massive category; run founder-led discovery inside the customer’s workflow; ship code alongside the service until the workflow is reliable; price early to validate value; and align outcomes vs output OKRs so the team optimizes for customer impact, not feature volume. Do this, and you convert messy service learnings into a repeatable product engine.

Make no mistake about it — being a founder is incredibly difficult — but choosing the right problem to tackle can drastically smooth the path ahead of you. For product creators, that choice — and the discipline to live in the customer’s workflow early — is the difference between meandering and momentum.

October 21, 2025
Goal-Setting for AI Products: How I Plan, Prioritize, and Confidently Ship in a Nonlinear GenAI World

I build and ship AI products in an environment where the frontier changes weekly, so my planning system has to be adaptive, evidence-driven, and unapologetically outcome-focused. In this piece, I share the frameworks I use to set goals for generative AI, balance research with product execution, and scale responsibly — drawing sharp lessons from one of the most influential applied AI companies operating today.

Consider Runway, an applied AI research company shaping the next era of art, entertainment, and human creativity. Runway has raised $237m and was one of Time Magazine’s “100 most influential companies” in 2023. Runway has been a persistent viral sensation in recent years, and is behind many of the most famous AI demos online.

The earliest stages of an AI company often begin with research breakthroughs, scrappy prototypes, and clever distribution. In practice, that means leveraging containerization (https://aws.amazon.com/what-is/containerization/) and Docker (https://www.docker.com/) to package models reproducibly, showcasing work where practitioners already gather — Hugging Face (https://huggingface.co/), Hugging Face Spaces (https://huggingface.co/spaces), and Hugging Face Model Hub (https://huggingface.co/docs/hub/models-the-hub) — and tapping infrastructure like Replicate (https://replicate.com/) to get demos into people’s hands. Early, magical use cases — like the Green screen tool by Runway (https://runwayml.com/green-screen/) — teach us which problems are both technically feasible and viscerally valuable.

I’ve learned to be cautious about “The limitations of being “customer-driven” when building in AI”. Traditional product discovery assumes needs are legible and solutions are relatively deterministic. In generative AI, user desire often follows model capability, not the other way around. The job is to triangulate: run tight user loops to validate perceived value, instrument objective model quality, and explore novel interaction patterns that customers can’t yet articulate. I treat this as a portfolio of discovery bets — some customer-led, some capability-led, all evaluated against clear outcome thresholds.

Balancing research development with product development requires organizational design that prevents context-switching tax while preserving velocity. I pair research pods with product pods, supported by forward deployed engineers and domain PMs who translate evaluation metrics into user-visible milestones. Safety and content moderation sit on the critical path, not as afterthoughts — think policy definition, classifier tooling, abuse red teaming, and clear escalation playbooks. This balance is how you move from a great demo to a dependable product without losing momentum.

Goal-setting amidst constant change in AI starts with outcomes vs output OKRs. I write OKRs in terms of user impact and model performance thresholds — for example, target ranges for latency, quality scores against a golden dataset, or creator retention — then let teams choose the highest-leverage outputs (data pipelines, fine-tuning, UX improvements) to get there. Why I don’t plan very far ahead: I treat the annual view as a vision and bet map, the quarterly view as a constrained slate of outcomes, and the 6–8 week cycle as the execution heartbeat. AI roadmaps are hypotheses; evaluation harnesses and launch gates are the truth.

Community is a force multiplier. Forming a vocal community and fostering community requires real access and real listening: early release cohorts, office hours, and transparent changelogs. How they picked users for early release matters — diversity of use cases, sophistication of workflows, and willingness to give crisp feedback. Expanding past the first 100 users of Gen-2 demands readiness: evaluation parity across modalities, scalable infra, and safety coverage. Done well, this motion compounds learning while building authentic advocacy.

For founders, my advice echoes the core lessons above. Start with a narrow, high-intent wedge and prove durable value fast; let founder-led GTM compress the feedback loop; instrument everything from day one; and resist the urge to over-plan features before you’ve nailed outcomes. Product-market fit lessons in AI often arrive via small, fast experiments — not grand, long-range plans. Ship thin slices that demonstrate unmistakable value, then iterate toward a system, not a single feature. When in doubt, shorten the loop and improve the evaluation harness.

People often ask: Will AI replace video editors? My view is that AI will replace zero editors who master these tools — and many who don’t. The winners blend taste, storytelling, and generative leverage. The products we build should honor this reality: design for control, iteration, and co-creation, not just automation.

If you’re mapping the progression of tech and use-cases, a few public references are instructive: Runway Gen-1 (https://research.runwayml.com/gen1) and Runway Gen-2 (https://research.runwayml.com/gen2) show how capability unlocks new workflows and demand. Runway’s 30 AI Magic Tools (https://runwayml.com/ai-magic-tools/) illustrates portfolio thinking — a suite of composable powers rather than a monolith.

For builders focused on gen ai for product prototyping through production: keep your demo muscle strong, your evaluation stronger, and your outcomes strongest. Invest in community, treat safety as a feature, and let your OKRs steer what ships — not the other way around.

October 20, 2025