How we use Teams & Projects for the product management of Clubhouse

March 6, 2019

Heather PurdyProduct Lead at Clubhouse

Note: This is the second post in a series of four posts on how we use Clubhouse for the Product Management of Clubhouse. For other posts in the series check out the links at the end of the post!

Now it’s time to look at how we use Teams & Projects. In Clubhouse (the product), a Team is a collection of related Projects with the same workflow. At Clubhouse (the company), the relationship of the Projects could be based on role, purpose, department, or any number of other factors.

“Teams” should:

Have a clear purpose.
A clear workflow that aligns with its purpose.
An understood owner (either a group or individual).

Some of the ways we group projects into “Teams”:

All Projects related to active development.
All Projects related to active development for a specific squad.
Backlog management.
Team specific Projects (Marketing, CX, etc.) that aren’t part of another purpose (like active development).

Because of the way we use Teams means that Projects can be used for any number of purposes, Projects do not have a specific definition. Their content and format depend on usage. However, we do have some considerations when creating and using Projects.

Does the content of the Project match the purpose of the ‘team’?
Is a label or epic more applicable?
Does the Project have a clear purpose or goal?

Teams & Projects in action at Clubhouse

To illustrate this a little further, let’s look at two types of “Teams” we use at Clubhouse: one based on a department - in this case, Engineering - and one based on a purpose - in this case, Unsolved User Problems. Due to their different natures, each one has a specific workflow (which I’ll also detail).

Engineering as a Clubhouse Team:

At Clubhouse “Engineering” projects are where any given group (e.g., backend, frontend, DevOps, etc.) goes to see what work they have assigned to them, which is related to active development. “Active development” includes any story that has been prioritized either because its parent Epic is linked to a current Milestone or because the story was prioritized in a prioritization planning meeting.

Engineering Projects should:

Have one project per group involved in active development, including non-engineering teams responsible for deliverables (like design, marketing).
Organized in a way that can be used in daily/weekly standup/planning meetings.
Include only work that has been prioritized.

Engineering Projects should not:

Include work not related to active development.
Include backlog work or other unprioritized work.

Projects within the Engineering Team look about how you’d expect. There’s the standard “group” stuff that you’d expect, i.e.:

Backend
Frontend
DevOps

We also have additional projects for work done in support of Engineering stories, while not sitting within the Engineering “department” or team, i.e.:

Design: work by the Design team in support of Engineering stories.
Product: work by the Product team in support of Engineering stories.
Analytics: analysis in support of Engineering stories. e.g., feature releases.
CX: work by the CX team in support of engineering stories. e.g., feature releases.
Marketing: marketing work in support of engineering stories, e.g., feature releases.

The Engineering Team’s workflow tracks the progress of work. The workflow looks like this:

Unstarted:

Spec Needed
Ready for Dev

Started:

In Development
Ready for Review
Deployed to Staging/Canary
Ready for Deploy

Done:

Completed

Unsolved User Problems as a Clubhouse Team:

The Unsolved User Problems ‘Team’ (UUP) is where all feature requests and known user problems are recorded and triaged. This is where all non-active development stories/ideas/requests are kept until they are moved into active development. All your personas can be accounted for in UUP including, your internal tech teams, APIs, internal stakeholders, etc.; they do not need to be limited to your end user personas.

UUP Projects should:

Be specific enough that it’s clear where to put a request but not so specific that we have many overlapping projects
Have a clear description
Contain stories that are worded with a clear user problem rather than a specific solution to a user problem (possible solution ideas can be listed in the notes)

UUP Projects should not:

Be feature specific

Here’s some examples of projects we have in our UUP team:

Epics: Issues specific to Epic creation and management.
Milestones: Issues specific to Milestone creation and management.
Notifications (In-App & External): All triggered notifications.
Integrations: Any 3rd party/external integration requests.
Billing (User Facing): User-facing billing issues.

Unlike Engineering’s workflow, which tracks progress, the UUP workflow tracks the priority of work:

For Discussion: New requests that haven’t yet been assigned a priority, or that a team member would like to open up again for discussion.
Low Priority: Someday we may do these things, but they’re not a current priority.
Medium Priority: Candidates for next sprint/quarter but not critical enough to interrupt current priorities/roadmap.
High Priority: Highly critical and should be slotted into the current sprint/quarter as soon as reasonable.
Won’t Do/Outside Strategy: Based on current vision and strategy, we’ll never work on this request.

Priority for stories is discussed and decided in a weekly prioritization meeting. After a UUP Story has been prioritized, and work begins on it, it will get moved out of the UUP Team and into the relevant Project within the Engineering Team, converted into an Epic if necessary.

“Back-office” teams

But what about work that isn’t related to the product itself, i.e. “back-office” stuff like brand marketing, recruiting and customer support? We account for these as separate Teams, e.g. Marketing, People & Recruiting, CX, etc. As mentioned, due to its sensitive and confidential nature, Finance has a separate, private Workspace.

To illustrate, here’s how some Teams look in Clubhouse: