How Cohorts Work

The methodology. How a cohort comes together, runs a cycle, and hands off. Written so a new cohort member or sponsor can pick up the pattern without asking.

The cycle

A cohort runs a four to six week cycle. Every cycle mixes the same activities, described in the founding brief: opportunity review and selection, workflow mapping and requirements, rapid validation and lightweight build, office hours and unblockers, handoff into execution, and readout and knowledge sharing. A good cohort leaves behind a workflow with fewer manual handoffs, clearer operating patterns, and a team that can keep applying the same approach.

Roughly phased over the weeks:

Week 1 — opportunity review and scope lock. The cohort meets, agrees what's in and out, and defines what success looks like.
Weeks 1–2 — workflow mapping. Interviews, trace a real piece of work through the full lifecycle, surface handoffs and bottlenecks.
Weeks 2–4 — rapid validation and lightweight build. Produce prototypes, skills, or playbooks and test them with real users.
Weeks 5–6 — handoff and readout. Package what's ready, write the monthly Operating Council readout, graduate.
Throughout — office hours, unblockers, and async collaboration. Goose Group is available through the day, not just in working sessions.

Not every cycle produces the same artifacts. Every cycle produces something Balsam can keep using after the cycle ends.

How a cohort gets formed

1. Idea enters the backlog

Either via intake, Operating Council nomination, or the COE's own triage. The idea becomes a one-pager: what the workflow is, why it matters, what success looks like.

2. Operating Council picks the next cohort

From the backlog. Monthly decision. The COE presents the top candidates; the Council picks one (and, after the first few months, sometimes two concurrent cohorts).

3. Sponsor named, roster proposed

The business leader closest to the workflow sponsors the cohort. The COE proposes the roster — core owners, participants, adjacent ring — with rationale. Sponsor signs off.

4. Cohort package created

A directory in cohorts/ based on the TEMPLATE. The package contains:

A pitch doc (the one-pager that got it approved)
A roster (who's in, what role, why)
A scope doc (what's in, what's out, what we're testing)
A readouts folder (populated during the cycle)
An artifacts folder (what gets built)

5. Kickoff

First working session. Everyone in the cohort together. Review the pitch. Agree the scope. Set the rhythm. Confirm who's doing what.

Who goes in a cohort

Three archetypes. Miss any of them and the cohort limps.

Someone who does the work today. The core owner. They know the current workflow because they live in it. They feel the friction and they know what a good day looks like.

Someone who uses the output. A consumer. They know what's wrong with what the workflow produces from a different angle. They see things the owner doesn't.

Someone who can build. A hacker — a developer, technical operator, or AI-fluent contributor. They can move from idea to working thing quickly. They don't have to be on the workflow today; they bring capability the core owners can pair with.

A cohort without a hacker tends to produce good analysis and no shipped thing. A cohort without a consumer tends to solve the wrong problem. A cohort without a core owner tends to build something nobody uses. All three matter.

What we look for across the group:

People who are ready to build and experiment, not people who need onboarding on basic tools.
Mixed altitudes — a leader who can clear blockers and operators who do the hands-on work.
People whose day jobs are close enough to the workflow that the cohort is not extra work — it's their existing work, done differently.

How the COE supports a cohort

During a cycle:

Weekly working session. Two to three hours with the full cohort. The COE facilitates, but the cohort drives.
Weekly 1:1s with core owners. Goose Group and the core owners go deep on whatever is in front of them.
Daily async. Slack channel per cohort. Goose Group available through the day.
Hands-on build support. When the cohort wants to prototype something, Goose Group pairs with them or builds alongside. We do not just advise.
External build partner coordination. If the cohort's work needs engineering beyond what the COE can do, Goose Group scopes the work and manages the partner engagement (build-partner.md).
Readout preparation. Goose Group is primary pen on the monthly readout. The cohort contributes; we write the doc.

Being the adult in the room

Beyond the mechanics, the COE's job is to provoke bigger thinking. Product teams get stuck. They spend months on the wrong problem. They don't talk to the VP who would decide the thing. They order a thousand prototypes before asking whether anyone actually needs the product.

Goose Group has been in that room before. A useful share of our time inside a cohort is asking uncomfortable questions: Why hasn't anyone talked to so-and-so? Why are we assuming this is what the customer wants? What if we just skipped this step entirely? The answers surface faster than the team's normal meeting rhythm allows.

This is not consulting-by-skepticism. It is pattern-matching from having built the kind of thing the cohort is trying to build, in bigger and messier contexts, and knowing which assumptions usually turn out to be wrong.

What a cohort produces

The outputs vary by cohort. A non-exhaustive list:

A workflow map of how the work moves today.
A scope doc describing what the cohort tested, what worked, what didn't.
Prototypes, scripts, or internal tools — code that lives in the cohort's package and can be extended.
Skills — reusable AI prompts and configurations for specific tasks in the workflow.
Playbooks — how-to documents for the pattern the cohort validated.
A readout — what was built, what was learned, what the recommended next step is.
A handoff package — if something validated needs production engineering, the package contains the requirements, the evidence, the pitch, and the estimate.

All of it lives in the cohort's directory. After the cycle, it stays there as the record.

Graduation and alumni

When a cycle ends, the cohort graduates.

What happens immediately:

Monthly readout to the Operating Council.
Handoff package delivered if the work needs to continue.
Cohort package frozen — further work on the same topic goes in a new package or into the shipped product.

What happens over time:

Core owners move into the alumni ring. They stay available for office hours, coach the next cohort, and carry the learning into their day job.
Participants move into the adjacent ring or into the next cohort if the fit is there.
The skills, playbooks, and patterns the cohort produced become shared infrastructure the whole company can use.

Propagating the work

When a cohort ships something good, the COE doesn't just publish the readout and wait for adoption. We actively propagate the work into adjacent teams.

In practice that means:

Booking time with the people who should use it. If the cohort built a workflow improvement, the COE schedules sessions with the teams upstream and downstream to demo, install, and coach.
Turning cohort output into starter kits. A skill a cohort built for one team gets generalized into a template the next team can adapt. A workflow map becomes a pattern others can trace.
Pulling the right next cohort from the ring. People who saw a neighboring cohort's work and want to run one of their own are the best candidates for intake. The COE invites them directly.
Surfacing the pattern at all-hands or leadership venues. Good cohort work is visible. The COE makes it visible.

The goal is compounding. One cohort's output is the next cohort's starter kit. One cohort's alumni are the next cohort's participants. The longer the COE runs, the less legwork each cohort has to do from scratch.

What a cohort is not

A cohort is not:

A training program. People join because they are doing the work, not because they need to learn about AI.
A strategy deck. A cohort that produces a deck and no shipped thing has failed the test.
A permanent team. Four to six weeks, then graduation.
A workshop series. The ratio of doing to discussing should be high.
A cross-functional committee. Decisions belong to the sponsor and the core owners, not to consensus.

Failure modes we watch for

The cohort becomes a meeting. Treat this as a cohort-threatening problem. Working sessions should be working, not status updates.
The hacker isn't hacking. If prototypes aren't shipping by week three, something is wrong. Either the scope is too big, the blockers aren't getting cleared, or the wrong people are in the room.
The shipped thing isn't being used. If the cohort produces a prototype and nobody adopts it, we surface that in the readout honestly. A cohort that shipped the wrong thing is more useful than a cohort that pretended it shipped the right thing.
The cohort can't end. If the work isn't done at week six, we graduate anyway and open a new cohort for the continuation. Packaging as a new cycle forces the handoff and the honest readout.