Tribe, Product Lead Case Study

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

Overview

Two audiences inside one product: organisers running the business and members showing up to use it, served from one release plan and one shared system.

Scope: organiser dashboard, memberships, events, ticketing, payments, member surface and 80 components.

Every release shortened organisers’ day while keeping the member surface calm, even when monetisation had to land early. That shaped the architecture: load-bearing flows on one system every later feature plugs into, not a wider surface that fragments under its own weight.

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

I direct a platform serving organisers and members.

My remit spans product and operations. I judge work by whether organisers run their community with less friction and each release leaves the platform more coherent, making trade-offs explicit so the team ships end-to-end.

Management & Strategy

Prioritise the roadmap against user pain, operational reality and commercial pressure rather than whoever asks loudest.

Design & Execution

Sole designer across the product. I own the design system and core flows so every feature extends the platform coherently.

Product Collaboration

Stay involved through discovery, build, QA and release so hand-off carries intent and edge cases from the start.

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 in four quarters. Onboarding and dashboard shipped first, then memberships and events, so the core was proven first.

Sprints & Backlog

Weekly sprints run against a groomed backlog. Tickets carry intent and acceptance, so engineering builds straight to done.

Feature deep dives

For load-bearing features, deep dives align design, engineering and founders on behaviour and edge cases, reducing surprises.

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

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.

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

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, so new features land without a parallel design track.

Key decision: built memberships, events and ticketing as one connected product, not three loosely linked tools. Slower to ship v1, but organisers run a single product and engineering maintains one core.