Buildkite

Buildkite needed to grow self-serve adoption and help engineers see pipeline value fast—without a visual pipeline or a clear path from “interested” to “converted.”

A pro tool used by the best—but powerful meant opaque, and growth was blocked.

Buildkite is the CI/CD platform that powers the world's top tech companies like Reddit, Intercom, PagerDuty and many more—a fast, scalable 'pro tool' that scales with serious engineering orgs. The product was proven at the top tier; the problem was growth and onboarding.

Buildkite is powerful, but that power made it hard to understand how it works and hard for new developers to see its competitive edge. The core product Pipelines' secret sauce was buried in YAML configuration and dev docs, not in something you could easily see or explore. In practice, adoption was reliant on very senior developers guiding DevOps teams through implementation—we weren’t onboarding new developers at scale, and there was no self-serve path.

PM → discovery → design → engineering: bridging complex infrastructure and visual clarity so the growth bet could ship.

I moved across four modes so the initiative could move fast without handoff drag:

• Acting PM first: I spun up Buildkite’s new Onboarding Team—hiring, early strategy, and bringing in contractors.
• Discovery: I led workshops with the founder, senior leadership, and domain experts around the globe to map where adoption was breaking down and where the real bottlenecks were.
• Design: I ran dozens of developer interviews to define our Ideal Customer Profile (ICP) and sharpen our unfair advantage, then led the UX design direction for the visual pipeline and template gallery so the experience was clear and conversion-minded.
• Engineering: I shifted into implementation—building the UI in React and quickly picking up Ruby on Rails so I could ship the experience into the core product. That end-to-end ownership is what turned the bet into shipped product: a "Visual Whiteboard" for YAML and a high-intent template gallery that turned SEO→Onboarding into a Product-Led Growth (PLG) engine.

The "YAML-to-Graph" Translator

The core challenge wasn't just "drawing lines," but creating a mathematical model that translated abstract YAML into a coherent visual graph. I worked alongside our Staff Engineer to map Buildkite’s flexible pipeline logic (parallelism and dependencies) into a ReactFlow canvas.

This allowed me to design for progressive disclosure: engineers could maintain a "Bird’s Eye View" of the entire architecture, then zoom into specific nodes for fine-grained details. This visual layer turned a "Senior-only" task into an accessible, self-serve experience.

Template gallery

The gallery had to serve two goals: help new users discover ready-made pipeline definitions for common use cases (CI/CD, mobile, IaC, languages), and give the business a set of indexable, keyword-rich pages that could rank for DevOps search terms. I built the gallery and template detail pages with Next.js, with content managed in DatoCMS and search powered by Algolia so we could scale templates and filters.

I drove the UI design, and partnered with our domain experts to create the information architecture to enrich the implementation, so the experience was crafted with an interactive product.

SEO as a growth channel and sales collateral

I integrated our domain knowledge into the SEO strategy to ensure our templates ranked for high-intent DevOps keywords. By aligning the Information Architecture (IA) and content design with search intent, we created a seamless funnel: Search → Template Preview → Sign up → Onboarding → Activation.

These pages became essential tools not just for organic growth, but as part of the collateral for our Sales team to demonstrate Buildkite’s "Pro-Tool" superiority to enterprise prospects.

The Hybrid Execution Model

To move at the speed of a 0→1 growth bet, I stepped out of a pure design role to act as both PM and Software Engineer during different phases. I started out as an acting PM to hire the team, then back to product designer to run discovery and design the experience. Once the design direction was established, I switched between owning the implementation design←→code, eliminating the friction of traditional handoffs.

This allowed for rapid ABC testing (Variant A, B, and Control) to iterate on the onboarding flow in real-time, and ensured the foundation we built was ready for future interoperability with the core product and tools like the VS Code Extension.

Aha! moment from 8 hours → 1.8 minutes: a scalable PLG engine for self-serve and enterprise.

We collapsed the time-to-value from an 8-hour "manual climb" to a 1.8-minute "visual win," establishing a scalable PLG engine that onboarded both self-serve engineers and the enterprise sales team.

Shipped the First Visual Pipeline

Designed and engineered the core ReactFlow graph model that translated complex YAML into a readable mental map. This introduced progressive disclosure to Buildkite, allowing devs to toggle between a high-level architectural "Bird's Eye" view and deep-dive configuration.

SEO as a Multi-Channel Asset

The Template Gallery became more than a landing page; it served as high-intent sales collateral and a bridge to the developer docs. This created a unified "Marketing → Product → Docs" funnel that felt like a cohesive "Pro-Tool" experience.

Built the "Live Preview" Foundation

Engineered an interoperable architecture designed to eventually bridge the gap between the web dashboard and the VS Code Extension, ensuring engineers have a consistent visual mental model regardless of their environment.

The highest leverage was combining design and implementation in one role and leaning on expert insight to enrich the solution.

• Design + build in one role — For a focused growth bet, owning both design and implementation removed handoff gaps and let me iterate on the visual pipeline and gallery in tight loops.
• Templates as product and growth — The template gallery wasn’t just a feature; it showed developers what was possible. Designing pages that were useful (good IA, search, clear templates) and conversion-oriented (keywords, structure, CTAs) meant one asset served product and marketing.
• SEO as product work — Treating SEO as a product initiative—beyond organic traffic, the content design aligned the team to focus on showcasing high impact CI/CD use cases.
• When to switch hats — Transitioning from design to engineering for this initiative was a calculated move: it sped up delivery and gave me a deeper understanding of how the systems complement each other. Knowing when to wear which hat (and when to hand back to dedicated eng) was something I struggled with at first; through the process I learned to context-switch quickly and laser-focus on the highest-impact work to keep momentum moving.