How we use Story Workflows (née Teams) & Projects for the product management of 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!

Update: As of 7/23/19 we have updated Teams and replaced it with a more descriptive name: Story Workflow. While the name has been updated no functionality has changed. Learn more about this change in this blog post.

Now it’s time to look at how we use Story Workflows (formerly Teams) & Projects. In Clubhouse (the product). A Story Workflow 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.

“Story Workflows” should:

Some of the ways we group projects into “Story Workflows":

Because of the way we use Story Workflows 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.

To illustrate this a little further, let’s look at two types of “Story Workflows” 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).

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:

Engineering Projects should not:

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

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

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

Unstarted:

Started:

Done:

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:

UUP Projects should not:

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

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

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.

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 Story Workflows, 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 Story Workflows look in Clubhouse:

Next up, we’re going to look at how we use Milestones & Epics at Clubhouse.

How do you use Story Workflows & Projects at your company? We’d love to hear about it on Twitter.