Burning Man Project · Product + Design Leadership

Ten years of building the systems a global community actually runs on.

Burning Man is not one product. It is a nonprofit running ticketing, payments, volunteer operations, art grants, and year-round community platforms, under demand curves most consumer companies never see. I led product, UX, research, design ops, and delivery across that portfolio for nearly a decade.

Role: Development Leader + Sr. Product Design/Management
Years: 2011 – 2020
Focus: High-scale platforms · Community systems · Org building

Burning Man ticketing, profiles, refund workflow, and platform ecosystem collage

Context

Burning Man Project is a nonprofit that supports a year-round global community and an annual event of roughly 80,000 people. The digital surface area is unusually wide: public ticketing, payments, volunteer and staff tooling, art grants, directories, and community platforms, over 20 public and internal systems.

The organization is mission-driven and consensus-heavy, with 20+ departments that each own real operational responsibility. Technology decisions are never purely technical: they change how volunteers work, how the community experiences fairness, and how the organization absorbs risk.

I joined as design capacity and left having built the Product Design function, owned roadmaps and release planning across the portfolio, and led the products that handled the organization's highest-stakes money and trust moments.

The challenge

User: Community members hit these systems in short, brutal bursts, a ticket sale, a refund window, a grant deadline, and any friction is read as unfairness, not as a bug.
Business: Ticket revenue funds the year. Failed sales, oversells, or payment errors are existential, not inconvenient.
Organization: 20+ departments requesting work with no shared intake, prioritization, or product practice. Everything was urgent; nothing was sequenced.
Market: Demand vastly exceeds supply. Systems must survive a load profile closer to a ticketing platform's worst day than a nonprofit's normal one.

My mandate

Role: Product Design + Development Leader, product, UX, research, design operations, and engineering delivery across the platform portfolio.
Authority: Owned roadmap definition, release planning, prioritization, vendor selection, and a $1.1M technology/vendor budget.
Team: Built and led the Product Design function. [ADD: team size and reporting structure]
Disciplines: Product, UX, research, design ops, engineering, QA, external vendors, volunteer contributors.
Stakeholders: Executive leadership, 20+ departments, communications, legal/compliance, finance, customer support.
Timeframe: 2011 – 2020

What I learned first

The failure mode was sequencing, not talent.
Departments were not asking for the wrong things. There was no shared way to say what came first, so the loudest request won and dependencies surfaced late.
Peak-load behavior is a product problem before it is an infrastructure problem.
Most of what people experience during a high-demand sale is expectation-setting: queue communication, state clarity, error recovery, and what happens when a payment fails at the worst possible second.
Fairness is a design requirement.
In a community that scrutinizes access, perceived fairness of a flow mattered as much as throughput. Ambiguity in a confirmation screen turns into a week of support volume and public debate.
Support and operations were the best research channel available.
Ticket queues, refund exceptions, and volunteer workarounds told us exactly where the product was failing. [ADD: number of users interviewed / research artifacts to cite]

At peak, the product is not the interface. It is what happens in the four seconds after something goes wrong.

Strategy

Treat the portfolio as a portfolio: one roadmap view across 20+ platforms, with explicit tradeoffs instead of 20 parallel queues.
Stand up a product operating system, intake, prioritization, critique, release planning, risk tracking, lightweight enough for a nonprofit to actually sustain.
Invest disproportionately in the moments that carry money and trust: ticket sales, refunds, and fundraising.
Design high-demand experiences around clarity and recovery rather than raw speed alone.
Buy, integrate, or build deliberately, with vendor relationships managed as product decisions against a fixed budget.

Decisions and tradeoffs

Scale from a single annual ticket sale to seven differentiated sales.

Why: One sale forced every audience, low-income members, artists, theme camps, first-timers, veterans, through the same door, which concentrated both technical load and community frustration.
Tradeoff: Substantially more operational complexity: seven sets of rules, comms, support windows, and edge cases to design and staff, instead of one.
Result: Load was distributed across the calendar and access became segmentable by community need. Peak-demand sales continued to support $30M+ in ticket transactions inside roughly seven minutes. [ADD: confirmed per-sale volumes]

Build a dedicated Ticket Refund Application instead of processing refunds manually.

Why: A manual refund at that volume would have taken months, exposed the organization to error and compliance risk, and pushed thousands of anxious community members through email support.
Tradeoff: Committed scarce engineering capacity on a compressed timeline to a product with a short usable life, deferring roadmap work elsewhere.
Result: $2.8M processed in 4 weeks with coordinated product, engineering, operations, compliance, and support. [ADD: refund request volume and support ticket deflection]

