I’ve spent the last few years turning AI from an intriguing demo into an operational advantage, and the clearest wins come when we treat agents as productized workflows—not toys. In practice, that means aligning agentic AI to a sharp product strategy, instrumenting everything, and scaling what works across the organization.
Learn how companies like Replit are consolidating workflows, creating one-person departments, and building systems for scale with Amplitude
When I talk about agentic AI, I’m focused on outcomes: fewer handoffs, faster cycle times, and measurable uplift in activation, retention, and NPS. The most successful rollouts start with a specific job-to-be-done, translate it into clear AI workflows, and then iterate with a tight feedback loop between data, design, and engineering.
My implementation playbook is simple and disciplined. First, choose a high-friction workflow and define success upfront. Second, make the build vs buy call on the foundation model, orchestration layer, and connectors. Third, establish AI risk management and safeguards early—before scale amplifies errors. Finally, run small, eval-driven releases and promote what performs.
Instrumentation is where the leverage compounds. With Amplitude analytics as a unified analytics platform, I design purposeful events (agent intent, tool calls, resolution state, human handoff), map funnels from user input to agent outcome, and cohort users by context to pinpoint lift. This gives me an honest read on where agents help, where they hinder, and what to tune next.
The “one-person departments” concept isn’t about doing more with less at all costs; it’s about assembling a tight loop of product management leadership, data, and automation so one operator can own a business outcome end-to-end. An agent handles the repeatable work, while the human focuses on judgment, edge cases, and continuous improvement that compounds.
As we scale, I look for platform scalability patterns: shared tools and policies, reusable prompt libraries, standardized evaluation suites, and consistent governance. That structure keeps agent performance predictable while preserving speed, and it aligns beautifully with product-led growth when agents are embedded directly in the product experience.
If you’re starting now, begin with a single, valuable workflow. Instrument it thoroughly with Amplitude analytics, make decisions from the data you see—not the demos you remember—and expand only after you’ve proven uplift. Iteration beats ambition here: agentic AI rewards teams who measure relentlessly and scale only what truly works.
Inspired by this post on Amplitude – Perspectives.
Every planning cycle, I’m asked the same high-stakes question: should we build or buy? In 2026, with generative AI reshaping the software landscape and budgets under scrutiny, the classic calculus needs an upgrade. The right call can accelerate time to value, protect precious engineering capacity, and sharpen competitive differentiation—while the wrong one can quietly inflate total cost of ownership for years.
“Navigate the build vs buy software dilemma, learn how AI is changing the game, and what you should leverage (and when).” That’s been my north star for product strategy this year, and it’s how I guide teams when the pressure is on.
My first principle is simple: build where we differentiate, buy where we need parity. If the capability is central to our value proposition or our defensibility, I’m inclined to build—often with a phased approach that de-risks scope. If it’s a non-differentiating layer (think billing, analytics plumbing, basic CRM integration), I’ll buy to accelerate, then revisit once scale and specialization justify a deeper internal investment.
AI changes the equation on both sides. On the “buy” side, modern platforms now ship agentic AI, fine-tuning options, and robust APIs that let us compose advanced capabilities fast. On the “build” side, AI workflows and toolchains (from code copilots to eval-driven development) compress cycle time, making bespoke solutions more attainable. The trade-off has shifted from pure functionality to questions of AI risk management, model governance, data privacy, and the portability of prompts, embeddings, and training data.
I evaluate decisions across two economic horizons: time to value versus total cost of ownership. Buying often wins the first round—faster deployment, proven reliability, and lower initial lift. But TCO can creep: integration work, per-seat or consumption SaaS pricing, training, vendor-driven roadmap gaps, and the “shadow ops” of maintaining connectors in our CI/CD. Building flips that profile: slower early velocity, higher upfront complexity, but potentially lower long-run costs and tighter fit with our platform scalability goals.
Operational risk matters just as much as features. I look at incident management posture, SRE maturity, SLAs, and DORA metrics to gauge resilience. If a vendor can’t meet our uptime and recovery expectations—or if their roadmap pace mismatches our deployment frequency—we’re effectively renting risk we can’t control. Conversely, if our team can’t realistically support the operational burden, buying is the safer choice.
Security, regulatory compliance, and data governance are non-negotiables. I assess privacy-by-design, data residency, audit logs, role-based access, SOC2/ISO coverage, and threat detection and response. For AI-heavy systems, I add model lineage, red-teaming practices, PII handling, and retention policies. If we can’t verifiably meet our obligations in a build scenario within the launch window, we buy and require clear data exit and portability clauses.
To keep decisions objective, I use a lightweight scorecard across five dimensions: differentiation, urgency/time to value, regulatory/security risk, integration complexity, and AI leverage/portability. We weight criteria with product trios (PM, design, engineering), run discovery spikes, and validate assumptions with stakeholder management up front. A disciplined scorecard curbs recency bias and helps us communicate trade-offs to leadership.
In practice, I favor staged commitments. When uncertainty is high, we buy to learn—ship value quickly, instrument usage, and collect evidence. If adoption proves sticky and integration pain remains moderate, we double down with deeper vendor integration. If we uncover unique needs or cost inflection points, we pivot to a build plan that reuses learnings, data models, and UX patterns from the bought solution to reduce risk.
AI-specific choices deserve their own pass. For example, if we need retrieval-augmented generation, I’ll often buy for the orchestration and observability layer while building our domain-specific retrieval-first pipeline and prompt engineering guardrails. That split gives us speed plus control: we retain our IP and data gravity while tapping best-in-class tooling that evolves with the ecosystem.
Vendor strategy matters as much as technology. I negotiate clear data export, transparent API quotas, sandbox environments for continuous discovery, and price protections for growth. I pressure-test roadmaps, ask for integration references, and align on outcome-based milestones rather than feature checklists. Strong partners welcome this rigor; weak ones stall—another useful signal.
On the build side, I right-size ambition. We target minimum lovable scope, isolate risk in early sprints, and leverage open source where it’s mature and secure. We design for modularity so we can swap components without rewriting the world, and we budget time for in-app guides and product tours to smooth adoption, because user activation is the real finish line.
Here’s the playbook I return to: buy to validate and compress time to value; build to differentiate and reduce long-run TCO; continuously re-evaluate as the AI toolchain and our scale evolve. With a transparent scorecard, a bias for learning, and a clear view of risk, the build vs buy decision becomes less of a leap of faith and more of a repeatable product management capability.
2026 will reward teams that move fast without mortgaging the future. Make the call deliberately, instrument the outcomes, and stay humble—because the best strategy is the one you can adapt as new evidence arrives.
