Tribe, Product Lead Case Study

Product · Community/2025 — ongoing/Live, shipping continuously

Overview

Two audiences inside one product. Organisers running the business of a community, and members showing up to use it, served from one release plan and one shared system.

Scope: organiser dashboard, memberships, events, ticketing, payments, the member surface, and an 80-component system built from scratch.

Each release had to make organisers' day-to-day shorter without making the member surface louder. The business needed monetisation early; the community needed a calm product first. Both pressures lived in the same backlog.

The constraint shaped the architecture. A small set of load-bearing flows on one system every later feature plugs into, rather than a wider surface that fragments under its own weight. Less to maintain, more to compound.

Impact

01200+ communities created within the first six months of launch200+ communities created within the first six months of launch
02100+ memberships sold without making the member surface louder100+ memberships sold without making the member surface louder
03Took the product from 0 → live platform across core product areas.Took the product from 0 → live platform across core product areas.
04Designed and shipped 5 major digital features within the first 6 months.Designed and shipped 5 major digital features within the first 6 months.
0540+ releases shipped from specs that held up in QA40+ releases shipped from specs that held up in QA
061,000+ tickets purchased by members on the surface we shipped1,000+ tickets purchased by members on the surface we shipped

My Role

As Product Lead at Tribe, I shape what we build, why, and in what order, across a platform serving organisers and members.

My remit spans the product and the operational systems behind it, judged on whether organisers run their community with less friction and each release leaves the platform more coherent than it found it.

In practice that means making trade-offs explicit and holding the team to a few decisions at a time, so we ship end-to-end rather than half-built.

Management & Strategy

Partner with founders and engineering on what to build, what to drop, and in what order, holding the roadmap to real user pain, operational reality and commercial pressure rather than whoever shouts loudest in the room.

Design & Execution

Sole designer across the product. I own the design system and core flows, from onboarding through memberships, ticketing and payments, so every feature extends the platform coherently rather than fragmenting into one-off screens.

Product Collaboration

Work with engineering through discovery, build, QA and release instead of handing over a file. Tickets carry intent, behaviour and edge cases up front, so hand-off stays clean, scope survives reality, and decisions only ever get made once.

Getting orientation fast

Getting our bearings by surfacing needs.

Tribe welcome, create tribe and event screens

Tribe insights dashboard with booking trends and growth metrics

Tribe event discovery, ticket purchase and wallet screens

Tribe event management dashboard listing upcoming events

Stakeholder interviews

12 interviews: the business needed monetisation, the community a calm product.

Community interviews

20 organisers showed where revenue leaked: onboarding, events, payouts.

Information architecture

Two surfaces under one ruleset: public marketing split from the authenticated app.

What we built first and why

Ship the foundation first, then the features that depend on it.

Roadmap planning

Sequenced v1 across four quarters with the founders, first release live with real organisers inside three months: onboarding and the dashboard first, memberships and events second, growth surfaces last, so the core was proven in the wild before anything new was layered on top of the product.

Sprints & Backlog

Weekly sprints run against a groomed backlog where every ticket carries intent, behaviour, edge cases and acceptance criteria up front, so engineering can build straight through to done without constant back-and-forth, mid-sprint clarification or rework once a ticket is already in flight.

Feature deep dives

For load-bearing features like payments and ticketing, cross-functional deep dives bring design, engineering and the founders together to align on behaviour, edge cases and the definition of done before design or engineering work starts. That upfront alignment meant fewer surprises once build began.

Tribe early concept exploration showing homepage and community cards

Early concepts

One language carrying organiser tooling, member surfaces and marketing. These concepts let us stress-test how a single visual language could stretch from member discovery to organiser administration, and became the blueprint for the design system that followed.

Design System

Built from scratch: tokens, typography, spacing, iconography and a documented component library. Every new feature, membership tiers, ticketing, organiser analytics, extends the system rather than fragmenting it.

The product

Tribe event dashboard for community organisers

B2B · Community creators

The operating side of Tribe: one place to create events, manage memberships, understand performance and run the day-to-day business of a community.

B2C · Ticket purchasers

The member-facing side: discover nearby events, choose a date, purchase tickets and move naturally from a first booking into an ongoing community.

From discovery to daily use, built as one product.

Tribe hero landing page showing Find your people In real life

Tribe community setup dashboard with insights and page builder

Tribe membership pricing and payment settings

Tribe onboarding interest selection screen

Design approach

The product was designed in the system it shipped in: components pulled and extended rather than screens redrawn, so booking, membership and community tools stayed consistent as the product grew feature by feature.

Validation & shipping

PRD's

Behaviour, permissions, edge cases and failure states the designs can't carry.

User testing

Every load-bearing flow prototyped and tested with 5 active organisers first.

What changed

Membership purchase moved inside the event flow; refunds became self-serve.

Conclusion

A year in, both sides of the product are live and used daily, on a foundation the team keeps shipping into feature by feature.

Memberships, ticketing, payments and analytics behave consistently because they extend the same system. New features land without a parallel design track and specs hold up in QA.

Key decision: built memberships, events and ticketing as one connected product rather than three loosely linked tools. Slower to ship v1; meant organisers ran a single product instead of stitching separate flows together, and engineering only maintained one core.