From 495d01a29a48be593d37f246f5af92e535c4b74e Mon Sep 17 00:00:00 2001 From: Srinivas Pendem Date: Fri, 21 Aug 2026 01:48:12 +0530 Subject: [PATCH 1/3] docs: add "How to Plane" quickstart guides by org size Add three guides under Quickstart guide for startups, growing teams, and enterprise teams, each covering plan choice, rollout structure, and when to move to the next model. Co-Authored-By: Claude Sonnet 5 --- apps/docs/docs/.vitepress/config.ts | 30 +- .../quickstart/enterprise-teams.md | 871 ++++++++++++++++++ .../introduction/quickstart/growing-teams.md | 779 ++++++++++++++++ .../docs/introduction/quickstart/startups.md | 439 +++++++++ 4 files changed, 2116 insertions(+), 3 deletions(-) create mode 100644 apps/docs/docs/introduction/quickstart/enterprise-teams.md create mode 100644 apps/docs/docs/introduction/quickstart/growing-teams.md create mode 100644 apps/docs/docs/introduction/quickstart/startups.md diff --git a/apps/docs/docs/.vitepress/config.ts b/apps/docs/docs/.vitepress/config.ts index 0595d889..ebeae667 100644 --- a/apps/docs/docs/.vitepress/config.ts +++ b/apps/docs/docs/.vitepress/config.ts @@ -266,7 +266,25 @@ const config = defineConfig({ text: "Get started", items: [ { text: "Introduction", link: "/introduction/home" }, - { text: "Quickstart guide", link: "/introduction/quickstart" }, + { + text: "Quickstart guide", + link: "/introduction/quickstart", + collapsed: true, + items: [ + { + text: "How to Plane: For startups", + link: "/introduction/quickstart/startups", + }, + { + text: "How to Plane: For growing teams", + link: "/introduction/quickstart/growing-teams", + }, + { + text: "How to Plane: For enterprise teams", + link: "/introduction/quickstart/enterprise-teams", + }, + ], + }, { text: "Core concepts", link: "/introduction/core-concepts" }, { text: "Tutorials", @@ -370,7 +388,10 @@ const config = defineConfig({ }, ], }, - { text: "Workspace Governance", link: "/workspace-administration/workspace-governance" }, + { + text: "Workspace Governance", + link: "/workspace-administration/workspace-governance", + }, { text: "Authentication", collapsed: true, @@ -383,7 +404,10 @@ const config = defineConfig({ }, ], }, - { text: "Workspace Audit Logs", link: "/workspaces-and-users/audit-logs" }, + { + text: "Workspace Audit Logs", + link: "/workspaces-and-users/audit-logs", + }, { text: "Billing and plans", collapsed: true, diff --git a/apps/docs/docs/introduction/quickstart/enterprise-teams.md b/apps/docs/docs/introduction/quickstart/enterprise-teams.md new file mode 100644 index 00000000..a7668bdc --- /dev/null +++ b/apps/docs/docs/introduction/quickstart/enterprise-teams.md @@ -0,0 +1,871 @@ +--- +title: "How to Plane: For enterprise teams" +description: Set up Plane across your organization with common governance, clear visibility, and enough flexibility for teams to work in the way that suits them. +--- + +# For enterprise teams + +Set up Plane across your organization with common governance, clear visibility, and enough flexibility for teams to work in the way that suits them. + +This guide is for CTOs, Heads of Engineering, IT and Platform teams, and Workspace Admins responsible for setting up and rolling out Plane across a large organization. + +By the end of this guide, you will have a practical model for choosing a deployment, setting up access, structuring workspaces, migrating teams, standardizing shared processes, and rolling Plane out across the organization. + +The goal is not to make every team work the same way. It is to give the organization a shared source of truth while letting every team work their own way. + +> **A useful rule:** Standardize what needs to be understood across the organization. Let teams decide what only affects their own work. + +If you are setting up Plane for a smaller organization, see [For startups](/introduction/quickstart/startups) or [For growing teams](/introduction/quickstart/growing-teams) instead. + +## Plan the rollout + +Start with the foundation, test it with one team, and expand from there. + +A practical rollout looks like this: + +1. Set up identity, access, and security. +2. Choose the deployment and workspace structure. +3. Define the standards teams will share. +4. Migrate one representative team. +5. Fix what you learn during the pilot. +6. Add teams in manageable groups. +7. Connect the tools teams already use. +8. Create clear intake paths. +9. Set up leadership reporting. +10. Add workflows and automation where they remove manual work. +11. Introduce AI after permissions and governance are in place. + +Bring the Security team into the process from the beginning. Include the platform or infrastructure team before migration, especially for self-hosted deployments and organization-wide integrations. + +The first team should be representative of the wider organization, but not under pressure from an immediate deadline. Document the decisions, problems, and changes that come out of the pilot. Use those lessons to improve the next phase of the rollout. + +> **Tip:** Avoid starting with either the simplest team or the most complicated one. Choose a team whose work, permissions, and integrations resemble what most teams will need. + +## Choose the right Plane plan + +The [Business plan](https://plane.so/pricing) covers many of the workflows in this guide, including advanced work management, custom properties, project templates, dashboards, intake, customers, and knowledge management. + +[Enterprise Grid](https://plane.so/enterprise-grid) is the better fit when the organization needs centralized governance, granular access control, LDAP support, API-enabled audit logs, multiple workflows and approvals, private or managed deployments, or migration and implementation support. + +Enterprise Grid includes: + +- Granular access control +- Custom roles and permission schemes +- Multiple workflows and approvals +- LDAP support and group synchronization +- API-enabled audit logs +- Private and managed deployment options +- Migration and implementation services +- Enterprise support +- Flexible AI credits and usage controls + +The right plan depends on the controls and deployment model the organization needs, not headcount alone. + +> **Note:** Feature availability can vary by plan and deployment. Check the current [Plane pricing page](https://plane.so/pricing) before finalizing your rollout. + +## Choose a deployment option + +Plane can be deployed in three ways: + +- **Cloud:** Plane manages the infrastructure and updates. +- **Self-hosted:** Plane runs in your organization's infrastructure. +- **Air-gapped:** Plane runs in an isolated environment with restricted or no external network access. + +Choose based on your security, infrastructure, network, and data requirements. + +| | Cloud | Self-hosted | Air-gapped | +| ------------------------------------------------------- | ------------------ | ----------------------------------------------------------------------- | ------------------------------- | +| Infrastructure, capacity, monitoring, incident response | Plane | Yours | Yours | +| Upgrades | Automatic | You schedule and test | You schedule, offline | +| Backups | Automatic | Yours, including recovery-testing | You, and you prove it | +| SSO | Business and above | SAML and OIDC from Pro and above | SAML and OIDC included | +| Network egress | Required | Required | None | +| Best when | No hard constraint | Residency, policy, or a contract requires you to control the deployment | Isolation is a hard requirement | + +Self-hosting gives the organization more control, but it also creates ongoing responsibility for deployment, upgrades, backups, monitoring, and recovery. Review the [self-hosting documentation](https://developers.plane.so/self-hosting/overview) before deciding whether your team can operate the deployment over the long term. + +Before choosing a deployment, confirm: + +- Where data must be stored +- Whether outbound network access is permitted +- Who will operate and upgrade the instance +- How backups and recovery will work +- Which integrations the deployment must support +- Whether approved AI providers can be accessed +- What availability and support commitments are required + +## 1. Identity, access, and governance + +Set up access before inviting teams or importing their work. + +Plane should fit into the identity and security systems the organization already uses. Retrofitting those controls after rollout creates avoidable cleanup. + +## Connect your identity provider + +Verify the organization's domain and configure the approved authentication method. + +Depending on the plan and deployment, Plane supports enterprise identity options such as [single sign-on](/authentication/sso), LDAP, and [identity-provider group sync](/authentication/group-sync). + +Directory-driven access makes onboarding and off-boarding easier to manage. It also reduces the number of permissions administrators need to maintain manually. + +Before rollout, test: + +- Sign-in for each required user group +- Group and role mapping +- New employee provisioning +- Role changes +- Employee off-boarding +- Guest access +- Administrator recovery access + +![Identity provider sign-in](https://media.docs.plane.so/for-enterprise/identity.webp#hero) + +> **Tip:** Test off-boarding as carefully as onboarding. Confirm that removing someone from the identity provider removes the access you expect it to remove in Plane. + +## Design roles around responsibilities + +Plane uses [roles and permissions](/roles-and-permissions/overview) at the workspace, teamspace, and project levels. + +Default roles cover common access patterns. Enterprise Grid organizations can use Granular Access Control to create [custom roles](/roles-and-permissions/custom-roles) from reusable [permission schemes](/roles-and-permissions/permission-schemes). + +**RBAC** is the default. Every user holds a role, either a system-defined one (owner, admin, member, guest, contributor, or commenter) or a custom one, and that role carries a fixed set of permissions. All plans include the system-defined roles. + +**GAC** unlocks custom roles, available on Enterprise Grid only. A role is what you assign to a user. A permission scheme is a named, reusable bundle of permissions that a role is built from. A custom role can combine one scheme or several, and its effective permissions are the union of everything attached to it, for example, a "Release Manager" role built from a Contributor scheme plus a custom Release Publishing scheme. + +A practical role model might look like this: + +| Role | Typical responsibility | +| ----------------- | ------------------------------------------------------------ | +| Workspace owner | Organization-level ownership, billing, and critical settings | +| Workspace admin | Members, projects, integrations, and workspace configuration | +| Project admin | Project configuration, membership, and delivery oversight | +| Contributor | Creating and updating project work | +| Commenter | Reviewing and commenting without changing project work | +| Guest | Limited access to selected projects | +| Security reviewer | Reviewing configuration, access, and audit activity | + +Keep the number of custom roles manageable. If two roles have nearly identical permissions, they probably do not need to be separate. + +> **Tip:** Name roles after responsibilities, not individuals or temporary organizational structures. "Security Reviewer" will remain useful longer than a role named after a person. + +## Keep external access limited + +Contractors, vendors, customers, and other external collaborators rarely need the same access as employees. + +Give each external user access only to the projects and actions required for their work. Decide whether they need to create work, edit it, comment, or simply follow progress. + +Review external access regularly. Project completion, contract changes, and extended inactivity are useful review points. + +> **Note:** Document who can invite external collaborators and who is responsible for removing them. Guest access should not become a permanent workaround for unclear access policies. + +## Set it up to be auditable + +Define audit requirements before rollout. + +Agree on: + +- Which administrative and security-sensitive actions need to be reviewed +- Who reviews audit activity +- How often access reviews happen +- Which events should reach existing security tools +- Whether logs need to be exported +- What records are required during an incident investigation + +Enterprise Grid provides [workspace audit logs](/workspaces-and-users/audit-logs) with time-stamped records of sign-ins, membership changes, role changes, settings changes, integration activity, and other security-sensitive events. Workspace Owners and Admins can filter and export the logs. + +**Workspace audit logs** + +![Workspace audit logs](https://media.docs.plane.so/for-enterprise/audit-logs.webp#hero) + +> **Tip:** Include audit-log exports in the organization's existing security review or evidence-collection process. Do not leave them as a feature that is only checked after an incident. + +## 2. Workspace structure + +Workspace structure determines where governance boundaries sit and how easily teams can collaborate. + +Create separate workspaces for meaningful boundaries such as business units, regions, legal entities, or confidentiality requirements. + +Different team workflows do not always require different workspaces. [Teamspaces](/core-concepts/workspaces/teamspaces), projects, roles, and project-level configuration can often provide the separation teams need within one workspace. + +**How work is organized in a Plane workspace** + +```text +Workspace +├── Projects +│ ├── Work items +│ │ ├── Work item types (Epics) +│ │ ├── Custom properties +│ │ ├── Sub work items +│ │ ├── Relations +│ │ ├── Comments +│ │ ├── Links +│ │ ├── Attachments +│ │ ├── Activity history +│ │ ├── Work logs +│ │ └── Archives +│ ├── Cycles +│ │ ├── Work items +│ │ ├── Burndown and progress +│ │ └── Work item transfer +│ ├── Modules +│ │ ├── Work items +│ │ └── Progress +│ ├── Milestones +│ │ └── Work items +│ ├── Views +│ │ ├── Layouts +│ │ ├── Filters +│ │ ├── Display properties +│ │ └── Access control +│ ├── Pages +│ ├── Intake +│ │ ├── Intake work items +│ │ ├── Intake forms +│ │ ├── Email intake +│ │ └── Triage +│ ├── Project updates +│ ├── Workflows +│ │ ├── States +│ │ ├── Transition rules +│ │ └── Approvals +│ └── Project settings +│ ├── General +│ ├── Members and roles +│ ├── Project states +│ ├── Labels +│ ├── Estimates +│ └── Features +├── Teamspaces +│ ├── Projects +│ ├── Work items [rollup] +│ ├── Cycles [rollup] +│ ├── Views +│ ├── Pages +│ └── Members +├── Wiki [workspace knowledge] +│ ├── Collections +│ │ └── Pages +│ ├── Pages +│ │ ├── Sub-pages +│ │ ├── Private pages +│ │ ├── Public pages +│ │ ├── Sharing +│ │ ├── Comments +│ │ ├── Version history +│ │ ├── Page templates +│ │ ├── Locking +│ │ └── Archives +│ ├── Blocks +│ │ ├── Headings and text +│ │ ├── Lists and to-dos +│ │ ├── Quotes +│ │ ├── Callouts +│ │ ├── Toggles +│ │ ├── Tables +│ │ ├── Code blocks +│ │ ├── Images and media +│ │ ├── File attachments +│ │ ├── External embeds +│ │ ├── Work item embeds +│ │ ├── Mentions +│ │ ├── Dividers +│ │ └── Database blocks +│ └── Databases +│ ├── Properties +│ ├── Views +│ └── Records +├── Initiatives +│ ├── Projects +│ ├── Epics +│ └── Work items [rollup] +├── Releases +│ ├── Work items +│ ├── Release tags +│ ├── Release labels +│ └── Changelog +├── Customers +│ ├── Requests +│ ├── Custom properties +│ └── Linked work items +├── Dashboards +│ ├── Private dashboards +│ ├── Public dashboards +│ ├── Widgets +│ │ ├── Bar chart +│ │ ├── Line chart +│ │ ├── Area chart +│ │ ├── Donut chart +│ │ ├── Pie chart +│ │ └── Number +│ └── Layout +├── Analytics +│ ├── Overview +│ ├── Projects +│ ├── Users +│ ├── Work items +│ ├── Cycles +│ ├── Modules +│ └── Intake +├── Plane AI +│ ├── Modes +│ │ ├── Talk to build +│ │ ├── Ask to know +│ │ └── Assign to ship +│ ├── Agents +│ │ ├── Built-in agents +│ │ ├── Custom agents +│ │ └── Skills +│ ├── Models +│ │ ├── Model routing +│ │ └── Model cocktailing +│ └── Usage +│ ├── Consumption +│ ├── Limits +│ ├── Per-model breakdown +│ └── Per-agent breakdown +├── Integrations +│ ├── GitHub +│ ├── GitHub Enterprise Server +│ ├── GitLab +│ ├── GitLab Enterprise +│ ├── Slack +│ ├── Sentry +│ ├── Draw.io +│ ├── Agents (Claude, Cursor, VS Code MCP) +│ └── Importers (Jira, Jira Server, Linear, Asana, ClickUp, Confluence, Notion) +└── Workspace settings + ├── General + ├── Members + ├── Roles and permission groups + ├── Granular access control + ├── Security and identity + │ ├── SSO / SAML / OIDC + │ └── LDAP (Enterprise Grid) + ├── Work item types + │ ├── Hierarchy levels + │ └── Type properties + ├── Automations + │ ├── Global automations + │ └── Project automations + ├── Plane Runner (Enterprise Grid) + │ ├── Transition scripts + │ ├── Automation scripts + │ └── Functions + ├── Billing and plans + ├── API tokens + ├── Webhooks + ├── Imports + ├── Exports + └── Audit logs +``` + +### Structure workspaces around real boundaries + +Enterprise Grid supports organizations that need to manage multiple workspaces under a shared enterprise arrangement. + +An organization might have separate workspaces for Product and Engineering, Business Operations, and a regulated regional operation. Within each workspace, teamspaces can group related people and projects. + +Ask these questions before creating another workspace: + +- Does this group need a separate security boundary? +- Does it have different regulatory or data requirements? +- Should administrators govern it independently? +- Does its work need to be hidden from the rest of the organization? +- Would a teamspace or private project provide enough separation? + +> **Tip:** Fewer workspaces are easier to govern. Add a workspace when it represents a real organizational boundary, not simply because a team wants different labels or states. + +### Set predictable visibility defaults + +Decide when projects should be public within the workspace and when they should be private. + +Broad visibility works well where discoverability and cross-team collaboration matter. Private access is more appropriate for confidential, customer-sensitive, security, legal, or personnel-related work. + +Document the default and its exceptions. Teams should not need to make a new policy decision every time they create a project. + +## 3. Shared standards + +Standardization should make work easier to understand across teams. It should not force every team into an identical operating model. + +A practical split looks like this: + +| Standardize across the organization | Leave to teams | +| ----------------------------------- | -------------------------- | +| Core work item types | Team-specific labels | +| Required project fields | Saved views | +| Shared workflow states | Board and list layouts | +| Project and work item templates | Cycle length | +| Approval requirements | Module structure | +| Update cadence | Local planning practices | +| Project naming rules | Optional custom properties | + +The exact split will vary. The important question is who needs to understand the information. + +If leadership compares something across teams, standardize it. If the information is only useful inside one team, let that team manage it. + +## Keep the work taxonomy small + +Use a small, consistent set of conventions for how work is organized across teams. Keep names predictable, use each object for its intended purpose, and review the taxonomy regularly. + +| Object | Suggested convention | Examples | +| ---------------------------------------------------------------------------------- | -------------------------------------------- | ------------------------------------------- | +| [Teamspaces](/core-concepts/workspaces/teamspaces#teamspaces) | Team or function name | Design team, Backend team, Platform team | +| [Projects](/core-concepts/projects/overview) | Product or workstream name | Mobile app, Product design | +| [Work item types](/work-items/workspace-work-item-types#workspace-work-item-types) | Singular noun naming the nature of work | Epic, Bug, Task, Feature request | +| [Modules](/core-concepts/modules) | Focused area of work or specific goal | Mobile push notifications, Website redesign | +| [Initiatives](/core-concepts/projects/initiatives#initiatives) | Long-term, strategic objective | Q3-Q4 roadmap, FY27-28 GTM strategy | +| [Labels](/core-concepts/issues/labels#work-item-labels) | Classification or characteristic of the work | Enhancement, security, performance | + +Avoid creating multiple names for the same concept. Synonyms such as `bug`, `Bug`, `bugs`, and `defect` make cross-project reporting harder to trust and understand. + +Teams can add properties for their own context, but the common work item types should remain easy to recognize across the organization. Plane supports both [workspace work item types](/work-items/workspace-work-item-types) and [project work item types](/work-items/project-work-item-types). + +> **Tip:** If a new employee needs a glossary to tell two work item types apart, the taxonomy is probably too detailed. + +## Create reusable project templates + +[Project templates](/templates/project-templates) give teams a reliable starting point without requiring administrators to configure every project. + +A template can include the project structure and configuration that a recurring type of work needs. Create templates for repeatable processes such as product development, incident response, customer implementation, or security review. + +Do not create a separate template for every team. A smaller set of well-maintained templates is easier to understand and update. + +**Project template** + +![Project template](https://media.docs.plane.so/for-enterprise/project-templates.webp#hero) + +## 4. Migration + +Define the target workspace structure and shared standards before the first import. + +Start with one representative team. Validate the structure, permissions, work item mapping, and reporting before moving additional teams. + +Plane provides [importers](/importers/overview) for Jira, Linear, Asana, ClickUp, Confluence, Notion, and CSV data. + +During the pilot, check: + +- User and assignee mapping +- Project and work item structure +- States and workflows +- Labels and custom fields +- Comments and attachments +- Links between related work +- Dates and historical information +- Permissions after import +- Reporting after import + +Not every field from the old system needs to be preserved. Keep information that remains useful and archive what no longer has operational value. + +> **Tip:** Do not redesign every process during migration. Define the target structure, move representative work into it, and adjust based on what the pilot reveals. + +**Importer mapping** + +![Importer mapping](https://media.docs.plane.so/for-enterprise/imports.webp#hero) + +**Migration guides:** [Import from Jira](/importers/jira) | [Import from Linear](/importers/linear) | [Import from CSV](/importers/csv) + +Planning a large migration? [Talk to the Plane team](https://plane.so/talk-to-sales) about migration planning and implementation support. + +## 5. Strategy and planning + +Leadership needs a view of strategic work without requiring teams to report every task upward. + +### Connect initiatives to projects + +[Initiatives](/core-concepts/projects/initiatives) bring related projects together around a larger objective. + +Leadership can follow progress, dates, owners, and state at the initiative level. Teams can continue managing delivery through projects, cycles, modules, milestones, and work items. + +Keep initiative names focused on the intended outcome. "Improve enterprise activation" communicates more than "Activation projects." + +**Initiative** + +![Initiative](https://media.docs.plane.so/for-enterprise/initatives.webp#hero) + +> **Tip:** An initiative should help leadership understand progress and make decisions. If it only groups unrelated projects, it will not provide a useful strategic view. + +### Give every project an owner and outcome + +Every active project should have: + +- A clear name +- One accountable owner +- A defined outcome +- A target date or planning horizon +- A current state +- A regular update + +Choose a project naming convention while the number of projects is still manageable. + +For example: + +- ENG / Enterprise SSO +- ENG / Mobile App +- GTM / Customer Expansion +- OPS / Regional Rollout + +The exact format matters less than consistent use. + +## Cycles, Modules, and Milestones + +All three give teams different ways to organize and track project work. + +**Cycles** help teams plan work within a defined period, such as a week, two weeks, or a month. Teams can use them to decide what to focus on next, monitor progress during the cycle, and carry unfinished work forward when needed. + +**Modules** group work connected to the same feature, component, or deliverable. A module can span multiple cycles, making it useful for tracking work that belongs together but will not be completed within a single planning period. + +**Milestones** mark significant points in a project, such as a beta release, security review, product launch, or customer rollout. They give teams and stakeholders a clear view of the major outcomes and dates that matter. + +For example, a mobile app launch may be tracked as a milestone. Authentication, onboarding, and notifications may be organized into separate modules, while the work required for each module is planned across several cycles. + +Teams can use all three together or only the ones that fit their planning process. + +**Cycles** + +![Cycles](https://media.docs.plane.so/for-enterprise/cycles.webp#hero) + +## 6. Integrations + +Connect the systems that already create or update important work. For engineering organizations, this often starts with source control, error monitoring, and communication tools. + +Plane provides native integrations for tools including GitHub, GitLab, Sentry, Slack, Bitbucket, and Cursor. + +| Integration | Use case | +| -------------------------- | ------------------------------------------------------------------------------ | +| GitHub / GitHub Enterprise | Two-way sync between work items and pull requests | +| GitLab | Automatic linking and tracking of merge requests against work items | +| BitBucket | A single Plane workspace, connected to many Bitbucket workspaces, kept in sync | +| Slack | Work item creation, actions, and discussion sync, without leaving Slack | +| Sentry | Sentry issues converted into work items, with state kept in sync | +| Draw.io | Diagrams embedded directly into pages | + +Start with the integrations used by the pilot team. Confirm that work moves as expected before making them available organization wide. + +**Integrations** + +![Integrations](https://media.docs.plane.so/for-enterprise/integrations.webp#hero) + +## Define ownership before connecting tools + +For each integration, record: + +- The business purpose +- The system owner +- The Plane owner +- The permissions or scopes it receives +- Which workspaces or projects it can access +- Where credentials are stored +- How failures are monitored +- How access is reviewed +- What happens when the integration is removed + +API keys, OAuth applications, and webhooks should have named owners. Avoid credentials tied to an individual employee where a service or organization-level identity is available. + +> **Note:** An integration can create or change work without someone opening Plane. Treat it as part of the organization's access model. + +## Extend Plane through approved paths + +For organization-specific workflows, Plane provides a [REST API](https://developers.plane.so/api-reference/introduction), [webhooks](https://developers.plane.so/dev-tools/intro-webhooks), and tools for building custom applications and integrations. + +Keep custom extensions under shared ownership. Document what they do, which permissions they have, and how they are maintained. + +## 7. Intake and customer requests + +Incoming work needs one visible path and a clear owner. + +[Plane Intake](/intake/overview) can collect work through: + +- [In-app submissions](/core-concepts/intake) +- [Public forms](/intake/intake-forms) +- [Email](/intake/intake-email) + +Submissions enter a triage state before they become planned project work. Teams can review, clarify, accept, decline, merge, or prioritize requests before adding them to the backlog. + +## Give every intake queue an owner + +Decide: + +- Who reviews new submissions +- How quickly submissions should be reviewed +- Which information submitters must provide +- How duplicates are handled +- What qualifies for planned work +- How requesters receive an update +- Who covers the queue when the main owner is unavailable + +> **Tip:** Keep forms short enough that people will complete them, but collect enough context for the team to make an initial decision. + +**Intake requests** + +![Intake requests](https://media.docs.plane.so/for-enterprise/intake.webp#hero) + +Teams can create intake forms for structured submissions or accept requests through intake email. + +## Connect requests to delivery + +[Customers and customer requests](/customers) connect external demand to the work addressing it. + +Support and Customer Success teams can follow whether a request has been accepted, linked to planned work, or completed without maintaining a separate delivery tracker. + +**Customer requests** + +![Customer requests](https://media.docs.plane.so/for-enterprise/customers.webp#hero) + +## 8. Knowledge and documentation + +Shared knowledge should be easy to find outside individual projects. + +Use the [Wiki](/core-concepts/pages/wiki) for durable organizational knowledge such as: + +- Engineering standards +- Architecture +- Runbooks +- Product principles +- Planning processes +- Policies +- Decision records +- Onboarding material + +Project Pages are better suited to knowledge connected to a specific project, such as briefs, meeting notes, specifications, and launch plans. + +Organize the Wiki through [collections](/pages/collections) and [nested pages](/pages/nested-pages) so people can browse it without already knowing the title of the page they need. + +**Organization Wiki** + +![Organization wiki](https://media.docs.plane.so/for-enterprise/wiki-docs.webp#hero) + +## Keep decision records consistent + +For significant decisions, record: + +- What was decided +- Why it was decided +- Which alternatives were considered +- Who made the decision +- When it was made +- When it should be reviewed again + +A short, consistent decision record is more useful than a detailed document nobody maintains. + +> **Tip:** Link decision records to the projects, initiatives, or work items they affect. People should be able to move from the decision to the work without searching for it. + +## 9. Reporting and leadership visibility + +Reporting should answer a known question for a known audience. + +Teams need operational views. Functional leaders need progress, risk, and dependency information. Executives need a clear view of strategic commitments. + +## Start with saved views + +Saved views are often enough for recurring operational questions such as: + +- What is blocked? +- What is overdue? +- Which incidents remain open? +- What needs review? +- Which work has no owner? + +Do not build a dashboard if a saved view answers the question clearly. + +## Build dashboards around decisions + +[Dashboards](/dashboards) should help someone decide or act. + +Useful leadership questions include: + +- Which initiatives are at risk? +- Where are dependencies blocking delivery? +- Which projects have missed an update? +- What work is consuming capacity? +- What shipped during the current period? + +Keep dashboards focused. A screen filled with widgets can provide less clarity than three well-chosen measures. + +**Leadership dashboard** + +![Leadership dashboard](https://media.docs.plane.so/for-enterprise/dashboards.webp#hero) + +> **Tip:** Assign an owner to every dashboard. Review it periodically and remove anything that no longer informs a decision. + +## Set an update cadence + +Numbers show what changed. Updates explain why. + +A practical reporting rhythm might include: + +**Weekly functional updates** + +- Initiative progress +- Major blockers +- Material changes +- Decisions needed + +**Monthly executive updates** + +- Progress against commitments +- Major risks +- Capacity shifts +- Cross-team dependencies +- Changes since the previous update + +The cadence should match how often the audience can act on the information. [Project updates](/communication-and-collaboration/project-updates) give teams a consistent place to record health, progress, blockers, and next steps. + +## 10. Workflows and approvals + +Create [workflows and approvals](/workflows-and-approvals/workflows) around processes the organization genuinely needs to enforce. + +Shared workflows are useful for: + +- Production changes +- Security reviews +- Incident response +- Customer escalations +- Procurement +- Release readiness + +Approvals should represent real decision points. Adding approval steps to ordinary work slows teams down without improving control. + +For every approval, define: + +- What is being approved +- Who can approve it +- What information the approver needs +- What happens after approval +- What happens after rejection +- Who handles exceptions + +**Workflow with approval** + +![Workflow with approval](https://media.docs.plane.so/for-enterprise/workflows.webp#hero) + +> **Tip:** If approvals regularly happen outside Plane, check whether the workflow includes enough context and the right approver. + +## 11. Automation + +Automate stable, repeatable processes like: + +- Routing work based on type or property +- Updating a state after a defined event +- Adding standard comments +- Sending reminders +- Creating recurring work +- Calling an approved webhook +- Running scheduled maintenance +- Applying organization-specific business rules + +Start with a small number of automations that solve visible problems. Monitor the results before expanding them across projects. + +Plane supports project automations, while Enterprise Grid provides additional capabilities for organization-wide and more advanced automation requirements. Review the [custom automation documentation](/automations/custom-automations) and current plan comparison before deciding which automations belong in the rollout. + +**Automation builder** + +![Automation builder](https://media.docs.plane.so/for-enterprise/automation.webp#hero) + +For every automation, record: + +- What starts it +- Which conditions it checks +- Which actions it takes +- Which projects it affects +- Who owns it +- How failures are detected +- When it was last reviewed + +> **Note:** Someone should be able to explain why every organization-wide automation exists and what would happen if it stopped running. + +## 12. Plane AI + +Plane AI is built into the workspace you already use, not a separate chat window bolted onto the side. It reads and acts on the same projects, work items, and pages your team works in. What it's allowed to do without asking depends on the mode. + +## The three modes + +| Mode | What it does | +| --------- | -------------------------------------------------------------------------------- | +| Ask | Read-only. Answers questions from your workspace, changes nothing. | +| Build | Plans a set of actions, shows them to you as cards, waits for your confirmation. | +| Autopilot | Same planning as Build, but executes immediately. No review step. | + +![Plane AI modes](https://media.docs.plane.so/for-enterprise/plane-ai.webp#hero) + +Introduce Plane AI after the organization has clear permissions, reliable workflows, and defined data boundaries. + +[Plane AI](/ai/plane-ai) can help people search, summarize, draft, and work with project information. [MCP connectors](/ai/mcp-connectors) can extend that work to approved external tools and data sources. + +These capabilities should follow the same governance model as employees and integrations. + +## Set an AI policy + +Before broad access, decide: + +- Which AI features are approved +- Which teams and workspaces can use them +- Which model providers are permitted +- What data can be shared with external providers +- Whether private or locally hosted models are required +- How usage and cost are monitored +- Who reviews generated output +- Which actions require human approval + +The policy should distinguish between generating content and taking action. Summarizing a project update carries a different level of risk from changing work, calling an external system, or running a script. + +## Control access to MCP connectors + +Review each connector before making it available. + +Confirm: + +- What data it can access +- What actions it can take +- Which credentials it uses +- Which users or teams can use it +- Who owns the connection +- How access will be reviewed and removed + +Start with contained use cases and expand access only after the organization understands how the connector behaves. Teams building their own connections can use the Plane MCP server. + +> **Tip:** If an AI connection does not have a clear owner, it should not have access to organizational work or external systems. + +## 13. Ongoing ownership + +A successful rollout needs clear ownership after the initial implementation. + +| Area | Typical owner | +| ---------------------------------- | -------------------------------------------------- | +| Identity and access | IT or Security | +| Workspace structure and governance | Platform, Operations, or workspace administration | +| Migration | Platform team and team champions | +| Shared standards | Workspace administration and functional leadership | +| Integrations and API access | Platform and Security | +| Intake | The team receiving the requests | +| Dashboards and reporting | Functional or operational leadership | +| Workflows and automation | Platform team or workflow owner | +| AI and MCP connectors | AI governance owner, Security, and platform team | +| Adoption and training | Department champions | +| Self-hosted operations | Infrastructure or SRE | + +The exact owners will vary, but ownership should be explicit. + +Create a regular review for: + +- Administrators and privileged roles +- External users +- Inactive accounts +- Integrations and credentials +- Workspace and project visibility +- Organization-wide templates +- Workflows and automations +- Dashboards +- AI access and MCP connectors +- Self-hosted upgrades and backups + +> **Tip:** Keep the review lightweight and regular. A short quarterly review is easier to run than a large cleanup after access and configuration have accumulated for a year. + +## Roll out Plane with a clear operating model + +Plane gives large organizations a common operating system without requiring every team to work in exactly the same way. Establish governance centrally, roll Plane out team by team, and assign clear ownership as the system grows. + +## Where to go from here + +- **Live reference:** [Plane's docs site](https://docs.plane.so). This guide is a snapshot. That page has the current pricing, seat limits, and feature availability by plan. +- **Build on Plane:** [the developer docs](https://developers.plane.so), for the API, webhooks, the MCP server, and self-hosting guides. +- **Talk to sales:** [reach out here](https://plane.so/talk-to-sales), for Enterprise Grid scoping, migration services, or anything else this guide didn't answer. diff --git a/apps/docs/docs/introduction/quickstart/growing-teams.md b/apps/docs/docs/introduction/quickstart/growing-teams.md new file mode 100644 index 00000000..1e290d08 --- /dev/null +++ b/apps/docs/docs/introduction/quickstart/growing-teams.md @@ -0,0 +1,779 @@ +--- +title: "How to Plane: For growing teams" +description: Structure Plane for multiple teams, introduce the right capabilities at the right time, and create reliable cross-team visibility without adding unnecessary administration. +--- + +# For growing teams + +Once several teams share products, dependencies, and company goals, informal coordination stops being enough. Requests get lost, ownership becomes unclear, and leaders need answers that span more than one project. + +Plane gives each team a focused place to manage its work while creating enough shared structure for the company to plan and report across teams. + +This guide is for: + +- Operations leads +- Engineering and product managers +- Workspace Owners and Admins +- Anyone responsible for maintaining Plane alongside another role + +By the end of this guide, you will know how to structure Plane for multiple teams, introduce the right capabilities at the right time, and create reliable cross-team visibility without adding unnecessary administration. + +## Choose the right Plane plan + +[Plane Pro](https://plane.so/pro) is a practical starting point for many growing companies. It provides the structure needed to manage multiple teams, including Work Item Types, Teamspaces, Milestones, Initiatives, Dashboards, Wiki, time tracking, and advanced estimates. + +Move to [Business](https://plane.so/business), when the company needs capabilities such as: + +- Intake Forms and Intake Email +- Customer request tracking +- Reusable project and work item templates +- Recurring work +- Configurable workflows +- Custom automations +- Nested Pages and embeds +- Advanced reporting controls + +Review the current capabilities on the [Plane pricing page](https://plane.so/pricing) before choosing a plan. + +Most growing companies can begin with Plane Cloud. Consider self-hosting when infrastructure control, data residency, security policies, or customer requirements make it necessary. See the [Plane self-hosting documentation](https://developers.plane.so/self-hosting/overview) for deployment options. + +[**Compare Plane plans**](https://plane.so/pricing) + +## Import active work + +Plane provides importers for tools including [Jira](/importers/jira), [Linear](/importers/linear), and [ClickUp](/importers/clickup). You can also use the [CSV importer](/importers/csv). Review the [importers overview](/importers/overview) for all available migration paths. + +Move active work, recent context, and records the team still needs. Historical data that has no role in current planning or reporting can remain in a read-only archive. + +![Importing active work](https://media.docs.plane.so/for-growing-teams/imports.webp#hero) + +> **Tip:** Clean up states and labels before importing. Mapping several variations of "in progress" into Plane only carries the existing inconsistency into the new Workspace. + +## Set roles and ownership + +Start by deciding who will manage Plane at the Workspace level and who will manage each Project. + +### Assign Workspace Admins + +Keep the group of Workspace Admins small. They can change settings that affect every team, so assign this role only to people responsible for the overall Plane setup. + +### Assign a Project Admin to every Project + +Give each active Project at least one Admin who understands the team's workflow. Project Admins can manage members, states, features, and project-level settings without requiring Workspace Admin access. + +Plane separates Workspace roles from Project roles. Someone can remain a Workspace Member while serving as a Project Admin for the Projects they own. + +Use this access model as a starting point: + +| Responsibility | Recommended access | +| -------------------------------------- | --------------------- | +| Manage company-wide Plane settings | Workspace Admin | +| Manage a team's Project and workflow | Project Admin | +| Create and update the team's work | Member or Contributor | +| Review work without changing it | Commenter | +| Submit requests or access limited work | Guest | + +Review the [roles and permissions overview](/roles-and-permissions/overview) and [permissions matrix](/roles-and-permissions/permissions-matrix) before assigning access. + +### Limit access for external collaborators + +Give contractors, agencies, customers, and other external collaborators access only to the Projects they need. Use the Guest role when someone needs limited access without becoming a full Workspace Member. + +> **Note:** Team leads and managers do not automatically require Workspace Admin access. Project-level administration is usually enough. + +### Create consistency across Projects + +Teams do not need identical workflows. They need enough shared meaning for people to understand work across projects. + +Standardize the information that supports company-wide planning and reporting: + +- Priority definitions +- Broad state groups +- Ownership +- Target or due dates +- Work item relationships +- A small set of cross-project labels +- Project health and update language + +Teams can add local states, labels, properties, and views around this shared minimum. + +For example, one team may use states like "Development" and "Code Review" while another uses "In Progress" and "Verification". Both can still map active work to the same broad state group for cross-team reporting. + +## Organize teams and projects + +**How work is organized in a Plane Workspace** + +```text +Workspace +├── Projects +│ ├── Work items +│ │ ├── Work item types (Epics) +│ │ ├── Custom properties +│ │ ├── Sub work items +│ │ ├── Relations +│ │ ├── Comments +│ │ ├── Links +│ │ ├── Attachments +│ │ ├── Activity history +│ │ ├── Work logs +│ │ └── Archives +│ ├── Cycles +│ │ ├── Work items +│ │ ├── Burndown and progress +│ │ └── Work item transfer +│ ├── Modules +│ │ ├── Work items +│ │ └── Progress +│ ├── Milestones +│ │ └── Work items +│ ├── Views +│ │ ├── Layouts +│ │ ├── Filters +│ │ ├── Display properties +│ │ └── Access control +│ ├── Pages +│ ├── Intake +│ │ ├── Intake work items +│ │ ├── Intake forms +│ │ ├── Email intake +│ │ └── Triage +│ ├── Project updates +│ ├── Workflows +│ │ ├── States +│ │ ├── Transition rules +│ │ └── Approvals +│ └── Project settings +│ ├── General +│ ├── Members and roles +│ ├── Project states +│ ├── Labels +│ ├── Estimates +│ └── Features +├── Teamspaces +│ ├── Projects +│ ├── Work items [rollup] +│ ├── Cycles [rollup] +│ ├── Views +│ ├── Pages +│ └── Members +├── Wiki [workspace knowledge] +│ ├── Collections +│ │ └── Pages +│ ├── Pages +│ │ ├── Sub-pages +│ │ ├── Private pages +│ │ ├── Public pages +│ │ ├── Sharing +│ │ ├── Comments +│ │ ├── Version history +│ │ ├── Page templates +│ │ ├── Locking +│ │ └── Archives +│ ├── Blocks +│ │ ├── Headings and text +│ │ ├── Lists and to-dos +│ │ ├── Quotes +│ │ ├── Callouts +│ │ ├── Toggles +│ │ ├── Tables +│ │ ├── Code blocks +│ │ ├── Images and media +│ │ ├── File attachments +│ │ ├── External embeds +│ │ ├── Work item embeds +│ │ ├── Mentions +│ │ ├── Dividers +│ │ └── Database blocks +│ └── Databases +│ ├── Properties +│ ├── Views +│ └── Records +├── Initiatives +│ ├── Projects +│ ├── Work items (epics) [rollup] +│ └── Work items [rollup] +├── Releases +│ ├── Work items +│ ├── Release tags +│ ├── Release labels +│ └── Changelog +├── Customers +│ ├── Requests +│ ├── Custom properties +│ └── Linked work items +├── Dashboards +│ ├── Private dashboards +│ ├── Public dashboards +│ ├── Widgets +│ │ ├── Bar chart +│ │ ├── Line chart +│ │ ├── Area chart +│ │ ├── Donut chart +│ │ ├── Pie chart +│ │ └── Number +│ └── Layout +├── Analytics +│ ├── Overview +│ ├── Projects +│ ├── Users +│ ├── Work items +│ ├── Cycles +│ ├── Modules +│ └── Intake +├── Plane AI +│ ├── Modes +│ │ ├── Talk to build +│ │ ├── Ask to know +│ │ └── Assign to ship +│ ├── Agents +│ │ ├── Built-in agents +│ │ ├── Custom agents +│ │ └── Skills +│ ├── Models +│ │ ├── Model routing +│ │ └── Model cocktailing +│ └── Usage +│ ├── Consumption +│ ├── Limits +│ ├── Per-model breakdown +│ └── Per-agent breakdown +├── Integrations +│ ├── GitHub +│ ├── GitLab +│ ├── Slack +│ ├── Sentry +│ ├── Draw.io +│ ├── Agents (Claude, Cursor, VS Code MCP) +│ └── Importers (Jira, Linear, Asana, ClickUp, Confluence, Notion) +└── Workspace settings + ├── General + ├── Members + ├── Roles and permission groups + ├── Security and identity + │ └── SSO / SAML / OIDC + ├── Work item types + │ ├── Hierarchy levels + │ └── Type properties + ├── Automations + │ ├── Global automations + │ └── Project automations + ├── Billing and plans + ├── API tokens + ├── Webhooks + ├── Imports + ├── Exports + └── Audit logs +``` + +The Workspace is the shared company environment. Projects contain the work owned by a specific team, product, or area of responsibility. + +A project should have a clear group responsible for its backlog, workflow, and updates. + +Projects might represent: + +- Frontend +- Backend +- Mobile Applications +- Platform +- Infrastructure +- Security +- Product Design +- Growth +- Customer Experience + +Not every temporary initiative needs a new project. If several teams contribute to the same launch or company objective, keep their work in their existing projects and connect it through an Initiative or Milestone. + +See [how projects work in Plane](/core-concepts/projects/overview). + +### Keep project names clear + +Choose names that remain understandable as the company grows. + +| Project | Identifier | Description | +| ------------------- | ---------- | ---------------------------------------------------- | +| Web Application | WEB | Customer-facing web application | +| Backend | API | APIs, services, and core business logic | +| Mobile Applications | MOB | iOS and Android product development | +| Platform | PLAT | Shared developer infrastructure and internal tooling | +| Security | SEC | Product security, reviews, and remediation | + +Avoid names based on temporary managers, quarters, or internal abbreviations that new employees will not understand. + +### Keep project features focused + +Projects can have their own set of enabled features and workflows. This allows each team to work within the same Workspace without using an identical setup. + +Start with how the team plans and manages its work, then enable the features that support it. For example: + +- Engineering teams may use Cycles for planning, Modules for grouping related work, and Pages for project context. +- Support teams may rely on Intake and Views to review and organize incoming requests. +- Security teams may use Work Item Types and custom properties to capture risk, severity, and review details. + +**Projects organized by team** + +![Projects organized by team](https://media.docs.plane.so/for-growing-teams/projects.webp#hero) + +### Create Teamspaces for shared team context + +A [Teamspace](/core-concepts/workspaces/teamspaces) brings together the people, projects, Pages, Views, dependencies, and activity associated with a durable team. + +Create a Teamspace when a team works across more than one project or needs a shared place for its knowledge and reporting. + +For example, a Product Engineering Teamspace might include the Frontend, Backend, and Mobile Applications projects. A Platform Teamspace might include Infrastructure, Developer Experience, and Security. + +Teamspaces should follow real organizational ownership. Do not create a Teamspace for every temporary initiative, launch, or reporting category. + +A useful Teamspace description states: + +- What the team owns +- Which products or systems it supports +- Who depends on it +- Where requests should be submitted + +**Teamspace** + +![Teamspace](https://media.docs.plane.so/for-growing-teams/teamspaces.webp#hero) + +### Organize work by type + +Every work item has a type, and the type decides which properties that item carries. A Bug carries severity and environment. An Epic carries an owner and a target date. Projects start with one default type for general work. Use [Work Item Types](/work-items/project-work-item-types) to create the rest. + +Teams can create types such as Bug, Feature Request, Security Review, Incident Follow-up, or Content Request. Each type can have properties suited to the work. + +![Work item types](https://media.docs.plane.so/for-growing-teams/work-item-type.webp#hero) + +| Work Item Type | Useful properties | +| --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Epic | Owner (member), Target date (date), Health (dropdown: on track, at risk, off track), Success metric (text) | +| Bug | Severity (dropdown: S1 to S4), Environment (dropdown: production, staging, local), Affected version (text), Steps to reproduce (text), Regression (boolean) | +| Security Review | System (dropdown), Risk level (dropdown: critical, high, medium, low), Reviewer (member), Remediation due (date) | +| Content Request | Channel (dropdown: blog, docs, email, social), Audience (dropdown), Reviewer (member), Publish date (date), Brief (URL) | + +Keep the number of types manageable. If two types require the same information and follow the same workflow, they may not need to be separate. + +Work Item Types cannot be turned off after they are enabled for a project, although individual types can be disabled. Agree on the initial structure before enabling them broadly. + +### Keep labels useful + +Labels work best for information that people regularly filter, group, or report on. + +Useful shared labels might include: + +- Customer reported +- Technical debt +- Compliance +- Reliability +- Accessibility + +Do not create a label when the information already belongs in a state, priority, assignee, project, Work Item Type, or custom property. + +Give shared labels a clear owner. Merge duplicates and archive labels that no longer support a decision. + +### Create the Views teams need + +[Views](/core-concepts/views) save filters, layouts, grouping, and sorting without duplicating work items. + +Useful project Views include: + +- Unassigned high-priority work +- Work blocked by another team +- Customer-reported bugs +- Work due this month +- Items waiting for review +- Work without an estimate or target date + +Workspace Views bring together work from several projects. They can show all blocked work across Product Engineering, every security-related item due this quarter, or unassigned high-priority work across the company. + +Create Views around recurring planning, review, and delivery conversations. If no one uses a View to answer a question or make a decision, it does not need to be maintained. + +## Connect the tools teams already use + +Connect Plane to the tools your teams already use: + +- [GitHub](/integrations/github) and GitHub Enterprise for syncing issues and pull requests +- [GitLab](/integrations/gitlab) for linking issues and tracking merge requests +- [Bitbucket](/integrations/bitbucket) for connecting repositories and development activity +- [Slack](/integrations/slack) for creating work items and managing updates from Slack +- [Sentry](/integrations/sentry) for turning application errors into trackable work +- [Cursor](/integrations/cursor) for working with Plane issues from Cursor +- [Draw.io](/integrations/draw-io) for embedding diagrams in Plane Pages + +For custom connections, read the [Plane API](https://developers.plane.so/api-reference/introduction), and [webhooks](https://developers.plane.so/webhooks/overview). + +Review the [integrations overview](/integrations/about) for the complete list and setup instructions. + +Integrations exist so context lands next to the work. Commits, pull requests, and deploys show up on the work item they belong to. Errors arrive with the trace attached. A Slack thread becomes a work item without anyone leaving the channel. The repository still holds the code and the CRM still holds the account record, but the decision, its owner, and the evidence behind it end up in Plane. + +Enable integrations project by project. Confirm the events flowing in are the ones you want before applying the same configuration across the workspace. + +## Keep project knowledge close to the work + +[Project Pages](/core-concepts/pages/overview) hold context that belongs to a specific project, including: + +- Project briefs +- Technical decisions +- Research summaries +- Release plans +- Retrospectives +- Runbooks + +Link relevant Pages to work items so people can move directly between a decision and its execution. + +Use the [Workspace Wiki](/core-concepts/pages/wiki) for knowledge that applies across teams, including: + +- Planning principles +- Shared workflow definitions +- Product and engineering standards +- Onboarding material +- Security policies +- Release processes +- Incident procedures +- Shared terminology + +**Workspace Wiki** + +![Workspace wiki](https://media.docs.plane.so/for-growing-teams/wiki.webp#hero) + +Business adds [nested Pages](/pages/nested-pages) for larger documentation structures. Add nesting when a flat structure becomes difficult to navigate. + +## Manage incoming requests + +Give stakeholders a clear path for submitting work before requests begin arriving through direct messages, meetings, emails, and spreadsheets. + +### Set up Intake for each team + +[Plane Intake](/intake/overview) creates a queue where teams can review, clarify, accept, decline, or defer requests before they enter the project workflow. + +In-app Intake supports requests submitted by members and guests. Business adds [Intake Forms](/intake/intake-forms) for public submissions and [Intake Email](/intake/intake-email) for requests sent to a dedicated address. + +Create separate Intake paths when teams make different decisions. Product feedback, security reviews, design requests, and platform support should not all enter one company-wide queue. + +Each Intake queue needs: + +- A named owner or rotation +- A response window +- Clear acceptance criteria +- A small set of request categories +- A process for duplicates and incomplete requests +- A way to communicate the outcome to the requester + +Accepted requests should enter the team's normal project workflow. Intake should not become a second backlog that exists alongside the project. + +> **Note:** Intake captures demand. It does not determine priority. Teams must still compare accepted requests with existing commitments. + +**Review incoming requests before they enter the team's planned workflow.** + +![Reviewing incoming requests](https://media.docs.plane.so/for-growing-teams/intake.webp#hero) + +### Connect customer requests to delivery work + +Customer profiles and request tracking are available on Business. + +Use [Customers in Plane](/customers) to connect customer context to requests and delivery work. This helps teams answer: + +- Which customers are affected? +- How many customers raised a similar request? +- Is the request connected to planned work? +- Who needs an update when the work changes? +- Which customer segments are generating the most demand? + +Keep implementation work in the project that owns delivery. Customer records and requests should provide context, not create parallel copies of the same work. + +## Plan and organize delivery + +Introduce each planning object for a specific question the team needs to answer. + +### Organize time-based work with Cycles + +[Cycles](/core-concepts/cycles) are Plane's version of a sprint: a fixed window of time with work items committed to it. + +Pick a cadence and hold it, weekly, two weeks, or monthly. Each cycle gives you a commitment, a view of what was added or dropped mid-cycle, and a fixed point to review what shipped. + +A project runs one cycle at a time by default. Turn on parallel cycles when two teams in one project need separate cadences, or when the next cycle needs planning while the current one closes. + +Repeated carryover points at oversized work items, shifting priorities, unresolved dependencies, or more unplanned demand than the team can absorb. Read it as a signal about the work, not the person. + +**Cycles** + +![Cycles](https://media.docs.plane.so/for-growing-teams/cycles.webp#hero) + +### Group related work with Modules + +[Modules](/core-concepts/modules) group work by theme, component, feature, or deliverable. A Module spans Cycles. + +A Module might represent: + +- Authentication +- Mobile onboarding +- Billing migration +- Search improvements +- A launch campaign +- A backend service + +**Modules** + +![Modules](https://media.docs.plane.so/for-growing-teams/modules.webp#hero) + +A Module can span several work items. Work can remain grouped around the same deliverable even when it is completed over multiple planning periods. + +### Track important dates with Milestones + +[Milestones](/core-concepts/projects/milestones) align work around a meaningful target date or checkpoint + +Use Milestones for: + +- Product launches +- Contractual commitments +- Compliance deadlines +- Major migrations +- Quarterly deliverables + +A Milestone should represent a date the company intends to manage, not every internal deadline. + +> **Tip:** If the question is "When are we working on this?", look at the Cycle. If it is "What body of work does this belong to?", look at the Module. If it is "Which important date are we working toward?", look at the Milestone. + +### Connect detailed work through Epics + +An [Epic](/core-concepts/issues/epics) is a Work Item Type used as a parent for a larger deliverable. + +Create an Epic when a deliverable contains several related work items that need a shared owner, target date, health, and progress view. + +For example, an _Introduce passkeys_ Epic might contain work for: + +- Authentication service changes +- Web settings +- Mobile support +- Recovery flows +- Analytics +- Documentation + +Keep the Epic in the project that owns the outcome. Keep the Epic in the project of the team responsible for the outcome. When another team contributes, link their work items to the Epic. Their work stays on their board, and the Epic still shows everything feeding into it. + +Do not create an Epic for every small group of tasks. Use it when someone needs to monitor the larger outcome independently from its individual steps. + +## Coordinate work across teams + +Once teams manage their work consistently, connect delivery across projects and company priorities. + +### Track dependencies within projects + +Dependencies become difficult to manage when they are discussed in meetings but not represented in the system. + +Some work cannot start until other work is finished. That is what [work item dependencies](/core-concepts/issues/overview#add-dependencies) record. + +On the item that has to wait, add the item it is waiting for. Say the dashboard needs the API endpoint first: open the dashboard item and add the endpoint. Both items now show the link, from each side. + +When two items are connected but neither has to wait, use _related_. When the same thing was filed twice, use _duplicate_. + +![Work item dependencies](https://media.docs.plane.so/for-growing-teams/gatt-chart.webp#hero) + +An important dependency should make four things clear: + +- What is needed +- Which team owns it +- When it is expected +- What will be affected if it moves + +Assign an owner on both sides of the handoff and review blocked work during planning and project updates. + +### Connect team execution to company priorities + +[Initiatives](/core-concepts/projects/initiatives) connect related projects and work to a company-level outcome. + +Create an Initiative when leadership needs to understand progress across several teams. Examples include: + +- FedRAMP readiness +- GTM launch: MENA and APAC +- Zero critical vulnerabilities by end of year +- Data residency: EU and India +- Take 12 legacy services off the deprecated runtime + +Each Initiative should have: + +- A clear outcome +- One accountable owner +- A small set of success measures +- Connected projects or work items +- A target period +- Regular status updates + +Do not create an Initiative for an individual team project. Keep the number of active Initiatives small enough that leadership can genuinely prioritize between them. + +**An Initiative across projects** + +![An Initiative across projects](https://media.docs.plane.so/for-growing-teams/initatives.webp#hero) + +### Share project updates consistently + +[Project updates](/communication-and-collaboration/project-updates) communicate what changed, whether a project is healthy, and where attention is needed. + +A useful update covers: + +- Current health +- Progress since the previous update +- The next important step +- Risks or blockers +- Decisions needed +- Changes to scope or target dates + +Choose a cadence that matches the pace of the work. Weekly updates may suit an active launch, while monthly updates may be enough for longer-running internal work. + +Define On Track, At Risk, and Off Track consistently. If each team interprets project health differently, company-wide reporting will be difficult to trust. + +## Reports + +Build reporting after ownership, states, dates, and relationships are reliable. + +### Build Dashboards around decisions + +[Dashboards](/dashboards) combine information from multiple projects into charts, metrics, and tables. + +Start with the question the Dashboard needs to answer. Useful examples include: + +- Which high-priority work has no owner? +- What is blocked across Product Engineering? +- Which Initiatives are at risk? +- What is due this month? +- Which customer-reported bugs remain unresolved? +- How much Cycle work was added after planning? +- Where is work concentrated across products or priorities? + +Different audiences need different views. Team leads may need workload, blockers, and Cycle progress. Product leadership may need Initiative progress and customer demand. Executives may need a concise view of outcomes, health, and major risks. + +Keep each Dashboard focused. Remove widgets that no longer change a conversation or decision. + +Business adds advanced Dashboard widgets for deeper analysis and more flexible reporting. + +> **Note:** A Dashboard can only be as reliable as its underlying data. Improve ownership, states, dates, and relationships before adding more reporting. + +**Build Dashboards around the decisions teams and leaders make regularly** + +![Leadership dashboard](https://media.docs.plane.so/for-growing-teams/dashboards.webp#hero) + +## Automate stable workflows + +Business supports [custom automations](/automations/custom-automations) that use triggers, conditions, and actions to handle repetitive project work. + +Good early automations include: + +- Assigning a default owner to a specific request type +- Adding a label when a defined condition is met +- Notifying an owner when a request enters Intake +- Creating recurring operational work +- Applying a standard template to repeated work +- Moving completed work out of an active View + +Start with low-risk actions that have a clear owner. Monitor the results and review automations when workflows or team responsibilities change. + +Do not automate an unclear process or use automation to compensate for inconsistent data. It will reproduce the inconsistency faster. + +> **Tip:** Begin with stable processes where an incorrect action would be easy to identify and reverse. + +**A focused automation** + +![A focused automation](https://media.docs.plane.so/for-growing-teams/automation.webp#hero) + +## Introduce Plane AI gradually + +[Plane AI](/ai/plane-ai) can answer questions about Workspace data, prepare actions, generate charts, work with Pages, and help manage projects. + +Begin with read-only questions that help teams evaluate the quality of their Workspace information: + +- Which high-priority work items are unassigned? +- What is blocking the current Cycle? +- What shipped this week? +- Which customer requests are connected to planned work? +- How has the scope of this Cycle changed? + +![Plane AI answering workspace questions](https://media.docs.plane.so/for-growing-teams/plane-ai.webp#hero) + +Once you are satisfied with the answers, introduce reviewed actions for clearly defined work. A person should inspect proposed changes before they are applied. + +Allow autonomous actions only when the instruction is narrow, precise, and reversible. Avoid broad actions that can change several projects, owners, or commitments at once. AI works from the information in the Workspace. It cannot correct unclear priorities or missing ownership on its own. + +> **Note:** AI assistance does not transfer accountability. The project owner still owns the resulting plan, update, or Workspace change. + +## Roll Plane out across teams + +Set up the operating model before introducing Plane across the company. Rollout should then follow a repeatable team-by-team process. + +### Start with a representative team + +Choose a team with active work, a clear owner, and enough cross-team interaction to expose gaps in the setup. + +Define: + +- The project the team will work from +- The Work Item Types it needs +- A small set of states and priorities +- The work that needs to be imported +- The tools that need to connect to Plane +- The Views the team uses during planning and delivery + +Run the setup through one complete planning cycle. Note what the team changes, what information people struggle to find, and which parts of the workflow they actually use. + +> **Tip:** Choose a representative team, not the simplest one. A pilot without real dependencies or incoming requests will not show whether the setup can support the rest of the company. + +### Build adoption through daily work + +Adoption begins when Plane becomes part of the team's regular planning, reviews, and updates. + +For each team: + +- Assign a rollout owner +- Explain what belongs in Plane +- Provide a short onboarding Page +- Train people on the features relevant to their roles +- Collect feedback after the first planning cycle +- Remove parallel trackers once Plane is working reliably + +Measure adoption through working habits, not sign-ins. Teams should update work regularly, keep ownership visible, and answer delivery questions directly from Plane. + +> **Tip:** Establish a few consistent habits first. Add more capabilities as the team becomes comfortable with the workflow. + +### Expand to the next team + +Apply what you learned from the pilot before adding the next team. + +Reuse the shared definitions that worked, but adjust the project workflow, features, Views, and training to match the work the new team owns. + +Do not copy the pilot configuration. The goal is to preserve a shared operating model while giving each team enough flexibility to manage its work effectively. + +Repeat the process until teams can work from Plane consistently and company-wide reporting no longer depends on separate trackers or manual status collection. + +## Know when Enterprise becomes necessary + +A growing company does not need Enterprise simply because it has several teams. + +[Plane Enterprise Grid](https://plane.so/enterprise) becomes relevant when governance and infrastructure requirements become formal. Common triggers include: + +- Centralized identity and user provisioning +- LDAP or advanced directory requirements +- Detailed auditability +- Stricter access controls +- Managed or controlled deployment +- Formal security or compliance obligations +- Dedicated platform administration +- Multiple Workspaces requiring centralized governance + +At that point, the question is no longer only how teams organize work. It is also how the company controls access, enforces policy, verifies activity, and operates Plane as shared infrastructure. + +[**Talk to Plane about Enterprise Grid**](https://plane.so/talk-to-sales) + +For a governance-first walkthrough of that transition, see [For enterprise teams](/introduction/quickstart/enterprise-teams). + +## Keep the operating model simple + +A growing company needs coordination, but every team does not need to work in exactly the same way. + +Standardize the information that must be understood across teams. Let teams shape the rest of their workflow around the work they own. + +Start with real work. Add each planning layer for a specific reason. Keep ownership visible and review the system as the company changes. + +The goal is not to build the most detailed Plane Workspace. It is to give teams a system they can work from every day and give the company a reliable view of what it is delivering. + +## Where to go from here + +- **Live reference:** [Plane's docs site](https://docs.plane.so). This guide is a snapshot. That page has the current pricing, seat limits, and feature availability by plan. +- **Build on Plane:** [the developer docs](https://developers.plane.so), for the API, webhooks, the MCP server, and self-hosting guides. +- **Talk to sales:** [reach out here](https://plane.so/talk-to-sales), for Enterprise Grid scoping, migration services, or anything else this guide didn't answer. diff --git a/apps/docs/docs/introduction/quickstart/startups.md b/apps/docs/docs/introduction/quickstart/startups.md new file mode 100644 index 00000000..02d2ae7f --- /dev/null +++ b/apps/docs/docs/introduction/quickstart/startups.md @@ -0,0 +1,439 @@ +--- +title: "How to Plane: For startups" +description: A lightweight Plane setup for managing company priorities, product work, customer feedback, and delivery in one place. +--- + +# For startups + +Startups need enough structure to keep priorities, product context, and execution connected. They do not need a process for every possible situation. + +By the end of this guide, you will have a lightweight Plane setup for managing company priorities, product work, customer feedback, and delivery in one place. You will also know which capabilities to introduce as your startup grows. + +This guide is for startups and small teams that: + +- Work on one primary product or a small number of outcomes +- Share context directly across the team +- Have few formal handoffs +- Change priorities frequently +- Optimize for speed, learning, and customer feedback +- Do not yet need governance across several departments + +This often applies to organizations with fewer than 25 people, but your operating model matters more than your headcount. + +## 1. Plan Recommendation: Start with Plane Pro + +[Plane Pro](https://plane.so/pro) is the recommended plan if Plane will be the operating system for your startup. + +Pro gives you the structure to connect planning, execution, and company knowledge without requiring the workflow controls of a larger organization. It includes: + +- Custom work item types and properties +- Workspace Wiki +- Work item and page templates +- Initiatives +- Teamspaces +- Dashboards +- Time tracking and work logs +- Published pages and views +- 1,000 AI credits +- Integrations and the Plane Marketplace + +The [Free plan](https://plane.so/pricing) works when you need projects, work items, cycles, modules, views, project pages, estimates, and in-app Intake for a team of up to 12 users. + +Choose Free if you are testing Plane or need a shared backlog before you need company-wide knowledge, custom work types, templates, initiatives, time tracking, or additional workspace structure. + +> **Tip:** Start with Pro if you already know Plane will hold your product work and company context. Moving from Free to Pro does not require a new workspace or a second migration. + +## 2. Set up Plane + +Plane organizes work across four levels: + +| Level | What it represents | +| --------- | ---------------------------------------------------------- | +| Workspace | Your company's main environment in Plane | +| Teamspace | A stable team or function working across multiple projects | +| Project | A product area, outcome, or continuing stream of work | +| Work item | A task, bug, feature, improvement, or other unit of work | + +Understanding this structure first makes it easier to decide where projects, imported work, and connected tools should live. + +### Create one workspace + +Most startups should begin with one workspace for the company. This keeps members, projects, documentation, product context, and reporting connected. + +Create another workspace only when the company needs a genuine boundary, such as a separate legal entity, strict access requirements, or an independently managed business. + +### Add Teamspaces + +[Teamspaces](/core-concepts/workspaces/teamspaces) group related projects for stable teams or functions. + +A very small startup may not need Teamspaces immediately. Enable this feature when teams like product, engineering, design, content, and more work across multiple projects. + +Create Teamspaces around stable areas of responsibility, not temporary initiatives. A feature launch or company objective usually belongs in a project, module, or initiative rather than a new Teamspace. + +![Teamspaces](https://media.docs.plane.so/for-startup/teamspaces.webp#hero) + +### Create one or two projects + +[Projects](/core-concepts/projects/overview) should represent a defined product area, outcome, or continuing stream of work. + +A startup might begin with: + +- Product Development +- Website +- GTM - MENA + +Add another project when the work needs different ownership, access, workflow, or reporting. Do not create a separate project for every feature. + +**Projects Overview** + +![Projects overview](https://media.docs.plane.so/for-startup/projects-overview.webp#hero) + +### Invite the team + +Add members after the initial workspace structure is clear. Keep administrative access limited and give external collaborators access only to the projects they need. + +Review [roles and permissions](/roles-and-permissions/overview) before inviting contractors, agencies, advisors, or other external collaborators. + +### Connect development tools + +[Plane integrations](/integrations/about) keep development activity and team communication connected to the work in Plane. + +| Integration | What it connects | +| ---------------- | ----------------------------------------------------------------------- | +| GitHub or GitLab | Issues, pull requests or merge requests, commits, and delivery activity | +| Slack | Discussions, notifications, requests, and follow-up work | +| Sentry | Production errors and the work created to resolve them | + +Connect the tools your team already uses. An integration should reduce manual updates, make ownership clearer, or preserve context that would otherwise be lost. + +## 3. Import active work + +[Plane importers](/importers/overview) help you move existing work from tools such as Jira, Linear, Asana, ClickUp, Notion, Confluence, and CSV files. + +Import the projects and work your team still needs. Old backlogs, outdated labels, duplicate tasks, and abandoned processes do not need to follow the team into Plane. + +Start with one active project: + +1. Review the project and remove work that is no longer relevant. +2. Map users, states, labels, dates, and custom fields. +3. Run the import. +4. Check assignees, comments, attachments, and links. +5. Fix any structural problems before importing the remaining work. + +This first import gives you a chance to test the workspace structure before bringing everything across. + +**Importer mapping** + +![Importer mapping](https://media.docs.plane.so/for-startup/imports.webp#hero) + +## 4. Turn priorities into work + +Keep the execution model easy to understand. The team should spend more time delivering work than maintaining the system around it. + +### Define work item types + +[Work item types](/work-items/workspace-work-item-types) describe the nature of work your team manages. + +Start with a short list: + +- Feature +- Bug +- Task +- Improvement + +Add another type only when it changes how the team assigns, plans, filters, or reports the work. + +Use custom properties for information that helps the team make decisions, such as product area, customer impact, confidence, or release target. + +### Write useful work items + +A work item should give its operator enough context to act without reconstructing the original conversation. + +- Name the outcome or problem clearly. +- Assign relevant owners. +- Add the product or customer context that affects the work. +- Link the relevant Page, design, discussion, or pull request. +- Use sub-work items when several pieces of work contribute to one deliverable. + +Use an epic work item type when a larger deliverable contains several related work items that need to be tracked together. + +**Work item** + +![Work item](https://media.docs.plane.so/for-startup/work-item.webp#hero) + +### Keep workflows simple + +Begin with a small workflow such as: + +- Backlog +- Planned +- In Progress +- In Review +- Done + +Add a state only when it represents a meaningful change in responsibility or progress. + +Use labels for flexible context that does not need its own workflow state. Review labels occasionally and merge duplicates before they become part of the team's vocabulary. + +### Plan in short horizons + +A lightweight planning loop is enough for most startups: + +1. Choose the most important outcomes for the next planning window. +2. Break those outcomes into owned work. +3. Confirm priorities and dependencies. +4. Review progress during the window. +5. Carry forward only the work that still matters. + +Short planning horizons allow the company to respond when customer feedback, delivery constraints, or business priorities change. + +![Short planning horizons](https://media.docs.plane.so/for-growing-teams/gatt-chart.webp#hero) + +### Set priorities + +Priority should help the team decide what to work on next. + +Keep the priority scale small and apply it consistently. If everything is marked urgent, the field is no longer helping the team make a choice. + +### Plan recurring work with Cycles + +[Cycles](/core-concepts/cycles) give the team a recurring planning window without changing the underlying project structure. Cycles are Plane's equivalent to sprints. + +Introduce Cycles when the team plans and reviews work on a regular rhythm. Keep each Cycle short enough for the team to change direction as the company learns. + +### Group related work with Modules + +[Modules](/core-concepts/modules) organize work connected to the same feature, component, or deliverable. + +A module can span multiple Cycles, making it useful for work that belongs together but won't necessarily be completed in a single cycle. + +For example, a mobile application project might contain separate modules for Authentication, Onboarding, and Notifications. + +### Connect projects with Initiatives + +Use [Initiatives](/core-concepts/projects/initiatives) when several projects contribute to the same company objective. + +An initiative can connect product, engineering, growth, and operational projects without consolidating all the work items in a single project. + +Introduce Initiatives only when the startup is coordinating outcomes across multiple projects or spanning a longer term. One or two straightforward projects usually do not need another planning layer. + +### Estimates work when it informs a decision + +[Estimates](/core-concepts/issues/estimates) are useful when they help the team compare scope, identify effort, or decide what fits into a Cycle. + +Skip estimates when they add maintenance but do not change a planning or delivery decision. + +## 5. Document product decisions + +Product work is easier to understand and revisit when decisions, documentation, and delivery remain connected. + +[Project Pages](/core-concepts/pages/overview) hold briefs, specifications, meeting notes, and decisions connected to a project. + +The [Workspace Wiki](/core-concepts/pages/wiki) holds knowledge used across the company, such as: + +- Product principles +- Engineering standards +- Architecture +- Onboarding material +- Research +- Operating practices + +Keep project-specific context with the project. Move durable knowledge to the Wiki when people outside the project will need it again. + +![Workspace Wiki](https://media.docs.plane.so/for-startup/wiki.webp#hero) + +### Reuse repeated processes + +Create a template after the team has repeated a process enough to understand which information is consistently useful. + +- Use Page templates for briefs, decisions, retrospectives, and research notes. +- Use work item templates for common bugs, experiments, launches, or reviews. + +Do not turn every good example into a template. A small collection of maintained templates is easier to use than a large library of near-duplicates. + +### Record product learning + +For an experiment, discovery project, or major product decision, record: + +- The original assumption +- The evidence collected +- The result +- The decision that followed + +Link this record to the project or work items it changed. This preserves the reasoning behind the decision and prevents the team from repeating the same investigation later. + +> **Tip:** A short decision record written at the time is more useful than a detailed retrospective nobody can find later. + +## 6. Manage incoming work + +[Plane Intake](/intake/overview) gives requests and feedback submitted inside Plane a visible path into the team's workflow. + +### Create one Intake queue + +Start with one Intake queue and make one person responsible for reviewing it. + +The owner should: + +- Triage new submissions +- Clarify requests when necessary +- Merge duplicates +- Accept or decline each submission +- Decide whether accepted work belongs in the project backlog + +A single owned queue is easier to maintain than several channels that nobody reviews consistently. + +![Intake queue](https://media.docs.plane.so/for-startup/intake.webp#hero) + +### Move accepted requests into planned work + +Review each submission before adding it to the project backlog. + +An accepted request should become a work item with a clear owner, priority, and enough context for the team to act. Decline requests the team will not pursue and merge submissions that describe the same need. + +> **Tip:** Intake should support triage, not become another backlog that nobody reviews. + +## 7. Share progress + +Progress reporting should answer a recurring question. Start with the smallest view that gives someone enough information to act. + +### Create views for recurring questions + +Create saved Views for questions your team asks repeatedly: + +- What is blocked? +- What needs review? +- What is planned for the current Cycle? +- Which work has no owner? +- Which Intake submissions still need a decision? + +Keep personal Views flexible. Standardize a View only when several people rely on the same definition. + +### Publish project updates + +[Project updates](/communication-and-collaboration/project-updates) give stakeholders a predictable summary without requiring them to inspect individual work items. + +A useful update covers: + +- Current health +- Progress since the previous update +- Blockers +- Decisions needed +- The next step + +Keep the cadence consistent enough that a missed update signals a real gap. + +### Share selected work externally + +Publish a Page or View when an advisor, customer, investor, or partner needs selected information but should not have access to the workspace. + +Review the content before publishing and remove access when the information no longer needs to be shared. + +### Add dashboards when Views are not enough + +[Dashboards](/dashboards) help teams track work, create visibility, and compare progress across projects, all from one place. + +Build a dashboard around a decision, such as: + +- Which project is falling behind? +- Where is work blocked? +- How is the current Cycle progressing? +- Which projects have not been updated? + +A small dashboard with a clear purpose is more useful than a screen filled with widgets. + +### Track time when the data affects a decision + +Use time tracking when the team needs the data for client work, capacity planning, cost analysis, or another operational decision. + +Do not introduce time tracking as a default measure of individual productivity. + +## 8. Plane AI + +[Plane AI](/ai/plane-ai) helps whether a workspace is brand new or already full of work items, documentation, and project history. + +![Plane AI](https://media.docs.plane.so/for-startup/plane-ai.webp#hero) + +**Setting up a workspace** + +Use Plane AI to help a new team get moving instead of staring at an empty project: + +- Turn a brief, meeting note, or rough idea into a first set of work items +- Propose an initial project structure, states, labels, work item types, based on how the team says it works +- Draft a starting Wiki page or onboarding doc for a new project +- Suggest an initial Cycle or Module breakdown from a rough plan + +**Once work is underway** + +Use Plane AI to help the team move faster within work already in the system: + +- Find information across the workspace +- Summarize project context +- Draft work item descriptions +- Turn notes into a useful first version +- Improve existing content +- Flag likely duplicate work items +- Suggest labels for incoming requests +- Answer questions about workspace data, such as what's blocked or what shipped this week +- Draft a project update from recent activity + +Begin with tasks that save time without automatically changing work. + +## 9. Add structure as the startup grows + +Add a capability when the team can name the coordination problem it needs to solve. + +This keeps Plane useful as the company grows without turning a startup workspace into a complex operating system too early. + +### Add capabilities when coordination becomes difficult + +| Signal | What to add | +| ------------------------------------------------------- | ------------------------------- | +| The team plans within a recurring window | Cycles | +| Larger deliverables contain several related work items | Modules or epic work item types | +| Several projects contribute to one objective | Initiatives | +| Stable teams need separate spaces for their work | Teamspaces | +| The same work or document is created repeatedly | Work item or Page templates | +| Stakeholders need recurring metrics | Dashboards | +| Selected work needs to be shared externally | Published Pages or Views | +| Team members need a controlled path for submitting work | In-app Intake | +| Time data affects billing, capacity, or cost decisions | Time tracking | + +### Review the workspace every month + +A short monthly review keeps the setup useful: + +- Archive completed or abandoned projects. +- Remove stale Views, labels, and templates. +- Check unowned and blocked work. +- Review guest and external access. +- Confirm that integrations still have an owner. +- Update project status. +- Close outdated Intake submissions. +- Add structure only where the same coordination problem keeps returning. + +### Move to the growing teams setup + +The startup model is no longer enough when: + +- Several teams need shared standards. +- Leadership needs comparable reporting across teams. +- Access becomes harder to manage. +- The company regularly coordinates work across many projects. +- Different teams need separate operating models. +- Workspace administration becomes an ongoing responsibility. + +At that point, define a small set of shared work item types, project fields, update expectations, and workspace rules. Keep local planning decisions with teams unless the information needs to be understood across the company. + +See [For growing teams](/introduction/quickstart/growing-teams) for that setup. + +## Start using Plane Pro + +Begin with one workspace, add Teamspaces where stable teams need separation, create one or two projects, and import only the active work your team still needs. + +Connect the tools your team already uses, keep the workflow simple, and add more structure when a recurring coordination problem makes it necessary. + +[Start a 14-day Plane Pro trial](https://plane.so/pricing) + +### Related resources + +[Plane documentation](https://docs.plane.so/) | [Developer documentation](https://developers.plane.so/) | [Compare Plane plans](https://plane.so/pricing) From 97187aa7f7e9cf56e68bb3f94d92d59875e55cf6 Mon Sep 17 00:00:00 2001 From: Srinivas Pendem Date: Fri, 21 Aug 2026 12:07:37 +0530 Subject: [PATCH 2/3] docs: drop hero image frame from How to Plane quickstart guides Co-Authored-By: Claude Sonnet 5 --- .../quickstart/enterprise-teams.md | 28 +++++++++---------- .../introduction/quickstart/growing-teams.md | 26 ++++++++--------- .../docs/introduction/quickstart/startups.md | 16 +++++------ 3 files changed, 35 insertions(+), 35 deletions(-) diff --git a/apps/docs/docs/introduction/quickstart/enterprise-teams.md b/apps/docs/docs/introduction/quickstart/enterprise-teams.md index a7668bdc..d0d54a9a 100644 --- a/apps/docs/docs/introduction/quickstart/enterprise-teams.md +++ b/apps/docs/docs/introduction/quickstart/enterprise-teams.md @@ -118,7 +118,7 @@ Before rollout, test: - Guest access - Administrator recovery access -![Identity provider sign-in](https://media.docs.plane.so/for-enterprise/identity.webp#hero) +![Identity provider sign-in](https://media.docs.plane.so/for-enterprise/identity.webp) > **Tip:** Test off-boarding as carefully as onboarding. Confirm that removing someone from the identity provider removes the access you expect it to remove in Plane. @@ -175,7 +175,7 @@ Enterprise Grid provides [workspace audit logs](/workspaces-and-users/audit-logs **Workspace audit logs** -![Workspace audit logs](https://media.docs.plane.so/for-enterprise/audit-logs.webp#hero) +![Workspace audit logs](https://media.docs.plane.so/for-enterprise/audit-logs.webp) > **Tip:** Include audit-log exports in the organization's existing security review or evidence-collection process. Do not leave them as a feature that is only checked after an incident. @@ -432,7 +432,7 @@ Do not create a separate template for every team. A smaller set of well-maintain **Project template** -![Project template](https://media.docs.plane.so/for-enterprise/project-templates.webp#hero) +![Project template](https://media.docs.plane.so/for-enterprise/project-templates.webp) ## 4. Migration @@ -460,7 +460,7 @@ Not every field from the old system needs to be preserved. Keep information that **Importer mapping** -![Importer mapping](https://media.docs.plane.so/for-enterprise/imports.webp#hero) +![Importer mapping](https://media.docs.plane.so/for-enterprise/imports.webp) **Migration guides:** [Import from Jira](/importers/jira) | [Import from Linear](/importers/linear) | [Import from CSV](/importers/csv) @@ -480,7 +480,7 @@ Keep initiative names focused on the intended outcome. "Improve enterprise activ **Initiative** -![Initiative](https://media.docs.plane.so/for-enterprise/initatives.webp#hero) +![Initiative](https://media.docs.plane.so/for-enterprise/initatives.webp) > **Tip:** An initiative should help leadership understand progress and make decisions. If it only groups unrelated projects, it will not provide a useful strategic view. @@ -522,7 +522,7 @@ Teams can use all three together or only the ones that fit their planning proces **Cycles** -![Cycles](https://media.docs.plane.so/for-enterprise/cycles.webp#hero) +![Cycles](https://media.docs.plane.so/for-enterprise/cycles.webp) ## 6. Integrations @@ -543,7 +543,7 @@ Start with the integrations used by the pilot team. Confirm that work moves as e **Integrations** -![Integrations](https://media.docs.plane.so/for-enterprise/integrations.webp#hero) +![Integrations](https://media.docs.plane.so/for-enterprise/integrations.webp) ## Define ownership before connecting tools @@ -597,7 +597,7 @@ Decide: **Intake requests** -![Intake requests](https://media.docs.plane.so/for-enterprise/intake.webp#hero) +![Intake requests](https://media.docs.plane.so/for-enterprise/intake.webp) Teams can create intake forms for structured submissions or accept requests through intake email. @@ -609,7 +609,7 @@ Support and Customer Success teams can follow whether a request has been accepte **Customer requests** -![Customer requests](https://media.docs.plane.so/for-enterprise/customers.webp#hero) +![Customer requests](https://media.docs.plane.so/for-enterprise/customers.webp) ## 8. Knowledge and documentation @@ -632,7 +632,7 @@ Organize the Wiki through [collections](/pages/collections) and [nested pages](/ **Organization Wiki** -![Organization wiki](https://media.docs.plane.so/for-enterprise/wiki-docs.webp#hero) +![Organization wiki](https://media.docs.plane.so/for-enterprise/wiki-docs.webp) ## Keep decision records consistent @@ -683,7 +683,7 @@ Keep dashboards focused. A screen filled with widgets can provide less clarity t **Leadership dashboard** -![Leadership dashboard](https://media.docs.plane.so/for-enterprise/dashboards.webp#hero) +![Leadership dashboard](https://media.docs.plane.so/for-enterprise/dashboards.webp) > **Tip:** Assign an owner to every dashboard. Review it periodically and remove anything that no longer informs a decision. @@ -736,7 +736,7 @@ For every approval, define: **Workflow with approval** -![Workflow with approval](https://media.docs.plane.so/for-enterprise/workflows.webp#hero) +![Workflow with approval](https://media.docs.plane.so/for-enterprise/workflows.webp) > **Tip:** If approvals regularly happen outside Plane, check whether the workflow includes enough context and the right approver. @@ -759,7 +759,7 @@ Plane supports project automations, while Enterprise Grid provides additional ca **Automation builder** -![Automation builder](https://media.docs.plane.so/for-enterprise/automation.webp#hero) +![Automation builder](https://media.docs.plane.so/for-enterprise/automation.webp) For every automation, record: @@ -785,7 +785,7 @@ Plane AI is built into the workspace you already use, not a separate chat window | Build | Plans a set of actions, shows them to you as cards, waits for your confirmation. | | Autopilot | Same planning as Build, but executes immediately. No review step. | -![Plane AI modes](https://media.docs.plane.so/for-enterprise/plane-ai.webp#hero) +![Plane AI modes](https://media.docs.plane.so/for-enterprise/plane-ai.webp) Introduce Plane AI after the organization has clear permissions, reliable workflows, and defined data boundaries. diff --git a/apps/docs/docs/introduction/quickstart/growing-teams.md b/apps/docs/docs/introduction/quickstart/growing-teams.md index 1e290d08..aec00deb 100644 --- a/apps/docs/docs/introduction/quickstart/growing-teams.md +++ b/apps/docs/docs/introduction/quickstart/growing-teams.md @@ -45,7 +45,7 @@ Plane provides importers for tools including [Jira](/importers/jira), [Linear](/ Move active work, recent context, and records the team still needs. Historical data that has no role in current planning or reporting can remain in a read-only archive. -![Importing active work](https://media.docs.plane.so/for-growing-teams/imports.webp#hero) +![Importing active work](https://media.docs.plane.so/for-growing-teams/imports.webp) > **Tip:** Clean up states and labels before importing. Mapping several variations of "in progress" into Plane only carries the existing inconsistency into the new Workspace. @@ -311,7 +311,7 @@ Start with how the team plans and manages its work, then enable the features tha **Projects organized by team** -![Projects organized by team](https://media.docs.plane.so/for-growing-teams/projects.webp#hero) +![Projects organized by team](https://media.docs.plane.so/for-growing-teams/projects.webp) ### Create Teamspaces for shared team context @@ -332,7 +332,7 @@ A useful Teamspace description states: **Teamspace** -![Teamspace](https://media.docs.plane.so/for-growing-teams/teamspaces.webp#hero) +![Teamspace](https://media.docs.plane.so/for-growing-teams/teamspaces.webp) ### Organize work by type @@ -340,7 +340,7 @@ Every work item has a type, and the type decides which properties that item carr Teams can create types such as Bug, Feature Request, Security Review, Incident Follow-up, or Content Request. Each type can have properties suited to the work. -![Work item types](https://media.docs.plane.so/for-growing-teams/work-item-type.webp#hero) +![Work item types](https://media.docs.plane.so/for-growing-teams/work-item-type.webp) | Work Item Type | Useful properties | | --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | @@ -432,7 +432,7 @@ Use the [Workspace Wiki](/core-concepts/pages/wiki) for knowledge that applies a **Workspace Wiki** -![Workspace wiki](https://media.docs.plane.so/for-growing-teams/wiki.webp#hero) +![Workspace wiki](https://media.docs.plane.so/for-growing-teams/wiki.webp) Business adds [nested Pages](/pages/nested-pages) for larger documentation structures. Add nesting when a flat structure becomes difficult to navigate. @@ -463,7 +463,7 @@ Accepted requests should enter the team's normal project workflow. Intake should **Review incoming requests before they enter the team's planned workflow.** -![Reviewing incoming requests](https://media.docs.plane.so/for-growing-teams/intake.webp#hero) +![Reviewing incoming requests](https://media.docs.plane.so/for-growing-teams/intake.webp) ### Connect customer requests to delivery work @@ -495,7 +495,7 @@ Repeated carryover points at oversized work items, shifting priorities, unresolv **Cycles** -![Cycles](https://media.docs.plane.so/for-growing-teams/cycles.webp#hero) +![Cycles](https://media.docs.plane.so/for-growing-teams/cycles.webp) ### Group related work with Modules @@ -512,7 +512,7 @@ A Module might represent: **Modules** -![Modules](https://media.docs.plane.so/for-growing-teams/modules.webp#hero) +![Modules](https://media.docs.plane.so/for-growing-teams/modules.webp) A Module can span several work items. Work can remain grouped around the same deliverable even when it is completed over multiple planning periods. @@ -565,7 +565,7 @@ On the item that has to wait, add the item it is waiting for. Say the dashboard When two items are connected but neither has to wait, use _related_. When the same thing was filed twice, use _duplicate_. -![Work item dependencies](https://media.docs.plane.so/for-growing-teams/gatt-chart.webp#hero) +![Work item dependencies](https://media.docs.plane.so/for-growing-teams/gatt-chart.webp) An important dependency should make four things clear: @@ -601,7 +601,7 @@ Do not create an Initiative for an individual team project. Keep the number of a **An Initiative across projects** -![An Initiative across projects](https://media.docs.plane.so/for-growing-teams/initatives.webp#hero) +![An Initiative across projects](https://media.docs.plane.so/for-growing-teams/initatives.webp) ### Share project updates consistently @@ -648,7 +648,7 @@ Business adds advanced Dashboard widgets for deeper analysis and more flexible r **Build Dashboards around the decisions teams and leaders make regularly** -![Leadership dashboard](https://media.docs.plane.so/for-growing-teams/dashboards.webp#hero) +![Leadership dashboard](https://media.docs.plane.so/for-growing-teams/dashboards.webp) ## Automate stable workflows @@ -671,7 +671,7 @@ Do not automate an unclear process or use automation to compensate for inconsist **A focused automation** -![A focused automation](https://media.docs.plane.so/for-growing-teams/automation.webp#hero) +![A focused automation](https://media.docs.plane.so/for-growing-teams/automation.webp) ## Introduce Plane AI gradually @@ -685,7 +685,7 @@ Begin with read-only questions that help teams evaluate the quality of their Wor - Which customer requests are connected to planned work? - How has the scope of this Cycle changed? -![Plane AI answering workspace questions](https://media.docs.plane.so/for-growing-teams/plane-ai.webp#hero) +![Plane AI answering workspace questions](https://media.docs.plane.so/for-growing-teams/plane-ai.webp) Once you are satisfied with the answers, introduce reviewed actions for clearly defined work. A person should inspect proposed changes before they are applied. diff --git a/apps/docs/docs/introduction/quickstart/startups.md b/apps/docs/docs/introduction/quickstart/startups.md index 02d2ae7f..c35adda8 100644 --- a/apps/docs/docs/introduction/quickstart/startups.md +++ b/apps/docs/docs/introduction/quickstart/startups.md @@ -70,7 +70,7 @@ A very small startup may not need Teamspaces immediately. Enable this feature wh Create Teamspaces around stable areas of responsibility, not temporary initiatives. A feature launch or company objective usually belongs in a project, module, or initiative rather than a new Teamspace. -![Teamspaces](https://media.docs.plane.so/for-startup/teamspaces.webp#hero) +![Teamspaces](https://media.docs.plane.so/for-startup/teamspaces.webp) ### Create one or two projects @@ -86,7 +86,7 @@ Add another project when the work needs different ownership, access, workflow, o **Projects Overview** -![Projects overview](https://media.docs.plane.so/for-startup/projects-overview.webp#hero) +![Projects overview](https://media.docs.plane.so/for-startup/projects-overview.webp) ### Invite the team @@ -124,7 +124,7 @@ This first import gives you a chance to test the workspace structure before brin **Importer mapping** -![Importer mapping](https://media.docs.plane.so/for-startup/imports.webp#hero) +![Importer mapping](https://media.docs.plane.so/for-startup/imports.webp) ## 4. Turn priorities into work @@ -159,7 +159,7 @@ Use an epic work item type when a larger deliverable contains several related wo **Work item** -![Work item](https://media.docs.plane.so/for-startup/work-item.webp#hero) +![Work item](https://media.docs.plane.so/for-startup/work-item.webp) ### Keep workflows simple @@ -187,7 +187,7 @@ A lightweight planning loop is enough for most startups: Short planning horizons allow the company to respond when customer feedback, delivery constraints, or business priorities change. -![Short planning horizons](https://media.docs.plane.so/for-growing-teams/gatt-chart.webp#hero) +![Short planning horizons](https://media.docs.plane.so/for-growing-teams/gatt-chart.webp) ### Set priorities @@ -240,7 +240,7 @@ The [Workspace Wiki](/core-concepts/pages/wiki) holds knowledge used across the Keep project-specific context with the project. Move durable knowledge to the Wiki when people outside the project will need it again. -![Workspace Wiki](https://media.docs.plane.so/for-startup/wiki.webp#hero) +![Workspace Wiki](https://media.docs.plane.so/for-startup/wiki.webp) ### Reuse repeated processes @@ -282,7 +282,7 @@ The owner should: A single owned queue is easier to maintain than several channels that nobody reviews consistently. -![Intake queue](https://media.docs.plane.so/for-startup/intake.webp#hero) +![Intake queue](https://media.docs.plane.so/for-startup/intake.webp) ### Move accepted requests into planned work @@ -351,7 +351,7 @@ Do not introduce time tracking as a default measure of individual productivity. [Plane AI](/ai/plane-ai) helps whether a workspace is brand new or already full of work items, documentation, and project history. -![Plane AI](https://media.docs.plane.so/for-startup/plane-ai.webp#hero) +![Plane AI](https://media.docs.plane.so/for-startup/plane-ai.webp) **Setting up a workspace** From 1834f3b7fc890b7f10669282aaacee15be57b947 Mon Sep 17 00:00:00 2001 From: Srinivas Pendem Date: Fri, 21 Aug 2026 12:21:08 +0530 Subject: [PATCH 3/3] docs: match How to Plane page headings to sidebar labels Co-Authored-By: Claude Sonnet 5 --- apps/docs/docs/introduction/quickstart/enterprise-teams.md | 2 +- apps/docs/docs/introduction/quickstart/growing-teams.md | 2 +- apps/docs/docs/introduction/quickstart/startups.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/apps/docs/docs/introduction/quickstart/enterprise-teams.md b/apps/docs/docs/introduction/quickstart/enterprise-teams.md index d0d54a9a..9624451b 100644 --- a/apps/docs/docs/introduction/quickstart/enterprise-teams.md +++ b/apps/docs/docs/introduction/quickstart/enterprise-teams.md @@ -3,7 +3,7 @@ title: "How to Plane: For enterprise teams" description: Set up Plane across your organization with common governance, clear visibility, and enough flexibility for teams to work in the way that suits them. --- -# For enterprise teams +# How to Plane: For enterprise teams Set up Plane across your organization with common governance, clear visibility, and enough flexibility for teams to work in the way that suits them. diff --git a/apps/docs/docs/introduction/quickstart/growing-teams.md b/apps/docs/docs/introduction/quickstart/growing-teams.md index aec00deb..dda00dc6 100644 --- a/apps/docs/docs/introduction/quickstart/growing-teams.md +++ b/apps/docs/docs/introduction/quickstart/growing-teams.md @@ -3,7 +3,7 @@ title: "How to Plane: For growing teams" description: Structure Plane for multiple teams, introduce the right capabilities at the right time, and create reliable cross-team visibility without adding unnecessary administration. --- -# For growing teams +# How to Plane: For growing teams Once several teams share products, dependencies, and company goals, informal coordination stops being enough. Requests get lost, ownership becomes unclear, and leaders need answers that span more than one project. diff --git a/apps/docs/docs/introduction/quickstart/startups.md b/apps/docs/docs/introduction/quickstart/startups.md index c35adda8..69fd6570 100644 --- a/apps/docs/docs/introduction/quickstart/startups.md +++ b/apps/docs/docs/introduction/quickstart/startups.md @@ -3,7 +3,7 @@ title: "How to Plane: For startups" description: A lightweight Plane setup for managing company priorities, product work, customer feedback, and delivery in one place. --- -# For startups +# How to Plane: For startups Startups need enough structure to keep priorities, product context, and execution connected. They do not need a process for every possible situation.