Startups & scaling teams

Once six to ten people are moving across a product, word of mouth stops being a reliable way to share context. The plan needs clear boundaries and visible outcomes, and it can have both without copying the org chart. The example below uses two product-line projects, stable system areas, and one active release per project.

Recommended setup at a glance

Part	Example setup
Projects	Core app and Public API
Product context	A shared support inbox where a team handles every customer conversation and account in one place
Core app areas	Auth, Permissions, Workspace, Billing, Dashboard
Active release	Enterprise permissions
Starter tasks	Define roles, enforce workspace permissions, add an access audit, migrate existing members
Cadence	One release owner; weekly feedback triage; fortnightly release review
Agent role	Retrieve cross-project context, draft scoped work, keep updates attached to the source task

Split projects by product line, not by team

Keep one project while the team ships one product. Add a second project only when a product line has its own release sequence, backlog, audience, and ownership. Core app and Public API qualify because each ships on its own schedule.

Don't create projects for engineering, design, marketing, or temporary squads. That structure breaks the first time responsibilities move, and it makes a single launch hard to read. Disciplines can contribute to the same release without owning separate plans.

Write product context for each project. The Core app context explains the user workflow and what the business gets from it. The Public API context explains who integrates with it and what compatibility promises shape its work.

Organise areas around systems

Areas should survive a reorg. Use names like Auth, Permissions, Workspace, Billing, and Dashboard, and describe what each system owns. Avoid "Platform squad", "Growth team", or "Q3 initiatives".

A stable area set means tasks, releases, feedback, and agents keep the same meaning while people move around. If an area gets too big, improve its description before inventing a hierarchy. If two areas always move together, combine them.

Set a release cadence without a sprint ritual

Each project has one active release. Name it after a result the team can verify, like Enterprise permissions, rather than a date. Give it a release owner who keeps the outcome, scope, and target current. Task ownership can still sit with several people.

Review scope every two weeks, or whenever the outcome changes. Three questions cover it: does this release still matter, is every included task required, and is any dependency hidden? Move later work out rather than letting the active release become a permanent bucket.

Completed releases are how you communicate what shipped. A clean release history beats a roadmap full of dates nobody trusts.

Turn feedback into a queue you trust

At this size, feedback arrives through sales, support, calls, and direct reports. Route it into the Feedback Portal so it gets reviewed before it becomes planned work. Rotate one owner to triage new submissions each week.

Triage is not a promise to build. Confirm the problem, link duplicates, and decide whether the item belongs in the backlog or the active release. The original feedback stays attached, so whoever owns the task sees the user context without digging through another system.

See progress without chasing it

The dashboard should answer whether the release is moving, where open work sits, and what changed recently. Leaders read project health without asking contributors to restate progress; contributors use the same view to spot stale tasks and unowned work.

If the numbers look wrong, fix the task or release state that produced them. The dashboard is an output of a current plan, not a second thing to maintain.

Give agents the same boundaries as the team

Connect coding agents to the project and repository they work in, and use auto-tracking so work can't land in the wrong project. Agents read the relevant product context, active release, area, and task before changing code.

Keep agents scoped to named tasks. Let them propose follow-up work, but the team decides whether it belongs in the current release. That preserves one plan even with several agents active at once. See the plugin guide.

Keep a steady rhythm

1. Triage new feedback weekly and assign an owner to anything needing investigation.
2. Review active release scope and dependencies every two weeks.
3. Check dashboard health and recent activity before requesting status updates.
4. Revisit project and area boundaries only when the architecture changes.