Tribe, Product Lead Case Study

A SaaS where organisers of interest-led communities run their business, paid memberships, events, ticketing and payments from one product, with the member-side surface that sits on top of it. Two audiences, one release plan, monetisation and member experience moving together from day one.

Tribe homepage with create your tribe hero

Overview

Process

Overview

Two audiences inside one product. Organisers running the business of a community, and members showing up to use it, served from the same release plan on a small founding team.

Scope: organiser dashboard, memberships, events, ticketing, payments, the member surface, and the design system underneath.

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

01Took Tribe from zero to a live SaaS organisers run their business onTook Tribe from zero to a live SaaS organisers run their business on
02Held monetisation and member experience on one release planHeld monetisation and member experience on one release plan
03Set the architecture every later feature plugs into without forkingSet the architecture every later feature plugs into without forking
04Shipped onboarding, memberships, events and ticketing on one systemShipped onboarding, memberships, events and ticketing on one system
05Wrote specs engineering builds against without a follow-up loopWrote specs engineering builds against without a follow-up loop
06Defined the operating cadence the next product hires step intoDefined the operating cadence the next product hires step into

The Process

Orientation

Decisions

Build

Making it

Shipped

Phase 01 / 05

Orientation

Get inside the business, the community team and the competitive set.

Stakeholder interviews
Community Lead interviews
Competitor analysis

My Role

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

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 against user pain, operational reality and commercial pressure.

Design & Execution

Sole designer across the product. Own the system and the core flows, onboarding, memberships, ticketing and payments, so each new feature extends the platform rather than fragmenting.

Product Collaboration

Work alongside engineering through discovery, build, QA and release. Tickets carry intent, behaviour and edge cases up front, so hand-off is clean and decisions get made once.

Getting orientation fast

Stakeholder interviews

Founders, community managers and the CTO all surfaced the same tension: the business needed monetisation, the community needed a calm product. The roadmap had to hold both.

Community Lead interviews

Tribe's most active organisers showed where revenue was leaking, onboarding, event setup, payouts, refunds. Those became the v1 priorities engineering shipped against.

Competitor analysis

No platform served interest-led organisers running paid memberships and live events from one place. That gap set the product positioning, and the IA fell out of it.

Getting orientation fast

Stakeholder interviews

Founders, community managers and the CTO all surfaced the same tension: the business needed monetisation, the community needed a calm product. The roadmap had to hold both.

Community lead interview videos featuring three creators

Community Lead interviews

Tribe's most active organisers showed where revenue was leaking, onboarding, event setup, payouts, refunds. Those became the v1 priorities engineering shipped against.

Competitor product screens compared side by side

Competitor analysis

No platform served interest-led organisers running paid memberships and live events from one place. That gap set the product positioning, and the IA fell out of it.

What we were actually building

Tribe sitemap showing public archetypes site and authenticated dashboard structure

IA & Sitemap

Separated the public marketing surface from the authenticated app and locked the permission model underneath, the spine every later feature plugged into.

Grid of user archetype cards with illustrations, motivations and category tags

User archetypes

Organiser and member archetypes spanning different community types, sizes and motivations, used live in roadmap and sprint planning to pressure-test which features genuinely served multiple archetypes versus only one.

Concept Exploration

Pressure-tested directions before committing. The brief: a language native to interest-led communities, neither generic SaaS nor social-network defaults, that could carry organiser tooling, member surfaces and marketing on one system.

Click to expand

What we built first and why

Roadmap planning

Sequenced v1 across four quarters with the founders: onboarding and dashboard first, memberships and events second, growth surfaces last. Each sprint stayed focused on a tight set of priorities.

Sprint planning & backlog

Weekly sprint planning. Every ticket carries intent, behaviour, edge cases and acceptance criteria, engineering builds without follow-up and QA verifies against something concrete.

Feature deep dives

For load-bearing features, memberships, ticketing, permissions, cross-functional deep dives with engineering and product align behaviour, edge cases and 'done' before any work starts.

What we built first and why

Agile roadmap board spanning January through May with colour-coded workstreams

Roadmap planning

Sequenced v1 across four quarters with the founders: onboarding and dashboard first, memberships and events second, growth surfaces last. Each sprint stayed focused on a tight set of priorities.

ClickUp sprint board showing tasks across QA, in progress, code review and ready for delivery

Sprint planning & backlog

Weekly sprint planning. Every ticket carries intent, behaviour, edge cases and acceptance criteria, engineering builds without follow-up and QA verifies against something concrete.

FigJam feature deep-dive frames covering analytics, sponsorship, merch and community homepage

Feature deep dives

For load-bearing features, memberships, ticketing, permissions, cross-functional deep dives with engineering and product align behaviour, edge cases and 'done' before any work starts.

How it got made

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.

Tribe events discovery with map and calendar

Tribe insights dashboard with growth trends and conversion metrics

Tribe community manager dashboard with membership management table

High Fidelity Designs

Skipped wireframes and worked straight in the production system, pulling components rather than redrawing screens. Every iteration feeds back into the system the next feature builds on, design compounds instead of fragmenting.

PDR document for Membership and Refund & Cancellations features

PDR's & Functional Specs

A functional spec for every load-bearing feature, behaviour, permissions, edge cases and failure states the designs alone can't carry. Engineering builds against it, QA verifies against it, hand-off stays clean.

What we learned shipping it

Tribe user testing notes and product iteration evidence

Prototyping & User testing

Every load-bearing flow, onboarding, membership purchase, event creation, ticketing, is prototyped in Figma and tested with active organisers before it reaches the community. Two findings reshaped the build: membership purchase had to live inside the event flow, not beside it, and refunds needed to be self-serve or organisers wouldn't run paid events at all. Both fed back into the spec before engineering started.

Conclusion

A year in, Tribe is a platform organisers run their community on day-to-day, end-to-end, on a foundation the team keeps shipping into.

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.

Other case studies

Website · Hospitality & Discovery

Mobile App · Everyday Experience

Website · Health & Community