Build a bespoke crowdfunding platform rather than run the campaign on an off-the-shelf tool.

Why: Third-party platforms could not carry the organization's donor relationships, community identity, reporting requirements, or fee structure. The fundraise was a product, not a campaign page.
Tradeoff: Higher build cost and ownership burden versus faster launch on a hosted platform; we accepted schedule risk to keep the donor experience and data in-house.
Result: $1.6M generated in 6 weeks through the custom platform. [ADD: donor count and average gift]

Create a formal intake and prioritization pipeline across all 20+ departments.

Why: Without one, product capacity was allocated by urgency theater. Departments could not plan and engineering could not sequence.
Tradeoff: Slowed the start of individual requests and required visible 'not now' decisions, politically expensive in a consensus culture.
Result: Improved roadmap clarity and release execution across the portfolio, and gave departments a predictable answer instead of a queue. [ADD: cycle-time or throughput measure]

Manage vendors as part of the product and design strategy against a $1.1M budget.

Why: A small internal team could not build everything. Which capabilities to outsource was a strategic decision about where the organization needed to own its own destiny.
Tradeoff: Ongoing coordination overhead and dependency risk in exchange for reach beyond internal capacity.
Result: Delivery sustained across distributed teams with tracked risks, dependencies, and milestones. [ADD: vendor count and scope]

Leading through it

Partnered across 20+ departments, operations, communications, finance, legal, art, volunteer management, translating operational reality into product requirements they could recognize as their own.
Ran the high-stakes releases as coordinated operations: engineering, customer support, comms, and finance in the same plan, with named owners for the failure paths.
Built the Product Design function from scratch: intake pipelines, critique cycles, collaboration practices, prioritization methods, and hiring. [ADD: team composition]
Managed program work plans, resourcing, vendor relationships, and budget while tracking risks and dependencies across distributed and volunteer contributors.
Held the line on sequencing with executives, including telling long-tenured departments that their request was real and still not next.

What we built

High-volume ticketing infrastructure

Product and experience work supporting ticket sales built for extreme, short-duration demand: queueing and waiting-state communication, purchase flows, eligibility and registration rules, payment failure recovery, and post-purchase clarity.

The system scaled from a single annual sale to seven distinct sales, each with its own rules, audience, and communications model, and supported more than $30M in ticket transactions within roughly seven minutes at peak demand.

$30M+: in transactions supported at peak (~7 minutes)
7: annual sales, up from 1

Ticket Refund Application

A purpose-built refund product delivered under a hard deadline, with eligibility logic, request handling, status transparency for the community, and operational tooling for finance and support.

The hardest part was not the interface. It was designing a process that finance, compliance, operations, and support could all execute simultaneously without a manual exception pile.

$2.8M: processed in 4 weeks

Bespoke crowdfunding platform

A custom digital fundraising product, not a campaign on someone else's platform. My team built the software: contribution flows, tiers and incentives, progress and transparency, donor communications, and reporting.

Product strategy, UX, stakeholder coordination, and release execution under a compressed timeline.

$1.6M: generated in 6 weeks

Internal and community platforms

Roadmap definition, release planning, and user testing across web and mobile products serving internal operations, volunteer workflows, and public-facing community needs.

[ADD: supporting image or artifact, system map, ticketing flow diagram, refund operations workflow]

[ADD: supporting visuals, ticketing flow diagrams, refund app screens, crowdfunding platform UI, portfolio roadmap artifacts]

Outcomes

$2.8M: refunded in 4 weeks via a purpose-built product
$1.6M: raised in 6 weeks on a custom crowdfunding platform
$30M+: in ticket transactions supported at peak
20+: platforms under coordinated roadmap and release planning
$1.1M: technology and vendor budget managed
[ADD]: team size, retention, or hiring outcome

Framing note: these are system and program outcomes. The revenue belongs to the organization and its community; my work was leading the products and coordination that let those transactions happen reliably under pressure.

What changed

The organization went from reactive request-handling to a portfolio it could plan against.
Product Design became a real function with practices that outlived any single project.
High-stakes money moments, sales, refunds, fundraising, became repeatable operations instead of heroics.
What I carry forward: build the operating system before you need it, and design the failure paths first when the money moves fast.