# Projan — full content > Projan turns the messy Slack and Teams discussion of a feature into a clean PRD, acceptance criteria and tickets in Jira, Notion, Linear and ClickUp, so the PM doesn't spend an evening writing it up. Generated from the site content at build time. See https://projan.ai/llms.txt for the curated index of pages. ## Documentation ### Asana Integration https://projan.ai/docs/integrations/asana/ ## Overview Export task breakdowns from Projan plans to Asana as tasks within a project, and import existing Asana tasks as conversation context for AI grounding. ## Prerequisites - Asana account with access to the target project - Projan team admin or individual account ## Setup Steps 1. Go to **Settings > Integrations > Asana** 2. Click **"Connect Asana"** 3. Authorize the connection on Asana's consent screen 4. Select a target project during export ## Permissions Requested | Scope | Purpose | Access Level | |---|---|---| | `projects:read` | List projects for export destination selection | Read | | `tasks:read` | Read tasks for context import and deduplication | Read | | `tasks:write` | Create and update tasks | Write | | `task_templates:read` | Read task templates for type mapping | Read | | `attachments:read` / `attachments:write` | Attach exported documents to tasks | Read/Write | ## What Data is Accessed - Workspace and project names - Existing tasks (for context import) ## Data Storage - Encrypted access and refresh tokens Tokens auto-refresh - no re-authentication needed unless you revoke access from Asana. ## Disconnecting Go to **Settings > Integrations > Asana > Disconnect**. Tokens are purged immediately. Previously exported tasks remain in Asana unaffected. You can also revoke access from **Asana > Settings > Apps**. ## Troubleshooting **"No projects found"** - Check that the connected account is a member of at least one project **Hierarchy mapping** - Epics are exported as sections or parent tasks; subtasks use Asana's native subtask support ### Azure DevOps Integration https://projan.ai/docs/integrations/azure-devops/ ## Overview Export task breakdowns from Projan plans to Azure DevOps as Epics, Features, User Stories, Tasks, and Bugs, preserving the plan hierarchy with parent-child links. Existing work items can be imported as conversation context. ## Prerequisites - Azure DevOps organisation with a project using the Agile, Scrum, or Basic process - Work item creation permission in the target project - Projan team admin or individual account ## Setup Steps 1. Go to **Settings > Integrations > Azure DevOps** 2. Click **"Connect Azure DevOps"** 3. Sign in with your Microsoft account and authorize the connection 4. Select your organisation and project during export ## Permissions Requested | Scope | Purpose | Access Level | |---|---|---| | `vso.work_write` | Create and update work items | Write | | `vso.project` | List projects and process templates | Read | | `vso.wiki_write` | Export documents to project wikis | Write | ## What Data is Accessed - Organisation and project names - Work item types and process configuration - Existing work items (for dependency linking and context import) ## Data Storage - Encrypted access and refresh tokens - Organisation URL Tokens auto-refresh - no re-authentication needed unless you revoke access from your Microsoft account. ## Disconnecting Go to **Settings > Integrations > Azure DevOps > Disconnect**. Tokens are purged immediately. Previously exported work items remain in Azure DevOps unaffected. ## Troubleshooting **"No projects found"** - Check that the connected account is a member of at least one Azure DevOps organisation **Work item types missing** - The available types depend on the project's process template (Agile, Scrum, Basic, CMMI) **Export fails with "Permission denied"** - The connected account needs "Edit work items in this node" permission in the target area path ### Canny Integration https://projan.ai/docs/integrations/canny/ ## Overview Import user feedback from Canny into Projan conversations. Attach feature requests or whole board summaries as context sources so the AI can ground PRDs and plans in real user demand. This integration is import-only - Projan never writes to Canny. ## Prerequisites - Canny account with API access (available on Canny's paid plans) - Your Canny API key and subdomain - Projan team admin or individual account ## Setup Steps 1. Go to **Settings > Integrations > Canny** 2. Enter your Canny API key (found in **Canny > Settings > API & Webhooks**) 3. Enter your Canny subdomain (the `your-company` part of `your-company.canny.io`) 4. Click **"Connect"** ## Permissions Requested The API key grants read access to your Canny boards and posts. Projan only reads data - it never creates, modifies, or deletes anything in Canny. ## What Data is Accessed - Boards and post titles when browsing for a context source - Feature requests, comments, and vote counts you explicitly attach to a conversation Imported content is fetched fresh each time the AI generates a response, and only for sources you have attached. ## Data Storage - Encrypted API key and subdomain - Imported context snapshots stored on the conversation they are attached to ## Disconnecting Go to **Settings > Integrations > Canny > Disconnect**. The API key is purged immediately. Context sources already attached to conversations retain their last imported snapshot until removed. ## Troubleshooting **"Invalid API key"** - Regenerate your API key in Canny settings and reconnect **"No boards found"** - Verify the subdomain matches your Canny workspace exactly ### ClickUp Integration https://projan.ai/docs/integrations/clickup/ ## Overview Export task breakdowns from Projan plans to ClickUp lists within your workspace hierarchy (Workspace > Space > Folder > List). Tasks are created with descriptions, tags, and status mapping. ## Prerequisites - ClickUp workspace with list access - Projan team admin or individual account ## Setup Steps 1. Go to **Settings > Integrations > ClickUp** 2. Click **"Connect ClickUp"** 3. Authorize the connection 4. Select your workspace ## Permissions Requested ClickUp OAuth grants full workspace access based on your user permissions. Projan only writes to lists you explicitly select during export. ## What Data is Accessed - Workspace, Space, Folder, and List hierarchy - Existing task names (for deduplication) ## Data Storage - Encrypted access token ## Disconnecting Go to **Settings > Integrations > ClickUp > Disconnect**. Token is purged immediately. ## Troubleshooting **"No lists found"** - Check that you have access to at least one Space and List - Verify folder permissions in ClickUp **Rate limits** - ClickUp has strict rate limits (100 requests/minute) - Larger exports are queued and processed automatically **Subtask hierarchy** - ClickUp does not natively support subtask hierarchy via API - Parent task information is included in the task description instead **Categories not appearing** - Categories are mapped to tags in ClickUp - Priority is encoded as a tag (ClickUp priority field not used) ### Coda Integration https://projan.ai/docs/integrations/coda/ ## Overview Export generated documents from Projan to Coda docs, and import existing Coda pages as conversation context for AI grounding. ## Prerequisites - Coda account - A Coda API token - Projan team admin or individual account ## Setup Steps 1. Go to **Settings > Integrations > Coda** 2. Enter your Coda API token (generate one at **Coda > Account settings > API**) 3. Click **"Connect"** ## Permissions Requested The API token grants access to the docs the token's owner can access. For tighter scoping, Coda lets you restrict a token to specific docs when generating it - Projan works with restricted tokens. ## What Data is Accessed - Doc and page names when browsing for an export destination or context source - Page content you explicitly attach to a conversation - Pages created by export ## Data Storage - Encrypted API token - Imported context snapshots stored on the conversation they are attached to ## Disconnecting Go to **Settings > Integrations > Coda > Disconnect**. The API token is purged immediately. Previously exported pages remain in Coda unaffected. You can also revoke the token from Coda account settings. ## Troubleshooting **"Invalid token"** - Regenerate the token in Coda account settings and reconnect **"Doc not found"** - If you generated a doc-restricted token, ensure it includes the doc you are trying to use ### Confluence Integration https://projan.ai/docs/integrations/confluence/ ## Overview Export generated documents from Projan to Confluence as pages with full formatting, and import existing Confluence pages as conversation context for AI grounding. ## Prerequisites - Confluence Cloud instance (not Server or Data Center) - Space access with page creation permission - Projan team admin or individual account ## Setup Steps 1. Go to **Settings > Integrations > Confluence** 2. Click **"Connect Confluence"** 3. Authorize via Atlassian's OAuth consent screen 4. Select your Confluence site if you have multiple ## Permissions Requested | Scope | Purpose | Access Level | |---|---|---| | `read:space:confluence` | List spaces for export destination selection | Read | | `read:page:confluence` | Read pages for context import | Read | | `write:page:confluence` | Create and update pages | Write | | `write:attachment:confluence` | Attach images to exported pages | Write | | `offline_access` | Refresh tokens without re-auth | System | ## What Data is Accessed - Space names and keys - Page titles and content (for context import) ## Data Storage - Encrypted access and refresh tokens - Confluence site URL and cloud ID Tokens auto-refresh - no re-authentication needed unless you revoke access from Atlassian. ## Disconnecting Go to **Settings > Integrations > Confluence > Disconnect**. This immediately purges all stored tokens. Previously exported pages remain in Confluence unaffected. ## Troubleshooting **"No spaces found"** - Verify you have page creation permission in at least one space **Export fails with "Permission denied"** - The connected account must have "Add Page" permission in the target space **Formatting differences** - Confluence storage format does not support every markdown construct; complex tables may be simplified ### Dropbox Paper Integration https://projan.ai/docs/integrations/dropbox-paper/ ## Overview Export generated documents from Projan to Dropbox Paper, where your team can continue editing collaboratively. ## Prerequisites - Dropbox account (Paper enabled) - Projan team admin or individual account ## Setup Steps 1. Go to **Settings > Integrations > Dropbox Paper** 2. Click **"Connect Dropbox"** 3. Authorize the connection on Dropbox's consent screen ## Permissions Requested | Scope | Purpose | Access Level | |---|---|---| | `files.content.write` | Create Paper documents | Write | | `files.content.read` | List folders and verify exports | Read | ## What Data is Accessed - Folder names (for export destination selection) - File metadata of exported documents ## Data Storage - Encrypted access and refresh tokens Tokens auto-refresh - no re-authentication needed unless you revoke access from Dropbox. ## Disconnecting Go to **Settings > Integrations > Dropbox Paper > Disconnect**. Tokens are purged immediately. Previously exported documents remain in Dropbox unaffected. You can also revoke access from **Dropbox > Settings > Connected apps**. ## Troubleshooting **"Export failed"** - Verify your Dropbox account has Paper enabled (some legacy accounts require opting in) **Formatting differences** - Paper's import format does not support every markdown construct; complex tables may be simplified ### GitHub Integration https://projan.ai/docs/integrations/github/ ## Overview Export task breakdowns from Projan plans to GitHub as issues, and import existing issues or pull requests as conversation context for AI grounding. ## Prerequisites - GitHub account with write access to the target repository - Projan team admin or individual account ## Setup Steps 1. Go to **Settings > Integrations > GitHub** 2. Click **"Connect GitHub"** 3. Authorize via GitHub's OAuth consent screen 4. Grant access to the organisations you want to export to ## Permissions Requested | Scope | Purpose | Access Level | |---|---|---| | `repo` | Read repositories, create and update issues | Read/Write | | `read:org` | List organisations and their repositories | Read | ## What Data is Accessed - Repository names and metadata - Existing issues and pull requests (for context import) - Issue labels and milestones ## Data Storage - Encrypted access token - Connected account login ## Disconnecting Go to **Settings > Integrations > GitHub > Disconnect**. Token is purged immediately. Previously exported issues remain in GitHub unaffected. You can also revoke the authorisation from **GitHub > Settings > Applications**. ## Troubleshooting **"No repositories found"** - Check that you granted access to the correct organisation during authorisation - Organisation owners may need to approve third-party OAuth access **Export fails with "Permission denied"** - The connected account needs write access to the target repository **Private repositories not appearing** - The `repo` scope requires organisation approval for private repositories in some organisations ### Google Docs Integration https://projan.ai/docs/integrations/google-docs/ ## Overview Export PRDs, technical designs, business plans, and other generated documents to Google Docs with formatting preserved. Documents are created in your Google Drive with proper headings, lists, and tables. ## Prerequisites - Google account - Google Docs access - Projan team admin or individual account ## Setup Steps 1. Go to **Settings > Integrations > Google Docs** 2. Click **"Sign in with Google"** 3. Grant document creation permissions 4. Select a default folder (optional) ## Permissions Requested | Scope | Purpose | Access Level | |---|---|---| | Google Drive (files) | Create new documents | Write | | Google Docs | Read and write document content | Read/Write | | `offline_access` | Refresh tokens without re-auth | System | ## What Data is Accessed Nothing is read from existing documents. Projan only creates new documents in your Drive. ## Data Storage - Encrypted access and refresh tokens - User email (for Drive identification, optional) ## Disconnecting Go to **Settings > Integrations > Google Docs > Disconnect**. Token is purged immediately. Also revoke from Google: **Security > Third-party access > Projan**. ## Troubleshooting **"Permission denied"** - Re-authorize the integration to ensure correct scopes are granted - Check that your Google account has Google Docs enabled **Formatting issues** - Complex tables may be simplified during export - Nested lists are supported up to 3 levels deep - Code blocks are rendered as monospace text **Document size limit** - Maximum 500,000 characters per document - Split large documents across multiple exports if needed **"Token expired"** - Tokens should auto-refresh. If issues persist, disconnect and reconnect ### Google Meet Integration https://projan.ai/docs/integrations/google-meet/ ## Overview Import Google Meet transcripts into Projan conversations as context sources, so the AI can ground PRDs and plans in what was actually discussed. This integration is import-only and read-only. ## Prerequisites - Google Workspace account with Meet transcription enabled - Meetings must have had transcription turned on during the call - Projan team admin or individual account ## Setup Steps 1. Go to **Settings > Integrations > Google Meet** 2. Click **"Connect Google Meet"** 3. Sign in with your Google account and grant the requested permissions ## Permissions Requested | Scope | Purpose | Access Level | |---|---|---| | `calendar.events.readonly` | List your recent meetings | Read | | `meetings.space.readonly` | Read meeting transcripts | Read | Both scopes are read-only. Projan cannot create, modify, or join meetings. ## What Data is Accessed - Your calendar events (to list recent meetings with transcripts) - Transcript content of meetings you explicitly attach to a conversation Only your own meetings are accessible - Projan uses your personal OAuth grant, not domain-wide access. ## Data Storage - Encrypted access and refresh tokens - Imported transcript snapshots stored on the conversation they are attached to ## Disconnecting Go to **Settings > Integrations > Google Meet > Disconnect**. Tokens are purged immediately. You can also revoke access from your [Google account permissions](https://myaccount.google.com/permissions). ## Troubleshooting **"No transcripts found"** - Transcription must have been enabled during the meeting; Meet does not generate transcripts retroactively - Transcripts can take a few minutes after the meeting ends to become available **"Permission denied"** - Your Workspace admin may restrict third-party access to Meet data; ask them to allow the Projan app ### Google Tasks Integration https://projan.ai/docs/integrations/google-tasks/ ## Overview Export task breakdowns from Projan plans to Google Tasks for tracking alongside Google Calendar. Tasks appear in your chosen task list and can be managed from any Google app. ## Prerequisites - Google account - Projan team admin or individual account ## Setup Steps 1. Go to **Settings > Integrations > Google Tasks** 2. Click **"Sign in with Google"** 3. Grant task read/write permissions 4. Select a task list (or create a new one) ## Permissions Requested | Scope | Purpose | Access Level | |---|---|---| | Google Tasks API | Read task lists, create and update tasks | Read/Write | | `offline_access` | Refresh tokens without re-auth | System | ## What Data is Accessed - Task list names and IDs ## Data Storage - Encrypted access and refresh tokens - User email ## Disconnecting Go to **Settings > Integrations > Google Tasks > Disconnect**. Token is purged immediately. ## Troubleshooting **Tasks not syncing** - Google Tasks has eventual consistency - tasks may take a few seconds to appear - Pull-to-refresh in Google Tasks or Calendar **Notes truncated** - Google Tasks limits notes to 8,192 characters - Longer descriptions are truncated with a link back to Projan **Formatting limitations** - Plain text only (no markdown rendering) - Binary status only: needsAction or completed - Single-level subtasks only - No priority field (priority is encoded in the task title) - Categories become title prefixes (e.g. "[Epic] Task name") ### Google Workspace Integration https://projan.ai/docs/integrations/google-workspace/ ## Overview The Google Workspace integration gives your team access to Google Meet transcripts, Google Docs, Drive files, and Google Tasks - all from within Projan. A Google Workspace administrator installs the Projan app for your organisation, and then any team member can import context from their own meetings, documents, and tasks without additional setup. ## Prerequisites - A Google Workspace account (Business, Enterprise, or Education - not a personal Gmail account) - An account with Google Workspace administrator access to install the app - A Projan team with an active subscription ## How to Connect ### Step 1: Start the Connection in Projan 1. In Projan, go to **Settings > Integrations** and find **Google Workspace**. 2. Click **Connect**. This opens a Google sign-in page in a new window. ### Step 2: Sign In with Your Admin Account 1. Sign in with your Google Workspace admin account. 2. If you are already signed in to Google, make sure the correct admin account is shown - click your profile picture in the top right to switch if needed. ### Step 3: Review and Approve Permissions 1. Google will show a consent screen listing the permissions Projan is requesting: - **View your calendar events** (read-only) - to access meeting details and find transcripts - **See your files on Google Drive** (read-only) - to read documents and files - **See and edit your Google Docs** - to read and update document content - **Create, read, update, and delete your tasks** - to sync tasks with Google Tasks 2. Click **Allow**. ### Step 4: Done 1. Google redirects you back to Projan. 2. The Google Workspace integration should now show as **Connected** on your integrations page. ## What Permissions Are Granted Projan requests four scopes: | Scope | Access | What It Accesses | Why | |-------|--------|-----------------|-----| | `calendar.events.readonly` | Read-only | Calendar events | Find meetings with transcripts | | `drive.readonly` | Read-only | Drive files | Read documents and spreadsheets | | `documents` | Read & write | Google Docs | Read and update document content | | `tasks` | Read & write | Google Tasks | Sync tasks with Google Tasks | Projan has **read-only** access to Calendar and Drive. For Google Docs and Google Tasks, Projan can read and write content. There is no access to Gmail, Contacts, or admin settings. ## What You Can Import Once connected, team members can import context from: | Type | Description | |------|-------------| | **Meeting Transcript** | Google Meet recordings and transcripts | | **Google Doc / Drive File** | Documents, spreadsheets, and other Drive files | | **Google Task** | Tasks from Google Tasks | ## Security Notes - Projan has **read-only** access to Calendar and Drive. It has **read and write** access to Google Docs and Google Tasks to enable syncing content back. - No passwords are stored - Projan uses industry-standard OAuth 2.0 tokens. - Access can be revoked at any time from Projan (Settings > Integrations > Disconnect) or from the [Google Account permissions page](https://myaccount.google.com/permissions). - Data is fetched on demand when a user imports context. It is not stored permanently. ## Revoking Access If you need to disconnect the integration: 1. **In Projan**: Go to **Settings > Integrations**, find **Google Workspace**, and click **Disconnect**. 2. **In Google**: Go to [myaccount.google.com/permissions](https://myaccount.google.com/permissions), find the Projan app, and click **Remove Access**. ## Troubleshooting | Issue | Solution | |-------|----------| | "You need admin approval" | The account you signed in with may not have the required admin permissions. Ask your Google Workspace administrator to complete the setup. | | Consent screen not appearing | Try using a private/incognito browser window. Cached sessions can sometimes interfere. | | "No data found" after connecting | Make sure the account you connected has Google Meet, Drive, and Tasks enabled in your Google Workspace subscription. | | Connection shows as "Error" | The OAuth token may have expired or been revoked. Disconnect in Projan and reconnect. | ### HubSpot Integration https://projan.ai/docs/integrations/hubspot/ ## Overview Import CRM context from HubSpot into Projan conversations. Attach deals, tickets, companies, or contacts as context sources so the AI can ground documents in real client data. This integration is import-only - Projan never writes to your CRM. ## Prerequisites - HubSpot account with CRM access - Projan team admin or individual account ## Setup Steps 1. Go to **Settings > Integrations > HubSpot** 2. Click **"Connect HubSpot"** 3. Select your HubSpot account and authorize the connection ## Permissions Requested | Scope | Purpose | Access Level | |---|---|---| | `crm.objects.contacts.read` | Read contacts for context import | Read | | `crm.objects.companies.read` | Read companies for context import | Read | | `crm.objects.deals.read` | Read deals for context import | Read | | `crm.objects.commercepayments.read` | Read payment context on deals | Read | | `tickets` | Read support tickets for context import | Read | | `oauth` | Identify the connected account | System | ## What Data is Accessed - Deals, tickets, companies, and contacts you explicitly attach to a conversation - Object names and metadata when browsing for a context source Imported content is fetched fresh each time the AI generates a response, and only for sources you have attached. ## Data Storage - Encrypted access and refresh tokens - Imported context snapshots stored on the conversation they are attached to ## Disconnecting Go to **Settings > Integrations > HubSpot > Disconnect**. Tokens are purged immediately. Context sources already attached to conversations retain their last imported snapshot until removed. ## Troubleshooting **"No records found"** - Verify the connected account has CRM read access for the relevant object types **Stale context** - Context is re-fetched at AI generation time; if a deal changed in HubSpot, the next AI response uses the updated data ### Jira Integration https://projan.ai/docs/integrations/jira/ ## Overview Export task breakdowns from Projan plans directly to Jira as Epics, Stories, and Tasks with dependency linking. ## Prerequisites - Jira Cloud instance (not Server or Data Center) - Project admin access for the target project - Projan team admin or individual account ## Setup Steps 1. Go to **Settings > Integrations > Jira** 2. Click **"Connect Jira"** 3. Authorize via Atlassian's OAuth consent screen 4. Select your Jira site if you have multiple 5. Grant the requested permissions ## Permissions Requested | Scope | Purpose | Access Level | |---|---|---| | `read:jira-work` | Read projects, issues, boards | Read | | `write:jira-work` | Create and update issues | Write | | `read:jira-user` | Look up assignable users | Read | | `manage:jira-project` | Access project configuration | Read | | `manage:jira-configuration` | Read issue types and workflows | Read | | `offline_access` | Refresh tokens without re-auth | System | ## What Data is Accessed - Project names and keys - Issue types and workflow configurations - Existing issues (for dependency linking) - User accounts (for assignment suggestions) ## Data Storage - Encrypted access and refresh tokens - Jira site URL and cloud ID - Installer account ID Tokens auto-refresh - no re-authentication needed unless you revoke access from Atlassian. ## Disconnecting Go to **Settings > Integrations > Jira > Disconnect**. This immediately purges all stored tokens. Previously exported issues remain in Jira unaffected. ## Troubleshooting **"No projects found"** - Verify you have project admin access for at least one project - Ensure the connected account has the correct Jira permissions **Token expired** - Tokens should auto-refresh. If issues persist, disconnect and reconnect **Missing issue types** - Ensure the target project uses a standard issue type scheme - Custom issue types are not automatically mapped **Export fails with "Permission denied"** - The connected Jira account must have "Create Issues" permission in the target project ### Linear Integration https://projan.ai/docs/integrations/linear/ ## Overview Export task breakdowns from Projan plans as Linear issues with proper labels, descriptions, and parent-child relationships. Issues are created with full context including acceptance criteria and priority. ## Prerequisites - Linear workspace - Team access in the target workspace - Projan team admin or individual account ## Setup Steps 1. Go to **Settings > Integrations > Linear** 2. Click **"Connect Linear"** 3. Authorize the connection 4. Select a default team (optional) ## Permissions Requested | Scope | Purpose | Access Level | |---|---|---| | `read` | Read teams, projects, labels | Read | | `write` | Create and update issues | Write | | `issues:create` | Create new issues | Write | ## What Data is Accessed - Team names and IDs - Project list - Labels - Existing issues (for parent linking) ## Data Storage - Encrypted access and refresh tokens (24-hour expiry, auto-refresh) - Organization name ### Category Mapping | Projan Category | Linear Mapping | |---|---| | Epic | Epic label | | Feature | Feature label | | Story | Story label | | Task | Task (default) | | Subtask | Task with parentId | | Bug | Bug label | | Spike | Spike label | | Milestone | Milestone label | ## Disconnecting Go to **Settings > Integrations > Linear > Disconnect**. Token is purged immediately. Also revoke from Linear: **Settings > Authorized Applications > Projan**. ## Troubleshooting **Issues not appearing** - Check that the correct team is selected during export - Verify your Linear account has issue creation permissions **Labels missing** - Projan creates labels automatically on first export - If label creation fails, check workspace admin permissions **Rate limits** - Batch exports may take a moment due to Linear's API rate limits - Exports are queued and retried automatically ### Microsoft 365 Integration https://projan.ai/docs/integrations/microsoft-365/ ## Overview The Microsoft 365 integration gives your team enterprise-wide access to Teams meeting transcripts, OneDrive and SharePoint files, and Microsoft To Do / Planner tasks - all from within Projan. Unlike individual Microsoft integrations that connect one user at a time, this uses an admin consent flow so your IT admin grants access once and every team member can pull context from their own meetings, documents, and tasks. ## Prerequisites - A Microsoft 365 Business or Enterprise subscription - An account with **Global Administrator** or **Application Administrator** role in your Microsoft Entra ID (formerly Azure AD) tenant - Projan team admin account ## How It Works When you connect Microsoft 365, Projan asks your organisation's admin to grant consent for specific read-only permissions. Once approved, Projan can access data across your tenant on behalf of any team member - no individual sign-in required. ## Step-by-Step Setup ### Step 1: Start the Connection in Projan 1. In Projan, go to **Settings > Integrations** and find **Microsoft 365**. 2. Click **Connect**. This opens a Microsoft sign-in page in a new window. ### Step 2: Sign In with Your Admin Account 1. Sign in with your Microsoft 365 admin account (the one with Global Administrator or Application Administrator permissions). 2. If you are already signed in to Microsoft, you may skip this step - just make sure the correct admin account is shown. ### Step 3: Review and Grant Permissions 1. Microsoft will show a consent screen listing the permissions Projan is requesting. These are **read-only** and include: - **Read calendars** - to access meeting details and transcripts - **Read files** - to access OneDrive and SharePoint documents - **Read tasks** - to access Microsoft To Do and Planner tasks 2. Check the box for **Consent on behalf of your organization**. 3. Click **Accept**. ### Step 4: Wait for the Redirect 1. After clicking Accept, Microsoft will redirect you back to Projan. 2. The Microsoft 365 integration should now show as **Connected** on your integrations page. 3. If something went wrong, you will see an error message - check the Troubleshooting section below. ### Step 5: Verify the Connection 1. Go to any conversation in Projan and try adding a context source. 2. Select **Microsoft 365** and choose a type (meeting, file, or task). 3. If data loads successfully, the integration is working. ## What Gets Connected Admin consent grants Projan access to data across your entire Microsoft 365 tenant. When a team member imports context, Projan accesses their specific data (their meetings, their files, their tasks) using their email address - not everyone's data at once. ## Security Notes - Projan only requests **read-only** permissions. It cannot modify, delete, or send anything on behalf of your users. - Admin consent can be revoked at any time from the [Microsoft Entra admin centre](https://entra.microsoft.com) under **Enterprise applications**. - No passwords or tokens are stored from your users - Projan uses app-level credentials granted during admin consent. - Data is accessed over encrypted connections and is not stored permanently - it is fetched on demand when a user imports context. ## What You Can Import Once connected, team members can import context from: | Type | Description | |------|-------------| | **Meeting Transcript** | Teams meeting recordings and transcripts | | **OneDrive / SharePoint File** | Documents, spreadsheets, and other files from OneDrive or SharePoint | | **To Do / Planner Task** | Tasks from Microsoft To Do or Planner | ## Revoking Access If you need to disconnect the integration: 1. **In Projan**: Go to **Settings > Integrations**, find **Microsoft 365**, and click **Disconnect**. 2. **In Microsoft**: Go to the [Microsoft Entra admin centre](https://entra.microsoft.com), navigate to **Enterprise applications**, find the Projan app, and delete it. This fully revokes all permissions. ## Troubleshooting | Issue | Solution | |-------|----------| | "You need admin approval" | The account you signed in with does not have admin permissions. Ask your IT administrator to complete the setup. | | "Consent could not be completed" | Try again in a private/incognito browser window. Cached sessions can sometimes interfere. | | "No data found" after connecting | Ensure the correct admin account was used and that users have active Microsoft 365 licences. | | Connection shows as "Error" | The admin consent may have been revoked in Entra. Disconnect in Projan and reconnect. | | "Tenant not found" | Your organisation may not have a Microsoft 365 subscription. This integration requires a business or enterprise plan. | ### Microsoft Teams Integration https://projan.ai/docs/integrations/microsoft-teams/ ## Overview The Microsoft Teams integration brings the Projan bot into your Teams workspace. Start AI-guided PRD conversations directly in Teams channels - the bot creates a dedicated channel per conversation, responds to mentions and messages, and shares a link back to the full document in Projan. ## Prerequisites - A Microsoft 365 subscription with Teams - An account with **Global Administrator** or **Application Administrator** role in your Microsoft Entra ID tenant (admin consent is required once per tenant) - Projan team admin account ## How It Works Connection uses an admin consent flow: a tenant admin grants consent once, linking your Microsoft tenant to your Projan team. After that, any team member can use the bot in Teams - no individual sign-in required. ## Setup Steps 1. In Projan, go to **Settings > Integrations > Microsoft Teams** 2. Click **Connect** - this opens Microsoft's admin consent screen 3. Sign in with a tenant admin account and click **Accept** 4. Install the Projan bot app in your Teams workspace 5. Mention **@Projan** in a channel to start a conversation ## Permissions Requested Admin consent grants application-level Microsoft Graph permissions used to: - Create and manage the dedicated channels the bot works in - Read and send messages in those channels - Generate share links for created documents Activity from tenants that have not been linked to a Projan team is rejected. ## What Data is Accessed - Messages sent to the bot or in bot-managed channels - Channel and tenant metadata (identifiers, display names) ## Data Storage - Tenant ID and display name on your Projan team record - Conversation metadata linking Teams channels to Projan conversations - No user passwords or personal tokens are stored ## Disconnecting 1. **In Projan**: Go to **Settings > Integrations > Microsoft Teams > Disconnect** 2. **In Microsoft**: Remove the Projan app under **Enterprise applications** in the [Microsoft Entra admin centre](https://entra.microsoft.com) to fully revoke consent ## Troubleshooting | Issue | Solution | |-------|----------| | "You need admin approval" | The signed-in account lacks admin permissions; ask your IT administrator to complete consent | | Bot replies "not connected" | The tenant is not linked to a Projan team - reconnect from Projan settings | | Bot not responding to mentions | Ensure the Projan app is installed in the team, not just the channel | | Connection shows as "Error" | Consent may have been revoked in Entra; disconnect in Projan and reconnect | ### Microsoft Teams Meetings Integration https://projan.ai/docs/integrations/microsoft-teams-meetings/ ## Overview Import Microsoft Teams meeting transcripts into Projan conversations as context sources, so the AI can ground PRDs and plans in what was actually discussed. This integration is import-only and read-only, and is separate from the Microsoft Teams bot integration. ## Prerequisites - Microsoft 365 account with Teams - Meetings must have had transcription turned on during the call - Projan team admin or individual account ## Setup Steps 1. Go to **Settings > Integrations > Microsoft Teams Meeting** 2. Click **"Connect"** 3. Sign in with your Microsoft account and grant the requested permissions ## Permissions Requested | Scope | Purpose | Access Level | |---|---|---| | `Calendars.Read` | List your recent meetings | Read | | `OnlineMeetings.Read` | Read meeting details | Read | | `OnlineMeetingTranscript.Read.All` | Read meeting transcripts | Read | | `offline_access` | Refresh tokens without re-auth | System | All data scopes are read-only. Projan cannot create, modify, or join meetings. ## What Data is Accessed - Your calendar events (to list recent meetings with transcripts) - Transcript content of meetings you explicitly attach to a conversation ## Data Storage - Encrypted access and refresh tokens - Imported transcript snapshots stored on the conversation they are attached to ## Disconnecting Go to **Settings > Integrations > Microsoft Teams Meeting > Disconnect**. Tokens are purged immediately. You can also revoke access from your Microsoft account's app permissions. ## Troubleshooting **"No transcripts found"** - Transcription must have been enabled during the meeting; transcripts are not generated retroactively - Transcripts can take a few minutes after the meeting ends to become available **"Permission denied"** - Some tenants require admin approval for transcript access; ask your IT administrator to approve the Projan app ### Microsoft To Do Integration https://projan.ai/docs/integrations/microsoft-todo/ ## Overview Export task breakdowns from Projan plans to Microsoft To Do for tracking alongside Outlook and Microsoft 365. Tasks appear in your chosen list and sync across all Microsoft apps. ## Prerequisites - Microsoft account (personal or work/school) - Projan team admin or individual account ## Setup Steps 1. Go to **Settings > Integrations > Microsoft To Do** 2. Click **"Sign in with Microsoft"** 3. Grant the requested permissions 4. Select a task list (or create a new one) ## Permissions Requested | Scope | Purpose | Access Level | |---|---|---| | `Tasks.ReadWrite` | Read task lists, create and update tasks | Read/Write | | `offline_access` | Refresh tokens without re-auth | System | ## What Data is Accessed - Task list names and IDs ## Data Storage - Encrypted access and refresh tokens ## Disconnecting Go to **Settings > Integrations > Microsoft To Do > Disconnect**. Token is purged immediately. Also revoke from Microsoft: **account.microsoft.com > Privacy > Apps and services**. ## Troubleshooting **"Token expired"** - Tokens should auto-refresh. If issues persist, disconnect and reconnect **Sync delay** - Microsoft Graph API has eventual consistency - Tasks may take a few seconds to appear across devices **Task limits** - Microsoft To Do supports up to 250 tasks per list via API - For larger exports, tasks are split across multiple lists automatically ### Monday.com Integration https://projan.ai/docs/integrations/monday/ ## Overview Export task breakdowns from Projan plans as items on Monday.com boards. Tasks are mapped to board items with column values for status, priority, and descriptions. ## Prerequisites - Monday.com account with board access - Projan team admin or individual account ## Setup Steps 1. Go to **Settings > Integrations > Monday.com** 2. Click **"Connect Monday.com"** 3. Authorize the connection 4. Select your workspace ## Permissions Requested Monday.com OAuth grants access based on your account permissions. Projan requests the minimum scopes needed to create and manage items. ## What Data is Accessed - Board names and IDs - Column definitions (for mapping task fields) ## Data Storage - Encrypted access token ## Disconnecting Go to **Settings > Integrations > Monday.com > Disconnect**. Token is purged immediately. Also revoke from Monday.com: **Admin > Apps > Projan**. ## Troubleshooting **Items not appearing** - Check that you have edit permissions on the target board - Verify the board is not archived **Descriptions as comments** - Monday.com has no native description field for items - Task descriptions are added as an update (comment) on the item **Subtasks not supported** - Monday.com's subitems API has limited support - All tasks are created as top-level items **Categories not mapped** - Monday.com does not have a native issue type concept - Categories are not directly supported; use status columns or groups for organisation ### Motion Integration https://projan.ai/docs/integrations/motion/ ## Overview Export task breakdowns from Projan plans to Motion where they are auto-scheduled based on priority and deadlines. Motion's AI scheduler optimises your calendar around the exported tasks. ## Prerequisites - Motion account with API access - API key from Motion settings - Projan team admin or individual account ## Setup Steps 1. Go to **Settings > Integrations > Motion** 2. Enter your Motion API key (found in **Motion > Settings > API**) 3. Click **"Connect"** 4. Select a default project ## Permissions Requested API key grants full access to your Motion workspace. Projan only creates tasks in projects you explicitly select during export. ## What Data is Accessed - Project names and IDs - Workspace information ## Data Storage - Encrypted API key ### Auto-Scheduling Configuration Exported tasks use the following defaults: - **Deadline type**: SOFT - **Schedule**: Work Hours - **Auto-scheduled**: Enabled ### Priority Mapping | Projan Priority | Motion Priority | |---|---| | Urgent / Critical | ASAP | | High | HIGH | | Medium (default) | MEDIUM | | Low | LOW | ## Disconnecting Go to **Settings > Integrations > Motion > Disconnect**. API key is purged immediately. ## Troubleshooting **"Rate limited"** - Motion allows 12 requests per minute - Larger exports are queued and retried with automatic backoff **"Invalid API key"** - Regenerate your API key in Motion settings and reconnect **Tasks not scheduling** - Check your Motion project settings and calendar availability - Ensure the target project has auto-scheduling enabled **No subtask support** - Motion does not support subtasks via API - Parent task information is included in the task description ### Notion Integration https://projan.ai/docs/integrations/notion/ ## Overview Export generated documents (PRDs, technical designs, business plans, etc.) and plan breakdowns to Notion as rich pages with full formatting support. ## Prerequisites - Notion workspace - Ability to authorize integrations in your workspace - Projan team admin or individual account ## Setup Steps 1. Go to **Settings > Integrations > Notion** 2. Click **"Connect Notion"** 3. Select the pages and/or databases you want to grant Projan access to 4. Confirm the authorization ## Permissions Requested Notion uses page-based permissions rather than granular OAuth scopes. Access is limited to pages explicitly selected during authorization. | Permission | Purpose | Access Level | |---|---|---| | Read content | Read selected pages and databases | Read | | Insert content | Create new pages | Write | | Update content | Update existing pages | Write | ## What Data is Accessed - Workspace name and icon - Selected page titles - Database schemas (for structured exports) ## Data Storage - Encrypted access token - Workspace ID and name - Bot ID Notion tokens are long-lived and do not require a refresh flow. ## Disconnecting Go to **Settings > Integrations > Notion > Disconnect**. This purges the stored token from Projan. You should also revoke access from Notion directly: **Settings > Connections > Projan > Disconnect**. ## Troubleshooting **"Page not found"** - Re-authorize the integration and ensure the correct pages are selected - Notion only grants access to explicitly chosen pages **Formatting issues** - Complex markdown (nested tables, code blocks with syntax highlighting) may be simplified during export - Notion's block API has formatting limitations compared to raw markdown **"Content too large" error** - Maximum 100,000 characters per export - Split large documents into multiple pages if needed **Pages not appearing in selection** - Ensure you have edit access to the pages you want to grant - Shared pages from other workspaces cannot be selected ### Productboard Integration https://projan.ai/docs/integrations/productboard/ ## Overview Export plan items from Projan to Productboard as features, and import existing features, objectives, and notes as conversation context so the AI can ground documents in real product feedback. ## Prerequisites - Productboard account with Maker access or above - Projan team admin or individual account ## Setup Steps 1. Go to **Settings > Integrations > Productboard** 2. Click **"Connect Productboard"** 3. Authorize the connection on Productboard's consent screen ## Permissions Requested | Scope | Purpose | Access Level | |---|---|---| | `entities:read` | Read features, components, and objectives | Read | | `entities:write` | Create features from plan items | Write | | `notes:read` | Read insights and notes for context import | Read | ## What Data is Accessed - Features, components, and objectives - Insights and notes (for context import) ## Data Storage - Encrypted access token ## Disconnecting Go to **Settings > Integrations > Productboard > Disconnect**. Token is purged immediately. Previously exported features remain in Productboard unaffected. ## Troubleshooting **"No features found"** - Verify the connected account has access to the relevant product hierarchy **Export fails with "Permission denied"** - Feature creation requires Maker access or above in Productboard ### SharePoint Integration https://projan.ai/docs/integrations/sharepoint/ ## Overview Export generated documents from Projan to SharePoint sites, and import existing pages and files as conversation context for AI grounding. ## Prerequisites - Microsoft 365 account with access to the target SharePoint site - Projan team admin or individual account ## Setup Steps 1. Go to **Settings > Integrations > SharePoint** 2. Click **"Connect SharePoint"** 3. Sign in with your Microsoft account and authorize the connection 4. Select a site and library during export ## Permissions Requested | Scope | Purpose | Access Level | |---|---|---| | `Sites.ReadWrite.All` | List sites, read pages, create documents | Read/Write | | `Files.ReadWrite.All` | Read and write files in document libraries | Read/Write | | `offline_access` | Refresh tokens without re-auth | System | Access is always bounded by the connected user's own SharePoint permissions - Projan cannot see sites the user cannot see. ## What Data is Accessed - Site and document library names - Pages and files you explicitly attach as context sources - Documents created by export ## Data Storage - Encrypted access and refresh tokens - Imported context snapshots stored on the conversation they are attached to Tokens auto-refresh - no re-authentication needed unless access is revoked in Microsoft Entra. ## Disconnecting Go to **Settings > Integrations > SharePoint > Disconnect**. Tokens are purged immediately. Previously exported documents remain in SharePoint unaffected. ## Troubleshooting **"No sites found"** - Verify the connected account has access to at least one SharePoint site **"Access denied" on export** - The connected account needs contribute permission in the target document library **Conditional access errors** - Some tenants restrict third-party app access; your IT admin may need to approve the Projan app in Microsoft Entra ### Slack Integration https://projan.ai/docs/integrations/slack/ ## Overview Connect Projan to your Slack workspace to enable PRD creation directly in Slack channels. Mention @Projan to start conversations, collaborate with your team in real-time, and export documents to Slack canvases - all without leaving your workflow. ## Prerequisites - Slack workspace (Free, Pro, Business+, or Enterprise Grid) - Team admin account in Projan - Permission to install apps in your Slack workspace ## Setup Steps 1. Go to **Settings > Integrations > Slack** 2. Click **"Connect Slack"** 3. Select your workspace from the dropdown 4. Review and approve the requested permissions 5. Choose a default channel for Projan notifications (optional) ## Permissions Requested | Scope | Purpose | Access Level | |---|---|---| | `channels:read` | List available channels | Read | | `channels:manage` | Create channels for PRD discussions | Write | | `channels:history` | Read conversation context | Read | | `chat:write` | Send messages and responses | Write | | `canvases:read` | Read existing canvases | Read | | `canvases:write` | Create and update PRD canvases | Write | | `users:read` | Identify team members | Read | | `users:read.email` | Match Slack users to Projan accounts | Read | | `team:read` | Detect workspace plan tier | Read | | `app_mentions:read` | Respond when mentioned | Read | | `commands` | Handle slash commands | Read | | `files:read` | Access shared files for context | Read | | `files:write` | Upload generated documents | Write | | `reactions:read` | Track engagement with responses | Read | ## What Data is Accessed - Channel names and IDs - Message content in threads where Projan is mentioned - User display names and emails - Workspace name and plan tier ## Data Storage - Encrypted bot token - Workspace ID and name - Installer user ID Message content is processed in real-time and stored as Projan conversations - not separately cached. ## Disconnecting Go to **Settings > Integrations > Slack > Disconnect**. This immediately revokes the bot token and removes all stored credentials. Existing Projan conversations created via Slack are retained but will no longer sync with Slack. ## Troubleshooting **Bot not responding** - Ensure Projan has been invited to the channel (`/invite @Projan`) - Check that the channel is not archived or restricted **Messages not appearing** - Verify the `app_mentions:read` scope was granted - Confirm the bot is not muted in the channel **Canvas errors** - Canvas features require Slack Business+ or Enterprise Grid - Free and Pro plans do not support the Canvases API **"Missing scope" error** - Disconnect and reconnect to re-authorize with updated permissions ### Smartsheet Integration https://projan.ai/docs/integrations/smartsheet/ ## Overview Export task breakdowns from Projan plans to Smartsheet. Each plan becomes a sheet with rows for every task, preserving hierarchy through row indenting and linking dependencies between rows. ## Prerequisites - Smartsheet account with sheet creation permission - Projan team admin or individual account ## Setup Steps 1. Go to **Settings > Integrations > Smartsheet** 2. Click **"Connect Smartsheet"** 3. Authorize the connection on Smartsheet's consent screen ## Permissions Requested | Scope | Purpose | Access Level | |---|---|---| | `CREATE_SHEETS` | Create new sheets for exported plans | Write | | `WRITE_SHEETS` | Add and update rows | Write | | `READ_SHEETS` | List sheets and verify exports | Read | ## What Data is Accessed - Sheet and workspace names - Rows of sheets created by Projan ## Data Storage - Encrypted access and refresh tokens Tokens auto-refresh - no re-authentication needed unless you revoke access from Smartsheet. ## Disconnecting Go to **Settings > Integrations > Smartsheet > Disconnect**. Tokens are purged immediately. Previously exported sheets remain in Smartsheet unaffected. ## Troubleshooting **"Sheet creation failed"** - Free Smartsheet plans limit the number of sheets; check your plan's sheet quota **Dependencies not showing** - Enable the dependencies setting on the sheet's project settings to display predecessor links ### Todoist Integration https://projan.ai/docs/integrations/todoist/ ## Overview Export task breakdowns from Projan plans to Todoist with labels, priorities, and parent task relationships. Tasks are organised within your chosen project. ## Prerequisites - Todoist account (Free or Pro) - Projan team admin or individual account ## Setup Steps 1. Go to **Settings > Integrations > Todoist** 2. Click **"Connect Todoist"** 3. Authorize the connection 4. Select a default project (or create a new one) ## Permissions Requested | Scope | Purpose | Access Level | |---|---|---| | `data:read_write` | Read projects and labels, create tasks | Read/Write | ## What Data is Accessed - Project names and IDs - Labels ## Data Storage - Encrypted access token (no refresh - Todoist tokens are long-lived) ## Disconnecting Go to **Settings > Integrations > Todoist > Disconnect**. Token is purged immediately. Also revoke from Todoist: **Settings > Integrations > Projan**. ## Troubleshooting **Labels not appearing** - Labels are created automatically on first export - Check that your Todoist plan supports labels (Pro feature for custom labels) **Duplicate tasks** - Check if the export has already completed - Projan does not deduplicate across multiple exports to the same project **Parent tasks** - Parent task linking is supported - Categories become labels (e.g. `@epic`, `@feature`, `@bug`) - Default priority is Normal (p4 in Todoist) ### Trello Integration https://projan.ai/docs/integrations/trello/ ## Overview Export task breakdowns from Projan plans to Trello as cards with descriptions and checklists, and import existing cards as conversation context. ## Prerequisites - Trello account with access to the target board - Projan team admin or individual account ## Setup Steps 1. Go to **Settings > Integrations > Trello** 2. Click **"Connect Trello"** 3. Authorize the connection on Trello's consent screen 4. Select a default board during export ## Permissions Requested | Scope | Purpose | Access Level | |---|---|---| | `read` | Read boards, lists, and cards | Read | | `write` | Create and update cards and checklists | Write | | `account` | Identify the connected account | Read | ## What Data is Accessed - Board and list names - Existing cards (for context import and deduplication) ## Data Storage - Encrypted access token ## Disconnecting Go to **Settings > Integrations > Trello > Disconnect**. Token is purged immediately. Previously exported cards remain in Trello unaffected. You can also revoke access from **Trello > Settings > Applications**. ## Troubleshooting **"No boards found"** - Check that the connected account is a member of at least one board **Hierarchy mapping** - Trello has no native task hierarchy; epics become lists or labelled cards, and subtasks become checklist items **Rate limits** - Trello limits API throughput; larger exports are queued and retried automatically ### Wrike Integration https://projan.ai/docs/integrations/wrike/ ## Overview Export task breakdowns from Projan plans to Wrike. Epics map to folders and tasks map to Wrike tasks, preserving the plan hierarchy. Existing tasks can be imported as conversation context. ## Prerequisites - Wrike account with task creation permission in the target space - Projan team admin or individual account ## Setup Steps 1. Go to **Settings > Integrations > Wrike** 2. Click **"Connect Wrike"** 3. Authorize the connection on Wrike's consent screen 4. Select a target folder during export ## Permissions Requested | Scope | Purpose | Access Level | |---|---|---| | `Default` | Read account, folder, and task data | Read | | `wsReadWrite` | Create and update tasks and folders | Write | ## What Data is Accessed - Space and folder structure - Existing tasks (for context import) ## Data Storage - Encrypted access and refresh tokens - Wrike account host Tokens auto-refresh - no re-authentication needed unless you revoke access from Wrike. ## Disconnecting Go to **Settings > Integrations > Wrike > Disconnect**. Tokens are purged immediately. Previously exported tasks and folders remain in Wrike unaffected. ## Troubleshooting **"No folders found"** - Verify the connected account can create tasks in at least one space **Dependencies not linking** - Dependency linking requires both tasks to exist in the same Wrike account; cross-account links are not supported ## Blog ### How to Write an RFP Response That Wins Agency Work https://projan.ai/blog/how-to-write-an-rfp-response-that-wins-agency-work/ Published: 2026-09-01 An RFP response should include an executive summary, your understanding of the client's problem, the proposed approach, the team and its relevant experience, a delivery timeline, pricing, assumptions, and answers to every mandatory question in the buyer's own format and numbering. Anything the RFP asks for and you omit is scored as a zero, not overlooked. This is written for agency new business and delivery leads answering a formal request for proposal (RFP): a buyer has published requirements, set a deadline and will mark submissions against stated criteria. A proposal you write after a good conversation is a different job, and [the types, structures and templates for those are covered separately](/blog/agency-proposals-and-partnership-proposals-types-examples-and-templates). ## Should you respond to this RFP at all? Only if you can name a person on the buying side who wants you to win. Cold RFPs that arrive with no prior conversation are usually won by an agency that has been talking to the client for months, and your response exists to make their shortlist look competitive. Work through six questions before anyone opens a document: 1. **Have you spoken to them?** Not a contact form reply. A real conversation with someone who will be in the room when the scores are agreed. 2. **Is there an incumbent, and is this a genuine re-tender?** Many RFPs are issued to price-check a supplier the client intends to keep. Ask directly whether an incumbent is bidding. A buyer who will not answer has told you something. 3. **Have you delivered this before, or would you like to have?** Panels score evidence. Ambition reads as inexperience when the comparison bid has three near-identical projects. 4. **Can you meet every mandatory requirement without a caveat?** Turnover thresholds, insurance levels, accreditations and reference counts are pass or fail. One miss and the rest of your submission is never read. 5. **Is there a budget, and will they indicate it?** A buyer who refuses any range is either shopping for a number or has not been given one. 6. **Can you afford the bid and the delivery?** A serious response costs several days of senior, unbillable time. Two bids in the same fortnight means both are worse. Most agencies lose RFPs they should never have entered and win RFPs they cannot deliver profitably. Both are qualification failures rather than writing failures. When the answer is no, decline in writing and say why. A warm, specific decline keeps you on the invitation list; silence removes you from it. ## How long do you have to respond to an RFP? Two to four weeks is the usual window for a private sector RFP, and public sector tenders normally run longer because minimum tendering periods are set by procurement rules rather than by the buyer's preference. Large or regulated procurements can allow six weeks or more. What matters is not the total, it is that the clarification deadline usually falls in the first third of it. Plan backwards from submission rather than forwards from the invitation: 1. **Day one.** Take the go/no-go decision and appoint one owner. Not a committee, one named person who can reject contributions. 2. **Days one to three.** Read the whole pack, including the appendices and the contract terms, and list every mandatory requirement and every scored question with its weighting. 3. **Before the clarification deadline.** Submit questions. This deadline is often only five working days in and it is the single most missed date in the process. 4. **First half.** Agree the approach and the price internally. The commercial argument is the part that overruns, so have it while there is still time to change the answer. 5. **Second half.** Draft against the scored questions in the buyer's order. Write the executive summary last, once you know what you have actually promised. 6. **Three working days out.** Internal red team review by someone who has not written any of it, marking each answer against the published criteria. 7. **One day out.** Upload the full submission. Portals time out, files exceed limits, and named uploaders go on annual leave. Treat the submission date as the day before the deadline and the schedule stops depending on a good evening at the end. ## What should be included in an RFP response? Everything the RFP asks for, in the order and format it asks for it, plus the material that makes your answers credible. The buyer's structure is not a suggestion. It is the sequence a panel will mark in, and a beautifully designed response that reorders it gets low marks for the sections nobody could find. A complete agency response usually contains: - **Executive summary.** One page, written last. What you understand the problem to be, what you propose, what it costs, why you. - **Understanding of the requirement.** Restated in your words, with the thing they did not say out loud made explicit. - **Approach and methodology.** Phases, activities, and what the client has to do at each one. - **Scope and deliverables.** Countable outputs, plus an explicit list of what your price excludes. - **Timeline and milestones.** Dates tied to client dependencies, not a bar chart of your own effort. - **Team.** Named people, real availability, and who is on it for the pitch versus the delivery. Panels have been burned by this and increasingly ask. - **Relevant experience.** Two or three closely comparable projects with outcomes, not a logo wall. - **Pricing.** The commercial model, a breakdown by phase or workstream, day rates if requested, and what triggers a change. - **Assumptions, dependencies and risks.** The conditions your price depends on, stated as conditions. - **Compliance material.** Insurance certificates, policies, accreditations, references, financial statements. - **Question responses.** Answered individually, in the buyer's numbering, each starting with the answer. Your assumptions section is doing commercial work, not administrative work. Every requirement you have priced generously and every one you have deliberately not priced belongs in it, phrased plainly enough that a procurement lead can query it before award rather than a delivery lead discovering it in week three. The discipline is the same one that keeps a live project honest, and [the scoping guide covers how to write scope statements that survive contact with a client](/blog/how-to-scope-a-client-project-definitions-examples-and-scope-statements-that-hol). If the RFP specifies a template, a word limit, a font size or a file naming convention, follow it exactly. Compliance costs nothing and non-compliance is the cheapest reason a panel has to reduce its shortlist. ## How are RFP responses scored? Against published criteria with published weightings, usually by a panel who mark independently and then meet to agree a consensus score. The RFP normally tells you the weightings. Read them before you decide how to spend your writing time, because most agencies over-invest in the sections they enjoy. An illustrative weighting for a mid-size agency tender: | Criterion | Illustrative weight | What the panel is marking | |---|---|---| | Understanding of the requirement | 15% | Whether you grasped the actual problem or restated the brief | | Approach and methodology | 25% | Whether the plan is specific and could be followed by someone else | | Team and capability | 15% | Named people, relevant roles, honest availability | | Relevant experience | 15% | Comparable work, with outcomes and a reference | | Price | 30% | Total cost, and whether the breakdown is credible against the approach | The actual split varies, and public sector buyers often publish a quality and price ratio such as 60/40 or 70/30 with sub-criteria beneath each. Some tenders add social value or accessibility as separately weighted sections. All of them are marked the same way: a scorer reads your answer, looks for the things the marking scheme lists, and assigns a number. That has a blunt implication. Evaluators do not read your response, they mark it. An answer that spends three sentences on context before reaching the point is scored by someone who has already started skimming. Put the answer in the first sentence, use the buyer's vocabulary rather than your agency's, and attach one piece of evidence to each claim. ## What does a good RFP response look like? Specific, structured the buyer's way, and evidenced at every claim. A good response reads as though it was written for one client with one problem, and a weak one reads as though the agency's credentials deck was cut into the shape of the questions. The differences that show up in scoring: - **It names the problem behind the brief.** The strongest submissions say something the buyer had not written down but recognises immediately. That is what "understanding" scores. - **It commits to numbers.** Six templates, four rounds, a fortnightly cadence, a named lead at 3 days a week. Ranges and "typically" invite the reader to assume the cheaper interpretation. - **Its evidence matches the sector and the size.** One closely comparable project beats five prestigious ones from a different market. - **It is honest about dependencies.** Saying that the timeline assumes content is signed off within five working days is not a weakness. It is the reason your timeline is believable. - **Its price has a shape.** Phase-by-phase breakdowns get challenged less than a single total, because a panel can see what they are buying and what they could drop. What loses is duller than most agencies expect. Boilerplate about your founding story. A case study with no outcome. A creative concept nobody requested in place of an answer about governance. Pricing that arrives as one number with no assumptions attached, which reads either as guesswork or as a figure you intend to revise upwards later. ## Who is involved in the RFP process? On the client side, procurement runs the process while the budget holder and the people who will use the work do the scoring. On the agency side, one owner runs the response and everyone else contributes to a deadline they did not set. | Side | Role | What they actually control | |---|---|---| | Client | Procurement or commercial lead | Process, compliance, deadlines, the clarification window | | Client | Budget holder or sponsor | Whether the project happens and at what value | | Client | Functional evaluators | Marks for approach, team and experience | | Client | Technical, legal or security reviewers | Pass or fail on mandatory requirements | | Client | External advisor (sometimes) | The marking scheme itself | | Agency | Bid owner | Structure, the schedule, and what gets cut | | Agency | New business lead | Positioning, relationship, the win themes | | Agency | Delivery lead | Whether the approach and the hours are real | | Agency | Finance or director | Price, margin, risk appetite, final sign-off | The failure mode is predictable. The new business lead writes the approach and prices it optimistically, the delivery lead sees it two days before submission, and either the price gets defended into a project nobody can deliver or the response is rewritten in a panic on the final evening. Get the delivery lead into the pricing conversation in the first half of the window, when changing the answer is still cheap. That conversation needs a fixed set of questions, not a general catch-up: which requirements are we pricing as included, which are we answering with an explicit exclusion, what are we assuming about client turnaround, and who is genuinely available in the delivery months. [Projan](/landing/creative-strategy) can run it as a structured session in Slack or Microsoft Teams, pushing on each of those points and writing the agreed answers up as the outline your contributors then draft against. However you do it, hold the argument before the response is written rather than after it is submitted. When you win, the response you wrote becomes the reference document for what you promised, and it gets translated into a scope you are contractually held to. [Statements of work for agencies](/blog/statements-of-work-for-agencies-structure-signatures-and-scope-protection) covers that translation, and the gap between what the bid implied and what the SOW says is where first-quarter margin usually disappears. ## Frequently asked questions **What is the difference between an RFP, an RFI and an RFQ?** An RFI gathers market information before a buyer knows what to buy, so answers are short and capability-led. An RFQ asks for a price against a specification that is already fixed, so the cheapest compliant bid usually wins. An RFP asks how you would solve a defined problem and at what cost, and it is scored on approach as well as price. **Should you ask questions during the RFP clarification window?** Yes, and early. Most RFPs set a clarification deadline well before the submission date, and the answers are usually circulated to every bidder, so ask what you genuinely need rather than what reveals your thinking. Budget range, incumbent status and evaluation weightings are all fair questions. If a mandatory requirement is impossible for you, find out before you spend three days writing. **How long should an RFP response be?** As long as the buyer allows and no longer. Where the RFP sets a word limit per answer, treat it as the target for the questions carrying the most marks and undershoot on the rest. Where no limit is given, assume a panel is reading several submissions in one afternoon and write the shortest version that still evidences every claim. **What happens if you submit an RFP response late?** It gets rejected, usually automatically. Procurement portals close on the stated minute, and the people running them rarely have authority to reopen them, particularly in the public sector where doing so would be challengeable by rival bidders. Upload a complete draft a day early and replace it if you improve something. Nobody has ever been marked down for submitting early. **Should you ask for feedback after losing an RFP?** Always, and ask for the scores rather than a general impression. Public sector buyers normally have to provide a written debrief covering your marks against each criterion and the characteristics of the winning bid. Private buyers often will if you ask politely and quickly. Scores tell you whether you lost on price, on evidence, or on a section you rushed. The response that wins is rarely the most impressive one. It is the one that answered every question in the buyer's order, evidenced each claim with comparable work, and priced the job the delivery team agreed to. Qualify harder, write to the marking scheme, and submit a day early. ### Statements of Work for Agencies: Structure, Signatures, and Scope Protection https://projan.ai/blog/statements-of-work-for-agencies-structure-signatures-and-scope-protection/ Published: 2026-08-31 Write a statement of work by naming each deliverable precisely, listing what sits just outside it, attaching acceptance criteria and a change process to both, then getting it signed by someone who can approve the spend. The commercial protection is concentrated in three sections: exclusions, assumptions and change control. The rest describes the job. Written for account and delivery leads who already know what an SOW is and keep losing days to work nobody priced. It covers the drafting order, where the document sits against the contract, the two sections that decide whether extra work gets paid for, and what the signature has to carry. ## How do you write a statement of work? Write it deliverable by deliverable, defining each one's boundary as you go rather than drafting a scope narrative and bolting exclusions on at the end. The order below is deliberate: each step closes off one class of argument. 1. **List deliverables as countable objects with their format.** "Six email templates, responsive, built in Klaviyo" can be checked off. "Email programme" cannot. A deliverable with no unit attached to it has no finish line, only a client's sense of when it feels done. 2. **Write each exclusion next to the deliverable it belongs to.** Exclusions buried in an appendix get skimmed at signature and disputed later. Sitting beside the thing they qualify, they get read while the client still has the pen. 3. **Attach acceptance to every deliverable.** Say who approves it, how many working days they have, and what happens when the window passes without comment. Name one approver per deliverable. Approval by committee is approval by nobody. 4. **Turn assumptions into dated client obligations.** "We assume timely client feedback" protects nothing. "Client returns one consolidated set of comments within three working days of delivery, and each additional day moves the final date by a day" is something you can point at in week six. 5. **Price the change process, not only the project.** Include the rate card, the minimum billable increment, and who on the client side can authorise additional spend. 6. **Set out the dependency list and what breaks.** Brand assets, API access, product photography, legal sign-off, a named client contact who is not on leave in August. Say what slips if each one is late. 7. **Version and date the document.** Number the draft, date the pricing, and keep the executed file separate from the working copy. Every change order should reference that version number. Two people should read it before it leaves the building: whoever sold the work, and whoever has to deliver it. The gap between those two readings is where most unpriced work is born. For the scoping work that feeds the document, our [guide to scoping a client project covers scope statements in more depth](/blog/how-to-scope-a-client-project-definitions-examples-and-scope-statements-that-hol). ## What comes first, RFP or SOW? The RFP comes first, often months first, and the SOW is written after you have won. A request for proposal (RFP) is a client canvassing the market. A statement of work is the selected agency committing to specifics. In between sit your proposal, the client's selection, and usually a contract or master services agreement. Plenty of agency work skips the RFP entirely and starts with a phone call, which changes nothing about the SOW's job. Where an RFP does exist, use it as a checklist before you finalise the document. Take every requirement the client wrote down and mark it included, excluded, or priced separately. The dangerous ones are the requirements that sat in the RFP, went unmentioned in your proposal, and never reached the SOW at all. Those resurface at acceptance, and the client is not being cynical when they raise them. They wrote it down at the start and nobody told them it had gone. Our [breakdown of agency proposal types](/blog/agency-proposals-and-partnership-proposals-types-examples-and-templates) covers what belongs in the document that precedes this one. ## Is a statement of work the same as a contract? No. A contract or master services agreement (MSA) governs the commercial relationship between two businesses. A statement of work governs one project inside it. A signed SOW can be legally binding in its own right, which is why an SOW sent without a contract behind it still needs care rather than less of it. The practical question is which clause belongs in which document. | Clause | Contract or MSA | Statement of work | Change order | |---|---|---|---| | Liability cap, indemnities, insurance | Yes | Cross-reference only | No | | IP ownership and licensing | Yes | Cross-reference only | Only if the change creates new IP | | Confidentiality and data handling | Yes | No | No | | Deliverables and exclusions | No | Yes | Yes, as an amendment | | Acceptance criteria and review windows | No | Yes | Yes, for the new item | | Fee, payment schedule, rate card | Rate card optional | Yes | The difference only | | Termination and notice | Yes | Project notice period | No | | Change process | Sets the rule | Names the approvers | Is the output | Most agencies end up with one MSA per client and a fresh SOW per project, which keeps the slow legal negotiation to once per relationship instead of once per brief. Standalone SOWs with no MSA behind them are normal on small jobs and expensive on large ones, because everything the SOW does not mention defaults to whatever the client's own terms say. None of this is legal advice. Pay a solicitor once for a structure you can reuse, and stop redrafting terms you are not qualified to write. ## What should the out-of-scope list actually say? It should name the specific things a reasonable client would assume are included, and say plainly that they are not. Generic exclusions such as "anything not listed above" achieve nothing, because the argument is never about work nobody thought of. It is about work the client sincerely believed was covered. Write exclusions in five categories: - **Adjacent formats and variants.** Extra sizes, additional languages, print adaptations, a version for the trade show stand. - **Volume limits.** Number of concepts, revision rounds, pages, templates, interview participants. Put numbers on all of them. - **Timing.** Out of hours support, expedited turnarounds, work during the client's own launch week. - **Client-supplied inputs.** Copy, translation, stock licensing, product data, legal review. Say who pays for each. - **After delivery.** Hosting, maintenance, training, ongoing edits, analytics reporting past the final milestone. A worked pair reads like this. Included: three concept routes, one developed to final artwork, two rounds of consolidated feedback. Not included: additional routes, resizing for paid social placements not listed in the media schedule, or amends after final artwork is approved. Clients do not read the exclusions list at signature. They read it during the disagreement, which is precisely the moment it exists for. Getting that list out of people's heads is a conversation, not a drafting exercise, because the account lead knows what the pitch implied and the delivery lead knows what will actually get asked for in week four. If you want it structured rather than improvised, Projan will work through it deliverable by deliverable inside Slack, asking where each boundary sits and who approves it, with the result exportable to Asana or Trello as tasks. Have it before the document goes out, not after the client queries an invoice. ## What are two common causes of scope creep? The two causes that account for most agency scope creep are deliverables described in adjectives rather than counts, and a change process that everyone bypasses because saying yes is faster. 1. **Undefined deliverable boundaries.** Words like "full", "complete", "launch-ready" and "final" carry a different meaning for each reader, and the client's meaning is always the larger one. Every quantity you leave off the page is a number the client gets to imagine, and nobody imagines conservatively. 2. **Change requests handled informally.** A request arrives in a Slack thread or at the end of a status call, someone agrees to take a look, and the work enters the project without a quote, a date change or an approval. Nothing about that moment feels like a loss. It feels like good service, which is why it is so hard to stop. Other causes are real and less common: client-side reorganisation, a new stakeholder arriving at week five, and your own team gold-plating work nobody asked for. All three are easier to manage once the first two are closed off. For the relationship side of this, once creep is already happening, see [how to push back on scope creep without damaging the client relationship](/blog/how-to-stop-scope-creep-without-damaging-the-client-relationship). ## How does a change request become a change order? By being logged, quoted and signed before any work on it starts. The mechanism is simple and it fails for social reasons, not technical ones, so make the compliant path the easy one. A workable change order states the requested change in the client's own words, the additional fee at the agreed rate card, the effect on the delivery dates, the effect on any deliverable already in progress, and the name of the person authorising it. One page. Same version reference as the SOW. Two details make the difference between a process that runs and a process that gets skipped. First, set a small allowance for trivial requests, say a fixed number of hours per month, so nobody has to raise paperwork for a twenty minute favour. Without it, the whole process gets bypassed for small things and the habit spreads to large ones. Second, agree at kickoff who on the client side can approve additional spend, and confirm that the day-to-day contact usually cannot. Discovering that during a dispute is worse than asking an awkward question in week one. ## Does a statement of work need to be signed? Yes, and before the first hour is billed. Until it is executed the document records your intentions and nobody else's obligations, which is a poor position from which to defend an invoice. The signature is what converts your exclusions list from an internal view into a term the client accepted. Three things to get right: - **Signed by someone who controls the budget.** Your day-to-day contact may have agreed every line of the scope and still have no authority over the spend. Establish who signs while you are still drafting, not on the day you send it. - **Signed even when an MSA exists.** An MSA in place is not consent to this project's deliverables, dates or fee, and those three are what clients challenge. - **Signed version kept and referenced.** Electronic signature is ordinary practice for commercial agreements in the UK, and platforms such as DocuSign are standard. Archive the executed file under its version number so a change order amends a specific document rather than a general understanding. Work does sometimes start on a verbal go-ahead, usually because the client's procurement is slower than their launch date. If you accept that, cap it in writing the same day: what you are starting, up to what value, and that it is subject to the SOW being executed. Anything you build before signature is funded entirely out of your own margin, and it is the only work an agency does with no route to an invoice. ## Frequently asked questions **Can you add exclusions to an SOW after it has been signed?** Only by agreement, through a signed amendment or change order that both parties accept. You cannot narrow an agreed scope unilaterally. If you spot a missing exclusion during delivery, raise it at the next review rather than in an invoice dispute, and price the work properly if the client wants it kept in. **How many revision rounds should an SOW specify?** Name a number and define what a round is. Two rounds of consolidated feedback per deliverable is a common agency default. The definition matters more than the count: a round is one set of comments from one named approver, not four people sending notes across a fortnight. State the cost of an extra round in the same paragraph. **Should the rate card go in the statement of work?** Yes, or in a schedule the SOW refers to. Without agreed day rates, every change order becomes a fresh price negotiation while the work is already late. Include the roles you actually bill, the rates, and any minimum increment such as a half day. Note how long the rates hold for. **Who inside the agency should review the SOW before it goes to the client?** The person who sold the work, the person who will run it, and whoever carries the commercial risk. The delivery lead catches deliverables that cannot be built as described. Finance or operations catches payment terms that will not be met. Sending an SOW that the delivery team has never read is how implied promises reach the client unchallenged. **Should an SOW have an expiry date?** Put a validity date on the pricing. Agency estimates assume a team, a schedule and a cost base that change within months. A quote accepted five months after it was written commits you to last year's rates and a team that is now booked. A short line stating the offer is valid for thirty days is enough. An SOW protects margin only where it is specific. Put numbers on every quantity, write the exclusions beside the deliverables they qualify, and make the change order the cheapest path for both sides rather than the slowest. ### How to Run an OKR Planning Session That Ends in Commitment https://projan.ai/blog/how-to-run-an-okr-planning-session-agenda-limits-and-getting-real-commitment/ Published: 2026-08-30 Run an OKR planning session in two hours with a context pack sent in advance, a hard limit of three objectives, and a closing round where each key result gets a named owner and a stated measurement source. The session's job is not to write beautiful objectives. It is to end disagreement about what the next quarter is for. This is for whoever facilitates. It assumes you know what an objective and a key result are, and if you do not, the [definitions and the pitfalls that sink them are covered separately](/blog/okrs-explained-types-examples-and-the-pitfalls-that-sink-them). What follows is the running order and the two moments where these sessions go wrong. ## How to run an OKR planning session Run it as two blocks: a short framing block for context and constraints, then a longer drafting block where the team writes, cuts and assigns. Two hours is enough for one team. A full day gets spent on adjectives. 1. **Send the context pack 48 hours ahead.** Strategy, last cycle's results with the misses shown as plainly as the hits, and any company-level objectives this team must align to. People arriving cold spend the first half hour catching up while the confident ones set the agenda. 2. **Open with the constraints, not the ambitions.** Cycle length, the maximum number of objectives, and what is already committed: contractual dates, roadmap promises, a hire that will not land until month two. 3. **Draft silently first.** Ten minutes, everyone writes two or three candidate objectives alone. Sessions that open with discussion converge on whoever spoke first, usually the most senior person rather than the closest to the work. 4. **Cluster, then cut to the limit.** Force the cut while the wording is still ugly. Once an objective has been polished, someone owns it emotionally and cutting it becomes a personal loss. 5. **Write key results against each surviving objective.** Aim for three. Each needs a number, a named source for that number, and a starting value. 6. **Stress-test every key result out loud.** Teams skip this when they are running late, and it is why OKR sets quietly turn into status reports by week four. 7. **Assign and schedule.** One named person per key result, and a first check-in date in calendars before anyone leaves. Steps four and seven are where sessions fail. Skip the cut and you leave with a wish list. Skip the scheduling and the document goes unopened until the cycle review. ## How many OKRs should a team have? Three objectives with three key results each is the practical ceiling for one team in one quarter, and two objectives is usually better. The figure most commonly taught is three to five of each, from John Doerr's writing on the method, but five by five hands a team twenty-five measurable commitments on top of its ordinary work. Count the key results, not the objectives. Nine is a set a team can recite in week seven. Twenty-five is a spreadsheet somebody maintains. - **One team, one quarter:** two or three objectives, three key results each - **Fewer than five people:** one objective, given proper key results - **An individual:** none of their own. Individual OKRs turn a planning tool into a performance review - **Company level:** three to five objectives, with team sets that support them rather than copy them. How those cascade downward is a rollout question, and [setup, levels and ownership are covered separately](/blog/how-to-implement-okrs-in-a-company-setup-levels-and-ownership) If the team insists everything on the list is essential, that is your finding. A group that cannot cut to three has not agreed a priority. It has agreed a wish list and distributed the blame for missing it. ## OKRs vs KPIs: which of your numbers belong in the session? Objectives and key results describe a change you intend to cause this cycle. Key performance indicators describe the health of something that runs continuously. Only the first belongs in the OKR set. | | OKR | KPI | |---|---|---| | **What it describes** | A change you are trying to cause | A condition you are trying to hold | | **Time bound** | Yes, one cycle | No, it runs indefinitely | | **Target** | Set beyond comfortable, deliberately | Set at a threshold you defend | | **In the session** | Yes, this is the work | On the wall as context, not on the list | The commonest way an OKR set goes stale is a team promoting a metric it already tracks. Uptime at 99.9 percent, churn under two percent: those are thresholds to defend, and dressing them as objectives commits the team to carrying on as before. A deteriorating KPI can become an objective for one cycle and revert afterwards. For the wider distinction, read the [comparison of OKRs, KPIs and north star metrics](/blog/okrs-vs-kpis-vs-north-star-metrics-what-s-the-difference-and-how-to-use-all-thre). ## How to stress-test a key result before it goes in the document Test every key result with four questions, asked out loud while its author is still in the room. 1. **Where does the number come from?** Name the report, dashboard or query. If nobody can, building the measurement is work that needs its own owner and date. 2. **What is it now?** "Increase activation to 40 percent" is a different commitment depending on whether you start at 38 or at 12. 3. **Who reads it out at the check-in?** Not who is responsible in a general sense. Who says the number. 4. **If we hit this and the objective still has not happened, what did we get wrong?** This flushes out proxy metrics, the ones that measure activity because the outcome is harder to see. Expect this step to kill drafts, and let it. Watch the verbs while you are at it. Improve, support, increase awareness of, drive engagement with: those describe effort, not result. ## How to close the session so the commitment is real Close by having each owner read their own key result aloud, in their own words, with the date of the first check-in. Agreement that was only nodded at across a table does not survive contact with a busy fortnight. Everyone should leave with four things: - The written set, visible to the whole team by end of day - One named person per key result, a person and not a function - A check-in cadence in calendars, fortnightly or monthly, with the first one booked - A note of what the team decided not to do this cycle, which is the part people forget and then relitigate in March Silence is not agreement. If someone stayed quiet through the cut, ask which of these they think will not happen, and write the answer next to the objective. The cheapest doubt to handle is the one voiced before the cycle starts. Some teams hand facilitation to software: Projan runs the session as a structured conversation in Slack or Microsoft Teams, pressing on where each key result's number comes from and who will report it, then writing the agreed set and its follow-up tasks out to Asana or Notion. The tooling matters less than the habit, which is the same one behind this [guide to running a project planning workshop](/blog/how-to-run-a-project-planning-workshop-agenda-steps-and-turning-ideas-into-owned). ## Frequently asked questions **How many OKRs per team?** Two or three objectives per team per quarter, each with three key results. Teams smaller than five people should carry one. The limit is about recall rather than ambition: a team that cannot list its key results from memory in week seven has stopped using them. **Who should attend an OKR planning session?** The people who will own the key results, plus whoever can say no for the wider organisation. Keep it under about eight. Observers change the dynamic, because people argue less honestly when their skip level is watching. Absentees send their input as pre-work instead of reopening decisions later. **What do you do if the team cannot agree on an objective?** Park it and name the decision that has to be made first. Most deadlocked objectives hide an unmade decision elsewhere, usually about resourcing or about which customer segment matters. Escalate that decision to whoever owns it, with a date, and leave the objective out until it returns. A good OKR session is mostly subtraction. Cut to a set the team can recite, put a name and a measurable number against every line, and book the first check-in before anyone stands up. ### How to Create a Product Roadmap: Detail, Timeframes, and Dates https://projan.ai/blog/how-to-create-a-product-roadmap-detail-timeframes-and-dates/ Published: 2026-08-29 A product roadmap is created by working down from the product strategy, not up from a list of requests. Collect inputs from customers, support, sales, engineering and analytics, group them into outcomes rather than features, attach evidence to each, sequence them against real capacity, then have the draft challenged before you publish it. The format is the last decision, not the first. This is for product managers and product owners building or rebuilding a roadmap for a software team. It covers how the thing gets made, how much detail each horizon needs, whether to commit to dates, how far ahead to look, and why some roadmaps get rebuilt every quarter. ## How is the product roadmap created? A product roadmap is created in a fixed order, and the order matters more than the format you eventually pick. Most teams start at the sequencing step, which is why their roadmap ends up as everyone's requests in priority order rather than a plan for changing something. 1. **Write the strategy down first, in one paragraph.** Who the product is for this year, what you are betting on, and what you are deliberately not doing. Skip this and every request becomes equally valid, because nothing exists to measure it against. 2. **Collect inputs without filtering them.** Support tickets, sales loss reasons, usage data, the list engineering keeps of things that will break, competitor moves, and the executive requests you cannot ignore. Gather them all in one place before you start judging any of them. 3. **Group inputs into outcomes, not features.** "Cut time to first invoice" is an outcome. "Build an invoice wizard" is one guess at how to reach it. Outcome framing keeps the solution open long enough for an engineer to propose the cheaper version. 4. **Attach evidence to each candidate.** Accounts affected, revenue at risk, the research behind it, or an honest note that says this is a bet by a named person. Items with no evidence are not banned. They are labelled, which is enough to change how the room treats them. 5. **Sequence against capacity, dependencies and confidence.** Use the capacity the team actually has after support, incidents and maintenance, which for most established products is well under half the calendar. Put low-confidence items later, not because they matter less, but because they need discovery before they can be sized. 6. **Have the draft attacked before you publish it.** Engineering checks feasibility and hidden dependencies. Sales checks it against what has already been promised. Support checks whether the most common complaint appears anywhere on the page. Only then do you choose a format. Now, next and later versus quarters versus a timeline is where roadmap discussions usually begin, and it is the least consequential decision in the whole process. A weak roadmap in a beautiful format is still weak, and everyone downstream can tell. ## What is a product owner's roadmap? A product owner's roadmap is the outcome-level view of one product or product area, sitting between the strategy above it and the backlog below it. It states what the team intends to change and roughly when. It stops short of saying which sprint the work lands in or how it will be built. A usable one carries, for each item: the outcome, the problem or evidence behind it, a horizon, an owner, a current status, and somewhere on the page, an explicit list of what is not being done. The distinction that causes the most trouble is roadmap versus delivery plan. A roadmap is direction. A delivery plan is commitment. They answer different questions and they should not be the same artefact: - The roadmap answers what we are trying to change, in what order, and why that order. - The delivery plan answers which team, which sprint, which dependency, which date. Once a roadmap has a row per engineer, it has become a resource plan, and it will be maintained like one: grudgingly, by one person, and only when someone complains. Keeping the two separate also keeps the argument clean, because you can change a delivery plan without reopening the strategy. For the related question of who holds the pen and how the document stays current, see [who owns the product roadmap and how to keep it from going stale](/blog/who-owns-the-product-roadmap-and-how-to-keep-it-from-going-stale). ## How detailed should a roadmap be? Detail should decay with distance. Near work is specified enough to start. Distant work is specified enough to argue about. A roadmap where every item carries the same level of detail is either over-specified at the far end, where it will be wrong, or under-specified at the near end, where it cannot be picked up. | Horizon | What the item says | Dates | Needed before work starts | |---|---|---|---| | Now: in build or next up | Named scope, drafted acceptance criteria, an owner | Sprint or month | An agreed spec, reviewed by engineering | | Next: roughly one to two quarters out | Outcome, the measure it moves, rough size in weeks or months | Quarter, no firmer | Discovery done or scheduled | | Later: beyond two quarters | The theme and the problem it addresses | None | Nothing. It is a candidate, not a commitment | A useful test for the later column: could you delete any item on it tomorrow without telling anyone outside the product team? If the answer is no, it is not later. Someone has already been promised it, and you have a commitment filed under the heading for things you have not committed to. When an item moves into now, the detail has to arrive from somewhere, and that somewhere is a separate document rather than more columns on the roadmap. That is the point at which it earns a spec, and [the structure of a PRD and the mistakes that spoil one](/blog/how-to-write-a-prd-structure-best-practices-and-mistakes-to-avoid) is worth reading before you write it. Feature-level detail on a roadmap is not thoroughness. It is a delivery plan that got mixed in with a strategy document. ## Should a roadmap have dates? Yes for near-term work, no for anything past the next quarter or two, and never a date sent out without the confidence behind it. Dates are not the problem. Dates that travel without their confidence level are. Both extremes fail in predictable ways. A roadmap with no dates at all pushes the guessing outward: sales invents a quarter, marketing books a campaign against it, and the guess comes back to you as a commitment you apparently made. A roadmap with a date on every row becomes a commitment register, and the team spends its energy defending old estimates instead of changing them. The working compromise: - Now items get a month or a sprint, and you treat those as commitments. - Next items get a quarter, stated as intent, with the word intent actually written on the page. - Later items get no dates. Not a fuzzy date. None. - Anything quoted outside the company gets a buffer and a named person who owns the message when it moves. When an executive demands a date for something you have not scoped, give a range with the assumptions that produced it and the single thing most likely to move it. That is a more honest answer than a confident number, and it is defensible later. [Estimating a software project with confidence levels](/blog/how-to-estimate-a-software-project-time-budget-and-confidence-levels) covers how to produce the range without pretending to precision you do not have. If your organisation treats every date on a page as a promise, switching to now, next and later is a reasonable defence. Be clear with yourself that you are solving a trust problem with a formatting change, and that the trust problem is still there. ## How long should a roadmap be? Two different questions hide in this one, and both have short answers. On horizon: match it to how quickly your evidence goes stale. On page length: one screen for the version you share. Horizon guidance by situation: - **Pre-product-market-fit or early stage.** One quarter of specifics, plus a direction statement. Anything further out is fiction and everyone knows it. - **Established product, single team.** Two to four quarters. Two quarters of shaped work and one or two of themes is the shape most teams settle into. - **Platform, regulated, hardware-dependent or enterprise-sold.** Longer, because procurement cycles and compliance work force it. Twelve to eighteen months of themes with only the first quarter specified. On length: if the shared version does not fit on one screen, you have published a backlog and given it a nicer title. People will read the first eight rows and treat the rest as decoration. Keep the long list somewhere else and link to it for the people who genuinely want the detail. ## What does a 3 year roadmap look like? At three years a roadmap stops being a plan and becomes a direction statement. It holds three to six themes, uses year-level granularity, names no features past the first year, and says plainly what has to be true for years two and three to happen at all. The usual shape: - **Year one.** Outcomes by quarter, with the current quarter specified in real detail and the rest as intent. - **Year two.** Two to four themes, each expressed as the capability or market position it represents rather than a product to be built. - **Year three.** The position you intend to hold and what you would need to have built to hold it. No dates, no features. Three year roadmaps are asked for by boards, investors, enterprise procurement, public sector buyers and platform partners. It is largely a financing and confidence document that happens to be about product, so write it as one: honest about which parts are decided and which are direction, with the assumptions listed rather than implied. [What investors look for in a technical roadmap](/blog/what-investors-look-for-in-technical-roadmap) is a useful sense-check before that version leaves the building. Review it twice a year, expect years two and three to change, and print that expectation on the page. A dated version number costs nothing and stops someone quoting an eighteen-month-old slide back at you in a board meeting. ## What can cause an unstable product roadmap? Roadmap instability is almost always an input problem rather than a discipline problem. The roadmap keeps getting rebuilt because the things that determine it were never settled, so each quarter starts the same argument from scratch. The usual causes: - **No written strategy.** With nothing to test a request against, priority is decided by whoever asks most recently or most loudly. - **Items admitted without evidence.** An item nobody can justify has nobody to defend it when something newer arrives. - **Capacity assumed rather than measured.** Support load, incidents and maintenance are left out, everything slips a quarter, and the whole board gets redrawn instead of one date moving. - **External promises made before the work is understood.** A sales commitment can reorder a roadmap in an afternoon, and it usually does so at the point of least information. - **No explicit not-now list.** Rejected requests come back next quarter as fresh ideas, and get re-argued from zero. - **Reorganisations and funding changes.** Legitimate, unavoidable, and worth versioning the roadmap for so the change is visible rather than mysterious. Making the input conversation explicit is one defence against the evidence problem. Projan works through the candidate list in Slack or Microsoft Teams, asking what each item is meant to change and what evidence sits behind it, then writing the agreed items out to Jira or Linear. Not all change is instability. A roadmap that never moves is not stable, it is ignored. The symptom worth worrying about is items leaving the roadmap before anyone can remember why they arrived. ## Frequently asked questions **Should a product roadmap be shared with customers?** Share a version, not the version. Customers get themes and rough sequence with no dates, usually as a public now, next and later page. Keep internal capacity, named bets and abandoned items private. The real risk is not that customers see the plan. It is that a salesperson quotes an internal quarter to close a deal and creates a commitment nobody agreed to. **How many items should be on a roadmap at one time?** Fewer than feels comfortable. A workable limit is one to three outcomes in flight per team, four to six in the next horizon, and an unranked later list. If a team has eight active items it usually has eight half-finished ones. The constraint is not how wide the roadmap can be drawn, it is how many things a team can actually finish. **What is the difference between a roadmap and a backlog?** A roadmap says what you intend to change and roughly when. A backlog holds every candidate piece of work, ranked, most of which will never be built. Roadmap items are outcomes and number in the dozens at most. Backlog items are stories and tickets and number in the hundreds. A backlog published as a roadmap is unreadable to anyone outside the team. **Does a roadmap need a dedicated roadmap tool?** No. A slide, a table in Confluence or Notion, or a filtered board in Jira all work, and most teams cope with whatever they already argue in. Dedicated tools earn their place when several teams need one combined view, or when you want a record of what changed. They do not fix a roadmap whose inputs were never agreed. **What should you do when an item is dropped from the roadmap?** Announce it in writing, with the reason and the date. Silent removals are the main reason people stop trusting a roadmap. An item vanishes, nobody says anything, and the person who asked for it finds out six weeks later from a colleague. Keep a short changelog on the roadmap page recording what moved, what left, and why. A roadmap is a statement of direction with confidence levels attached, and the confidence levels are the part people delete first. Keep the near end specific enough to start work on, keep the far end vague enough to stay honest, and write down why each item is there. The arguments you have while building it are worth more than the page that comes out of it. ### Requirements Documents Explained: BRD vs FRD vs SRD vs PRD https://projan.ai/blog/requirements-documents-explained-brd-vs-frd-vs-srd-vs-prd/ Published: 2026-08-28 A BRD (business requirements document) states why a change is worth making and what the business expects to get from it. An FRD (functional requirements document) specifies what the system must do, case by case. An SRD, more commonly called an SRS, collects the functional and non-functional requirements that engineering will build and test against. All three come from business analysis and systems engineering rather than product management, and they assume a world where requirements are agreed and signed before anyone writes code. That world has not gone anywhere. This covers what each document actually contains, why the acronyms survive, and how to tell whether you need three of them or one. ## What is BRD, FRD, and SRD? They are three levels of the same chain: why the organisation wants the change, what the system must therefore do, and what has to be built and verified. Each one is meant to trace back to the one above it, which is the part most teams drop first. | | BRD | FRD | SRD or SRS | |---|---|---|---| | **Question it answers** | Why are we funding this, and what does the business get | What must the system do, rule by rule | What must be built, to what limits, and how is each item verified | | **Usually written by** | Business analyst or the sponsoring business unit | Business analyst, with a solution architect | Systems or software engineer, often alongside the analyst | | **Who has to agree it** | The sponsor and whoever holds the budget | The business owner, before build starts | Engineering and testing, and the customer on contracted work | | **Detail level** | Objectives, scope, high-level needs | Every rule, state, role and error case | Functional and non-functional requirements, interfaces, constraints | | **Traces back to** | The business case or strategy | Numbered items in the BRD | Numbered items in the FRD | | **Still normal in** | Enterprise programmes, public sector | Regulated work, supplier contracts | Systems engineering, safety-adjacent software | SRD is the least stable of the three names. In software work it usually means a software requirements specification, and SRS is the term you will meet far more often in templates and job adverts. In systems engineering it can mean a system requirements document sitting above the software level, describing hardware, software and operational requirements together. If someone hands you an SRD, ask which of those two they mean before you start reading, because the answer changes who is supposed to sign it. ## What are the 4 types of requirements? Business, user, functional and non-functional. That is the split most training courses and templates teach, and it maps onto the documents above closely enough to explain why both survive together. 1. **Business requirements.** What the organisation needs to achieve, stated without reference to any system. "Handle renewals without a phone call." These live in the BRD and are the only requirements a finance director will read. 2. **User or stakeholder requirements.** What a particular group needs to be able to do. A claims handler needs to see prior claims for the same policy before deciding. In agile work these become user stories; in a BRD they sit in a stakeholder section, grouped by role. 3. **Functional requirements.** What the system must do in response to a given input or state. These are the numbered "shall" statements that fill an FRD, including the error cases, permissions and rules that nobody mentions in a workshop. 4. **Non-functional requirements.** The limits and qualities: performance, availability, security, accessibility, data retention, supported platforms. They belong in the SRS because they shape architecture. Treat the four as a teaching convention, not a standard. Plenty of sources add transition requirements, covering migration, training and cutover, and some split out constraints and regulatory requirements as their own categories. Nothing is lost by using a different set of buckets as long as every requirement lands in one of them. Non-functional is where this taxonomy earns its keep, because it is the category people write as adjectives. "Fast" is not a requirement. A stated response time at a stated load is. For the wider craft of writing them properly, see [what good requirements look like](/blog/what-good-requirements-look-like-and-how-to-write-them). ## Where these acronyms came from, and why they survive They come from disciplines built around agreeing requirements before build, rather than discovering them during it. Business analysis produced the BRD and FRD; systems engineering produced the layered requirements specification that SRD and SRS descend from. The software end of that lineage has a real standard behind it. IEEE 830 was the recommended practice for software requirements specifications for years, and the section structure in a great many corporate SRS templates is a direct copy of it. IEEE 830 has since been superseded by ISO/IEC/IEEE 29148, which drops the three-letter shorthand in favour of stakeholder, system and software requirements specifications. Most organisations kept the old template and the old acronyms anyway. These documents survive for one reason, and it is not tradition. They survive wherever somebody outside the delivery team has to formally accept the result: - **Enterprise IT.** A steering group approves funding against a BRD and later asks whether what was delivered matches it. - **Regulated industries.** Financial services, medical devices and pharmaceutical systems need each behaviour traceable to an approved requirement, because that trace is what an auditor inspects. - **Government procurement.** The specification is usually an annex to the contract, so changing it is a commercial event rather than an editorial one. - **Agency and systems integrator work.** On fixed-price builds the functional document is the acceptance artefact, and the supplier is paid against it. These documents are less a relic of a slower era than a product of contract law. Where the delivery relationship is commercial, someone has to be able to point at a page and say the thing on it was or was not delivered. ## What are the key components of a BRD? A BRD needs enough to justify the spend, bound the work and name the people accountable for both. Nine sections cover it, and templates that run to thirty are usually padding the front. 1. **Business need.** The problem or opportunity, in a paragraph, with the cost of doing nothing. 2. **Objectives and success measures.** What changes, by how much, measured how. Vague objectives here produce arguments at acceptance. 3. **Scope and out of scope.** Two lists. The second one is the one that gets used. 4. **Stakeholders.** Named people and their role in approval, not a list of departments. 5. **Current state.** How the process works today, including the workarounds, because those are requirements in disguise. 6. **Business requirements.** Numbered, uniquely identified, one requirement per statement, each traceable forward into functional detail later. 7. **Assumptions, constraints and dependencies.** Budget ceilings, fixed dates, systems that cannot be touched, other projects you rely on. 8. **Risks.** The ones material to the requirements themselves, such as a data source nobody has confirmed exists. 9. **Approval.** Who signs, what their signature means, and how a change to the document gets approved after that. The two most commonly missing components are the out of scope list and measurable success criteria. Both are omitted for the same reason: writing them forces a decision the sponsor would rather defer. ## How to structure a requirements document? Structure it so any single requirement can be found, understood and verified without reading the rest of the document. That constraint decides the layout more than any template does. 1. **Purpose and scope**, in one page, including what the document does not cover. 2. **Glossary**, defined early, especially for domain terms two departments use differently. 3. **Stakeholders and roles**, with the approval chain stated. 4. **Overall description**, meaning context, users, operating environment and known constraints. 5. **Functional requirements**, grouped by capability or user journey, each with a unique persistent identifier. 6. **Non-functional requirements**, in their own section with figures attached to every one. 7. **Interfaces and dependencies**, covering other systems, data feeds and third parties. 8. **Verification**, stating how each requirement will be shown to be met, whether by test, inspection or demonstration. 9. **Traceability and version history**, mapping requirements upward to their source and recording who approved which version. Four conventions make the difference between a document that survives delivery and one that gets abandoned in week three. Give every requirement a permanent ID and never reuse it. Write one requirement per statement, so that "and" in a requirement is a signal to split it. Keep "shall" for obligations and drop it everywhere else, so the mandatory items are countable. Attach a verification method to each requirement as you write it, because a requirement nobody can test is an opinion with a number next to it. Structure is downstream of gathering, and a well-formatted document built on unasked questions is still wrong. [Requirements gathering methods and how to handle ambiguity](/blog/requirements-gathering-methods-stages-and-how-to-handle-ambiguity) covers the part that happens before the template opens. ## Where the PRD fits A product requirements document does the BRD's job and part of the FRD's, for a team that does not need a signature. It carries the problem, the users, the scope boundary and the success measures, then leaves behaviour to stories and acceptance criteria written closer to the build. That is the real difference, and it is not about agile versus waterfall. A PRD is written to be changed while work is in flight. A BRD and an FRD are written to be approved and then formally amended, because a third party is relying on the approved version. Product teams shipping their own software can revise scope on a Tuesday and nobody is owed anything. The document families also disagree about who decides what. [PRD, product spec, technical spec and functional spec compared by decision rights](/blog/prd-vs-product-spec-vs-technical-spec-vs-functional-spec-what-each-document-is-f) sets out that side of the landscape, and [how to write a PRD](/blog/how-to-write-a-prd-structure-best-practices-and-mistakes-to-avoid) covers the writing itself. ## Do you need all three, or one document? Ask who has to formally accept the result. That question settles it faster than any comparison of templates, and it is the question teams skip while they argue about which acronym their process mandates. If an external party accepts delivery against a document, you need the separation. The BRD protects the funding decision, the FRD is what acceptance is measured against, and the SRS is what engineering and test work from. Collapsing them means one document is doing a legal job and an engineering job at once, and it will be too vague for one and too detailed for the other. If nobody outside the team accepts anything, most of this is ceremony with a version number. A BRD that nobody signs is a PRD with worse formatting and a longer approval queue. Write one document, put the objectives, scope boundary, non-functional limits and success measures in it, and keep the functional detail in tickets where it can change without a change request. The failure mode in the middle case, where sign-off is internal but real, is the one worth naming. Someone drafts alone, circulates for comment, gets approval rather than agreement because reviewing a finished document is much harder work than answering a direct question, and the disagreements surface during build. The questions are the deliverable; the file is the receipt. Projan asks them as a structured session in Slack or Microsoft Teams, pressing on the scope boundary, the owners and the non-functional limits, then exports the agreed items to Jira. ## Frequently asked questions **What is the difference between an FRD and an SRS?** Scope and audience. An FRD lists what the system must do in business language, so a client or business owner can check it. An SRS adds non-functional requirements, interfaces and constraints, and is written for the people who will build and test the thing. Many organisations produce only one of them and label it whichever way their template does. **Is a BRD the same as a business case?** No. A business case argues that the investment is worth making, with costs, benefits, options and a recommendation. A BRD assumes that argument has been won and records what the change has to achieve. They overlap on objectives and scope, and small projects often merge them, which is fine as long as the funding decision stays visible. **Who writes a BRD or an FRD?** A business analyst, usually, working from interviews and workshops with the people who own the process. On smaller engagements the project manager or the supplier's lead consultant writes it instead, and the sponsoring business unit approves it. Engineering should read the draft before approval, because unreviewed requirements turn into estimates nobody can defend. **Do agile teams write FRDs?** Rarely, and usually only when a contract asks for one. The functional detail lives in stories and acceptance criteria instead, written close to the work and changed as understanding improves. Teams delivering a fixed scope to an external client keep the FRD, because it is the document that acceptance gets measured against at the end. **What does non-functional actually mean?** It covers how well the system does its job rather than what it does: response times, throughput, availability, security controls, accessibility standards, data retention, recovery targets. These are the requirements most often left as adjectives, and the ones most likely to force a rebuild when they surface late, because they shape architecture rather than screens. Three acronyms, one chain, and a set of assumptions about approval that most software teams no longer live under. Count the signatures your delivery genuinely requires, then write the smallest number of documents that carries them. ### Definition of Done vs Definition of Ready: Owners, Checklists, and Examples https://projan.ai/blog/definition-of-done-vs-definition-of-ready-owners-checklists-and-examples/ Published: 2026-08-24 In Scrum, the Definition of Done (DoD) is the team's shared standard for when work is genuinely finished, and it is the only one of the two that the Scrum Guide actually defines. The Definition of Ready (DoR) is an optional team convention describing what a backlog item needs before anyone starts it. That asymmetry matters more than most comparisons of the two admit. This guide is for product managers, scrum masters and tech leads who need both agreements to hold up. It covers what each one is, who owns them, what a realistic DoD checklist contains, how done differs from the sprint goal, how PMI frames the pair, and how to encode a DoD in Jira without pretending the tool enforces it. ## What are DoD and DoR in Scrum? The Definition of Done is a formal description of the quality standard an increment must meet to be considered releasable. The Definition of Ready is a team-invented checklist describing what a backlog item needs before it can sensibly be pulled into a sprint. One is part of the framework; the other is a widely used practice that grew up beside it. The 2020 Scrum Guide names three commitments: the Product Goal for the Product Backlog, the Sprint Goal for the Sprint Backlog, and the Definition of Done for the Increment. It also says that where the organisation sets a Definition of Done, teams must treat it as a minimum and may add to it. There is no equivalent passage for a Definition of Ready anywhere in the guide, and there never has been. It comes from trainers, coaches and teams who got tired of starting work they could not finish. Treat that difference as practical rather than doctrinal. A DoR is a perfectly reasonable thing to have. It just does not carry the same authority, which means nobody outside your team is obliged to respect it and you cannot cite the framework when someone ignores it. | | Definition of Done | Definition of Ready | |---|---|---| | **Status in Scrum** | A commitment to the Increment, defined in the Scrum Guide | Not in the Scrum Guide; a team practice | | **Applies to** | Every increment, and therefore every item inside it | Each backlog item before it enters a sprint | | **Question it answers** | Can this be released or called finished? | Can the team start this without guessing? | | **Typical contents** | Code reviewed, tests written and passing, merged, deployed to a test environment, docs updated, telemetry in place | Value stated, acceptance criteria present, dependencies known, designs available, roughly sized | | **Owned by** | The whole Scrum Team, subject to any organisational minimum | The team, usually with the product owner, purely by convention | | **Checked at** | Any point work is called finished, and at sprint review | Refinement and sprint planning | | **How it changes** | Tightens deliberately as the team automates more | Rarely revisited, often quietly abandoned | | **Failure mode** | So aspirational that nothing ever meets it | A gate that blocks work while nobody fixes the cause | The shortest way to hold them apart: ready is a question about the item, done is a question about the team. A DoR varies with how well understood a piece of work is. A DoD does not vary at all, which is precisely what makes it useful. ## Who is responsible for DoD and DoR? The whole Scrum Team owns the Definition of Done, not the scrum master and not the product owner. The Scrum Guide is explicit that the Scrum Team creates it where the organisation has not already set one, and that any organisational standard is a floor rather than a ceiling. In practice, ownership splits like this: - **Developers** propose most of the technical items, because they are the ones who will perform them on every ticket. If engineers did not write the testing and deployment lines, those lines are someone else's homework and will be treated accordingly. - **The product owner** has a vote but not a veto. A product owner cannot waive the DoD to get something into a release, which is the whole point of writing it down. They can, and should, argue that an item is ceremony rather than quality. - **The scrum master** owns the fact that it exists, gets reviewed and is visible. Not its contents. - **The organisation** may impose a minimum: accessibility conformance, security review, regulated change records. Teams add to that, never subtract. The Definition of Ready has no such settlement, because no framework assigns it. The workable arrangement is that the team writes it and the product owner is accountable for meeting it, since most of its entries are inputs the product owner supplies or arranges. That gets uncomfortable quickly, which is the useful part. A DoR that nothing ever fails is decoration. A DoR that half the backlog fails is telling you that [refinement is not happening often enough](/blog/backlog-refinement-who-owns-it-how-long-it-takes-and-how-to-run-it), not that the team should work harder at gatekeeping. One rule saves a recurring argument: whoever is allowed to declare something done should not be the same person who did the work. Peer review is not a formality on the DoD, it is the mechanism. ## What are the criteria for a Definition of Done? The criteria are whatever your team performs on every item without being asked, written down so nobody has to remember it. Not what a good team would do. What this team does, every time, including the sprint before a launch. A realistic list for a team shipping a web product looks roughly like this: - Code peer-reviewed and merged to the main branch - Unit and integration tests written for new behaviour, and the full suite passing - Acceptance criteria demonstrated against the story, by someone other than the author - No new critical or high severity issues from static analysis or dependency scanning - Deployed to a staging environment from the pipeline, not by hand - Feature flag configuration recorded, including the default state on release - Logging and any relevant metric or alert in place - User-facing documentation and release notes updated - Support or operations told what changed, where the change is behind a flag Eight to twelve items is the range most teams settle at. Below about six, the list is usually missing the steps that actually get skipped under pressure. Above fifteen, people stop reading it and start ticking it. Three tests separate a real criterion from a wish. Is it binary, so two people would agree whether it holds? Is it performed on every item rather than on the big ones? Does someone specific perform it? An entry like "code is high quality" fails all three. "Reviewed and approved by an engineer who did not write it" passes all three. Keep story-specific conditions out of the DoD. Those are acceptance criteria, and they belong on the ticket; the formats and how they interact with a DoR are covered in [acceptance criteria formats and types](/blog/acceptance-criteria-formats-types-and-how-they-differ-from-definition-of-ready). The DoD is the bar every story clears whatever it is about. A story can satisfy every acceptance criterion it carries and still not be done, and that gap is where release-day surprises live. ## What is the difference between sprint goal and Definition of Done? The sprint goal states why this sprint matters; the Definition of Done states what quality any work must reach before it counts. One is a single outcome the team commits to for a fortnight, the other is a standing standard that does not change from sprint to sprint. The clean way to see it: the sprint goal can change during the sprint by negotiation between the developers and the product owner as more is learned. The Definition of Done cannot be renegotiated mid-sprint to get work over the line. If it could, it would not be a standard. They also fail differently. A team can meet its Definition of Done on every item and still miss the sprint goal, because it finished eight unrelated tickets and no coherent outcome. A team can also hit the sprint goal with work that is not done, having demonstrated something impressive that has no tests and lives on a branch. The second failure is the more expensive one, because it is invisible until the following sprint, when the tidying up appears as unexplained slippage. More on framing the outcome itself is in [how to set a sprint goal](/blog/sprint-goals-how-to-set-one-who-can-change-it-and-what-a-good-sprint-looks-like). Both are commitments in Scrum terms, attached to different artefacts. Sprint goal to the sprint backlog, Definition of Done to the increment. Conflating them usually shows up as a sprint review where nobody can say whether the demonstrated thing is releasable. ## What is the difference between DoD and DoR PMI? Very little in substance, and a good deal in scope. PMI's Agile Practice Guide, produced with the Agile Alliance, uses both terms with the meanings above, so a team moving between a Scrum context and a PMI-influenced one is not learning new concepts. What changes is what the surrounding governance expects "done" to include. Two differences are worth planning for. First, PMI framing tends to apply the pair beyond a single increment, to features, releases and phases, so you may be asked for a definition of done at release level as well as story level. Second, in a governance-heavy organisation the release-level list picks up items no Scrum team writes on its own: a change record raised and approved, training material updated, an operational handover accepted, a benefits measure baselined. The mistake is treating those as bureaucracy to be dodged. They are real work with real owners, and leaving them off the list does not remove them, it just moves them to the week after the release when nobody has capacity. Keep two lists if you need to. A short team-level DoD applied to every story, and a release-level checklist applied once per release, with named owners for the items the team does not perform itself. ## How do I add a Definition of done in Jira? Put the text where the work is, then use Jira to make skipping it awkward rather than to enforce it. Jira can remind, prompt and block transitions; it cannot make anyone write a test. 1. **Keep the source outside Jira.** A Confluence page or a markdown file in the repository is the version people edit and discuss. Everything below is a copy pointing at it. 2. **Set a default description on the story issue type.** In a company-managed project, a field configuration can give the Description field a default value, so every new story opens with the checklist already in it. Availability varies by Jira plan and project type, so check before you promise it. 3. **Add tickable items if the team wants them.** Jira has no native per-issue checklist beyond subtasks, so this means either subtasks or one of the marketplace checklist apps. Use subtasks sparingly, and only for the two or three items that regularly get skipped. 4. **Put a condition or validator on the transition into Done.** Requiring a resolution, a linked pull request or a completed subtask stops the most casual kind of drag-to-done. 5. **Use an automation rule to prompt at the right moment.** A rule that comments the checklist when an issue moves to In Review lands while someone is still looking at the code, which the description does not. 6. **Add a sidebar shortcut to the source page.** Cheap, and it means new joiners find it without asking. 7. **Review it in a retrospective, not in a tooling ticket.** The list changes when the team's capability changes. That conversation belongs to people, not to a board configuration. Encoding it is the easy half. Agreeing the contents is where teams stall, because it forces an explicit answer to what everyone has been assuming separately. If getting the whole team in a room to argue it out keeps slipping, run it asynchronously instead. [Projan](/landing/engineering) will put each proposed item to the team one at a time in Slack or Microsoft Teams, asking who performs it and what happens on the sprints it gets skipped, then write the agreed list out to Confluence or Jira. However you get there, the test is the same. Items nobody defended in the discussion will not be performed in the sprint. ## Frequently asked questions **What is the DoD checklist in Agile?** There is no universal list. A Definition of Done checklist is whatever your team performs on every item without being asked, written down so nobody has to remember it. Two teams in the same company will have different lists because they deploy differently and support different things. Borrowing another team's checklist gives you their aspirations, not your standard. **Should the Definition of Done ever change?** Yes, and it should tighten over time rather than loosen. When a team automates something it used to do by hand, that item stops being optional and joins the list. Loosening happens too, usually when an item has quietly stopped being performed. Make that change in the open at a retrospective rather than letting it erode. **What happens if a story does not meet the Definition of Done at the end of the sprint?** It is not done, so it does not go in the increment and it is not demonstrated as finished. Put the remaining work back on the product backlog and let the product owner order it. Do not split the story after the fact to make the burndown look better, because that hides the estimate that was wrong. **Do Kanban teams need a Definition of Done?** Yes, and often per column rather than one list for the whole flow. Continuous flow teams write exit criteria for each stage, so an item leaves In Progress only when the stated conditions hold. The purpose is identical to the Scrum version. Only the granularity differs, because there is no sprint boundary forcing the check. **Is a Definition of Ready worth having at all?** It is worth having as a short prompt and dangerous as a policy. Three or four items that catch genuinely unstartable work will save arguments in planning. A long list enforced strictly turns refinement into an approvals queue, and the team stops asking whether an item is understood and starts asking whether it has passed. Write the Definition of Done from what your team already does rather than from what you would like to be true, and keep the Definition of Ready short enough that failing it is informative. Both are agreements between people. The board configuration is only where you keep a copy. ### What Steps Should Be Taken When Planning a Meeting? https://projan.ai/blog/meeting-planning-and-follow-through-a-complete-playbook-from-agenda-to-action-it/ Published: 2026-08-22 Planning a meeting takes eight steps, and the first one decides whether the rest matter: name the decision the meeting must produce. Then invite only the people who can make it, write the agenda as questions, send a pre-read, timebox the items, appoint a recorder, sort the logistics, and agree where actions will be tracked. This is the end to end version: before, during and after, plus the documents that carry the outcome between them. It is written for whoever ends up running the thing, which in most organisations is not a trained facilitator. Each stage is simple on its own. Almost all the failures happen between them. ## What steps should be taken when planning a meeting? Work through these eight steps in order, because each one narrows the next. 1. **Write down what the meeting must produce.** Finish the sentence "this meeting ends when we have agreed...". If you cannot, you are booking a briefing, and a briefing can be an email that people read at their own speed. 2. **Invite the smallest group that can commit.** Everyone else gets the record. A person who cannot approve, veto or do the work is attending as an audience, and audiences make meetings longer without making them more decisive. 3. **Turn the agenda into questions.** "Budget" is a topic. "Do we fund phase two now at the quoted figure, or defer it to the next planning round?" is a question someone can answer in the room. An agenda that lists topics is a reading list. An agenda that lists questions is a plan. 4. **Send the pre-read with the invitation.** Say what to read, how long it takes, and what you want people to have formed a view on. Two clear days is the working minimum. 5. **Timebox each item and name who leads it.** Put the minutes on the agenda itself. An item with no lead becomes a general discussion, and general discussions expand to fill whatever is left. 6. **Appoint the recorder before the day.** Deciding who writes things down by looking around the room at minute fifty produces the notes you deserve. Rotate the job if you like, but assign it in the invitation. 7. **Sort the mechanics.** Room, dial-in, whether it is being recorded and whether everyone has been told, accessibility requirements, and who photographs the whiteboard. 8. **Agree where the actions will live.** Name the tracker before the meeting starts. Actions that are captured somewhere new every time are actions that get lost in the variance. Steps one to three are the ones that actually change outcomes. Steps four to eight mostly stop good preparation being wasted. ## Where meetings actually fail: the handovers Meetings rarely collapse in the middle of a stage. They collapse at the handovers between stages, each of which takes under two minutes and each of which is the first thing sacrificed when the clock runs out. | Handover | What it should produce | How it fails | The fix | |---|---|---|---| | Agenda to discussion | A room that knows what it is deciding | The chair opens with "so, thoughts on this?" and the question on the agenda is never actually asked | Read the question aloud before opening the item | | Discussion to decision | Agreed wording, not agreed mood | Everyone nods at slightly different propositions and leaves believing different things | Say the decision back in one sentence and ask if that is what was agreed | | Decision to record | A written line someone can quote in March | The decision is captured as a summary of the debate rather than the outcome | Write the outcome first, the reasoning second, in that order | | Record to action | A named owner and a date | The record says "team to progress" | Refuse to write an action without a person and a date attached | | Action to next agenda | Visible follow-through | Last meeting's actions are never reviewed, so the next set is written with the same optimism | Open every recurring meeting with the previous action list | The pattern is consistent. Each stage is a translation, and translations lose information unless somebody deliberately checks the output against the input while both are still present. The chair is the only person positioned to do that, which is why a meeting with a strong agenda and a passive chair still ends badly. The middle handover, discussion to decision, is where most of the damage is done, and it deserves more room than a pillar article can give it. If your meetings routinely end with a feeling of agreement rather than a decision anyone can quote, [running the session as an explicit decision-making meeting](/blog/how-to-run-a-decision-making-meeting-that-actually-ends-with-decisions) is the intervention that pays back fastest. ## Which document records meeting decisions? Minutes are the formal record of what a meeting decided. A decision log is the record of decisions across meetings, and for most working teams it is the more useful of the two. The difference matters because they answer different questions. Minutes answer "what happened in that meeting", and are organised by date. A decision log answers "why is the system like this", and is organised by subject. Anyone joining a project six months in needs the second one and will be handed the first. Formal minutes still have their place. In the UK, minutes of directors' meetings must be kept as a company record, which is why board minutes get formally approved at the following meeting before anyone treats them as final. Most internal meetings need nothing that heavy. The choice between notes, a transcript and full minutes depends on what the record is for, and the [comparison of notes, transcripts and minutes](/blog/notes-vs-transcripts-vs-minutes-which-meeting-record-do-you-actually-need) is worth reading before you commit a team to the expensive option by default. Whatever format you use, a decision entry needs five things: - The decision, stated as an outcome rather than a discussion - The date it was made - Who made it, by name or by role with authority - What was rejected, and briefly why - What it depends on, and what expires if that dependency changes The fourth is the one everyone skips and the one that stops the same argument reopening two quarters later. If the only record of a decision is that everybody nodded, the decision will be relitigated by the first person who was not in the room. ## What should be done after a meeting? Send the record within a day, with decisions at the top and actions underneath, each carrying a name and a date. Everything else in the follow-up sequence depends on that one artefact existing quickly. A workable sequence: 1. **Circulate the record the same day.** The half-life of a meeting decision is about twenty four hours. After that people remember the mood of the room rather than the wording. 2. **Open a short correction window.** Forty eight hours, stated explicitly, after which the record stands. This is not bureaucracy, it is what makes the record quotable later. 3. **Move actions into the tracker immediately.** An action that lives only in the minutes is an action nobody sees again until the next meeting. 4. **Nudge before the deadline.** Two days before, in the channel where the work happens. Chasing after the date has passed is not follow-up, it is reporting. 5. **Review the actions at the start of the next session.** Publicly, by name. This is the single change that most improves completion rates, because it makes follow-through visible. Chasing well is a craft in itself, and the tone of the nudge decides whether people start pre-empting it or start avoiding you. That belongs in a piece of its own, and [the mechanics of follow-up that actually sticks](/blog/meeting-follow-up-that-actually-sticks-emails-nudges-and-follow-through) covers the emails, the timing and the escalation path. The pillar-level rule is simpler: the record and the tracker must not drift apart, because the moment they disagree, people stop trusting both. ## How do you write an action item? An action item names one person, one verb, one output and one date. Remove any of the four and it stops being trackable. The output is the part most people get wrong. "Look into" and "follow up on" describe activity, not a result, so there is no moment at which the item is finished and no way for the owner to prove it was. Write the thing that will exist when the action is done. | Weak | Why it fails | Rewritten | |---|---|---| | Look into pricing options | No owner, no output, no date | Priya to circulate a one-page comparison of the three pricing options by Friday 22nd | | Team to review the draft | Plural owner, so nobody | Sam, Alex and Jo each to comment inline on the draft by Wednesday; no comment counts as agreement | | Follow up with legal | No definition of finished | Ravi to obtain written confirmation from legal that the data processing wording is acceptable, by 30 April | | Fix the onboarding flow | That is a project, not an action | Nadia to write a one-page problem statement on onboarding drop-off for the 12 May meeting | Two owners means no owner. If a piece of work genuinely needs two people, give it one owner and name the second as a dependency inside the item. And keep the dates real: an action item without a date is a wish with a name attached, and a date chosen to avoid an awkward conversation in the room will produce a worse conversation a fortnight later. If the capture step is the one that keeps collapsing, one option is [Projan](/landing/meetings-to-plans), which runs the wrap-up as a structured exchange in Slack or Microsoft Teams, asks for a named person and a date against every item raised, and writes the agreed list out to tools such as Asana or Notion. ## Frequently asked questions **What are action items in a meeting example?** An action item is work one person owes by a date. It is not a decision and not a note. If a record contains three decisions and fourteen actions, most of those actions are probably discussion that nobody wanted to resolve. A real example: Priya to send the revised supplier quote to the group by Thursday 14th. **How far in advance should an agenda go out?** Far enough that the pre-read can actually be read, which for most working meetings means two clear days. Send the agenda with the invitation rather than the morning of, and if the pre-read is not ready by the deadline you set, move the meeting. A meeting held on unread material is a meeting held twice. **What should you do if a meeting ends without a decision?** Record the non-decision explicitly, along with what is missing and who is getting it. Write it as an action with a name and a date, then either book the follow-up while everyone is still in the room or state that the decision now sits with one named person. An undecided item left silent will be rediscovered weeks later. **Who chases actions when there is no project manager?** Whoever chaired the meeting, until they hand it to someone by name. Chasing is not an administrative afterthought, it is the only part of the process that changes behaviour. Set the nudge for two days before the deadline rather than the day after, and do it in the channel where the work happens, not by private message. Judge your meetings by what exists the following morning, not by how the hour felt. If the decisions are written in words someone could quote, and every action carries a person and a date, the meeting worked. If not, the stages were fine and the handovers were not. ### Common Project Planning Mistakes and Their Root Causes https://projan.ai/blog/common-project-planning-mistakes-and-the-root-causes-behind-them/ Published: 2026-08-21 Most project planning mistakes are variations on four things: assumptions nobody wrote down, a single-point estimate treated as a commitment, scope with no stated edges, and a plan built by one person. The root cause behind nearly all of them is the same. A decision was made without the person who would have argued with it. This is about the planning stage specifically, before anyone writes code. Delivery-phase warning signs are a different subject, covered in [the early red flags that predict a failing software project](/blog/why-software-projects-fail-early-red-flags-and-how-to-catch-them). ## What are the most common project planning mistakes? The common project planning mistakes are the ones that look like reasonable shortcuts at the time. Each one saves an uncomfortable conversation in planning week and buys a worse one later. | Mistake | How it shows up in week six | Root cause | |---|---|---| | Assumptions left unstated | "We assumed the payments API would be ready" | Nobody had to accept or reject the assumption, so nobody owned it | | Single-point estimates | "Six weeks" appears on a slide as a delivery date | Someone wanted one number and the estimator gave one | | No out-of-scope list | Every adjacent request arrives looking included | Writing what you will do is quicker than deciding what you will not | | Plan written by one person | Engineers see it first at kickoff and start objecting | Planning was treated as a writing task, not a decision-making one | | Dependencies recorded, not agreed | "Blocked on the platform team" for eleven days | No named person on the other side ever committed to a date | | Acceptance left undefined | "Done" is argued about at the end | Everyone assumed their own definition was the shared one | | No trigger for replanning | The plan is stale by week three and stays published | Changing the plan feels like admitting the plan failed | Two of these do more damage than the rest combined. Unstated assumptions are the first, because an assumption that never gets written is never tested by the one person on the team who knows it is wrong. The second is the single-point estimate, which is less an estimation problem than a communication one. If you say six weeks and mean "six if the third-party integration behaves, ten if it does not", the second half is what gets dropped between your mouth and the roadmap. Give ranges with the condition attached, or a date with a confidence level, as covered in [estimating a software project with confidence levels](/blog/how-to-estimate-a-software-project-time-budget-and-confidence-levels). The out-of-scope list is the cheapest section of any plan to write and the only one that helps you refuse work politely in week nine. ## Why do project plans fail? Project plans fail in three distinct ways, and the fix is different for each. They were wrong when written, they became wrong and nobody said so, or they were right and nobody read them. **Wrong when written** is an information problem. The plan encoded a decision that the people with the relevant knowledge never made. This is the failure mode that planning practice is actually designed to prevent, and the one most often skipped in the interest of momentum. **Became wrong** is a maintenance problem. Something moved, the plan did not, and for a few weeks the team ran on a document everyone privately knew was stale. What makes this expensive is not the staleness. It is that people stop trusting the plan generally, so the next accurate version is ignored too. **Right but unread** is a format problem. A forty-page plan that only its author has finished is worth less than a page the whole team can recall. Plans get read when they carry decisions rather than descriptions, and when someone is expected to act on them this week. A useful test: pick any two people on the delivery team and ask each, separately, what is explicitly out of scope. If the answers differ, the plan has already failed and you have found it early. ## What is the root cause of project failure? There is rarely a single root cause, and looking for one is usually how teams end up blaming the estimate. A late project is a chain of small decisions, each defensible in isolation. The useful question is not which link broke, but which link you could have changed during planning. Run the chain backwards on a concrete example. The release slipped three weeks. Why? Integration testing found a data mismatch late. Why? Nobody tested against real production shapes until the end. Why? The staging data set was a fixture written a year ago. Why? Refreshing it was a two-day job that never had an owner. Why? It appeared in the plan as a dependency rather than a task with a name against it. That last answer is the one you can act on. The five-whys technique, which came out of Toyota's production system, is poor at assigning blame and very good at showing where a plan stopped being specific. The chain almost always terminates in the same place: a piece of work everyone assumed belonged to somebody else. At the planning stage the root causes worth naming are narrow. Decisions taken without the information holder. Estimates converted into commitments by someone other than the estimator. Work with no named owner. Everything else in the table above is downstream of one of those three. ## How do you design a planning session that catches these? Fix the root causes by changing the shape of the planning session, not by adding fields to the template. The following six moves take about an hour combined. 1. **Write the assumptions list before the schedule.** Anything that must be true for the plan to hold. Read them out. The ones that get an audible reaction are your real risks. 2. **Ask "what happens if this slips?" against every dependency.** If the answer is "the whole thing waits", that dependency needs a named owner on the other team and an agreed date, not a Jira link. 3. **Estimate in ranges, and record what would collapse the range.** "Four to nine days, four if the schema is unchanged" survives being repeated by someone else. "Six days" does not. 4. **Write three things you are explicitly not doing.** Say them out loud to the person most likely to want them. 5. **Agree the replanning trigger while everyone is calm.** Any task overrunning its upper estimate by half, say, or any dependency date moving. Deciding in advance removes the judgement call from the week it is needed. 6. **Name an owner for every item, including the boring ones.** Test data, environments, access requests. These are what eat the buffer. All of this depends on the right people being present, which is the real constraint. [Who should be in the room and who owns the plan afterwards](/blog/who-should-be-involved-in-project-planning-and-who-owns-the-plan) is worth settling before you book anything. Where the group genuinely cannot meet, running the questioning in writing beats skipping it. Projan does it that way, putting the scope, ownership and slip questions to the team in Slack or Microsoft Teams and exporting the agreed plan to Jira or Linear as tasks. For higher-risk work, add [a premortem before the plan is signed off](/blog/how-to-run-a-premortem-surfacing-project-failure-before-it-happens). Assuming the failure has already happened produces sharper objections than asking whether anyone has concerns, because it removes the social cost of being the pessimist. ## Frequently asked questions **What are some common mistakes to avoid in planning?** Before the session even starts: planning with the wrong people in the room, planning at the wrong altitude, and planning further ahead than you have information for. A plan that specifies month five in the same detail as week one is not thorough, it is fiction with a timestamp. Detail the next horizon, sketch the rest. **Who is responsible when a project plan turns out to be wrong?** The plan's owner is accountable for noticing and revising it, not for having predicted the future correctly. Blaming the estimate is a way of avoiding the more useful question, which is who held the information that would have changed the plan and why it never reached the person writing it. **How often should a project plan be reviewed?** On a fixed cadence and on defined triggers. Fortnightly is enough for most delivery work. The triggers matter more than the cadence: a dependency date moving, a requirement changing, or an estimate being overrun by more than a set margin should all force a review rather than waiting for the next scheduled one. **Is a Gantt chart a project plan?** No. A Gantt chart shows sequence and duration. A plan also carries scope boundaries, assumptions, dependencies with named owners, acceptance criteria and a change process. Teams that treat the chart as the plan tend to have detailed schedules built on decisions nobody ever explicitly made, which is why the chart survives contact with reality for about two weeks. Planning mistakes are rarely mistakes of effort. They are the residue of conversations that felt too awkward or too slow to have while the plan was still cheap to change. Have the awkward ones early, write down what they concluded, and agree in advance what will make you rewrite it. ### How to Break Down an Epic Into User Stories https://projan.ai/blog/how-to-break-an-epic-into-user-stories-sizing-rules-examples-and-limits/ Published: 2026-08-21 Break an epic down by slicing it vertically: every story should deliver something a person can do end to end, however narrow that thing is. Split by workflow step, user role, business rule, or happy path versus edge case. Never by layer. Most epics settle at three to ten stories. This is for product managers, business analysts and tech leads who keep producing stories that cannot be demonstrated, or epics that stay open for two quarters. It covers the splitting patterns worth knowing, a worked example, how big a story should be, and the point where splitting stops helping. ## How do you break down an epic into stories? Start from the outcome and cut the thinnest slice that still reaches the user, then split what remains. The order matters, because teams that begin with a list of tasks end up with a list of tasks. 1. **Write the epic's outcome in one sentence, and name who gets it.** If you cannot say who is better off, you have a project, not an epic. 2. **List the steps that person takes to reach the outcome.** This is usually the first and best split, and it takes ten minutes. 3. **Cut the first slice end to end.** One user, one path, no options, behind a flag if needed. This slice exists to test whether the shape of the epic is right. 4. **Split the remainder using the patterns below.** Work through the list rather than inventing splits from scratch, because the patterns catch slices you will otherwise miss. 5. **Check each slice against INVEST.** Bill Wake's acronym (Independent, Negotiable, Valuable, Estimable, Small, Testable) is thirty years old and still the fastest filter. Independent and testable are where most splits fail. 6. **Write acceptance criteria for the first two or three only.** Detail on story eight is waste, because story three will change your mind about it. [Acceptance criteria formats and how they differ from a definition of ready](/blog/acceptance-criteria-formats-types-and-how-they-differ-from-definition-of-ready) covers the shapes that survive review. 7. **Record what you decided not to build.** Rejected slices are the cheapest scope protection you will ever write down. Splitting is a conversation, and it goes wrong when one person does it alone the night before refinement. Teams that keep landing there sometimes give the conversation a structure: Projan takes the split as a Slack discussion, asking which slice a user could use on its own and what done looks like for each, then writes the agreed stories out to Jira or Linear. What matters is that the engineer who will hit the integration problem is in the room while the slices are being drawn. ## Which splitting patterns actually work? Use a known pattern list rather than improvising, because the same handful of splits covers most epics. Richard Lawrence's story splitting patterns and Mike Cohn's SPIDR (Spikes, Paths, Interfaces, Data, Rules) are the two sets most teams work from, and they overlap heavily. | Pattern | Split by | Example slice | |---|---|---| | Workflow steps | Stages in the user's journey | Submit a request, then approve one, then report on them | | User roles | Who is doing it | Customer first, support agent later, finance last | | Business rules | Conditions the system applies | Standard items now, restricted and hazardous items next | | Happy path and edge cases | Success first, failure handling after | Card payment succeeds, then declines and retries | | Data variations | Types, formats, volumes | One currency now, multi-currency later | | Operations | Create, read, update, delete | View existing records before editing them | | Interface or platform | Where it is used | Web first, mobile after, API for partners last | | Spike | Unknowns | Timeboxed investigation of the address lookup provider | The pattern that gets misused is the layer split: one story for the database, one for the API, one for the front end. Splitting by layer is not splitting. It is scheduling the same story three times, and it produces a sprint where everything is in progress and nothing is finished. The test is simple. If a slice cannot be shown to somebody outside the team, it is a task inside a story, not a story. The boundary between the two is worth getting straight, and [epic vs user story vs task](/blog/epic-vs-user-story-vs-task-how-to-break-work-down-without-losing-the-thread) sets it out properly. ## What is an example of an epic story? Here is an epic and its children, split by workflow step and then by role. The epic: **customers can return an online order without contacting support.** - **See what is returnable.** As a customer, I can see which items on a past order are eligible for return and why the others are not. Read-only, no return can be started yet. This slice proves the eligibility rules are right before anything depends on them. - **Request one return.** As a customer, I can request a return for a single eligible item and receive a confirmation email. One item, standard reason codes, no label. - **Get a label.** As a customer, I can download a returns label from the confirmation screen. - **Handle the awkward cases.** As a customer, I am told clearly when an item is outside the return window, and offered the support contact route instead. - **Support can intervene.** As a support agent, I can view and cancel an in-flight return request so a customer who changes their mind does not have to wait for it to expire. - **Multiple items at once.** As a customer, I can return several items from one order in a single request. Six stories, each demonstrable, each shippable in some order. Note what is absent: there is no "build the returns service" story and no "design the returns screens" story. Both would be real work and neither would be a story, because neither can be released or judged on its own. Note also the sequencing logic. The first slice is the one that answers the riskiest question, which here is whether the eligibility rules match what the returns policy actually says. Epics rarely fail because they were too big. They fail because nobody agreed what the first slice was, so three people started three different halves. ## How big should a user story be? A story should be finishable by the team inside one sprint with room left over, which in practice means a few days of work rather than most of a fortnight. Anything that consumes half a two-week sprint on its own is a risk, because it leaves no space for the thing you discover on day four. Practical ceilings teams use, none of them canonical: - **Sprint fit is the hard rule.** If it cannot finish inside a sprint, it has to be split. This is the only sizing rule that is genuinely universal. - **Estimate ceilings are common.** Plenty of teams cap stories at eight points on a modified Fibonacci scale and split anything larger by default. The number is arbitrary; the habit of splitting on a trigger is not. - **Three to five days of one pair's work is a comfortable upper limit** for most teams doing continuous delivery. - **Count the people, not just the hours.** A story that needs three specialists in sequence is too big even when the total effort is small, because the handoffs are where it will sit idle. The lower bound gets less attention and causes as much trouble. A story that can only be demonstrated by opening a database client is not a story. Stories smaller than a day tend to be tasks that were promoted to make a board look busy, and they add ceremony without adding clarity. Getting the wording right at either size is its own skill, covered in [user stories, use cases and tickets](/blog/user-stories-use-cases-and-tickets-how-to-write-work-engineers-can-act-on). Size is also relative to the team. A story that is two days for a team that owns the whole stack is two weeks for a team that has to raise a ticket with a platform group. Split for the team that will actually pick it up. ## How many stories should an epic have? There is no canonical number, and any source giving you one has made it up. The useful range in practice is three to ten, for reasons that are about attention rather than arithmetic. - **Fewer than three stories** and the epic is doing no work. Either it is a story with subtasks, or the split is horizontal and the pieces are not independently releasable. - **Three to ten** is where an epic stays comprehensible. Everyone can hold the shape of it in their head, and it can plausibly finish within a quarter. - **More than about fifteen** and you have a theme or an initiative. Break it into several epics with distinct outcomes, otherwise progress becomes unreadable and the epic burns down at a rate nobody can interpret. Watch out for the epic that grows during delivery. New stories arriving mid-flight are normal; new stories arriving that do not serve the original outcome statement are how a six-week epic becomes a permanent fixture. Check every addition against the outcome sentence. If it does not serve that sentence, it belongs somewhere else, even when it is genuinely worth doing. ## How do you convert an epic to a story? Change the issue type, but only after you have established that it really is a story. The question comes up in two different situations and they need different answers. The first is the tracker mechanic. In Jira, Linear and most other tools you change an issue's type in place, through the issue type field or a move action depending on your version. The catch is hierarchy: a story cannot parent other stories, so you must reparent or delete the children first, and you will usually lose the epic-level fields such as colour and epic name. Do it in that order and the conversion is clean. Do it in the other order and you will spend an afternoon hunting orphaned tickets. If you are rearranging hierarchy often, [how to structure a Jira backlog](/blog/how-to-structure-a-jira-backlog-hierarchy-views-and-ways-to-organize-it) is worth reading first. The second situation is the judgement call, and it is the one that matters. An epic should become a story when it turns out to describe a single releasable change: one user, one path, finishable in a sprint. This happens more than teams admit, usually because the work was sized during roadmap planning when it looked frightening, and refinement revealed it was a fortnight of work behind a flag. Demote it without ceremony. Carrying a one-story epic clutters the board and inflates every report that counts epics. ## When splitting has gone too far Stop splitting when the coordination costs more than the work. Slicing is a tool for reducing risk and getting feedback earlier, not a scoring system, and past a certain point it inverts. Signs you have overshot: - Stories that cannot be released individually, so they are all held for a big-bang deploy anyway - A dependency chain where story four cannot start until stories one to three are all done, which means you have written one story in four tickets - Refinement sessions spent debating ticket boundaries rather than the behaviour the user gets - Acceptance criteria that describe internal state because there is no observable outcome left to describe - Splits made to fit a points target rather than to reduce uncertainty The honest check is to ask what you would learn from shipping each slice alone. If the answer for three consecutive stories is "nothing, they only make sense together", merge them and accept the larger story. A single story that takes eight days and teaches you something beats four two-day stories that teach you nothing until the last one lands. Refinement is where this gets caught, so raise it there rather than in sprint planning, when the tickets already exist and nobody wants to touch them. ## Frequently asked questions **How to break down epics into stories?** Do it with the team, in refinement, on the two or three epics closest to the top of the backlog. One person splitting alone produces slices that look tidy and hide the integration work. Timebox it to about half an hour per epic, take the first three slices to acceptance criteria, and leave the rest as titles until they get closer. **Can an epic have multiple user stories?** Yes. That is what an epic is for. An epic is a container for stories that share an outcome, and one with a single child is not doing any work. The reverse is not true in most trackers: a story sits under one epic only, so shared work either belongs to one of them or becomes its own story. **How small should a user story be?** Small enough to finish inside a sprint with room to spare, and large enough to demonstrate. The lower bound matters more than teams think. If the only way to show the result is to open a database client or read a log, you have written a task, and it belongs inside a story rather than beside it in the backlog. **Do all stories under an epic have to be user-facing?** No, but most should be. Technical enablers are legitimate stories when they carry real risk or effort, such as a migration that must land before any feature work. Write them with the same clarity about what changes and how you will know it worked. If half your epic is enablers, you have a technical project that has been given a product name. **What do you do with an epic that never finishes?** Close it and re-form what is left. An epic that has been open for two quarters has usually absorbed unrelated work, so its remaining stories no longer share an outcome. Ship what is done, move genuinely valuable leftovers into a new epic with a fresh outcome statement, and delete the rest rather than carrying it. Slice vertically, cut the riskiest question first, and let the size of a story be decided by what the team can finish and show rather than by the tidiness of the board. Every other rule here is a rule of thumb you should be willing to break once you can say why. ### How to Turn a Business Idea Into an Action Plan https://projan.ai/blog/from-idea-to-action-plan-how-to-turn-a-business-idea-into-real-steps/ Published: 2026-08-19 Turn an idea into an action plan by writing down what has to be true for it to work, running the cheapest test that could prove one of those things false, then converting whatever survives into dated tasks with a named owner. Decide before you start what result would make you stop. This is written for someone running a small business, or about to, with one idea and a limited amount of money to risk on it. The order below matters more than the format. Most plans that came to nothing were tidy, complete and never tested. ## How to put a business idea into action Put a business idea into action by finding the cheapest thing you could do this week that would prove the idea wrong. Not the thing that would prove it right. Almost anything proves an idea right if you squint. Start by writing the sentences that have to be true for the business to work. A mobile dog grooming round needs roughly three: enough owners within a twenty minute drive, a willingness to pay more than the high street salon charges, and a van that costs less to run than the margin on four appointments a day. Each sentence can be checked separately. Rank them by how badly you would be hurt if one turned out to be false, and test the worst one first. Most people test the easiest one first, which is why so much validation produces encouraging results and no information. | Cheap test | What it takes | What a bad result tells you | |---|---|---| | Twenty conversations with people who fit your buyer description | A fortnight of evenings | Nobody describes the problem the way you do, so your pitch answers a question they are not asking | | A one-page site and a small ad budget | An afternoon, plus whatever you decide to spend | The promise is not interesting enough to earn a click, learned before you build anything | | Pre-orders or refundable deposits | A payment link and a firm delivery date | People approve of the idea and will not fund it | | Delivering the service by hand for three customers | Two or three weeks of unpaid labour | The work costs more to deliver than the price supports | | One stall, pop-up or event | A day and a pitch fee | Nobody stops, and passing trade will not carry the business | None of these are market research. They are attempts at failure, run in the order that would hurt most. A test you cannot fail is a hobby. ## Decide what would make you stop before you spend anything Write down the result that would make you drop the idea, and write it before the first pound goes out. A stopping rule is a sentence with a number and a date in it: if I have not taken five paid bookings by 30 September, I stop advertising and rethink the offer. Two more numbers belong beside it. The total amount of money you are willing to lose, and the date you will look at the evidence properly. Both are far easier to set now than in October, after four months of telling friends about it. Small businesses rarely close a bad idea. They let it go quiet. Nobody cancels it, it simply stops being mentioned, while the money keeps trickling out on hosting, stock and a stall every third Saturday. A plan with no stopping rule is not a plan, it is a standing order. Stopping need not mean abandoning. Most useful stopping rules trigger a change rather than an exit: different price, different customer, different channel. The point of writing one in advance is that the decision gets made by the person you are today rather than the person who has already spent the money, which is [one of the more expensive planning mistakes small businesses make](/blog/common-business-planning-mistakes-small-businesses-make-and-how-to-avoid-them). ## How to turn an idea into an action plan, step by step Write the plan by fixing an end result with a date on it, working backwards to milestones, then breaking only the nearest milestone into tasks. Planning a whole year at task level is how you produce a document that is wrong within a fortnight. 1. **Write the goal as a result, not an activity.** "Fifteen paying customers by 31 March" can be checked. "Grow the business" cannot. 2. **Set three to five milestones between now and then.** Each is a state the business will be in, such as "priced and able to take payment" or "first ten customers served". 3. **Break the nearest milestone into tasks you could start cold.** If a task needs its own plan, it is a milestone that has been mislabelled. The first task on a real action plan is usually small enough to be faintly embarrassing. 4. **Give every line one name.** Two owners means no owner. Where you have staff or a co-founder, [agree who is involved in the planning and what they decide](/blog/who-should-be-involved-in-business-planning-and-when-to-hire-help) out loud rather than assuming it. 5. **Put a date on every line, not just an order.** Sequence tells you what is next. Dates tell you when you are behind. 6. **Write what finished looks like for each milestone.** One sentence, checkable by somebody other than you. 7. **Book the review before you need it.** A recurring half hour in the calendar, with the plan open in front of you. The administrative work belongs on the same list as dated lines, not in a separate mental category. Choosing between sole trader and limited company changes your tax, your liability and your record-keeping, and [GOV.UK sets out the differences](https://www.gov.uk/set-up-business) clearly enough to decide from. Registration, insurance and a business bank account all have lead times, and they are the tasks most likely to be discovered late. Keep the whole thing to one page. An eight-page action plan for a three-person business was written to feel productive. If you also need the version a lender will read, that is a separate document, and there is [a faster way to write a simple business plan](/blog/how-to-write-a-simple-business-plan-fast-without-cutting-corners). ## How to turn plans into action Plans turn into action when every line has one name, one date, and a first step small enough to start without preparation. Writing the plan is the easy half. The stall happens afterwards, for reasons that repeat across almost every small business: - The task is secretly a project. "Sort out the website" is not a task and nobody will start it on a Tuesday evening. - Nobody owns it, or everybody does, which produces the same result. - It has no space in the week. Work that is not in the calendar competes with paying customers and loses. - Nothing follows a slip, so slipping is free. Run a twenty minute review on the same day each week. Three questions: what moved, what did not move and why, and the one thing that must happen before next week. Write the answers down. The value sits in the second question, which is where you discover that the plan quietly assumed a supplier who takes three weeks to reply. Where the idea has been growing in a long chat thread rather than a notebook, Projan can pull that thread into a planning session, press each loose suggestion for a date and a first step, and write the survivors out as tasks in Trello or Todoist. What matters is not the tool but the forcing: loose intentions need somebody to attach a date to them, every week, out loud. ## How to plan a product launch as a small business Plan a small business launch backwards from the day you will take money, not forwards from today. Choose the launch date first, then work out what has to be true by then. A launch run by three people is not a scaled-down corporate launch. There is no launch team, so every date on the plan competes with serving the customers you already have. Assume one significant launch task per week outside normal trading, and build the schedule from that number rather than from optimism. | When | What must be true | How you know | |---|---|---| | 8 weeks out | Price set, and someone unrelated to you has agreed it is worth paying | Three people have said the number out loud without wincing | | 6 weeks out | You can take payment and fulfil an order end to end | You have sold one to a friendly customer at full price | | 4 weeks out | Stock, capacity or availability confirmed for the first month | Supplier order placed, or diary blocked out | | 2 weeks out | Launch messages written and scheduled | Drafts exist, rather than intentions | | Launch week | One channel doing the work, one person answering enquiries | Enquiries answered within a day | | 2 weeks after | Numbers checked against the stopping rule | The review is already in the calendar | Resist launching on four channels because an article told you to. Small business launches usually work on one channel with a real audience behind it, and the other three are a way to feel busy on the day. For the fuller version of this, including sequencing and the post-launch review, see [what a complete product launch plan and checklist includes](/blog/product-launch-plan-and-checklist-what-to-include-step-by-step). The launch is also the first honest test of your capacity estimate. If launch week took three times the hours you expected, that number is worth more than the sales figures, because everything you plan afterwards depends on it. ## Frequently asked questions **How do you convert ideas into action when you have several at once?** Rank them by how quickly you could be proved wrong, not by how exciting they are. Pick the one you could test soonest and give it a fixed window of six or eight weeks. Write the others on a list and refuse to touch them until the window closes. Running two ideas at half attention usually kills both slowly. **What is the difference between a business plan and an action plan?** A business plan explains the business to someone else, usually a lender or an investor, and covers market, model and forecasts. An action plan is for you, and it covers the next few months: tasks, owners, dates and milestones. You can run a small business on an action plan alone. You cannot usually borrow money on one. **Should an action plan live in a spreadsheet or an app?** Whichever one you will actually open on a Monday morning. A spreadsheet is fine for a plan with fewer than fifty lines and one or two people. Move to a shared board when more than two people need to see who is doing what, or when tasks start being handed between people. The tool is not the failure point. **What should you do when a milestone slips?** Move the date and record why, in the plan, in one line. Do not quietly re-scope the milestone so that it still counts as done. Three recorded slips with the same cause, usually a supplier or your own available hours, tell you something the plan needs to change to accept. Silent slippage tells you nothing at all. **How far ahead should a small business action plan go?** Three months in task-level detail and twelve months in milestones is enough for most small businesses. Beyond that you are guessing about your own capacity, which changes every time you take on a customer or lose a supplier. Re-plan the detail every quarter rather than maintaining an unrealistic year of tasks. The distance between an idea and a business is rarely a missing plan. It is the absence of a test that could have failed and a date on which somebody said so out loud. Write the stopping rule first, then the tasks underneath it. ### Should You Use AI to Write User Stories? https://projan.ai/blog/should-you-use-ai-to-write-user-stories/ Published: 2026-08-19 Use AI to write user stories for the mechanical part of the job and not for the judgement. A model produces the As a, I want, so that shape competently, and that shape was never the hard bit. Deciding which user, which problem and why now comes from conversations the model has not had. This is for product managers, business analysts and tech leads already running a model over the backlog, or being asked why they are not. It covers what AI does well here, how generated stories go wrong, and where the line sits. ## Can AI write user stories? Yes, easily. Give a model a feature name and it returns a dozen stories in correct form, each with a role, a want and a rationale, most of them grammatical and several of them plausible. The template is a fill-in-the-blanks exercise, and filling in blanks is exactly what these systems are built to do. It is worth conceding that plainly, because the objection to AI-written stories is not that the output looks wrong. It looks good. A story earns its place when someone can say which user asked for this, what breaks if it is never built, and how you will know afterwards that it worked. The rest is a formatting convention for work an engineer has to act on. So the capability question is settled and uninteresting. The question that matters is what happens to the parts of a story that were supposed to come from outside the room. ## What AI is genuinely good at in a backlog AI earns its keep on the parts of story writing that are transcription, restructuring or completeness checking. Specifically: 1. **Reformatting notes you already have.** A page of discovery notes, a recorded decision and a half-written ticket go in; consistent story shape comes out. Nothing is invented because everything was already there. 2. **Splitting a story that is plainly too big.** Ask for splits by workflow step, user type or rule variation and you get a reasonable set to choose from. Sizing rules still decide which of those splits is real. 3. **A first pass at acceptance criteria you then argue with.** The draft is rarely right. It is much faster to attack a wrong list than to face an empty one. Which criteria format you are arguing in matters here. 4. **Catching structural gaps.** Stories missing an actor, missing a value clause, or written as a solution with no user in them at all. This is proofreading, and models proofread well. 5. **Producing the boring variants.** Error states, empty states, permission cases, expiry, what happens on a second submission. Humans skip these on a Friday afternoon. The model does not get tired. The pattern underneath all five is the same. AI is useful where you already know the answer and want it written down consistently. It is dangerous where you do not know the answer, because it will supply one anyway and the supplied answer will read exactly like the real ones. ## Where AI-written stories reliably fail They fail by being confidently specific about things nobody checked. The failures are not random noise, they cluster: **Invented users.** A generated backlog will happily address the compliance officer, the power user and the first-time visitor. If nobody researched those people, you now have stories written for personas that exist only in the prompt's echo. **Acceptance criteria that restate rather than constrain.** "Given the user is logged in, when they click save, then the record is saved" tells a developer nothing they did not already assume. Real criteria pin down the case that would otherwise be argued about in code review. **Plausible edge cases from someone else's domain.** Models are good at the edge cases of a generic system. Yours has a rule about part-refunds on annual plans that appears in no training data anywhere, and the generated list will not include it while confidently including six that do not apply. **Volume that defeats refinement.** A person can write eight stories in a morning. A model can write eighty. Nobody refines eighty stories properly, so the batch gets skimmed and waved through, and refinement quietly stops being a review. If your sessions have started ending early with everything approved, that is the symptom. **The accountability gap.** The most damaging one. Ask why a story is in the sprint and the honest answer becomes a shrug. A backlog nobody can defend line by line is worse than a thin one, because a thin backlog visibly prompts the conversation that fills it, while a full one closes the conversation down. ## AI PRD generator vs writing it yourself Neither pure option is right, and the trade is between speed of first draft and where the context comes from. The comparison is the same whether the artefact is a story, an epic or a full requirements document that has to survive review. | | AI generator | Writing it yourself | |---|---|---| | **Time to first draft** | Minutes | Hours, spread across a week of conversations | | **Where the context comes from** | Your prompt, plus the model's priors | The people who hold the answers | | **Typical failure** | Confident detail nobody verified | Nothing written down until it is too late to change | | **Review burden** | High, and easy to skip because the draft looks finished | Lower, because the arguing happened during drafting | | **Fits** | Reformatting, splitting, variants, gap-checking | Anything that encodes a decision | The right-hand column is not nostalgia. Its advantage is that the slowness is doing work: you cannot write "as a returning customer" by hand without briefly wondering whether returning customers actually behave that way, and that pause is the entire value of the exercise. The third shape is a tool that will not draft until it has asked. Projan works that way: the questions go to the team in Slack or Microsoft Teams first, pressing on which user a story serves and what would make a reviewer reject it, and the stories are written from those answers rather than from the prompt, then exported to Jira or Linear. It still knows nothing about your users; the difference is that the gap gets filled by a person answering a question instead of by the model guessing. ## Is it okay to write stories with AI? Yes, as long as a named person owns each story and can defend it without mentioning the model. That is the whole test, and it is stricter than it sounds, because it rules out generating a sprint's worth of work and adopting whichever ones nobody objected to. Two practical norms are worth agreeing before anyone asks: - **Ownership does not transfer.** Whoever puts the story on the board answers for it in refinement, in review and in the retro when it turns out to have solved a problem nobody had. - **Say where a claim came from, not who typed it.** Nobody needs a disclosure banner on the ticket. They do need to know whether "users expect an email confirmation" came from a support ticket or from the model's general sense of how software behaves. That distinction decides whether the claim can be challenged. Teams get twitchy about this for reasons that are half professional and half territorial. The professional half is legitimate. Story writing is one of the few points where a product person is forced to demonstrate that they understand the users, and handing that to a generator removes the evidence along with the effort. ## Should you use AI to write user stories? Use it when the answer already exists somewhere and needs shaping. Do not use it when the answer does not exist yet, because the model will produce something in the shape of an answer and you will not notice the substitution. Use AI on a story when: - The source material exists in notes, tickets, transcripts or a recorded decision - The task is structural: splitting, reformatting, checking for missing actors or value clauses - You are generating variants of a case you have already thought through - Someone specific will read every line before it reaches the board Write it yourself, or rather write it with other people, when: - You cannot name the user without guessing - The story encodes a scope decision or a trade-off between teams - The acceptance criteria will settle an argument that has not happened yet - The feature touches a domain rule that lives only in someone's head The tell that you have crossed the line is easy to spot once you look for it. If you cannot say which sentence in the prompt produced a given detail in the output, that detail was invented, and you are about to build it. ## Frequently asked questions **How do you prompt AI for a user story that is not generic?** Give it the raw material rather than the topic. Paste the interview notes, the support ticket, the constraint an engineer raised, and the acceptance criteria pattern your team already uses. A prompt that names a feature gets you a plausible average of every similar feature on the internet. A prompt carrying your specifics gets you your specifics, tidied. **Can AI write acceptance criteria as well as the story?** It can draft them, and the first pass is usually too soft. Generated criteria tend to restate the story in Given, When, Then clothing rather than constrain it. Treat them as a list to argue with: for each one, ask what a developer could ship that satisfies the wording and still fails the intent. **Can AI split an epic into smaller user stories?** Yes, and this is one of its better uses, because splitting is mostly a pattern-matching job. Ask for splits by workflow step, by user type, by rule variation and by happy path versus error path, then throw out the ones that do not deliver value alone. The judgement left to you is which slice ships first. **How many AI-drafted stories should you take into refinement at once?** As many as the team can genuinely read, which is far fewer than a model can produce. Sixty generated stories on a board do not get refined, they get skimmed and approved. Cut the batch to what fits the session you have booked, and delete the rest rather than leaving them to rot in the backlog. The format of a user story is the cheapest part of it and the only part AI reliably improves. Spend the time it gives back on the argument about which user you are actually serving. A backlog that looks finished is not the same thing as a backlog anyone in the room agrees with. ### How to Use AI to Write a PRD (and Requirements That Hold Up in Review) https://projan.ai/blog/how-to-use-ai-to-write-a-prd-and-requirements-that-hold-up-in-review/ Published: 2026-08-17 Use AI to create a PRD by giving it the raw material you already have, the ticket, the research notes, the transcript, then asking it to list the decisions nobody has made yet. Get those answered by the people who own them. Draft afterwards. AI is fast at structure and confident about things your team has not decided. This is for product managers who are going to use ChatGPT, Claude or whatever sits in their doc tool for this anyway, and would rather the output survive a review with engineering in the room. It covers the workflow, what the models reliably get wrong, how to handle requirements specifically, and what "PRD for AI" actually means. ## What AI gets wrong when it writes a PRD Three failures show up in almost every AI-drafted PRD, and none of them look like errors on the page. The first is confident prose over undecided questions. The model has no way of knowing which parts of your input were decisions and which were placeholders, so it writes them all in the same voice. A sentence you agonised over in a design review and a sentence the model produced to fill a heading are typographically identical. The second is invented acceptance criteria. These are the most dangerous output because they are plausible. Ask for acceptance criteria on an export feature and you will get a clean Given/When/Then for the happy path, which is the one case nobody was ever going to get wrong. The third is that nobody argued about it. A PRD is not a writing task with a research problem attached. It is a decision record with a writing task attached, and a document produced in ten seconds from one person's prompt has recorded exactly one person's assumptions. It reads finished, so it gets approved rather than interrogated. | What the draft says | What is actually happening | |---|---| | "Users can export their data as CSV or PDF." | A scope decision has been made by a model, not by you | | "Success metric: 20% lift in weekly active users." | A target has been fabricated because the heading needed filling | | "Out of scope: mobile." | An exclusion has been guessed at, and it will be disputed | | "Given a logged-in user, when they click Export, then a file downloads." | The happy path is being presented as the acceptance criteria | None of that is an argument against using AI here. It is an argument for using it in the right order. ## How to use AI to create a PRD Work in this order and the model spends its time on structure and stress-testing rather than on inventing product decisions. 1. **Gather the context first.** The ticket, the customer conversation, the analytics question, the last PRD for an adjacent feature, the support threads. Paste it all in. A model with no context does not tell you it lacks context. It writes around the hole. 2. **Ask for the questions, not the draft.** Your first prompt should be some version of: read this and list every decision that has not been made, plus who would have to make it. Do not let it answer them. This one instruction removes most of the fabrication risk. 3. **Take the open list to the people who own it.** Usually five to fifteen questions, most answerable in a thread. The ones that need a call are the ones that would have surfaced in review anyway, three weeks later. 4. **Draft with your own headings.** Paste in the actual PRD template your team uses rather than accepting whatever structure the model prefers. If you do not have one, the [structure, best practices and mistakes guide to writing a PRD](/blog/how-to-write-a-prd-structure-best-practices-and-mistakes-to-avoid) covers what the sections are for. 5. **Mark every sentence you did not verify.** Bold, highlight, whatever you like. Anything still unmarked at the end is a guess going out with your name on it. 6. **Turn the model on the draft.** Prompt it as the engineer who has to build this, and ask what is ambiguous enough that two developers could implement it differently. It is much better at finding gaps in text than at filling them. 7. **Cut.** AI drafts run long because length is cheap for them and reads like effort. Delete anything you would not defend out loud. The step people skip is the second one, because it feels like a delay when a full draft is one prompt away. Review comments are the most expensive place to discover that nobody agreed the scope. ## How do you use AI to write requirements? Use it to expand and pressure-test requirements you have already decided, never to originate them. The distinction matters more at requirement level than anywhere else in the document, because a requirement is the sentence an engineer implements literally. AI is genuinely good at four things here: normalising phrasing across a list, generating candidate edge cases for you to accept or reject, spotting requirements that contradict each other, and converting between formats when your team wants Given/When/Then instead of prose. On [acceptance criteria formats and how they differ from a definition of ready](/blog/acceptance-criteria-formats-types-and-how-they-differ-from-definition-of-ready), it will follow whichever convention you show it. It is bad at everything involving a number. Timeouts, retry counts, page sizes, permission levels, retention periods, rate limits. It will supply all of them and they will look reasonable. A pass that works, once you have a draft list: 1. Ask it to extract every requirement into a flat numbered list, stripped of narrative. Seeing them separated from the prose is usually the first shock. 2. Ask which of them can be tested. Anything that cannot be tested gets rewritten or deleted, and "the interface should be intuitive" gets deleted. 3. Ask for the contradictions between them. This is the strongest use of the whole exercise and takes about a minute. 4. Ask for the negative cases it thinks are missing, then decide each one yourself. Half will be irrelevant. The other half are the ones that would have become bugs. 5. Put the numbers back in by hand. Every threshold in the document should be one you can trace to a person or a measurement. ## What is the "PRD method in AI"? There is no established method by that name, and any article presenting one as standard practice has made it up. The phrase turns up in search because two separate ideas have collided. The first is using AI to produce the PRD, which is what most people mean and what the workflow above describes. The second is treating a written spec as the primary artefact that AI coding tools then work from, which does have a name and a growing set of practices around it. That is covered in [what spec-driven development is and whether it actually works](/blog/what-is-spec-driven-development-and-does-it-actually-work). Worth saying plainly: neither is a methodology in the sense that Scrum is. They are working habits, and treating them as a formal framework is how teams end up with ceremony instead of a decision. ## How to write a good PRD for an AI feature Specify the behaviour band and the failure handling, not the output. This is where PRDs for AI features break, because the usual approach of writing exact expected results does not survive contact with a probabilistic system. Five things an AI feature PRD needs that a normal one does not: - **What good enough looks like**, expressed as a rate or a band rather than a single correct answer. "Correctly extracts the invoice total on at least 95 of the 100 documents in the evaluation set" is a requirement. "Extracts invoice totals accurately" is a wish. - **An evaluation set that exists.** Name it, say who assembled it, say where it lives. A PRD that assumes someone will produce one later has deferred the hardest task in the project. - **What wrong looks like, and what happens then.** Silent failure, visible failure, human review queue, refusal. Pick one per failure type. - **The fallback when the model is unavailable or too slow.** It will be both at some point. - **Data handling.** What goes to the provider, what is retained, what the customer has been told. If the PRD's real audience is a coding agent rather than a person, the constraints are different again and the phrasing gets stricter. That is a separate craft, covered in [how to write requirements an AI coding agent can actually follow](/blog/how-to-write-requirements-an-ai-coding-agent-can-actually-follow). ## Which AI tool is best for writing PRDs? No single tool wins, and the useful question is not which one writes the best prose. It is which one can see what your team already knows. | Category | What it is good at | Where it falls down | |---|---|---| | General assistants (ChatGPT, Claude, Gemini) | Drafting, restructuring, edge-case lists, playing the sceptical reviewer | Knows only what you paste, and will not tell you what is missing | | AI inside your doc tool (Notion, Confluence, Google Docs) | Drafting in place, summarising a comment thread, keeping format | Fluent about whether anything was actually decided | | Coding agents and IDE tools | Turning an agreed spec into tickets or scaffolding | Will build the invented requirement as cheerfully as the real one | | Planning tools that run the conversation | Getting the open questions answered before a draft exists | Still needs the people who own the answers to show up | That last category is small and worth knowing about. Projan is one example: it works in Slack, Microsoft Teams or its own workspace, pulls in an existing ticket or document so the session does not start from a blank page, and puts the questions a PRD has to answer to the team rather than to one person. The answers become the document, and the tasks go out to Jira, Linear or Notion. For most teams the honest answer is a general assistant plus discipline. The discipline is the part that transfers between tools. ## Frequently asked questions **Which AI is best for PRD?** Test it rather than trust a ranking. Take a PRD you already shipped, strip the decisions out of it, and ask each model to reconstruct it from the same context you had at the time. The one that asks you questions instead of confidently filling the gaps is the one to keep. Model quality moves faster than any recommendation stays accurate. **Can AI draft a PRD from a meeting transcript?** Yes, and it is one of the better uses, because a transcript contains decisions people actually made rather than guesses. Ask for a decision list first, with the person who made each call, then check that list against your memory of the room. Anything the transcript does not support is still invented, whatever the model says about it. **Should you tell reviewers a PRD was drafted with AI?** Tell them what you verified, which is more useful than a disclosure. Reviewers do not need a label. They need to know which sections are settled and which are proposals waiting on an answer, so mark those two states in the document. A PRD where every sentence reads as decided gets skimmed, whatever produced it. **Does an AI-drafted PRD need a different review?** It needs one extra pass before the normal one. Go through the draft and separate what you supplied from what the model supplied, because reviewers cannot tell the difference and will assume all of it came from you. Numbers, thresholds and exclusions are where invented content hides. After that pass, review it like any other PRD. AI removes the blank page and the formatting work, which was never the hard part of a PRD. The hard part is getting four people to agree what is in scope, and no model can do that on your behalf. Use it to find the questions, answer them with humans, and let the document be the record of what you settled. ### Running a Client Kick-Off Meeting That Actually Sets Expectations https://projan.ai/blog/running-a-client-kick-off-meeting-that-actually-sets-expectations/ Published: 2026-08-17 A client kick-off meeting is expected to produce agreement, not enthusiasm: what the engagement will deliver and what it will not, who signs off decisions, what access you need and by when, how findings will reach the client, and how often you meet. If none of that is written down afterwards, it was a briefing. This is written for independent consultants and small firms. The generic mechanics of running the session are covered elsewhere. What follows is the consulting-specific part, where you are an outsider on a fixed fee, with no line authority and a client who has already formed a private picture of what you are for. ## What is expected in a kick-off meeting? A kick-off is expected to convert a signed proposal into a working agreement. Six things should be true when people leave the room: - **The problem is stated in one sentence** that the client repeats back without correcting it. - **Deliverables are countable.** Three workshops, one findings report, one prioritised recommendation set with indicative costs. Not "strategic support". - **Exclusions have been said out loud**, not merely printed in the contract. - **One person owns sign-off**, and everyone knows who that is. - **Access has dates against it.** Interviews, systems, documents, the finance extract. - **The cadence is fixed.** Who meets whom, how often, and what gets written down each time. Agenda timings, facilitation and who speaks when work the same way here as on any internal project, and [the general project kick-off guide covers the agenda and facilitation mechanics](/blog/how-to-run-a-project-kick-off-meeting-that-sets-real-alignment). The sections below deal with the five things consulting engagements get wrong: the scope boundary, the unstated expectations, access, decision rights, and what happens to findings nobody wants. ## What the client will get, and what they will not Say both, out loud, in the kick-off. The exclusions in your contract have been read by procurement and possibly by nobody else, and the people sitting in the kick-off are rarely the people who signed. The format that works is a pair of lists on one slide. "By the end of this engagement you will have" on the left, "this engagement will not" on the right. The second list is the one earning its place. Concrete exclusions sound like this: - This engagement will not produce a business case for the replacement platform. - This engagement will not cover the two regional subsidiaries. - This engagement will not include implementation support once recommendations are accepted. Watch faces while you read the right-hand list. Surprise at an exclusion is the gap between what was sold and what was heard, and it is far cheaper to find it in week one than in the final presentation. Clients rarely remember your scope section. They remember the sentence in the room where you said no. If the exclusions are still soft at kick-off, the scoping work was not finished, and [scoping a consulting project properly happens before this meeting](/blog/how-to-scope-a-consulting-project-without-guessing), not during it. ## What are the five common customer expectations? There is no canonical list of five, whatever the search results suggest, and the number moves depending on who is selling the training. Five do recur in consulting engagements, and what they share is that clients hold them firmly and state none of them. 1. **That you already understand their business.** They assume the pitch reading is done and resent being asked basics in week three. Ask the basics in the kick-off instead, framed as confirmation. 2. **That the senior people from the pitch will do the work.** If a junior analyst will run the interviews, say so now, with their name and what they are good at. 3. **That the work will not create work for them.** It will. The access table is where you break that assumption gently. 4. **That you will not embarrass them internally.** Whoever hired you has staked some credibility on it. This is why the route for unwelcome findings matters more than the findings. 5. **That the fee is a ceiling rather than an estimate.** Say plainly whether it is fixed, capped or time and materials, and what triggers a change note. None of these are unreasonable. They only become expensive when they stay unspoken for six weeks. ## What is the role of a customer in the ideal kick-off meeting? The client's role is to supply what only they can supply: the real objective, the political constraints, the decision rights and the access. They are not an audience. A kick-off where the consultant talks for fifty minutes has confirmed nothing except that you can present. Three questions reliably turn a passive client into a participating one: - What would make you regret commissioning this? - Which recommendation would be impossible to act on, whatever the evidence says? - Who has looked at this before, and what happened to their report? The third question is the most useful thing you can ask in the first hour. If a previous review exists and was shelved, you need to know why before you write a word of your own. ## Access is a dependency, and it needs a date Access agreed in principle is not access. A named person, a specific system and a date is access. Bring a table to the kick-off with the last column empty and fill it in live. | What you need | Granted by | Date agreed | What stalls without it | |---|---|---|---| | Interviews with eight operations staff | Operations director | | Findings section, all of it | | Read access to the ticketing system | IT service owner | | Volume analysis and baseline | | Last two years of cost data | Finance business partner | | Any recommendation with a number on it | | Attendance at the monthly ops review | Sponsor | | Understanding how decisions really get made | | The previous consultancy's report | Sponsor | | Avoiding repetition of work already done | Dependencies the client agreed to in a meeting and then missed produce a conversation about their delay. Dependencies you never raised produce a conversation about yours. That is the entire reason the table exists. Include what the access is worth in time. "Two weeks late on the cost data moves the final report by two weeks" is a sentence the sponsor can act on. "We will need finance data at some point" is not. ## Who is the real sponsor, and who can actually decide? The sponsor is whoever can stop the engagement without asking anybody's permission. That is often not the person who briefed you, and almost never the person coordinating your diary. Three roles need separating in the kick-off, and clients routinely blur them: - **The sponsor.** Owns the budget and the consequences. Sees findings first. - **The day-to-day contact.** Arranges access, chases documents, knows where everything is. Cannot approve scope changes, however helpful they are being. - **The decision-maker for the recommendations.** Sometimes the sponsor, sometimes a committee, sometimes a person who has not been mentioned yet. Ask the direct version out loud: if the recommendation is to close the Leeds site, who signs that off? The answer tells you who the report is really written for. Write it down and repeat it back before moving on. Sponsors change. If yours does mid-engagement, treat it as an event rather than an administrative detail and run a twenty-minute version of this meeting with the new one. Inherited engagements are the ones that get cancelled. ## Agree now how unwelcome findings will travel Decide in the kick-off exactly how you will tell the client something they will not enjoy hearing. The failure is rarely that consultants are too blunt. It is that the first time a client hears an uncomfortable finding is in a room containing the person responsible for it. Agree three things: - **The no-surprises rule.** The sponsor sees anything difficult in draft before anyone else does, with enough notice to think rather than react. - **The format.** Findings separated from recommendations, evidence attached, no individual named unless the client asks for that and understands why. - **The route.** Whether a difficult finding goes to the sponsor alone, to the steering group, or into the report only. State clearly that you will not soften a finding to keep the room comfortable, and that you will never present one the sponsor has not seen. Those two commitments together are what makes an uncomfortable report survivable. [Structuring the presentation of findings](/blog/how-to-present-findings-to-a-client-structure-examples-and-summary-docs) is a separate craft, but the permission to deliver them is granted here, in week one, while everyone is still relaxed. ## Do not let the engagement become extra delivery capacity Consulting engagements get quietly reclassified as staff augmentation, and the reclassification starts with requests that are easier to accept than to refuse. Nobody announces it. It arrives as a favour with a deadline attached: could you sit in on the supplier call, could you draft the paper for Thursday's board, could you take the minutes since you are here anyway. Inoculate in the kick-off with an operating principle stated in your own words. "We advise on the target operating model. We do not run the transition programme" takes four seconds and gets referenced for the next three months. Then give extra requests somewhere to go. A change note, priced, approved by the sponsor, is not bureaucracy; it is the only alternative to saying no repeatedly to a client you like. The test that settles most cases in seconds: if you removed the request from the engagement, would any agreed deliverable be weaker? If not, it is not your work, however small it looks. ## What are the 3 C's of engagement? No canonical set of three exists for consulting engagements. The phrase circulates mainly in employee engagement writing, where different authors expand it differently, so quoting it as established doctrine would be inventing authority you do not have. If you want three words to hold a kick-off against, these are the ones worth using, offered as shorthand rather than as a framework anybody teaches: - **Clarity.** Deliverables and exclusions both stated aloud, in language the client uses rather than the language of your proposal. - **Cadence.** A fixed rhythm of contact, so information does not travel only when something has gone wrong. - **Candour.** An agreed route for bad news, established before there is any. The three-letter version is memorable, which is its only real advantage. The underlying commitments are what a client will hold you to. ## How to make an engagement plan? Turn the kick-off outputs into a short engagement plan within two working days, while people still remember agreeing to things. It is a working document, not a contract annex, and it should be readable in five minutes. 1. **Restate the objective** in one sentence, plus the decision the client will make with your output. 2. **List deliverables** with dates and the named person who accepts each one. 3. **Convert the access table** into dated dependencies with a client owner beside each. 4. **Set the cadence and the escalation route.** Weekly update, fortnightly sponsor check-in, and who you call when something is blocked. 5. **Record assumptions**, including the ones the fee depends on. Availability of interviewees is usually the first to break. 6. **Name the change process** and who is authorised to trigger it. 7. **Circulate it and ask for corrections, not approval.** People will correct a document they would never get round to approving. Capture the answers during the meeting rather than reconstructing them from memory afterwards, because reconstruction is where the exclusions quietly soften. One tool for that is Projan, which puts the kick-off questions to the group in Slack or Microsoft Teams, holds the agreed answers against each one, and writes the result out to Confluence or Asana. [Building the plan out into full deliverable definitions](/blog/how-to-write-a-consulting-engagement-plan-and-define-deliverables-that-hold-up) is the next job after this meeting. ## Frequently asked questions **What are the 4 principles of engagement?** There is no agreed set of four for consulting work, and lists claiming otherwise come from unrelated fields. Four things do need settling before delivery starts: who decides, what is out of scope, when access is granted, and how bad news reaches the sponsor. Agree those and the number you call them stops mattering. **What should you send out before a client kick-off?** Send the agenda, the draft deliverables list with the exclusions attached, the access table with blank dates, and the names you want in the room. Sending it two working days ahead gives the client time to notice a missing name. It also means objections arrive by email rather than as a silence you misread as agreement. **How long should a consulting kick-off run?** Ninety minutes covers scope, exclusions, sponsor, access and cadence for most engagements. Half a day is justified when the client team is large or the work spans several business units, and then only if the extra time is spent on their constraints rather than your credentials. Anything under an hour tends to skip the exclusions. **What if the client wants to skip the kick-off?** Treat it as a signal rather than an efficiency. Clients skip kick-offs when they think the answer is already known or when the sponsor does not want to be pinned to a decision. Offer a shorter session, insist the sponsor attends, and send the confirmations in writing afterwards regardless. Silence on that email is worth having on record. **Should the kick-off summary be signed?** A signature is unnecessary for most engagements, but written confirmation from the sponsor is not. Send the summary, ask for corrections by a stated date, and note that you will proceed on that basis. If the engagement is fixed-price or politically exposed, ask for an explicit reply rather than treating silence as agreement. A kick-off that ends in agreement rather than goodwill is worth an hour of anyone's time. Name the exclusions aloud, put dates against access, find the person who can stop the project, and agree how bad news will reach them before there is any. ### How to Plan an API Design and Get It Reviewed https://projan.ai/blog/how-to-plan-an-api-design-and-get-it-reviewed-before-you-ship-it/ Published: 2026-08-14 Plan an API design by naming its consumers and their real use cases first, then modelling the resources, the write behaviour and the error contract, and only then deciding how you will version it. Get the plan reviewed while it is still a draft. Once a client depends on the shape, the shape is a commitment. This is for engineers designing a new HTTP or RPC interface that other teams will call. ## How to plan an API design Work in the order that decisions constrain each other: consumers first, shape second, failure behaviour third, versioning policy last. Doing it the other way round produces a tidy resource model that nobody can build against. 1. **Name the consumers and what each is trying to do.** Not "the mobile app" but the three calls the mobile app makes on its home screen. An endpoint with no named caller is speculative work. 2. **Sketch real requests and responses before schemas.** Write actual JSON for two or three use cases. An abstract resource model survives a meeting unchallenged; a concrete payload gets argued with, which is the point. 3. **Decide identity and collection semantics.** What is a resource and what is a field on one, which identifier clients will store, and how collections filter, sort and paginate. Retrofitting cursor pagination onto an endpoint that returned an unbounded array breaks every caller. 4. **Work out write behaviour.** Idempotency keys for retries, concurrency control for conflicting updates, and whether a partial failure leaves the caller able to tell what happened. 5. **Design the error contract.** Status codes, a stable machine-readable error code, which errors are worth retrying, and what the client should do about each. Reviews that only walk the success path miss most of the integration cost. 6. **Fix the authorisation model, rate limits and quotas.** Who may call this, at what volume, and what a rejected call looks like. 7. **Write the compatibility rules down.** What your team counts as a breaking change, how new fields get added, how long a deprecated field survives, and whether you version by URL, by header or not at all. 8. **List the open questions, each with an owner and a date.** A plan that admits what it has not decided attracts better comments than one that quietly guesses. Steps one and two carry most of the value and are the two most often skipped, because both require talking to people outside the team that owns the service. ## Which parts of the design become permanent Anything a client can observe becomes something a client depends on, including behaviour you never documented and did not mean to promise: field ordering, the exact error string, the fact that a list happens to come back newest first. Hyrum's law is the usual name for this, and it is why the review has to happen before the first integration. Treat all of these as commitments from the moment a caller ships: - Field names, types and nullability - Enum values, and whether clients reject ones they do not recognise - Pagination shape and default page size - Error codes that clients branch on - Ordering, timing and retry behaviour that clients infer, documented or not You are not only choosing an interface. You are choosing which of your current mistakes you will keep supporting for years. That is the argument for a week on the design and a day on the first implementation, and for [recording the alternatives you rejected in an ADR](/blog/how-to-write-an-architecture-decision-record-adr-that-your-team-actually-uses) while the reasoning is fresh. ## Who should review an API design? The teams that will call it, whoever owns the platform's conventions, and security if the endpoint exposes data or actions that need authorisation. Everyone else can read it. A review with nine attendees produces consensus about naming and silence about failure modes. | Reviewer | What only they will catch | Bring them in | |---|---|---| | Consuming teams | Whether the response matches what their screen or job needs, and how many calls a common task takes | At the request and response sketches | | Platform or API owner | Inconsistency with existing endpoints: naming, pagination, error format, auth | Before the schema is written up | | Security | Authorisation gaps, what list responses and error messages leak, missing rate limits | Before the auth model is fixed | | Service on-call | Timeouts, retry storms, behaviour under load, which failures page a human | With the error contract | | Docs or developer experience | Whether the interface can be explained without a page of exceptions | Once the design is stable but unshipped | Reviewing is not voting. One person owns the design and decides; the reviewers exist to raise what the owner cannot see from inside the service. Where the API crosses team boundaries or sets a precedent others will copy, the [RFC process is the right vehicle](/blog/the-engineering-rfc-process-what-it-s-for-when-to-write-one-and-who-decides), because it forces objections into writing before anyone gets attached. ## When to send it for review Send it when you have request and response examples plus a list of open questions, and before you have a finished OpenAPI file. The useful test: if a reviewer's suggestion would irritate you because of how much work the change implies, you sent it too late. Two passes are usually enough. A shape review on the sketches, asynchronous, three working days for comments. Then a contract review on the full spec whose only agenda item is what went unresolved in the first pass. [Running that second pass as a short meeting rather than another comment thread](/blog/running-engineering-review-meetings-design-reviews-project-reviews-and-who-owns) helps when there is real disagreement and wastes everyone's morning when there is not. The hard part is getting consuming teams to answer before the spec exists rather than after it ships. [Projan](/landing/engineering) runs that round in Slack, asking each team which fields they will read and what they will do on a 409, then writing the replies up as a draft and pushing unresolved items to GitHub or Linear as tasks. ## Frequently asked questions **What counts as a breaking change to an API?** Anything that can make a working client stop working: removing or renaming a field, tightening validation, changing a status code, adding a required request parameter, or changing what an existing value means. Adding an optional response field is usually safe, though not for clients that reject unknown fields. Write your own list down, because teams disagree about the edges. **Do internal APIs need a design review?** Yes, and usually a shorter one. The consumers are known and reachable, so it can be a half-hour conversation with the two teams that will call it rather than a public process. The cost of a bad internal API is lower per change and higher in total, because nobody budgets time to fix it. **Who decides when reviewers disagree?** The person accountable for the service decides, once the disagreement has been written down rather than argued in a call. If two teams cannot agree on the contract, escalate to whoever owns both and record what was chosen and what was rejected. Unresolved design disagreements reappear as workarounds in client code. **How do you design an API with no consumers yet?** Design the smallest thing your first known caller needs and ship it as unstable, with the instability stated in the docs. Speculative generality is how APIs acquire fields nobody reads and options nobody sets. If you genuinely cannot name a caller, the honest answer is that the design can wait. API designs fail review for the same reason they fail in production: nobody asked the people who would call the thing what they needed until the shape was fixed. Sketch the payloads early, publish what you have not decided, and treat everything observable as a promise. ### What Makes a Good Jira Ticket? Examples and Anti-Patterns https://projan.ai/blog/what-makes-a-good-jira-ticket-best-practices-examples-and-anti-patterns/ Published: 2026-08-13 A good Jira ticket states what changes in its title, gives enough context for someone who missed the conversation to start work, defines done in checkable terms, and holds one piece of work rather than five. Everything else is optional. Most bad tickets fail on the first and third of those, not on formatting. This is for product managers, tech leads and engineers whose board is full of items nobody can interpret without asking. It covers the fields that carry real information, the title, a weak ticket rewritten, what a bug report needs, the anti-patterns, and how much detail is warranted. ## What makes a good Jira ticket? A good ticket puts a decision in every field it fills in. Jira gives you plenty of fields and most teams treat them as a form. Treat them as questions instead, and these are the ones worth answering. - **Summary.** The one field that appears in every view. It gets its own section below because it is the field most often wasted. - **Issue type.** Less a taxonomy than a switch. Type drives which workflow the item follows, where it sits in the hierarchy and how it appears in reports. Pick the type that gets the work onto the right board, not the one that satisfies a definition. - **Description.** Three things belong here: why this exists, what changes, and what finished looks like. - **Assignee.** One person. A field with a name in it is a commitment; a field with a team in it is a hope. - **Parent or epic link.** Where this sits in the larger piece of work. Without it, the epic is a label rather than a plan. - **Priority.** Only meaningful if the levels behave differently. If every ticket is High, take the field off your screen and stop pretending. - **Issue links.** Blocks, is blocked by, relates to. Teams skip this one, and it is the field that explains why a sprint stalled. - **Labels and attachments.** Add a label only if somebody filters on it. Attach the log line or request ID rather than describing it, because a ticket that describes its evidence makes the assignee go and find it. Which fields exist, which are mandatory and which appear on which screen varies, because Jira screens and workflows are configured per project rather than globally. Atlassian's documentation now calls these items [work items rather than issues](https://support.atlassian.com/jira-software-cloud/docs/what-is-an-issue/), though almost nobody has changed what they say out loud. This article is about the container, not what goes inside the description or how a ticket differs from a user story or a use case. ## How do you write a ticket title someone will recognise six weeks later? Write the title so it names what changes, specifically enough to be identified in a list of forty without opening it. That is the whole test. The title is read hundreds of times and written once, usually in about four seconds, and everyone who scrolls the board pays for that asymmetry. Two habits produce most bad titles. The first names the area rather than the change: "Login", "Payments", "Dashboard". The second names the verb without the object: "Fix bug", "Investigate", "Update". Both read fine to the author on the day, because the author is holding the context the title is supposed to carry. | Weak title | Stronger title | |---|---| | Fix login | Show a lockout message instead of a 500 when the account is locked | | Payments bug | Duplicate refund created when the provider times out and the agent retries | | Update API | Add pagination to GET /orders with a default page size of 50 | | Dashboard improvements | Show the last sync time in the dashboard header | | Tech debt | Remove the second copy of the address validator in checkout | Three rules. Lead with a verb where the ticket is a change and with the symptom where it is a bug. Keep it short enough to survive being clipped in a board or list view, which usually means well under seventy characters. And never lean on the ticket key for meaning, because "PROJ-4471" tells a reader nothing and half the people discussing the work are reading it in Slack, not in Jira. ## What does a good Jira ticket look like? Here is one piece of work written twice, first the way it usually arrives. > **Summary:** Export broken > > **Description:** Customer says the CSV export is wrong. Can we look at this please. Nobody can start that. It does not say which export, which customer, what wrong means, or what would count as fixed. The assignee's first action is to find the author, and if the author is on leave the ticket waits. Now the version that can be picked up: > **Summary:** Orders CSV export omits refunded lines when a date filter is applied > > **Description:** Reported by two enterprise accounts this week (support threads linked). The Orders export includes refunded lines when run unfiltered and drops them when any date range is applied. Finance reconciles from this file, so its totals no longer match the dashboard. > > **Scope:** the Orders export only. The Payouts export has a separate filter path and is not part of this ticket. > > **Done when:** a date-filtered export contains every order created in the range, including refunded and partially refunded ones, and the row count matches the Orders list view for the same filter. > > **Notes:** reproduces on the sandbox account with any range longer than one day. Feature flag `orders_export_v2` is on for that account. > > **Open question:** whether cancelled orders should appear at all. Asked Priya in #finance-ops, answer expected Thursday. Not blocking the fix. The rewrite is longer because six questions were answered in advance rather than asked one at a time over three days. The scope line and the open question are the two parts most often missing, and the two that decide whether anyone other than the author can pick it up. ## What does a bug ticket need that a feature ticket does not? A bug ticket needs reproduction steps, and without them it is a request for someone else to do the diagnosis you skipped. A feature ticket describes work that has not happened. A bug ticket describes an event that already has, and the person who saw it holds evidence nobody else can recover. Six things, in this order: 1. **Steps to reproduce**, numbered, starting from a known state. "Log in as a support agent, open order 10432, apply a date filter of 1 to 31 July, click Export." Not "try exporting". 2. **What happened.** The observed behaviour, quoted exactly if it is an error message. Paraphrased errors send people hunting for strings that do not exist. 3. **What you expected.** Often obvious, occasionally not, and where it is not obvious this line prevents a fix that satisfies nobody. 4. **Environment and build.** Which environment, which version or commit, which browser or client, which account and role. Bugs that only reproduce under one permission are common and invisible without this. 5. **Frequency and scope.** Every time or once. One customer or all of them. Since a specific deploy or always. This is what turns a bug into a priority, or fails to. 6. **Evidence.** Request ID, trace, log excerpt, screenshot, the exact timestamp with a timezone. If it does not reproduce reliably, say so and say what you tried. An intermittent bug written up honestly is useful. The same bug written up as though it were deterministic wastes an afternoon and comes back as "cannot reproduce, closing". Whether severity is recorded separately from priority depends on your configuration. Where both exist, keep the distinction honest: severity is how badly it behaves, priority is when somebody will do something about it. ## Jira ticket anti-patterns, and what each one costs Each of these costs something specific rather than being generally untidy. 1. **The note to self.** One line in the author's private shorthand. Cost: the work cannot be reassigned. It is a personal to-do stored in a shared system, and when that person is busy or gone it becomes dead weight that still shows on the board. 2. **The five-in-one.** Several unrelated changes in one ticket because they came up in the same meeting. Cost: it can never be finished, only partly finished. Progress is unreportable, the review is enormous, and one blocked piece holds the other four hostage. 3. **The epic as a dumping ground.** An epic that started as a feature and now holds anything vaguely adjacent. Cost: it stops predicting anything. Nobody can say how close it is to done, so the answer becomes a guess, and the guess goes into a roadmap. 4. **The decision in comment 14.** The description says one thing and the agreed behaviour sits halfway down a comment thread after two false starts. Cost: whoever reads only the description builds the wrong thing, and they are not being careless. Move the decision up and note that it changed. 5. **The reopener.** Closed and reopened three times because done was never defined, so each party had a different finish line. Cost: cycle time that looks fine per pass and is dreadful overall, plus the slow erosion of anyone's belief that Done means anything. 6. **Assigned to a team.** The ticket sits against a group or a rotating placeholder account. Cost: nobody starts it, because at no point does any individual feel late. Diffused ownership is not fairness, it is a queue with no head. 7. **The eleven-month ticket.** Open since last year, never going to be done, and nobody will close it because closing feels like conceding the problem was real. Cost: every count becomes untrustworthy. A backlog holding a hundred of these is a graveyard with a search function. The last one is the one teams argue about, so be blunt internally. A ticket you would not schedule this quarter or next is not a plan, it is a wish. Close it. If it matters, somebody will raise it again. ## How do you write tickets engineers actually understand? Match the detail to the distance the ticket has to travel, in time and in team distance. A ticket you wrote this morning and will start after lunch needs almost nothing. A ticket picked up in five weeks by a contractor who was not in the room needs context, scope boundaries and criteria, because each of those is a question they cannot ask cheaply. Ticket hygiene is not free, and over-specifying is its own failure. A thorough ticket takes fifteen to thirty minutes to write, which is a poor trade against an hour of work, and it invites the assignee to implement the description rather than solve the problem. So write only the parts that would be expensive to ask about later. Which user, what happens on failure, and what done means are almost always in that category. The rest usually is not. ## Should developers write their own tickets? Yes, for their own work, and it is normal on healthy teams. Engineers write the refactors, the upgrades, the flaky test fixes and the follow-ups they spot in review, and those are usually better written than a product manager could manage, because the author knows exactly what is wrong. The trouble starts with the assumption that whoever writes the ticket also decides the scope. Two different jobs: - **Deciding the work happens** and what it is for. Product, usually with the tech lead. - **Writing it down** so the next person can act. Whoever holds the detail, which for technical work is the engineer and for a customer-facing change is often whoever spoke to the customer. The arrangement most teams settle on is that anyone may create a ticket, and nothing enters a sprint without a short conversation that settles scope, ownership and what done means. Refinement exists precisely to catch tickets that read as complete while hiding an unmade decision. If you want a mechanism rather than a habit, Projan puts those questions to the team in Slack or Microsoft Teams and writes the agreed answers out to Jira as a ticket. The questions matter more than the route they take: ask them while the work is still cheap to change. One rule worth holding either way. Whoever writes the ticket is not the person who decides it is done. ## Frequently asked questions **What is the best practice for Jira tickets?** Agree a small number of house rules and enforce those rather than a long standard nobody reads. Useful ones: every ticket has a person against it, every ticket in progress has a written definition of done, no ticket carries two outcomes, and the backlog gets a cull on a fixed date. Four rules kept beat twelve ignored. **What is the difference between an issue and a ticket in Jira?** Nothing, in practice. Issue was the original Jira term for any tracked item, Atlassian's documentation now uses work item, and most teams say ticket regardless. The word only matters when you are reading documentation or configuring a project, where the official term is the one that appears in menus and permission settings. **How long should a Jira ticket description be?** Long enough that the assignee does not need to find the author, and no longer. For work someone starts today, a couple of lines is honest. For work that sits in a backlog for a month, expect a short paragraph of context, the scope boundary, and checkable criteria. Length is a symptom, not a target. **Who should close a Jira ticket?** Whoever can confirm the acceptance criteria were met, which is often not the person who wrote the code. On most teams that is the reviewer, the tester or the person who raised it. Closing your own work is fine when the criteria are objective and someone else has reviewed the change. Write the title for the person scanning forty of them, write the description for whoever opens it next, and hold one outcome per ticket. If you only change one habit, make it closing the tickets you are never going to do. ### How to Write a Summary of Findings Your Client Will Actually Read https://projan.ai/blog/how-to-write-a-summary-of-findings-your-client-will-actually-read/ Published: 2026-08-12 Write a summary of findings by leading with the answer to the client's decision, not the process that produced it. State what you found, what it means, and what should happen next, in that order, on one page. The full report exists to defend those claims. The summary exists to be read. This is for consultants and internal advisers who have finished the analysis and now have to compress it. It covers what goes in the summary, how long it should be, how to cut a long report down without stripping out the evidence trail, and when a slide beats a page. ## How to write a summary of findings report? Write the summary last, but write it as though it were the only document. Every step below removes something the reader does not need in order to act. 1. **Decide which decision the summary serves.** Almost every commissioned review exists because someone has to choose: invest or stop, restructure or leave alone, fix in-house or buy. Name that decision before you write a word. If you cannot name it, ask the sponsor, because the alternative is a summary that is interesting to nobody in particular. 2. **Write the headline finding as a sentence with a verb.** "Handover between sales and delivery" is a topic. "Handover between sales and delivery fails because nobody owns the account after signature" is a finding. Topics fill contents pages; findings change minds. 3. **Group the rest into three to five findings.** More than five and the reader stops ranking them. If you genuinely have eleven, some of them are symptoms of the others and belong underneath, not alongside. 4. **Attach the evidence to each finding in one clause.** "Nine of fourteen interviewees described the same delay" or "four of the last six projects overran at the same stage". Specific counts survive challenge. Adjectives do not. 5. **Separate what it means from what you recommend.** The implication is what follows from the evidence. The recommendation is what you think should be done about it, which is a judgement the client may reject while still accepting the finding. Keeping the two apart is what lets a client disagree with you without discarding the analysis, and it is worth [reading the boundary between findings and recommendations properly](/blog/findings-vs-recommendations-how-to-write-both-in-one-report-without-blurring-the) before you draft either. 6. **State what happens next.** Two or three actions, with an owner against each if you have that far. A summary that ends at diagnosis invites the client to invent their own treatment. 7. **Put the method at the bottom, in two lines.** What you looked at, over what period, with what access. Enough for a sceptical reader to weigh the evidence. No more. If your opening line is "This report presents the findings of a review commissioned in March", you have spent your best sentence on a date. ## How long should a summary of findings be? One page. For a report over fifty pages, two. In words that is roughly 250 to 600, which is far shorter than most consultants first draft and about right for the way the document is actually consumed, which is standing up, on a phone, ten minutes before a meeting. Length is set by the decision, not by the report. A ninety-page technical review that resolves into a single yes or no still gets one page. A shorter review covering four independent workstreams may need two, because the reader has four decisions to make and cannot take them as a set. The useful test is not word count. It is whether a director who reads only the summary can defend the conclusion in a meeting you are not in. If they would have to say "the consultants looked into it and they think we should", the summary has failed regardless of its length. ## Is a summary of findings the same as an executive summary? Not quite, though the two are used interchangeably often enough that you should check which one a client means. An executive summary summarises the whole document, including scope, approach, findings and recommendations. A summary of findings covers only what you found and what it implies. In practice the distinction matters most on regulated or evidence-heavy work, where the findings need to be readable on their own without the recommendations attached to them. An audit committee may want the findings circulated to one group and the recommendations discussed by another. If that is your situation, write the summary of findings so it stands alone, then let the executive summary wrap it with scope and next steps. For ordinary consulting work, most clients say "executive summary" and mean "the page I will read". Write that page well and the terminology argument disappears. ## How do you compress a long report without losing the evidence trail? Keep the pointer, drop the working. Every claim in the summary should be traceable to a section of the report, and the cheapest way to preserve that is a bracketed reference after each finding: "(section 3.2)". The reader who wants proof can find it in seconds, and you have not spent a paragraph explaining where it came from. Beyond that, the compression is mostly deletion of a few reliable categories: - **The project narrative.** What you did in week two is of no interest. The report can carry it; the summary cannot afford it. - **Balanced framing.** "There are strengths as well as areas for development" is a sentence that survives every draft and informs nobody. If the strengths matter, name one specifically. If they do not, cut them. - **Quotations.** One short quotation can carry a finding. Three turn the summary into evidence rather than conclusion. - **Caveats that apply to everything.** Sample limitations, access constraints and time boxes go in the method line at the bottom, once, not attached to each finding. - **Anything that only makes sense if you read the report first.** This is the defect a colleague who did not write the report will catch and you will not. What survives is claim, count, implication, action. If a sentence is none of those, it is describing the work rather than the answer, and it belongs in [the body of the findings report](/blog/how-to-write-a-findings-report-structure-content-and-what-to-leave-out) instead. ## Should you write it as a page or a slide? Match the format to how the summary will first be encountered, not to how you like writing. Most engagements need two versions of the same content, and the mistake is producing one and hoping it works everywhere. | Format | Use when | Rough length | What goes wrong | |---|---|---|---| | One-page written summary | The report is circulated for reading, or the decision is taken without you present | 250 to 600 words | Written as prose paragraphs, so nothing is scannable | | Summary slides | You are presenting, and discussion will follow each finding | 3 to 5 slides, one finding each | Bullet fragments that do not make sense once the slide is forwarded on | | Email summary | The client asked for the short version before the report is finished | 150 words, findings only | Becomes the version everyone quotes, before it has been checked | The email version is the one to be careful with. A summary sent early to be helpful has a habit of being pasted into a board pack, where it will be read as your considered position. If you send one, say plainly that it is provisional and give the date the full report lands. If you are building the slide version, the [structure of a findings presentation differs from the structure of a written summary](/blog/how-to-present-findings-to-a-client-structure-examples-and-summary-docs) in ways worth planning for before you start cutting. ## What makes a summary of findings unreadable Four failures account for most of them, and all four are easier to fix in the summary than anywhere else in the report. - **Findings that are activities.** "We interviewed 14 staff and reviewed 30 documents" tells the reader what you were paid to do, not what you learned. - **Hedging on every claim.** "There may be some indication that handovers could be improved" is a sentence written to survive review, not to be acted on. If the evidence is thin, say the evidence is thin and state the finding anyway. - **No numbers.** "Widespread concern about resourcing" is unfalsifiable. "Nine of fourteen interviewees raised the same resourcing problem, unprompted" is a fact a client can act on or dispute. - **Recommendations with no owner.** The most common ending to a good summary is a list of sensible actions belonging to nobody, which is how a report ends up cited approvingly for two years and implemented never. That last one is a fifteen-minute conversation, held before the summary goes out, with the people who will actually do the work. [Projan](/landing/consulting) handles that conversation inside Microsoft Teams or Slack, pressing each recommendation for a named owner, a date and a test that would show it had happened, and writing the agreed list into Asana or Notion. However you run it, hold it while the client's attention is still on the report. ## Frequently asked questions **What to write in a summary of findings?** Five things a reader can check: the headline finding stated as a claim, three to five supporting findings, the evidence behind each one in a clause, what the findings imply for the client, and what happens next. Anything that describes the project rather than the organisation belongs in the report, not the summary. **How do you write the summary of your findings?** Draft it twice. Write a rough version before you finish the analysis, as a hypothesis you are trying to disprove, because it exposes which evidence you still lack. Then rewrite it from scratch once the report is complete, working from the finished findings rather than editing the earlier draft down. **Should a summary of findings include recommendations?** Usually yes, kept short and clearly separated from the findings themselves. A summary that states problems and stops leaves the client to invent their own response, which is rarely the one you would have chosen. Two or three lines of recommendation is enough; the reasoning stays in the report. **Does a summary of findings need a methodology note?** One or two lines, placed at the end rather than the beginning. State what you looked at and over what period, in enough detail that a sceptical reader can judge the weight of the evidence. Anything longer belongs in an appendix. Method at the top pushes the finding below the fold. **Who should review the summary before the client sees it?** Someone on your team who did not write the report. They will spot claims that only make sense if you already know the evidence, which is the most common defect in a summary written by the analyst. If the engagement has a sponsor who is not the day-to-day contact, test the summary against their decision too. A summary that could be true of any organisation in the sector is not a summary, it is a genre. Write it so the first sentence would be wrong about a different client, put a number behind every claim, and let the report do the arguing. ### Brand Messaging Framework: What It Is and How to Write One https://projan.ai/blog/brand-messaging-framework-what-it-is-how-to-write-one-and-examples-that-stick/ Published: 2026-08-11 A brand messaging framework is an internal document that fixes what your brand says, who it says it to, and in what order of priority. It normally holds a positioning line, two to four message pillars, proof for each pillar, and rules on the language to use and avoid. Its job is consistency across everyone who speaks for the brand. This is written for the person who has been handed the job: a brand or product marketing lead, often with sales asking for something usable by Thursday. It covers what goes in the document, a worked example, how to write one, and why most of them quietly stop being used. ## What is a brand messaging framework? A brand messaging framework is the reference document that a salesperson, a copywriter, an agency partner and a support rep all work from, so that the company sounds like one company. It sits below positioning and above any individual piece of copy. Positioning decides where you compete; the messaging framework decides what you actually say about it out loud. Most frameworks contain some version of these layers. | Layer | What it answers | Typical length | |---|---|---| | Positioning line | Who this is for, what category it is in, why it is different | One or two sentences | | Value proposition | The single clearest reason to choose you | One sentence | | Message pillars | The two to four themes every claim rolls up to | A phrase plus a sentence each | | Proof points | Why each pillar is credible: features, data you own, references | Two or three per pillar | | Audience variants | How the pillars change emphasis by buyer or segment | A line per audience | | Language rules | Words you use, words you refuse, phrases competitors own | A short list | | Boilerplate | The approved paragraph for press, decks and partner sites | 50 to 80 words | The framework is not a tagline, a campaign concept or a brand book. Those are downstream. It is also not the positioning statement itself, though the two get conflated constantly; if you need the line between them drawn properly, our guide to [where brand positioning ends and the messaging framework begins](/blog/brand-positioning-vs-messaging-framework-where-one-ends-and-the-other-begins) does that job. The internal structure of the pillars, and how they expand into a grid by audience, is covered in [messaging hierarchy and messaging matrix](/blog/messaging-hierarchy-and-messaging-matrix-pillars-structure-and-how-to-build-both). ## What is an example of a brand messaging framework? Here is a worked example. It is illustrative, not a real company's document, and it is written for a fictional business called Kerbside, which sells route-planning software to independent waste collection firms. **Positioning line.** For independent waste collection operators running 5 to 40 vehicles, Kerbside is route-planning software that a depot manager can change on the morning of a round, without calling anyone. **Pillar 1: changes on the day, not the week.** Rounds get rewritten when a truck breaks down at 6am. Proof: routes recalculate in the app in under a minute; no support ticket needed; drivers get the update on the handset they already carry. **Pillar 2: built for depots, not fleets of 500.** Proof: pricing per vehicle with no minimum; setup in one working day; no integration project. **Pillar 3: an audit trail that satisfies the paperwork.** Proof: every collection timestamped and exportable; duty of care records retained; report format accepted by the operators we work with today. **We do not say:** "end-to-end platform", "optimise", "revolutionise waste". We do not claim fuel savings, because we cannot evidence them yet. That last line is the part most examples leave out and the part that does the most work. A framework containing nothing you have refused to say is not a framework, it is a list of adjectives. A caution about examples generally. Published real frameworks are rare, because a framework is an internal document and what a company publishes is its output. Most articles offering "the brand messaging framework of a famous company" are reverse-engineering the website of a business the author never worked at. Read those as inference, not as documents. ## Can you give me an example of a brand message? A single brand message is one sentence a real person could say out loud in a meeting, containing a claim, the person it is aimed at, and something that makes it credible. It is the smallest unit in the framework, and it is where most drafts fall apart. Weak, in the sense that nobody would ever say it: - "Kerbside enables waste operators to unlock operational efficiency at scale." Stronger, because a sales rep could say it on a call without embarrassment: - "If a truck goes down at six in the morning, your depot manager can rebuild the round before the crews leave, from a phone, without ringing us." The test is not whether the sentence sounds like brand copy. It is whether a salesperson would say it to a sceptical buyer who knows the category. Messaging fails at the mouth long before it fails on the page. If your team quietly translates every line into their own words before using it, the framework has already been overruled. ## How do you write a messaging framework? Write it by collecting language that already works, narrowing it to a few claims you can prove, and then testing it in a real conversation before you format anything. The sequence below assumes positioning is settled; if it is not, do that first, because messaging built on unresolved positioning gets rewritten within a quarter. 1. **Settle the positioning line.** One sentence covering audience, category and difference. The [formula and the four parts of a positioning statement](/blog/how-to-write-a-positioning-statement-formula-four-parts-and-positioning-maps) are worth following properly rather than improvising. 2. **Harvest the language that already converts.** Read recent sales call notes, support tickets, review sites and win-loss records. Write down the exact phrases customers use for the problem. You are not inventing a vocabulary, you are choosing between the ones in circulation. 3. **Narrow to two to four pillars.** Every claim you keep has to roll up to one of them. If a claim fits none, it is either a new pillar or a distraction, and it is nearly always a distraction. 4. **Write claims as spoken sentences.** Subject, verb, object. Noun phrases like "operational excellence" survive workshops because nobody can disagree with them, which is exactly why they are useless. 5. **Attach proof to every claim, then delete the ones without any.** A feature, a number you own, a named reference, a demonstration. This step is where a framework shrinks, and the shrinking is the point. 6. **Write the do-not-say list.** Competitor-owned words, claims legal will not clear, category jargon you have decided to skip, and anything you cannot evidence. 7. **Test it live before you design it.** Give the pillars to two salespeople and a support agent for a week and collect the edits. Ship the version that survives, dated and numbered. Steps 2 and 5 are the ones people skip under deadline, and skipping them produces the framework nobody uses. ## What makes a messaging framework stick? Frameworks stick when the people expected to speak them helped write them, and when the document is short enough to be recalled under pressure. Almost every other trait follows from those two. What the durable ones have in common: - **Contributors from outside marketing.** Sales, support and whoever handles renewals. They are the ones who will find out first when a claim does not land. - **One page for the core.** Appendices can be long. The pillars cannot. - **A proof point per claim**, so nobody has to guess what backs it up when a prospect pushes. - **An explicit do-not-say list**, which is the only part that ever settles an argument quickly. - **A named owner and a review date**, not a shared folder and good intentions. - **A home in the tools people already open.** A framework that lives only in a slide deck is consulted twice and then remembered inaccurately. The failure mode is predictable. One person drafts it alone, it gets presented rather than discussed, everyone nods, and three weeks later the sales team is using their own words because nobody asked them what they currently say. Getting those people into one room at the same time is often the real obstacle. Where the calendar makes that impossible, run the drafting as a round of questions rather than a document review: Projan will put questions like "which of these claims would you say on a live call, and which would you skip?" to each contributor in Slack or Microsoft Teams, then write the agreed wording out into a document in Notion. Whichever method you use, the rule holds: wording that has never been said aloud by the people who have to say it is a draft, not a framework. Deciding who signs it off is a separate question, covered in [who owns what in marketing](/blog/who-owns-what-in-marketing-strategy-content-campaigns-and-briefs). ## What is a brand communication strategy framework? A brand communication strategy framework is the wider plan for how the brand reaches people, and the messaging framework is one component inside it. Messaging answers what we say. Communication strategy answers to whom, through which channels, how often, in what sequence, and to what measurable end. A communication strategy framework typically adds: - Audience and stakeholder mapping, including people who are not buyers - Channel choices and the role each channel plays - Cadence and campaign calendar - Spokespeople, approvals and crisis handling - Objectives and the measures that show whether the communication worked The practical relationship: you cannot plan channels sensibly until you know what you are saying, and you cannot judge whether the messaging works until it has run through real channels. Write the messaging framework first, keep it in the strategy document as an appendix, and update it when the channel evidence contradicts it. ## Frequently asked questions **What are messaging frameworks?** The plural covers more than brands. Teams build messaging frameworks for a single product, a campaign, an employer brand or a fundraise, and they share the same shape: a named audience, a small set of claims, proof for each claim, and words to avoid. The brand-level framework sits above the others, and the rest should not contradict it. **Who owns the brand messaging framework?** One named owner, usually the brand or product marketing lead, with sign-off from whoever is accountable for revenue messaging. Contributors are wider: sales, customer support, and the founder if the founder still sells. Ownership means that person decides when a claim changes, keeps the version history, and answers wording questions within a day rather than a sprint. **How long should a brand messaging framework be?** One page for the core, with appendices only if you genuinely need audience variants. If a salesperson cannot hold the pillars in their head walking into a call, the framework will be replaced by whatever they improvised last week. Length is usually a symptom: long frameworks tend to mean the pillars were never narrowed down. **How often should a messaging framework be updated?** Review it once a year and rewrite it whenever something material shifts: a new segment, a repositioning, a competitor taking your ground, or a product change that invalidates a proof point. Between reviews, keep a running note of the wording people keep correcting on calls. Those corrections are the first draft of the next version. **Is a tagline part of the brand messaging framework?** A tagline can live in the framework, but it is an output rather than a foundation. Write the pillars and the proof first, then let the tagline be the compressed public version of them. Frameworks reverse-engineered from a line someone liked in a workshop tend to collapse the first time a claim gets challenged in a deal. A brand messaging framework is worth exactly as much as it is spoken. Keep it to a page, prove every claim, name the things you refuse to say, and build it with the people whose job it is to say the words. ### Brand Positioning vs Messaging Framework: Where One Ends and the Other Begins https://projan.ai/blog/brand-positioning-vs-messaging-framework-where-one-ends-and-the-other-begins/ Published: 2026-08-10 Brand positioning is the decision: who you are for, which category you compete in, what you claim to do better, and why that claim is believable. A messaging framework is the language built on that decision, covering pillars, proof and phrasing the whole team reuses. Positioning settles the argument. Messaging repeats the result consistently. This is for marketers who have both documents, or think they have, and cannot tell which one to fix when the copy keeps drifting. It covers what each one decides, what belongs inside a messaging framework, where the handoff sits, and who signs off. ## Brand positioning vs messaging framework Positioning decides what is true about your place in the market. The messaging framework decides how that truth gets said, by whom, to which audience, in which channel. One is a set of commercial decisions, the other is a writing tool. | | Brand positioning | Messaging framework | |---|---|---| | **What it settles** | Which market you are in, who you are for, what you claim, why it is credible | The words that express those claims, per audience and channel | | **Typical output** | A positioning statement plus the reasoning that produced it | Value proposition, message pillars, proof points, boilerplate, words to avoid | | **Who drafts it** | Founder or brand lead, with sales and product in the room | Product marketing or the senior copy lead | | **Who signs off** | The CEO or commercial lead, because it constrains what the company sells | The marketing lead, working inside the position already agreed | | **Who reads it** | The leadership team, and anyone briefing an agency | Everyone who writes or speaks: sales, support, freelancers, partners | | **How often it changes** | Rarely. A new segment, a new category, a real competitive shift | Continually at the edges, meaningfully once a quarter | | **What a mistake costs** | You compete in the wrong category and lose deals you should never have been in | Every channel sounds like a different company | | **Test that it is done** | Two competitors could not sign the same statement | Two writers, given the framework, produce different words carrying the same meaning | The dependency runs one way. Messaging inherits from positioning and never the reverse, which is why a framework written before the position is settled tends to read like a well-formatted argument rather than a reference document. Writers can feel this even when they cannot name it. They keep asking for one more round of feedback because the feedback keeps changing. The two also fail differently, and that is the fastest way to work out which one you are looking at. Bad positioning produces confident, fluent copy aimed at people who will never buy. Bad messaging produces accurate copy that reads differently on every page. ## What is a messaging framework? A messaging framework is a short internal document fixing what your company says about itself: one value proposition, a small number of message pillars, the evidence behind each, and the variations for each audience you sell to. It exists so that ten people writing in ten places produce one recognisable company. It is not brand guidelines. Guidelines govern how you look and how you sound, covering logo use, colour, tone and grammar. The framework governs what you claim. A team can follow the tone guide perfectly and still put four incompatible claims on four pages. It is also not a copy deck. Nothing in a framework should be lifted word for word onto a landing page, apart from the boilerplate. Its sentences are meant to be reference, not final copy. If you find people pasting from it, the framework has quietly become a template and will stop being updated. For a full walkthrough of building one, including examples of finished pillars, see [our guide to writing a brand messaging framework](/blog/brand-messaging-framework-what-it-is-how-to-write-one-and-examples-that-stick). ## What should a messaging framework include? A messaging framework should include the positioning it inherits, the audiences it serves, the claims it authorises, and the evidence behind each claim. Anything that does not eventually help someone decide what to write can be cut. The working contents: - **The positioning statement, copied in verbatim.** Not restated in fresh words. If the framework paraphrases the position, you now have two positions. - **Audience segments**, with what each one is actually trying to do, not their demographics. - **The value proposition**: one sentence a buyer would recognise as being about their problem. - **Message pillars**: three to five themes, each with its claim, its reason to believe and its proof. - **Proof points**: named evidence. Integrations, certifications, published research, specific product behaviour. Vague credibility is not proof. - **Objections and the answer to each**, in the words a buyer uses when they raise it. - **Boilerplate and a one-liner**, so nobody writes a new company description at 4pm on deadline. - **Words you use and words you avoid**, with the reason. The reason matters more than the list. - **An owner and a review date.** A framework with no owner ages badly and nobody notices. The two sections teams skip are objections and words to avoid, which are precisely the two that sales and agencies use most. Everything above them is written for marketers; those two are written for everyone else. ## What are the three main pillars of a messaging framework? There is no canonical set of three. The number is a convention, not a rule: three is roughly what a salesperson can hold in their head under pressure, and the pillars themselves are specific to your brand rather than a standard trio you can look up. Anyone selling you a fixed three has invented them. What is genuinely standard is the internal structure of a pillar. Each one has three layers: 1. **The claim.** One sentence stating something a buyer would care about, phrased so it could be disagreed with. "Set up in an afternoon without a developer" is a claim. "Easy to use" is not. 2. **The reason to believe.** The mechanism that makes the claim true. This is the part that gets skipped, and its absence is why some pillars collapse the first time a prospect pushes. 3. **The proof.** Named, checkable evidence: a feature that behaves that way, a published benchmark, a customer willing to say so, a certification. Choosing the themes is a competitive exercise rather than a creative one. Write your three candidate pillars, then write your closest competitor's homepage claims next to them. Anything appearing on both lists is a requirement of the category, not a differentiator, and it should sit in your proof section rather than at the top of your framework. Three to five pillars is the working range. Beyond five, nobody remembers them, and a framework nobody remembers has no effect on what gets written. If you sell to more than one buyer, the pillars stay constant and the expression changes per segment. That grid is a messaging matrix, and [the structure of hierarchies and matrices is worked through in more detail here](/blog/messaging-hierarchy-and-messaging-matrix-pillars-structure-and-how-to-build-both). ## Which comes first, positioning or messaging? Positioning comes first, and the handoff happens when you stop deciding what is true and start deciding how to say it. The practical way to know you have crossed that line is to answer three questions without hedging. 1. **Who is this for, specifically enough to exclude someone?** If the answer includes nobody you are turning away, you have described a market, not a target. 2. **What do they use instead today, and why is that tolerable to them?** The alternative is often a spreadsheet, an agency or nothing at all. You are positioning against that, not against the vendor you benchmark on. 3. **What can we claim that the alternative genuinely cannot?** Not what you would like to claim. What survives a sceptical buyer asking how you know. Answer those three and the messaging framework is largely a writing job. Leave any of them open and every wording debate becomes a proxy for the unanswered question, which is why those debates never resolve on their own. The [positioning statement formula and how to map the alternatives](/blog/how-to-write-a-positioning-statement-formula-four-parts-and-positioning-maps) covers that upstream work properly, and [the longer positioning document that surrounds the statement](/blog/how-to-write-a-brand-positioning-document-and-how-it-differs-from-a-positioning) covers what else goes with it. One exception worth naming. Companies with a live product and no written position sometimes get further by writing the messaging first, treating the pillars as a draft hypothesis, then reverse-engineering the position from whichever claims survive contact with sales calls. That works, but only if you then write the position down. Otherwise you have preserved the symptom. ## What goes wrong when positioning and messaging get blurred The blur shows up as an argument about words that nobody can win. The tell is that feedback arrives as taste, because the criteria for a right answer were never agreed anywhere. Common symptoms, roughly in order of how often they appear: - **The headline gets rewritten every quarter** and each version is defensible, because there is no agreed claim to test them against. - **Sales quietly write their own deck.** They are not being difficult. They are filling in a position you did not give them. - **The positioning document is full of adjectives.** Premium, innovative and trusted are attempts at messaging that wandered upstream. A position names a market, a buyer and a claim. - **The framework opens with a mission statement.** Mission explains why the company exists. It does not tell a copywriter what to say about the product. - **Every channel sounds like a different company**, because each writer resolved the same ambiguity in their own way and none of them were wrong. The fix is procedural rather than editorial. Get the three handoff questions answered once, with the person who can overrule everyone else present, and write the answers down before another copy doc is opened. Where that conversation has no obvious owner, running it as a facilitated session helps. Projan does this inside Slack or Microsoft Teams, asking who the buyer is, what they use instead and what you can claim that the alternative cannot, then writing the agreed answers into a document your writers open before drafting. When you can only fix one, fix positioning. Messaging written on a settled position can be rewritten in a week. Messaging written on an unsettled one gets rewritten forever. ## Frequently asked questions **What are the pillars of a messaging framework?** They are the three to five themes your messaging keeps returning to, each one a claim your positioning already entitles you to make. The useful test is competitive rather than creative. If a rival could put the same pillar on their own site without lying, it is a category requirement, not a pillar, and it belongs lower down as a proof point. **Is a value proposition the same as a positioning statement?** No. A positioning statement is written for your own team and records the target, the category, the claim and the reason the claim is credible. A value proposition is written for the buyer and states what they get. One is a decision kept internally, the other is language you would put on a homepage. **How often should you rewrite each one?** Positioning changes when the market changes: a new segment, a new category, or a competitor moving onto your claim. That is rarely more than once a year. Messaging moves far more often because channels, campaigns and objections move. Review the framework quarterly, and treat pressure to reword the position as a signal to reopen positioning properly. **Do small teams need both documents?** Yes, but not as two long documents. A page each is plenty. Four lines of positioning naming the target, the category, the claim and the evidence, then a page carrying pillars, proof and words to avoid. The point is that the decisions exist somewhere other than in the founder's head. **What is a messaging matrix?** A grid mapping each message pillar against each audience segment, so you can see what one claim sounds like to a finance director as against an end user. It sits underneath the framework rather than replacing it, and it is worth building only once the pillars are settled and you sell to more than one buyer. Positioning is a decision and messaging is its consequence, so when the words will not settle, look upstream before you brief another round of copy. Keep the two documents separate, keep the positioning statement quoted verbatim inside the framework, and give each one a named owner who has to approve changes. ### Common Minute-Taking Mistakes (and How to Avoid Them) https://projan.ai/blog/common-minute-taking-mistakes-and-how-to-avoid-them/ Published: 2026-08-10 The most common mistakes in taking minutes are recording the discussion instead of the decision, writing actions with nobody's name against them, transcribing verbatim, adding tone or opinion, and writing up days later from memory. Every one of these is a judgement failure rather than a typing failure, and every one has a fix that costs nothing. This is for whoever ends up with the notebook: committee secretaries, chairs, project managers, and the person who arrived last. It covers the mistakes, why capable people keep making them, and what to check before you send. ## What are common mistakes in taking minutes? Nine mistakes account for most bad minutes, listed roughly in order of the damage they do. 1. **Recording the discussion instead of the decision.** A minute that captures the debate but not the outcome proves a conversation happened. Everyone knew that already. Write the decision as a past-tense sentence, then stop. 2. **Actions with no owner and no date.** "The team will review the supplier list" is a wish. "Ravi to review the supplier list by 22 May" is an action. If you cannot name a person, nobody in the room accepted it. 3. **Transcribing verbatim.** A full account of who said what is a transcript, a different artefact with different uses. [Notes, transcripts and minutes each do a different job](/blog/notes-vs-transcripts-vs-minutes-which-meeting-record-do-you-actually-need), and minuting like a court stenographer produces a document nobody opens. 4. **Editorialising.** "A heated exchange followed" and "Priya reluctantly accepted" are your interpretation, and they read very differently once the file leaves the room. Record what was decided, not the temperature. 5. **Writing up days later from memory.** Recall decays fastest for the things that matter: numbers, conditions, who agreed to what. Draft into the agenda structure during the meeting and finish within a few hours. 6. **A vague attendance record.** Note who attended, who sent apologies, and who arrived late or left early. If a decision is challenged, the attendance line is what shows the meeting was quorate when it was taken. 7. **Recording things that should not be recorded.** Unresolved allegations, individual salaries, half-formed legal opinions and off-record asides do not belong in a circulated, retained document. UK companies must keep minutes of directors' meetings and general meetings for ten years under the Companies Act 2006, so assume anything you write outlives the argument. 8. **Hedged wording that hides the absence of a decision.** "It was agreed to look into this further" usually means nothing was agreed. Say so plainly: the item was discussed, no decision was reached, and record who is bringing it back and when. 9. **Late or misdirected distribution.** Minutes that arrive the day before the next meeting have already failed the actions in them. [Who signs off the minutes and who receives them](/blog/approving-and-distributing-meeting-minutes-who-signs-off-who-gets-a-copy-and-whe) should be settled once, not worked out per meeting. ## Why capable note-takers still produce bad minutes Most bad minutes are produced by competent people in badly run meetings. The note-taker can only record decisions that were actually made, and much of what passes for a decision is a confident opinion nobody contradicted before the chair moved on. Three structural causes do most of the damage. The chair never says the words "so the decision is". The note-taker is also a participant, and nobody can argue and write at the same time. And there is no template, so every meeting is minuted in a slightly different shape. The first is the chair's job, not the minute-taker's. Closing each item by stating the decision, the owner and the date out loud takes ten seconds, forces the room to notice when there is nothing to state, and turns minuting from interpretation into copying. Another fix is to write the record at the moment of agreement rather than afterwards. Projan does this for planning meetings: it puts the clarifying questions to the group in Slack or Microsoft Teams and writes each agreed answer down with an owner attached as it lands, so nothing is reconstructed from anyone's notes later. ## Where each mistake shows up, and what it costs The mistakes are rarely noticed on the day. They surface later, in front of the people you least want to explain them to. | Mistake | Where it surfaces | What it costs | |---|---|---| | Decision not recorded | The next meeting, when the item is reopened | The meeting is held twice | | Action with no owner | The status update a fortnight later | Nobody started it | | Editorialised tone | When the file is forwarded or disclosed | A personal problem, occasionally a legal one | | Vague attendance | When a decision is formally challenged | You cannot show it was properly taken | | Late distribution | When the deadlines in it have already passed | The actions start a week behind | ## What do AI note-takers get wrong? AI note-takers transcribe well and decide badly. They capture every word accurately, then weight a confident tangent the same as the agreed outcome, because nothing in the audio marks the difference. Three failures recur. They record the loudest framing as the conclusion. They assign an action to whoever spoke the sentence rather than whoever accepted the work. And they include the aside everyone understood to be off the record, because nobody said so aloud. That makes them a drafting aid needing a human editor who was present, which is not the job they are usually sold for. [The gap between an AI note taker and an AI facilitator](/blog/ai-note-taker-vs-ai-facilitator-two-very-different-jobs-in-your-meetings) is worth understanding before you hand over the notebook. ## The check before you send Five checks catch nearly everything, and they take about three minutes. - Every action has a person's name and a date, not a team and a month. - Every agenda item ends in a decision, a deferral with an owner, or an explicit "no decision reached". - No adjective describes anyone's mood, tone or motive. - Attendance, apologies and any late arrivals or early departures are recorded. - Someone who missed the meeting could act on this document without ringing you. The last one is the real test. Nobody returns to minutes to relive the debate. They return to settle an argument about what was agreed, and a record that cannot settle it was not worth taking. For the underlying structure, start with the [eight elements a set of minutes should contain](/blog/meeting-minutes-what-to-include-best-format-and-the-8-essential-elements). ## Frequently asked questions **What are common mistakes in minutes?** Judge the document rather than the meeting. The usual defects are actions with no date, decisions written as summaries of the debate, an attendee list that does not say who left early, inconsistent numbering that makes items impossible to reference, and a file that was edited after circulation with no note of what changed. **Is it a mistake to record who said what?** Usually. Minutes should attribute decisions and actions, not opinions. Naming who argued which way turns a working record into ammunition, and people speak more carefully once they know it happens. The exceptions are formal boards and statutory meetings, where a member may specifically ask for their objection to be recorded by name. **How long should writing up minutes take?** Twenty to thirty minutes for an hour-long meeting, assuming you captured decisions and actions during it rather than raw notes. If it reliably takes two hours, you are transcribing and then editing down, which is the expensive way round. Draft straight into the agenda structure while the meeting runs. Minutes fail in predictable ways, and nearly all of it traces back to recording what happened instead of what was settled. Write the decision, put a name and a date on every action, and send it the same day. ### What Is the Point of a Content Calendar? https://projan.ai/blog/content-calendars-what-they-re-for-the-main-types-and-how-to-pick-one/ Published: 2026-08-10 A content calendar exists to turn intentions into dated commitments other people can see. Its job is coordination: showing who is producing what, by when, and what each item waits on, early enough for the dependency to be met. Publishing on schedule is the side effect, not the point. How the calendar differs from a strategy and a plan is covered in [what each layer actually covers](/blog/content-strategy-vs-content-plan-vs-content-calendar-what-each-layer-actually-co). This piece is about the artefact itself. ## What is the point of a content calendar? The point is to make future work visible far enough ahead that the people who must contribute can plan around it. A calendar that only records what will be published is a to-do list with a nicer view. What makes it a calendar is the lead time: the dates before the publish date. Three things a working calendar does that a publishing list does not: - **It exposes collisions.** A launch landing on a sales push, or one designer booked by three campaigns and told about none of them. - **It surfaces lead time.** Most content misses its date on the input, not the output. The interview never got booked, the compliance review took nine days, the screenshots needed a build that was not ready. - **It gives you something to argue with.** When a stakeholder asks for an extra post next Tuesday, a calendar turns that into a question about what moves, rather than a question about whether the team can absorb it. A content calendar earns its keep the first time it stops something, not the first time it schedules something. ## What are the different types of content calendars? There are five in common use: editorial, social media, campaign, channel and master marketing calendars. These are conventions rather than a standard, and most teams run two or three of them as views of one list. 1. **Editorial calendar.** Long horizon, low volume, organised around themes and substantial pieces such as articles, reports and video. Planned a quarter at a time, revised monthly. 2. **Social media calendar.** Short horizon, high volume, organised by channel and slot. It holds the actual copy and asset, because nobody has time to go looking on the morning of the post. 3. **Campaign calendar.** One campaign across every channel, planned backwards from the launch date. It shows that the email, the landing page and the paid creative must all be ready at once, and which is furthest behind. 4. **Channel calendar.** One pipeline, one cadence: the newsletter, the podcast, the YouTube schedule. Useful when a channel has a production rhythm that matches nothing else. 5. **Master marketing calendar.** Everything that touches an audience: events, launches, sales pushes. Its only job is collision detection, so it should be readable in one screen rather than complete. The mistake is keeping these as five separate files. Five files means five answers to the question of what goes out next Thursday, and the answer people act on is whichever file they had open. Keep one dataset and filter it. ## What goes in a content calendar Each row needs enough for someone other than its author to act on: a publish date, a channel, a named owner, a state, and the dates for the steps before publication. - **Owner, as a person.** Not "social", not "the content team". A team cannot be chased. - **State.** Idea, briefed, drafting, in review, approved, scheduled, live. A missing state field is the commonest reason a calendar becomes decorative. - **Lead dates.** Draft due, review due, asset due. These are the dates the work runs to; the publish date is only the one it is judged by. - **Dependencies.** What the item waits on: a release, a legal sign-off, a photographer, a partner's approval. Where sign-off comes from outside marketing, that person and their realistic turnaround belong here rather than in somebody's memory. - **The brief, or a link to it.** [What belongs in a campaign brief and who signs it off](/blog/campaign-creative-briefs-what-to-include-who-writes-them-and-who-signs-off) covers the input side. - **The objective it serves.** Which pillar or funnel stage, taken from your [content strategy](/blog/content-strategy-101-purpose-pillars-and-the-7-steps-to-build-one) rather than from the calendar. Not for reporting, but for deciding what gets cut when the month tightens. ## Why content calendars stop being used Calendars fail for reasons that have little to do with the tool. **Slot-filling.** The calendar was built as a grid of empty slots, so filling them became the objective. Volume gets planned, purpose does not, and two months in nobody can say what any of it was meant to achieve. **Silent drift.** With no state field, nothing looks late until it is late. The calendar shows a tidy month while four of its items have not been started. **Nobody owns the grid.** Everyone owns their rows and no one owns the calendar as an object, so it decays between people who each assume somebody else is maintaining it. Settle [who owns what in marketing](/blog/who-owns-what-in-marketing-strategy-content-campaigns-and-briefs) before the calendar is built. Slot-filling is the one worth fixing upstream. Dates set in a document and circulated for comment get agreed by silence. Dates walked through with the person producing each item get agreed properly, or refused, and a refusal in week one is cheaper than a gap in week six. That conversation is what Projan is built to hold: it asks who is producing each item and what the item waits on, then writes the agreed set out to Asana or Notion. ## What is the best content calendar for social media? The best social media content calendar is the one that feeds your scheduler without anyone retyping a caption. Beyond that, it depends on how many people touch a post and how often you publish. | Team | Cadence | Setup that usually works | Where it breaks | |---|---|---|---| | One person | Anything | The scheduler's own queue plus an ideas list | The moment a second person has to approve a post | | Two to five | A few posts a week per channel | A shared board or database (Notion, Trello, Airtable) feeding the scheduler | Multiple brands, or channels on different cadences | | Six or more, or several brands | Daily across channels | Work management (Asana, monday.com, ClickUp), scheduler downstream | When people plan inside the scheduler and the board goes stale | Whatever the size, judge a candidate on three questions. Does it hold the asset, or only a link to a folder somebody will reorganise? Can it carry per-channel variants of one message without duplicating the item? Does it get the post into the scheduler without a copy and paste? A spreadsheet is a respectable answer for a small team and better than an expensive tool nobody opens. It stops being respectable once you need approvals, because it cannot tell you a post is waiting on someone. And if your calendar and your scheduler ever disagree about what is going out, the scheduler wins, which makes the calendar documentation rather than a plan. ## Frequently asked questions **How far in advance should a content calendar be planned?** Far enough ahead to cover your longest lead time, which is usually design or approval rather than writing. In practice that means a quarter sketched at theme level, the current month planned in detail with owners and dates, and the coming fortnight locked. Anything further out than a quarter tends to be rewritten before it is produced. **What is the difference between a content calendar and an editorial calendar?** In most teams the editorial calendar is one type of content calendar. Editorial usually means the longer-horizon plan for substantial pieces such as articles, reports and video, organised around themes. Content calendar is the broader term, covering everything scheduled including social posts. Plenty of people use the two interchangeably, so check what a colleague means. **How often should a content calendar be reviewed?** Weekly for the coming fortnight, monthly for the next quarter. The weekly pass is about state, catching items that have not moved since you last looked. The monthly pass is about commitment, deciding what stays, what shifts and what gets dropped. Reviews that only add items and never remove them are how calendars turn into fiction. A content calendar is worth keeping to the extent that it changes decisions. Build it around lead times and named owners rather than empty slots, and let it tell you what to drop as readily as what to publish. ### Course Feedback and Evaluation: What to Say, Examples, and How to Report Findings https://projan.ai/blog/course-feedback-and-evaluation-what-to-say-examples-and-how-to-report-findings/ Published: 2026-08-10 Good course feedback names a specific moment, says what effect it had, and suggests what you would change. Judge the course against what it promised to teach, not against how likeable the trainer was. One precise comment about pacing in session three is worth twenty ratings of "good". This is for two readers who rarely speak to each other: the person filling in the form, and the person holding two hundred completed forms wondering what to do next. ## How do you write good feedback for a course? Write it the way you would want to receive it: tied to something that actually happened, sorted by what it concerns, and specific enough to act on. 1. **Anchor each point to a moment.** "Session two ran forty minutes past the break" gives the trainer something to fix. "Timing could be better" gives them nothing. 2. **Separate content, delivery, pacing and materials.** A trainer can be excellent and the handouts still unusable, and a single overall score hides which it was. 3. **Say what the effect on you was.** "The slides moved on before I had copied the worked example, so I lost the rest of that section" locates the problem exactly. 4. **Offer the change you would make.** You do not have to be right. A concrete suggestion is easier to weigh than a complaint. 5. **Check it against the stated objectives.** If the course said you would leave able to plan a mixed-attainment sequence, say whether you can. [Objectives written with a real performance verb](/blog/how-to-write-learning-objectives-types-three-parts-and-worked-examples) make that test easy to apply. 6. **Write the praise as carefully as the criticism.** Most people invert this and produce three warm sentences plus one sharp one. The warm sentences are then discarded as politeness. Leave out comments about the trainer as a person rather than as a teacher, and leave out the word "fine", which is what people write once they have decided the form goes nowhere. ## What is an example of positive feedback for a course? A good example of positive feedback names what worked and why, so the trainer can repeat it on purpose. "Great session" cannot be repeated. "You stopped every fifteen minutes and made us explain the idea back" can. | Area | Vague version | Usable version | |---|---|---| | Content | "Really useful content" | "The retrieval practice section gave me three routines I can use with Year 9 on Monday." | | Delivery | "Great trainer" | "Stopping every fifteen minutes to have us explain the idea back caught two misunderstandings in my group." | | Pacing | "Good pace" | "Ninety minutes on one technique was right. Nothing was rushed and I never had to catch up." | | Materials | "Nice handouts" | "The one-page planner is the only CPD handout I have kept on my desk." | Every usable version identifies a mechanism. Praise that reports a mood tells the course designer the room was happy, which changes nothing about next term. The same test applies to criticism: "poorly organised" is a mood, while "the pre-reading arrived the night before, so half the room had not done it" is a mechanism, and mechanisms can be fixed. ## What should a course evaluation form ask? Ask only about things you are willing to change, and ask them one at a time. A question nobody will act on spends attention the useful questions needed. - **One idea per question.** "Was the content relevant and well presented?" gives you a score you cannot act on, because you will never know which half of it moved. - **Pair every rating with a free-text prompt.** Scales tell you where to look. Free text tells you what to do. "What makes you say that?" under each scale is enough. - **Ask a behaviour question.** "What will you do differently in the next two weeks?" is the most valuable line on any evaluation form. It gives an early transfer signal and makes the participant commit while they are still in the room. - **Ask what to cut.** People will list what to add all day and never volunteer what to remove. Ask directly: if this course had to be an hour shorter, which part would you drop? - **Keep the trainer's name off the scale questions** unless the form is part of an appraisal. Ratings attached to a person drift towards likeability. - **Ask twice.** A form at the end measures reaction while the biscuits are still out. Three lines sent six weeks later tell you whether anything survived contact with a timetable. However carefully you word it, an end-of-course form measures reaction and little else. Whether the training changed anything is [a separate measurement problem with its own methods](/blog/how-to-measure-training-effectiveness-methods-criteria-and-the-simplest-approach). ## How do you present training needs analysis results? Present training needs analysis (TNA) results as a short ranked list of gaps, each with its evidence and a proposed response. Nobody wants the raw data. They want to know what you are asking them to fund, and why this rather than that. A readout that survives a leadership meeting has six parts: 1. **The three or four gaps you want a decision on.** Not the fourteen you found. Rank them, and say what the ranking is based on. 2. **The evidence behind each gap.** Which sources agreed: survey, lesson observation, outcomes data, exit interviews. Say where they disagreed, because someone in the room has heard the counter-example. 3. **Need separated from want.** Requests cluster around topics people enjoy. Gaps cluster around things people avoid. The overlap is smaller than anyone hopes. 4. **The gaps training will not close.** Some arrive labelled as training needs and are really workload or timetabling problems. Saying so protects the budget you are actually asking for. 5. **A cost and a slot against each proposal.** A need with no INSET slot and no budget line is a wish with a footnote. 6. **The decision you want, written as a sentence someone can agree to.** Include the date you need it by. Keep the readout to a page and the data in an appendix. Collecting and analysing the evidence is a separate job, covered in [the five steps of a training needs analysis](/blog/training-needs-analysis-the-5-steps-and-how-to-turn-findings-into-a-pd-plan). ## How do you tell people what changed? Send a short "you said, we did" note within a fortnight, naming what you changed, what you decided not to change, and why. The second list carries more weight than the first. Feedback dries up when it vanishes. If the same three complaints return every year and the course runs unaltered, staff correctly conclude the form is a ritual and next year's responses come back as single words. One rejected request published with an honest reason does more for response rates than another reminder email. Each change then needs an owner and a date, which is where evaluation debriefs quietly fail. Everyone agrees session three needs rewriting. Nobody agrees who is rewriting it. For that step, [Projan](/landing/education) holds the debrief in Microsoft Teams and presses for the specifics people skip: which session changes, who is doing it, before which cohort. The agreed actions leave as tasks in the tools the team already uses. ## Frequently asked questions **What do you say when evaluating a course you did not enjoy?** Describe the gap between what was advertised and what happened, and keep it on the session rather than the person. Something like: the outcome promised was planning a mixed-attainment sequence, the day covered behaviour instead, so I left without the thing I came for. Then name the single change that would have made the biggest difference. **Should course feedback be anonymous?** Usually yes for the standard form. Named feedback from a new teacher about a senior colleague's session is not free feedback, whatever you tell people. Anonymity does cost you the ability to follow up on an interesting comment, so add an optional name field and one line explaining who reads the responses and what happens to them. **What is the difference between course feedback and course evaluation?** Feedback is what one participant says about their experience. Evaluation is the judgement the organisation makes about whether the course was worth running, using feedback as one input alongside attendance, assessment results and later observation. Feedback is evidence. Evaluation is a decision, and a decision made on one source of evidence is a guess. **How many questions should a course evaluation form have?** Enough to cover content, delivery, pacing, materials and intended action, which usually lands between six and ten. Past ten, completion rates drop and free-text boxes fill with single words. If you need more depth than that, interview a sample of six participants properly instead of asking everybody more questions. Feedback is only as useful as it is specific, and the form either invites specificity or prevents it. Name a mechanism when you write a comment, ask only about things you are prepared to change, and tell people afterwards what you did with their answers. ### How Long Should an Intervention Last in the Classroom? https://projan.ai/blog/how-long-should-a-classroom-intervention-last-session-length-duration-and-exampl/ Published: 2026-08-10 Most classroom interventions run 15 to 30 minutes a session, three to five times a week, for a cycle of six to twelve weeks before you judge them. Primary sessions sit at the short end, secondary at the long end. The total dose matters more than any single number, and the date you review it matters more than either. This is for class teachers, teaching assistants and SENCOs deciding how to timetable support and when to stop it. There is no official figure to quote. What follows are the ranges schools actually work to, and the things that push a particular intervention towards the top or the bottom of them. ## How long should an intervention last in the classroom? An intervention lasts as long as it takes to close the specific gap it was set up to close, which in practice means a fixed cycle with a review at the end and a decision to stop, continue or change. Six to twelve weeks is the usual cycle. Anything running with no end date is not an intervention, it is provision, and it should be described that way in the pupil's plan. Three numbers define the dose, and you have to set all three: - **Minutes per session.** How long the pupil is actually working, not how long the slot is. - **Sessions per week.** Usually the number that matters most. - **Weeks in the cycle.** Fixed at the start, with a review date in the diary. Four things move those numbers: 1. **The size of the gap.** A pupil six months behind on number bonds needs a different dose from one who has never decoded a word reliably. 2. **Age and attention.** Reception and Key Stage 1 pupils get short and frequent. Key Stage 3 and 4 pupils can hold a longer session, and often need one because the content is harder to break up. 3. **Group size.** One to one goes faster per minute than one to six. A group of six is a small class, and it needs the same planning a class needs. 4. **The timetable.** In most schools this is the honest answer. A 20 minute slot exists between assembly and maths, so the intervention is 20 minutes long. That is not a scandal, but be clear that the slot chose the dose rather than the assessment choosing it, because that changes what you can fairly expect at review. The SEND Code of Practice describes support as a four part cycle of assess, plan, do, review. The duration question is really a question about how long the "do" part runs before you are honest about the "review" part. Schools that still talk in waves of provision are describing the same idea: whole class teaching first, then targeted small group, then something more intensive and individual. ## How long should an intervention session last? Fifteen to twenty minutes is right for most primary interventions and twenty to forty for secondary, with the test being whether the pupil is working for nearly all of it. A session that is too long produces compliance rather than learning, and the pupil learns to survive the twenty minutes instead of doing the twenty minutes. | Intervention | Typical session | Usual frequency | |---|---|---| | Phonics catch-up (KS1) | 10 to 15 minutes | Daily | | Reading fluency or paired reading (KS2) | 15 to 20 minutes | 3 to 5 times a week | | Number fact fluency (KS1 to KS2) | 10 to 15 minutes | 4 to 5 times a week | | Pre-teaching vocabulary (any phase) | 10 to 15 minutes | Once or twice per new unit | | Small group literacy or numeracy (KS3) | 30 to 40 minutes | 2 to 3 times a week | | Speech and language programme | 10 to 20 minutes | As directed, often daily | | Behaviour or SEMH check-in | 5 to 10 minutes | Start and end of each day | Two practical corrections to those figures. First, count the walk. A 20 minute slot that includes fetching a pupil from class, settling them and walking them back is a 12 minute session. If the slot is the constraint, shorten the activity rather than letting the activity be cut off at the end, which is where the review and consolidation live. Second, frequency generally beats length. Splitting an hour a week into four fifteen minute sessions gives four chances at retrieval instead of one. If you have to choose between a longer session and a more frequent one, take the frequency for anything that is fundamentally about recall: phonics, number facts, spelling, key vocabulary. ## How many weeks should an intervention last? Six to twelve weeks, with a checkpoint at the halfway mark, is the range almost every school lands on. It is not arbitrary. It maps onto the half term, so it fits the way the year is already broken up, and it is long enough for a genuine change to show without being long enough for a failing intervention to eat a term. Set the review date on the same day you set the start date. If the start is the first Monday back and the cycle is eight weeks, the review is already in the diary before the first session runs. At the halfway point you are looking for direction of travel, not a result. Nothing moving at all after three or four weeks is information: usually the target was too broad, the pupil was absent more than the record suggests, or the programme is pitched at the wrong level. Interventions rarely get formally stopped. They fade, generally in the week the teaching assistant is covering a class, and nobody notices until someone asks in July what happened to it. A dated review is the only thing that reliably prevents that. Writing the intervention target in the same way you would write any [learning objective, with a condition and an observable behaviour](/blog/how-to-write-learning-objectives-types-three-parts-and-worked-examples), makes the review much faster. "Reads 40 words per minute on unseen Year 3 text" can be checked in two minutes. "More confident with reading" cannot be checked at all. ## What are 5 examples of interventions? These five cover most of what runs in a typical primary or secondary school, and each shows how the dose follows the gap. 1. **Daily phonics catch-up (Year 1 to Year 2).** Ten to fifteen minutes, every morning, one to one or in a pair, targeting the specific graphemes a pupil missed rather than restarting the programme. Run for a half term, then re-check against the same set of sounds. 2. **Repeated or paired reading for fluency (Key Stage 2).** Fifteen to twenty minutes, three to five times a week, with the pupil re-reading a short passage until it is fluent before moving on. Measure words per minute and errors on an unseen passage at the start and end of the cycle. 3. **Number fact fluency, often run as precision teaching (Key Stage 1 to 2).** Ten minutes daily on one narrow target, such as number bonds to 20 or the six times table, with a timed probe at the end of each session that produces a data point without any extra recording. 4. **Pre-teaching vocabulary before a new unit (any phase).** Ten to fifteen minutes, once or twice before the unit starts, teaching the six or eight words the unit depends on. This is the cheapest intervention in the building and the one most often skipped, because it needs the class teacher to look a fortnight ahead. It fits naturally into [the way a scheme of work is sequenced](/blog/how-to-write-a-scheme-of-work-a-step-by-step-process-for-teachers-and-curriculum). 5. **Check-in check-out for behaviour and engagement (Key Stage 2 to 4).** Five to ten minutes with the same adult at the start and end of every day, against two or three specific targets on a card the pupil carries. Runs for six to eight weeks, then reduces deliberately rather than stopping dead. None of these is a menu item to pick from. The assessment decides which one, and the size of the gap decides the dose. Choosing the intervention first and then working out what it might fix is the most common way a term of teaching assistant time gets spent on nothing in particular. ## When do you stop, extend or change an intervention? At the review there are three honest outcomes, and picking one is the whole point of having a review. - **Gap closed.** Stop, and put a date in for a light check in four to six weeks. Pupils who close a gap in a small group sometimes reopen it back in a class of thirty, and you want to know that in November rather than in May. - **Progress, but not closed.** Run one more cycle with the same method, and say at the outset that this is the second and last cycle before something changes. - **No real progress.** Change the method or reassess the need. Do not repeat the same cycle louder. Running a second identical cycle because nobody wanted to call the first one a failure is a common way to lose a term of teaching assistant hours. The decision falls apart when the exit criteria were never agreed at the start. The class teacher remembers the aim as "better with blends", the teaching assistant remembers "more confident", and the meeting ends with everyone agreeing to keep going because nobody can say what stopping would look like. If those two lines never get written down, [Projan](/landing/education) is one of the tools that will prompt for them, running the planning exchange as a set of questions in Microsoft Teams, asking what the pupil should be able to do by the review date and who is checking, then writing the answers out as dated actions. Keep the record small enough to survive the term: one measure taken the same way at start, midpoint and end, a tick for attendance, and one line a week from whoever delivers the sessions. That is enough to make a fifteen minute review meeting produce a real decision. ## Frequently asked questions **What is an example of an intervention?** A Year 1 pupil who failed the phonics screening check gets ten minutes of one to one phonics every morning before the whole class lesson, working on the specific sounds the check flagged, for one half term. That is a complete example: named gap, named pupil, fixed dose, fixed end date, and a re-check that decides what happens next. **Who should deliver classroom interventions, the teacher or a teaching assistant?** Usually a trained teaching assistant delivers, and the class teacher stays accountable for the plan and the outcome. That split only works if the TA has the programme, the target and the recording sheet before session one. Handing over a vague instruction to do some extra reading is how an intervention turns into supervised time. **Should interventions be delivered in class or by withdrawal?** In class where the pupil can still access the lesson, by withdrawal where the task needs quiet, repetition or a different starting point. Withdrawal costs the pupil whatever they miss, so check what that is before you fix the slot. Pulling a child out of the same subject twice a week for a term creates a second gap while closing the first. **Can an intervention run for a whole academic year?** Support can run all year, but call it what it is. A year long arrangement with no review points is provision, not an intervention, and it should sit in the pupil's SEN support plan with its own targets. If you genuinely need a year, break it into termly cycles so there are three moments where continuing is an actual decision. **How much progress data do you need to collect?** One measure, taken the same way, at the start, the midpoint and the end. Attendance for each session, marked as a tick. One line of comment a week, written by the person delivering. Anything more gets abandoned by week three, and a half finished record is worse at review time than a small complete one. Pick the dose from the gap, write the exit criteria before session one, and put the review date in the diary at the same time as the start date. An intervention that runs for six weeks and ends in a decision is worth more than one that runs all year and ends in a shrug. ### How to Present Findings to a Client (Structure and Examples) https://projan.ai/blog/how-to-present-findings-to-a-client-structure-examples-and-summary-docs/ Published: 2026-08-10 Present findings by leading with the answer, then the evidence that forces it, then the decision you want made. Tell the sponsor the most uncomfortable finding privately before the meeting. Keep your delivery to about twenty minutes of a sixty minute session and spend the rest on implications, objections and who does what next. This guide is about the room rather than the document: sequencing a readout, handling a sponsor who does not like what you found, and what to do when someone disputes your evidence with an audience watching. For the written artefact, see [how to structure a findings report and what to leave out](/blog/how-to-write-a-findings-report-structure-content-and-what-to-leave-out). ## What are findings in simple terms? A finding is something you observed to be true, written so that a reasonable person looking at the same evidence would reach the same conclusion. It is not an opinion, an instruction or a plan. "Invoice queries are resolved by three teams with no shared queue" is a finding. "You should consolidate invoice queries into one team" is a recommendation. The distinction matters most in the room, because the two attract different objections. Findings get challenged on accuracy. Recommendations get challenged on feasibility, cost and politics. If you blur them, every conversation about whether the fix is affordable becomes a conversation about whether you got the facts right. [Keeping findings and recommendations apart in one report](/blog/findings-vs-recommendations-how-to-write-both-in-one-report-without-blurring-the) is the written half of the same discipline. ## How do I present my findings? Present findings in the order a decision-maker needs them, which is the reverse of the order you produced them in. You worked from data to pattern to conclusion. They want the conclusion first and the data only if they doubt it. A workable running order for a sixty minute readout: 1. **The answer, in one sentence** (2 minutes). What you were asked, and what you found. If someone leaves after this, they should still know the outcome. 2. **The decision you are asking for** (2 minutes). Name it early so people listen with the right question in mind. 3. **Three to five findings, each with its evidence** (10 minutes). One claim per slide or paragraph, with the evidence underneath it, not in an appendix. 4. **What you looked at and what you did not** (3 minutes). Scope, period, sources, and the gap you know about. Volunteering the limitation is cheaper than having it found. 5. **Options and recommendations** (5 minutes). Each with a rough cost, an owner and a consequence of doing nothing. 6. **Discussion** (25 minutes). The largest block, deliberately. 7. **Agreed actions, owners and dates** (10 minutes). Written on the screen while people are still in the room. A readout is not a viva. Nobody is marking your method, and the twenty minutes you spend proving how thorough you were is twenty minutes not spent on what the client should now do. Method earns its place when it is contested, and only then. Two practical rules. Do not present a finding for the first time to a group; every person with a stake in it should have heard it from you individually first. And do not read the slides. If the pack can be understood without you, distribute it and use the hour for the argument. ## What are examples of research findings? A strong finding names the thing, quantifies it where possible, and stops before it starts blaming anyone. The examples below are invented, but the shapes are ones you will recognise. - **Weak:** "Communication between departments is poor." **Stronger:** "Sales commits delivery dates without checking capacity; in the twelve orders we traced, seven dates were set before operations saw the order." - **Weak:** "Staff find the system frustrating." **Stronger:** "All nine users we observed keep a personal spreadsheet alongside the system because they cannot see order status in it." - **Weak:** "There is a lack of governance." **Stronger:** "No forum has authority to stop a project once it is funded. Of the four projects that ran over, none was reviewed against its original business case." - **Weak:** "Onboarding could be improved." **Stronger:** "New joiners wait an average of eleven working days for system access, and their line managers are not told when it is granted." Notice that each stronger version carries its own evidence and can be argued with on the facts. That is the test. If a client cannot disagree with your finding except by disagreeing with your character, you have written a judgement, not a finding. Keep the number small. Five findings get discussed, fifteen get skimmed, and the two that mattered get lost among the thirteen that did not. ## What do you do when the sponsor does not like the finding? Tell them in private first, several days before the readout, and give them a role in the response rather than only a share of the blame. The sponsor should hear the worst of it from you alone, not from you in front of their peers. That pre-brief has a specific agenda. Say the finding plainly. Ask whether anything in it is factually wrong, and mean it. Ask what they think the room will say. Then agree how the finding will be framed: not whether it appears, but which decision it leads to. Sponsors will accept an uncomfortable fact far more readily when they are already holding the answer to it. If a sponsor asks you to remove an accurate finding, the position is straightforward and worth rehearsing before you need it. You will not delete it. You will state it in the least dramatic language that remains true, add their response next to it, and let the reader form a view. If they insist, ask for the request in writing. That request rarely arrives, and the asking usually ends the conversation. Watch for the softer version of the same pressure: a request to move a finding into the appendix, to describe it as an area for further exploration, or to attribute it to "some stakeholders" when it came from eleven of twelve interviews. Each of those is deletion with better manners. One more thing that reliably lowers the temperature. Separate the finding from the person who owns the process it describes. "The approval route has four hand-offs and no single owner" is a fact about a process. "Finance has not managed this well" is a fact about a colleague sitting three seats away, and it will cost you the rest of the meeting. ## What if someone disputes your evidence in the room? Take the challenge literally and answer it with the specific number, then move to the consequence. Most objections in a readout are not really about the evidence. They are about what the evidence implies for the person raising it, and arguing method with them for ten minutes gets you nowhere useful. | What they say | What it usually means | What to do | |---|---|---| | "Your sample is too small" | The result is inconvenient | Give the actual n, say what it does and does not support, and ask what sample would convince them | | "That data is out of date" | They have a newer version, or hope they do | Name the period and the source, and ask them to send the newer figures by a stated date | | "That is not how it works in our region" | Genuine local variation, often true | Accept it as a scope limit on the spot, and record it as a caveat rather than defending the general point | | "We already knew that" | The finding is uncomfortable but correct | Agree, then ask why it is still true, which is the more interesting question | | "Who told you that?" | An attempt to identify a source | Never say. Restate the confidentiality terms you agreed at the start | Three habits make this manageable. Bring the underlying numbers with you, even if they never leave your bag, because "I can show you the twelve orders" ends most disputes without needing to show anything. Timebox anything unresolvable: "let me check that and come back to you by Thursday" is a complete answer, and unfinished arguments in front of a steering group cost more than a two day delay. And when you are genuinely wrong, say so immediately and without decoration. A consultant who concedes one point cleanly is believed on the other four. If a challenge survives all that and you still hold your position, put the question back to the room. "If that figure were right, would it change what we do next?" Often the answer is no, and everyone can see it. ## What is the best way to show client results? Show results against the baseline you agreed before the work started, using the client's own measure rather than one you introduced afterwards. If no baseline was captured at kickoff, say so and describe the change qualitatively rather than inventing a percentage. Be careful with attribution. You almost never own the outcome alone, and a claim the client cannot repeat internally without embarrassment is worse than a modest one they can. Three levels of claim, in descending order of how well they survive scrutiny: - **Output**: what was produced and handed over. Always defensible, rarely interesting on its own. - **Adoption**: whether the thing is in use, by whom, and how often. Usually measurable within the engagement. - **Impact**: the business change. Strongest claim, hardest to attribute, and the one to make jointly with the client rather than about them. For the readout itself, the useful move is to show the measure and the mechanism together. "Exception handling dropped from four teams to one, and the queue is now visible to the team that owns it" is checkable. "Efficiency improved significantly" invites the one question you cannot answer. ## What is a summary of findings document and what goes in one? A summary of findings is a one to two page document stating what you found and what should happen, written for people who will not read the full report. It is the artefact most likely to be forwarded, so it should survive being read alone, on a phone, by someone who was not in the room. A workable outline: 1. **Headline** (one sentence): the answer to the question you were asked. 2. **Findings** (three to five bullets): each a single claim with one line of supporting evidence. 3. **Implications** (short paragraph): what follows if nothing changes. 4. **Recommended next steps** (three at most): each with an owner and a timeframe. 5. **Decision requested**: the specific thing you need from the reader. Leave out the method, the acknowledgements, the caveats about further research and the charts that need explaining. Those belong in the report. [Writing a summary of findings a client will actually read](/blog/how-to-write-a-summary-of-findings-your-client-will-actually-read) goes into the drafting in detail. The half hour after a readout is where agreed actions quietly evaporate, because the discussion produced them and nobody wrote them down with a name attached. Some teams hand that step to software: Projan, for instance, takes the summary document in as context, asks in Slack or Microsoft Teams who owns each agreed action and by when, and writes the answers out to Confluence or Asana. Whatever the method, the rule holds. Nobody should leave the room without knowing which action has their name on it. ## Frequently asked questions **How do you present research findings?** Same running order as any readout, with one addition: say what your method can and cannot support before anyone asks. State the sample, the period covered and the obvious gap. For qualitative work, quote participants rather than paraphrasing them, and give the count behind every pattern you claim, even when the count is four. **What is a summary of findings example?** One page for an operations review might read: headline sentence, then four findings, each a single bold claim with two lines of evidence beneath it, then three options with rough cost and owner, then the decision requested. No method section, no appendices, no charts wider than the page. If it takes longer than four minutes to read, cut a finding. **How long should a findings presentation be?** Book sixty minutes and plan to talk for twenty. The value of a readout sits in the discussion, not the delivery, and a consultant still presenting at minute forty has lost the room's attention and the chance to test the recommendation. If you cannot cover it in twenty minutes, you have too many findings. **Should you send the deck before the meeting?** Send the headline and the findings, not the full pack. A sponsor who has read the answer arrives ready to discuss it, and the awkward reactions happen in private beforehand. Holding everything back to preserve a reveal only guarantees the first ten minutes are spent reading in silence. **What if the client asks you to change the report after the readout?** Distinguish between accuracy and comfort. Correct anything factually wrong immediately and say so openly. If the request is to soften a finding that is accurate, offer to add the client's response alongside it rather than delete it, and put the ask in writing so the decision to omit it belongs to the person making it. A readout succeeds when the client argues about what to do rather than about what you found. Get the uncomfortable finding to the sponsor early, keep your delivery short enough that the discussion has room to happen, and leave with actions that have names on them. ### What Is the Purpose of Running a Premortem? https://projan.ai/blog/how-to-run-a-premortem-surfacing-project-failure-before-it-happens/ Published: 2026-08-10 The purpose of a premortem is to surface the reasons a project will fail while there is still time to act on them. The team assumes the project has already failed, then writes down why. Stating failure as fact rather than possibility makes people specific about problems they would otherwise soften. This is for engineering leads and project owners deciding whether the exercise justifies ninety minutes of the team's time. It covers where the technique came from, how to run one, who to invite, when in the project to hold it, and what separates the output from a postmortem. ## What is the purpose of running a premortem? A premortem exists to convert vague unease into named, specific risks that someone can act on before the plan hardens. It does three things a normal risk discussion does badly. It changes what people can retrieve. Asked what might go wrong, engineers produce categories: integration risk, unclear requirements, dependency on another team. Asked why the project failed, the same engineers produce events: the payments team never got the schema change in time, the migration script was tested on a copy that had no production nulls in it. Only the second kind can be assigned to anyone. It lowers the social cost of dissent. In a normal planning meeting, raising a serious objection is a bet against the plan and, by implication, against the person who wrote it. In a premortem, pessimism is the assignment. Nobody is being difficult; everyone is answering the question they were given. It produces mitigations while they are still cheap. A risk identified in the design week costs a conversation. The same risk identified in cutover week costs a weekend. A premortem is not a risk workshop with better branding. The difference is grammatical. A risk workshop asks what could go wrong; a premortem asserts that it did, and asks the team to explain themselves. What it does not do is tell you whether to proceed. It assumes the project is going ahead and asks how it dies. That constraint is the point, and it is also why the exercise occasionally produces an answer the sponsor did not order. ## What is the Gary Klein premortem technique? The premortem was described by Gary Klein, a research psychologist who studies how experts make decisions under pressure, in a 2007 Harvard Business Review article. The mechanism behind it is prospective hindsight: research on judgement found that people asked to explain an event that has already happened generate more reasons, and more concrete ones, than people asked to predict what might happen. Klein's contribution was to turn that finding into a meeting. A working version of the session: 1. **Brief the plan.** Ten minutes. Everyone must be attacking the same version of the plan, including the dates and the assumptions underneath them. Circulate the document beforehand and assume half the room skimmed it. 2. **State the failure.** One minute, out loud, with a date. "It is the fourteenth of March. We cut over last weekend, we rolled back on Monday morning, and the migration is being replanned from scratch." Vague failure produces vague reasons, so pick a specific form of disaster and a specific date. 3. **Write in silence.** Ten minutes. Everyone lists reasons independently, on their own, before anyone speaks. This step is not a formality. Skip it and the first confident voice sets the range of acceptable answers for the rest of the room. 4. **Read round the room.** Twenty to thirty minutes. Each person reads out one reason, going round until the lists are exhausted. One at a time, no debating, no ranking yet. The facilitator writes them down in the words the author used, not a tidied paraphrase. 5. **Cluster and choose.** Ten minutes. Group duplicates, then have the room pick the handful that are both plausible and expensive. Ten to fifteen distinct failure modes is a normal harvest; three or four are worth immediate work. 6. **Assign, before anyone leaves.** Each chosen failure mode gets a named person and one next action. Doing this in the room takes ten minutes. Doing it afterwards takes three weeks and usually does not happen. Klein's framing is that the exercise legitimises doubt. That framing matters more than the process detail. Run all six steps with a room that believes the decision is already made and you will get a polite list of things that are somebody else's fault. ## When should a premortem be held? Hold a premortem once there is a plan concrete enough to attack, and before the commitments in it become expensive to unwind. Run it late enough that there is something real to shoot at, early enough that the plan can still change in response. For engineering work, the usable moments are fairly narrow: - After the technical design or RFC is drafted, before the estimate goes to stakeholders as a date - Before a migration or cutover plan is signed off, while the rollback path is still being written - At the start of a rewrite, when the scope is still a proposal rather than a headcount plan - Before a launch that involves teams outside your own, once their dependencies are known The common mistake is holding it at kickoff, alongside everything else. At kickoff there is usually a goal and not yet a plan, so the exercise produces generic anxiety. Give it a slot a week or two after [the kickoff has established what the project actually is](/blog/how-to-run-a-project-kick-off-meeting-that-sets-real-alignment), when there is a design to argue with. There is also a point after which it stops being useful. Once the dates are external commitments and the team has been assembled around them, a premortem becomes a documentation exercise in which everyone lists the reasons they will later cite. That is not worthless, but do not confuse it with a chance to change anything. ## Who should be involved in a premortem? Invite the people who will have to make the plan work, plus at least one person who has reason to doubt it. Seniority is the wrong selection criterion; proximity to the failure is the right one. A good room for an engineering premortem: - **The people doing the build**, not only the leads. The engineer who will write the migration script knows things about the data that the design doc does not record. - **The plan's author**, present and answering questions, but not facilitating. Authors defend. Facilitators cannot. - **Downstream teams.** On-call, support, QA and data are the people who inherit the consequences of a bad launch, and they are usually the last to be asked. - **One informed skeptic.** Someone who argued against this approach and lost. They arrive with a list already written. - **One outsider.** A person with no history on the project asks the questions everybody else stopped asking eight months ago. Cap the room at around ten. Beyond that the round robin runs long and people stop contributing. If the project spans more organisations than that, run two sessions and merge the outputs rather than staging a large meeting in which nobody speaks twice. One practical note on hierarchy. The silent writing step exists mostly to protect the room from its most senior member. If the principal engineer speaks first and calls the schema migration the main risk, you will get six variations on schema migration and nothing about the third-party rate limit that will actually take you down. ## Turning premortem output into risks someone owns Convert every surviving failure mode into a risk with an owner, a trigger and a next action, then file it where the team already looks. A premortem that ends in a shared document nobody owns is a well-facilitated complaint. Each failure mode gets one of three dispositions, and the disposition is recorded: - **Mitigate.** There is work to do, so it becomes a ticket in the same backlog as everything else, with the failure mode written in the description. Tickets created out of a premortem and parked in a separate document do not get done. - **Monitor.** You are not acting yet, so name the signal that means you should, and the person watching for it. "If the vendor sandbox is still unavailable by the twentieth, we descope the integration" is a monitor. "Keep an eye on the vendor" is not. - **Accept.** You have decided to carry the risk. Write down that you accepted it, who accepted it, and why. This is the entry that matters most six months later, and it is the one teams skip. Phrase the entries as events with causes and consequences rather than as topics, and keep them somewhere with a review rhythm attached, whether that is [a RAID log or a risk register you actually reopen](/blog/risk-registers-and-raid-logs-how-to-build-one-and-actually-keep-it-alive) or the project's own board. One option for the write-up step, if the session already runs in Slack or Microsoft Teams, is [Projan](/landing/engineering): it presses each proposed mitigation for a named owner and a date before it exports the surviving ones to Jira or Linear as tickets. Set a date to reread the list. Most premortem output has a shelf life of about a fortnight in the team's memory and considerably longer in reality. ## How is a premortem different from a postmortem? A premortem imagines a failure that has not happened to prevent it; a postmortem examines one that has, to stop it recurring. Same muscle, opposite direction, and the input quality is completely different. | | Premortem | Postmortem | |---|---|---| | **When** | Before the work, once a plan exists | After an incident or a delivery | | **The failure** | Hypothetical, asserted as fact for the exercise | Real, with evidence | | **Main input** | The team's experience and instinct | Logs, timelines, the incident record | | **Facilitated by** | Anyone except the plan's author | Anyone not on the responding team | | **Output** | Risks with owners and mitigations | Contributing factors and action items | | **Fails when** | Held too late to change anything | Held too late to remember anything | | **Biggest threat to it** | Optimism about the plan | Blame directed at people | The two are not substitutes and the postmortem is not the more serious of the pair. A postmortem has better data; a premortem has better timing. Teams that run [blameless postmortems](/blog/postmortems-in-engineering-what-they-are-and-how-to-keep-them-blameless) already have most of what a premortem needs, because the cultural work of separating a bad outcome from a bad person is the same in both directions. One thing does transfer cleanly. Recurring themes in your postmortems make excellent seed material for the next premortem, particularly the ones about coordination between teams, which almost never appear in anyone's independent list. ## Where premortems go wrong Five failure modes account for most of the premortems that produce nothing usable. 1. **Held after the dates were promised.** Nothing can change, so the room performs the exercise instead of doing it. 2. **Facilitated by the person who wrote the plan.** Every reason gets answered rather than recorded, and the room learns to stop offering them. 3. **Discussion before silent writing.** The list converges on the first two ideas mentioned. You will not notice this happening. 4. **Reasons written as categories.** "Poor communication" cannot be assigned or mitigated. "The mobile team finds out about the API change from the release notes" can be, by one named person, this week. 5. **No owner attached in the room.** The output goes into a document that is opened once more, at the postmortem, by someone looking for evidence. None of these are cultural problems, which makes premortems unusually easy to improve. Get the timing right, hand facilitation to someone with no stake in the plan, and refuse to end the meeting without names against the top four items. ## Frequently asked questions **When should you conduct a premortem, and is one enough?** One is enough for a project measured in weeks. Anything running longer than a quarter deserves a second session at each phase boundary, because the failure modes change once code exists. A rewrite has different risks at design time and at cutover time. Repeat the exercise when the plan changes materially, not on a calendar. **How long should a premortem take?** Sixty to ninety minutes for a substantial project, including the plan briefing at the start. The silent writing takes ten minutes, the round robin twenty to thirty depending on group size, and clustering the rest. If you cannot spare ninety minutes, run a shorter version on one phase rather than a rushed version on everything. **Can a premortem be run asynchronously?** The writing step works well asynchronously, since it is silent and individual anyway. Post the plan and the failure statement, give people two days to submit reasons privately, then meet to cluster and assign. The part that does not survive going async is the discussion, where one person's reason reminds someone else of a worse one. **What if the premortem suggests the project should not go ahead?** That is a legitimate result, though a rare one, and it needs escalating rather than absorbing. Write up the failure modes the team could not mitigate and send them to whoever authorised the work, with the specific conditions that would make the plan viable. A premortem does not have authority to cancel anything. It produces evidence for the person who does. A premortem is cheap, and its cost is almost entirely in the discipline of running it at a point where the answers can still change the plan. Ask for reasons the project failed rather than risks it faces, write them down in the words people used, and leave the room with four of them owned. ### How to Write a Brand Positioning Document https://projan.ai/blog/how-to-write-a-brand-positioning-document-and-how-it-differs-from-a-positioning/ Published: 2026-08-10 Write a brand positioning document by settling six things in order: the category you compete in, the segment you are for, the alternatives that segment actually considers, your one meaningful difference, the evidence behind it, and the sentence that compresses all of it. The positioning statement is the output of that work, not a substitute for it. This is for marketers who have been asked to "write the positioning" and are not sure whether they are being asked for a page or a paragraph. It covers what the document contains, how it relates to the statement, the order to draft it in, and why most of these documents stop being opened within a quarter. ## What is a brand positioning document? A brand positioning document is the internal reference that records what your brand claims, for whom, against which alternatives, and on what evidence. It is not customer-facing and it is not copy. It is the argument behind the copy, written down so that six people writing in six places make the same claims. A usable one contains: - **Market and category.** The frame of reference you want to be judged in. A payroll tool positioned against spreadsheets is a different business from the same tool positioned against enterprise HR suites. - **Target segments.** Who it is for, in enough detail to exclude people. A segment that excludes nobody is a demographic. - **Competitive alternatives.** What the segment does today instead of buying from you, including doing nothing. - **Differentiators.** The things you do that the listed alternatives genuinely do not. - **Reasons to believe.** The evidence for each differentiator: architecture, certifications, published pricing, a capability a competitor cannot copy this year. - **Value by segment.** What the difference is worth to that buyer, in their terms rather than yours. - **The positioning statement.** One or two sentences carrying the whole thing. - **What we are not.** The claims you are deliberately declining to make. This is the first section cut and the most useful one to keep. Tone of voice, messaging pillars and campaign lines do not belong here. They belong in the messaging framework, and [the boundary between positioning and messaging](/blog/brand-positioning-vs-messaging-framework-where-one-ends-and-the-other-begins) is worth settling before you start, because teams routinely write half a messaging framework inside a positioning document and then wonder why it has reached forty pages. ## How is a brand positioning document different from a positioning statement? The document holds the decisions and the evidence; the statement is the one line those decisions compress into. You cannot write a credible statement without the document, and the document is worthless if it never produces a statement anyone can repeat. | | Brand positioning document | Positioning statement | |---|---|---| | **Length** | Five to fifteen pages | One or two sentences | | **What it answers** | Why we chose this position | What the position is | | **Read by** | Marketing, sales, product, leadership, agencies | Anyone writing a page, a pitch or a brief | | **Contains evidence** | Yes, that is most of it | No | | **How often it changes** | Reviewed yearly or when the market moves | Rarely, and never quietly | | **Typical failure** | Written once, never opened again | Written before the thinking was done | The practical test: if someone challenges the statement in a meeting, the document is what you open. If it contains nothing that would settle the argument, you have written a summary of your own opinion in two formats. ## How to write a brand positioning document Draft it in this order, because each step constrains the next and doing them out of sequence produces a document that argues with itself. 1. **Decide what the document is for and who approves it.** A positioning document written to unblock the website is a different length from one written to reposition the company. Name the approver before you start writing, not after. 2. **Collect evidence before opinions.** Win and loss notes, recorded sales calls, support themes, churn reasons, the phrases customers use unprompted. Opinions gathered first tend to survive contact with evidence gathered second. 3. **Define the category.** State the frame of reference in plain words, and state what you are choosing not to be compared with. Category choice moves more than any other line in the document. 4. **Pick one primary segment and name who it excludes.** Secondary segments can follow later in the document. If the primary segment is "growing businesses", you have not picked one. 5. **Write the alternatives as the customer would describe them.** This is the section people fudge. Write down what the buyer actually does today, including nothing, including the spreadsheet, including the incumbent they complain about and keep renewing. 6. **Choose at most two differentiators.** A document listing five is a feature list with better formatting. If a competitor would happily claim your differentiator in their own deck, it is not one. 7. **Attach a reason to believe to each.** No evidence means one of two things: delete the differentiator, or build the proof and come back. Both are acceptable. Keeping it and hoping is not. 8. **Pressure-test it with the people who use it.** Read the draft to a salesperson mid-quarter and a support lead. If either of them says "customers do not talk like that", you have found the problem while it is still cheap. The recurring failure is not the framework. It is one marketer drafting the whole thing alone, then presenting it as finished to the two functions whose agreement it depends on. Getting sales, product and leadership into the same conversation is the hard part; if that meeting keeps slipping, [Projan](/landing/creative-strategy) can run the questioning in Slack instead, pressing on which buyers the segment excludes and what evidence sits behind each claimed difference, then leaving a written draft rather than a page of notes. Whatever gets you there, the rule holds: a positioning document is an agreement, and agreements cannot be drafted by one person. ## How to build a brand positioning statement Build the statement by extracting five things from the finished document and refusing to include anything else. It is a compression exercise, not a writing exercise, and it should take an hour rather than a workshop. 1. **Take one segment.** The primary one. A statement covering three segments describes none of them. 2. **Take the alternative you actually displace.** Not the market leader you would like to be compared with, the thing the money currently goes to. 3. **Take the single strongest differentiator**, with its reason to believe attached. 4. **Write it as one sentence in the words your customers use.** If a phrase would not survive being said aloud on a sales call, cut it. 5. **Trace every clause back.** Each part of the statement should point at a section of the document. Any clause with nothing behind it is aspiration, and aspiration is what makes a statement unusable in the field. There is a standard four-part formula for the sentence itself, along with positioning maps for checking where you sit against everyone else. [The formula, its four parts and how to use a positioning map](/blog/how-to-write-a-positioning-statement-formula-four-parts-and-positioning-maps) are covered separately. What matters here is the sequence: the statement comes last, and a statement written before the document is a guess in a nice format. ## Why positioning documents stop being used Most of them die in the same four ways. - **Written for the approval meeting, not for the writers.** A document optimised to survive a leadership review is abstract enough to be unarguable, which makes it useless to whoever has to write a landing page on Thursday. - **Uncontested differentiators.** "Trusted", "innovative" and "customer-focused" are not positions. If no competitor would be embarrassed to claim it, delete it. - **No owner, no date, no version.** Three conflicting copies circulate and everyone quotes the one that supports their argument. - **Positioning changed in practice and the document did not.** Sales started leading with a different pain nine months ago and it worked. Nobody told the document. The fix is unglamorous. Put the document where the work happens, in the same workspace as the briefs and campaign plans rather than in a folder of strategy PDFs. Date it, name an owner, and review it when the market gives you a reason rather than when the calendar does. Positioning is ultimately decided by what customers repeat back to you, so the document's job is to keep the team's claims honest and consistent between those moments. ## Frequently asked questions **How do you create a brand positioning document?** Start with what you already have. Read the last twenty sales conversations, the reasons you lost deals, and the words customers use in support tickets. Draft the category, segment and alternatives sections from that, then interview six customers to check whether you were right. Formal research sharpens a positioning document. It rarely creates one from nothing. **How long should a brand positioning document be?** Long enough to hold the evidence and short enough that a new copywriter reads all of it. Five to fifteen pages is normal, and most of the length should be proof rather than prose. If it runs past twenty, check whether messaging pillars, tone of voice or campaign ideas have crept in. They belong elsewhere. **Who signs off on a brand positioning document?** One accountable owner, usually the most senior marketing leader, with explicit agreement from sales and product before it is circulated. Sign-off means those three functions will use the same words in front of customers. If the sales director has not read it, the document has not been approved. It has been published. **How often should a brand positioning document be updated?** Review it when something moves, not on a schedule. A new competitor winning your deals, a pricing change, a new primary segment or a product that now solves a different problem are all triggers. Absent those, an annual read-through is enough. Date every version and record what changed, because positioning arguments repeat every eighteen months. **Do you need a separate positioning document for each product?** Not for each product. You need one brand positioning document and a shorter product positioning section underneath it for anything sold separately to a different buyer. Two products bought by the same person on the same budget can share one. The test is whether the competitive alternatives differ, because if they do the positioning must. A brand positioning document earns its length in evidence, not in prose. Draft it with the people who will have to defend it in front of customers, keep the differentiator list short enough that a competitor would object to it, and let the statement fall out at the end. Once it exists, it becomes the input to everything downstream, starting with [the go-to-market plan](/blog/how-to-write-a-go-to-market-plan-components-structure-and-how-it-differs-from-a). ### How to Write a Data Migration Plan: Phases, Types, and Cutover Strategy https://projan.ai/blog/how-to-write-a-data-migration-plan-phases-types-and-cutover-strategy/ Published: 2026-08-10 Write a data migration plan by settling four things before anything else: what data actually moves, how each field maps to the target, how you will prove the move worked, and what triggers a rollback. The phases, the schedule and the cutover runbook all follow from those four answers rather than the other way round. This is about the data specifically, not the wider system move. If you are still choosing between rehosting, re-platforming and rebuilding the application around it, that decision sits upstream and is covered in [how to plan a system migration](/blog/how-to-plan-a-system-migration-stages-strategies-and-a-plan-template). What follows assumes the target exists and the question is how to get the records into it without losing any. ## How do you write a data migration plan? Write it backwards, starting from the check that will tell you the migration succeeded, because that check determines almost everything upstream of it. If you cannot describe the passing state in numbers, you have no basis for deciding whether to go live or roll back, and cutover night will be decided by whoever sounds most confident at 2am. A workable plan contains nine things: - **Scope.** Which sources, which entities, which date ranges, and an explicit list of what is not moving. - **Owners.** A named person per source system, per target, and per validation check. Not team names. - **Source profile.** Row volumes, quality findings, known bad data, and what happens to each category of it. - **Mapping.** Field by field, with transformation rules, defaults and the fields with no target. - **Environments and dry runs.** Where you rehearse, on what data, and how many times. - **Cutover sequence.** Freeze, extract, transform, load, verify, release, with times against each step. - **Validation and reconciliation.** The specific checks, the thresholds that count as passing, and who reads the results. - **Rollback.** The trigger conditions, the person authorised to call it, and the time after which it stops being available. - **Decommission.** When the source is switched off, who keeps a copy, and for how long. The section that gets left out is almost always the rollback trigger. A plan that does not say who is allowed to stop the migration is a schedule, not a plan. Keep the mapping in a separate sheet rather than inside the document. It changes daily during design and monthly forever afterwards, and a plan that has to be reissued every time a column is renamed stops being read. ## What are the 6 phases of migration? The six phases below are the ones that appear in nearly every published methodology, though the number itself is a convention rather than a standard. Vendors publish four, five, six and seven phase versions and they disagree about where the boundaries fall. Treat the sequence as reliable and the count as arbitrary. 1. **Discovery and scoping.** Find every source, including the spreadsheet the finance team has been maintaining since the last migration. Establish volumes, owners, dependencies and which downstream systems read from the source. 2. **Profiling and assessment.** Measure the data rather than describe it. Null rates, distinct values, orphaned foreign keys, duplicates, date fields holding free text. This is where you find out the plan you wrote is fiction. 3. **Design and mapping.** Agree the target model and map every field to it. Decide the transformation rules, the defaults for missing values, and what happens to source fields with nowhere to go. 4. **Build and rehearse.** Write the extract and transform code, then run it against a production-scale copy. Time the load. Record how long the reconciliation takes, because that time sits inside your cutover window too. 5. **Cutover.** Freeze writes on the source, run the migration for real, reconcile, and either release the new system or roll back. The plan should already say which. 6. **Validation and decommission.** Run the business-level checks over the first days of live use, keep the source readable but frozen, and retire it only once someone with a stake in the data has signed off. Phases two and three are where the schedule is actually decided, and they are the ones most often compressed to make a fixed go-live date work. Compressing them does not save time. It moves the work into phase five, where it costs considerably more. ## Profiling and mapping: where the plan meets the data Profiling is a measurement exercise, and the output is a list of exceptions with a decision against each one. Run counts and distributions on every column you intend to move: null rate, distinct count, min and max, length outliers, and format violations against whatever rule the target enforces. Compare row counts between related tables to find orphans. Every anomaly needs a named disposition before mapping starts, because a mapping rule written over unprofiled data is a guess, and downstream it gets read as a fact. The common findings are dull and expensive. Free-text values in fields the target treats as enumerations. Two customer records for the same organisation with different identifiers. Dates stored as strings in three formats because three applications wrote to the column over ten years. Mapping then produces four categories, and it is worth labelling them explicitly: - **Direct.** Source field to target field, no change. - **Transformed.** A rule applies. Write the rule as code or pseudocode, not as a sentence. - **Derived.** The target field has no source and must be computed or defaulted. State the default and who chose it. - **Dropped.** The source field does not move. This is the category that generates arguments later, so record who agreed to it. Field-level decisions get made in passing and forgotten within a fortnight. Keep them somewhere durable rather than in a thread, which is the same argument as for [keeping a decision log](/blog/decision-logs-for-engineering-teams-what-to-record-and-how-to-keep-one-current) on any long-running piece of engineering work. ## What are the different types of data migration? Five categories are commonly used, and the label only matters because each one changes a different part of the plan. - **Storage migration.** Data moves between storage systems with the format unchanged. The risk is throughput and integrity, not meaning. Checksums do most of the validation work. - **Database migration.** Data moves between engines or major versions. Schema and type differences dominate, along with anything that relied on engine-specific behaviour such as collation or default precision. - **Application migration.** The application changes, so the data model changes with it. This is the hardest type, because two systems rarely agree on what an entity is. One system's "account" is another's "organisation plus billing contact". - **Cloud migration.** Data moves to or between cloud platforms. Transfer time, egress cost and the security boundary become planning constraints in a way they were not on-premises. - **Business process migration.** The business changed, through a merger, restructure or regulatory split, and the data has to follow. The mapping questions are organisational rather than technical, and the answers usually need someone senior. Most real migrations are two or three of these at once. A move from a self-hosted CRM to a hosted one is an application migration and a cloud migration together, and the plan has to answer both sets of questions. ## What are the different types of migration methods? Three cutover methods cover almost all migrations: big bang, phased (also called trickle or incremental), and parallel run. They are decisions about time and reversibility, and they are separate from the rehosting and re-platforming choices that apply to the application layer. | | Big bang | Phased (trickle) | Parallel run | |---|---|---|---| | **How it runs** | Everything moves in one window, usually a weekend | Data moves in slices by entity, region or date range | Both systems run live on the same data until you switch | | **Downtime** | A defined freeze, hours to days | Little or none, but a long split state | None, paid for with dual writes | | **Rollback** | Clean while the freeze holds, difficult afterwards | Per slice, so one bad slice does not sink the release | Simplest available: keep using the old system | | **Build complexity** | Lowest | Needs sync or change data capture between old and new throughout | Highest: every write lands twice and the two must agree | | **Suits** | Smaller datasets, few consumers, a business that tolerates a weekend offline | Large datasets, many downstream consumers, regulated cutovers | Finance, payroll, clinical data, anything where a wrong number is unrecoverable | | **Main failure mode** | The window overruns and rollback is no longer available | The interim state quietly becomes permanent | Divergence nobody reconciles until a customer finds it | Phased migrations depend on keeping the old and new systems consistent while both are live, usually through change data capture reading the source's transaction log. Budget for that plumbing as a deliverable in its own right. Teams often choose phased because it sounds lower risk, then discover the sync layer is the largest piece of engineering in the project. Parallel running is the strongest control available and the least popular, because it doubles the write path and requires someone to compare the two outputs regularly. If nobody is assigned to read the comparison, a parallel run is just an expensive big bang. ## Decide the rollback criteria before cutover, not during it Rollback criteria are the numeric conditions under which you abandon the migration and restore service on the old system, and they have to be written down while everyone is calm. On the night, the people in the room will have spent months on the work and will be strongly motivated to push on. That is exactly when a pre-agreed threshold earns its place. Write four things: 1. **The triggers.** Specific and measurable. "Reconciliation variance above 0.1% on any monetary total", "load not complete by 05:00", "any orphaned record in the order tables", "error rate above the agreed threshold in the first hour of live traffic". 2. **The decision owner.** One named person with the authority to call it, plus a named deputy. Not a committee, and not "the migration team". 3. **The expiry.** The point of no return, which is usually the first user write to the new system. After that you are not rolling back, you are forward-fixing, and the plan needs a separate section for that. 4. **The rollback procedure itself.** Timed and rehearsed, in the [cutover runbook](/blog/how-to-write-a-runbook-structure-steps-and-what-to-include) alongside the forward steps. A rollback that has never been executed is a hope. Those answers come from people who rarely sit in the same meeting: the data owner, whoever is on call, and whoever answers for the downstream reporting. [Projan](/landing/engineering) will work through the open questions with that group in Slack, record each answer with the owner's name attached, and push the resulting tasks into Jira or Linear. The plan should not reach cutover with the rollback owner still unnamed. ## How do you prove the migration worked? Reconciliation, in layers, with the results written down and read by someone. Row counts matching is the weakest evidence available and it is where most teams stop. Run these in order, cheapest first: - **Row counts** per table and per partition. Fast, and catches only gross failures. - **Control totals.** Sums of every monetary and quantity column, compared source to target. These catch truncation, type coercion and duplicated loads. - **Column profiles.** Null rate and distinct count per column, compared against the profiling baseline you took in phase two. A column that was 2% null in the source and is 40% null in the target has a broken mapping. - **Referential integrity.** Orphan checks across every relationship the target enforces and every one it does not. - **Record-level sampling.** A stratified sample reconciled field by field, including the awkward records you found during profiling. Someone who knows the domain should read a handful in full. - **Business-level checks.** Reproduce a report both systems can generate, such as last month's revenue by region or headcount by department, and compare the outputs. This is the check the business trusts, and it is the one that finds mapping errors the technical checks pass. Variances are normal. What matters is that each one has an explanation and a disposition before sign-off, rather than a note saying it will be looked into. Keep the reconciliation output as an artefact with the plan. When someone questions a number six months later, the alternative is re-running an argument nobody can win. ## Frequently asked questions **How to write a data migration plan?** Keep it short and specific. Roughly a page per phase, with named owners rather than team names, a mapping sheet held separately because it changes daily, and a version number on the front. Review it with the people who operate the source and target systems, not only with the people funding the project. **Do you have to migrate all the historical data?** No, and deciding this early removes more work than any other scope call. Split records into migrate, archive and drop. Archive means a readable export plus a documented way to query it. Anything you drop needs a written decision with a name against it, because someone will eventually ask where the 2019 orders went. **How many dry runs should you do before cutover?** At least two on production-scale data, and the last one should be a full rehearsal including the freeze, the reconciliation checks and a timed rollback. Small runs on sample extracts tell you the transform logic works. They tell you nothing about whether the load finishes inside your window. **How long should the freeze window be?** Long enough for the slowest dry run plus the reconciliation checks plus the rollback, not the average dry run. Publish the window as a time by which you will either confirm or roll back, and give the business a read-only view of the old system during it if the data supports one. **Who signs off that a migration is complete?** Someone in the business who depends on the data, not the engineer who ran the load. The engineer confirms the technical checks passed. The finance lead, operations manager or clinician confirms the numbers they use every day still look right. Both signatures belong in the plan with a date. A data migration plan is worth what its exceptions list and its rollback criteria are worth. Profile before you map, rehearse at production scale, and agree in writing who can stop the cutover and on what number. The rest of the document is scheduling. ### How to Write a Project Communications Plan (With a Reporting Cadence That Sticks) https://projan.ai/blog/how-to-write-a-project-communications-plan-with-a-reporting-cadence-that-sticks/ Published: 2026-08-10 Write a communications plan by listing every stakeholder group, deciding what each one actually needs to know, then fixing the channel, format, frequency and named owner for each. The plan is a table, not an essay. Set the reporting cadence last, and set it at a frequency you can sustain for the whole project. This is for whoever ends up owning project comms. It covers the steps, the fields, the weekly beat everything hangs off, and why most cadences stop around week three. ## How to write a communications plan for a project Start from what each audience has to decide, not from what you would like to tell them. A communications plan is a routing table for decisions: information reaches the people who act on it while they can still act. 1. **List the audiences, then collapse them.** Sponsor, steering group, delivery team, affected users, suppliers. Five groups is usually enough. Fifteen rows means you will maintain none of them. 2. **Write down the decision each group makes.** The sponsor decides on budget and scope. Affected users decide nothing but need warning before their working day changes. If a group decides nothing and needs no warning, take them off. 3. **Pick one default channel per group.** Email where you need a record, chat for the day to day, a meeting only where discussion changes the outcome. Naming the default stops the same update being retyped in four places. 4. **Set frequency against decision points, not the calendar.** A steering group that meets monthly does not need a weekly pack. It needs a monthly pack and a phone call the day a date moves. 5. **Fix the shape of the report now.** Agree the sections and length before the first send. A report invented weekly grows into an essay by week six. 6. **Name a person against every line, and a deputy.** Roles do not send emails. "Comms lead" is not somebody you can chase on a Friday afternoon. 7. **Write the escalation rule.** State what counts as bad news, who hears it, and how fast: a milestone at risk, a budget variance over an agreed figure, a dependency blocked a week. Without that line, bad news travels at the speed of whoever is bravest. Do this in one sitting with the people named on it. The line most often disputed later is the one where somebody was made an owner while they were on holiday. ## What should a project communications plan include? For every audience: the information they need, the channel, the frequency, the format, a named owner and the escalation route. Most templates arrange optional extras around those six. | Field | What good looks like | What it prevents | |---|---|---| | Information need | The decision or action it supports | Reporting because it is Tuesday | | Channel | One default per audience | The same news retyped in four places | | Frequency | Tied to when the audience decides something | Weekly packs nobody opens | | Owner | A person, plus a deputy | The update stopping when someone is off sick | | Escalation | Trigger, recipient, time limit | The sponsor hearing about a slip from the client | | Review date | When the plan itself gets revisited | A kickoff artefact nobody has opened since | Keep it to one page. Two fields carry it: the information need, which stops you sending things nobody uses, and the escalation rule, the only part that matters on the day it goes wrong. The plan gets weak in the same place every time: one person drafts it after kickoff, and the owners listed on it never agreed to their own line. Settle that column as a conversation. In [Projan](/landing/meetings-to-plans) it runs as a Slack or Microsoft Teams thread where the group is asked who hears first when a date moves and who approves anything leaving the team, and the answers come out as the plan rather than somebody's notes. ## How to write a weekly status report Write it in one pass against a fixed template: status against plan, what changed since last week, what is blocked, what you need and from whom, and what happens next. Twenty minutes, one screen. The sections themselves are covered in [what a status report should include](/blog/what-should-a-status-report-include-the-four-core-sections-with-a-reusable-templ) and in [how to write a status report stakeholders actually read](/blog/how-to-write-a-project-status-report-stakeholders-actually-read). What follows is the routine that keeps it arriving. 1. **Book the slot.** Same day, same hour, a recurring calendar entry with your name on it. Write on Friday while you still remember the week, send on Monday when people read. 2. **Write from the record, not from memory.** Open the plan, the risk log and the board first. Memory reports the loud problems and forgets the slow ones. 3. **Keep the shape identical each week, and lead with what changed.** Readers learn where the bad news lives and go straight to it. Nobody rereads the parts that are the same as last week. 4. **Make asks specific.** "Decision needed on the hosting contract from Anna by Thursday" beats "awaiting decisions", which has never caused anyone to do anything. 5. **Send it before the meeting, not after.** The written update sets the agenda and the meeting handles the two lines people disagree with. That is also how you shorten the meeting, or [stop holding it at all](/blog/how-to-get-everyone-on-the-same-page-for-a-project-without-another-status-meetin). If the weekly report is the only part of the plan that survives, the project is still better off. It is also the first thing dropped, because it carries a deadline every week. ## Why reporting cadences stop working by week three They stop because the frequency was chosen at kickoff, when everyone was optimistic and nobody had yet had a delivery week from hell. Three things go wrong, usually in this order. **The cadence was set too high.** Weekly for the delivery team is fine. Weekly for a sponsor who reads one line of it is a tax you pay for eleven months. Set the cadence you can hold in the worst week of the project, not the first. **Nobody owns the send.** A habit dies when the person holding it goes on leave. Put the send in the tracker as a recurring task with an owner and a deputy, and it survives holidays and handovers. **The report is not used.** If a report has never once changed a decision, it is not a report, it is a receipt. Ask the sponsor which line they read first. If the answer is vague, halve it and see who complains. Keeping the plan current is the other half of the job. Revisit it at phase boundaries and whenever the stakeholder list changes: a new sponsor, a new supplier, the first real users on the system. Each is a new row or a changed frequency. Put the review date in the plan so it is somebody's job rather than an act of conscience, and retire lines that have stopped earning their place. ## Frequently asked questions **Who owns the project communications plan?** The project manager or delivery lead owns the plan and the routine that keeps it running. The sponsor owns the escalation route, because escalation ends with them. Individual lines can sit with whoever is closest to that audience, such as an account lead for a client group, provided their name is on the line and they know it. **What is the difference between a communications plan and a stakeholder engagement plan?** A communications plan covers information flow: who is told what, how often, through which channel, by whom. A stakeholder engagement plan covers relationships: who holds influence, what they currently think, and how you intend to shift that. On small projects the two collapse into one document. On anything politically awkward, keep the engagement thinking separate and unpublished. **Does a small project need a communications plan?** Yes, though five lines will do it. One row per audience with a channel, a frequency and a name is a working plan. The cost of skipping it is the fortnight where two people each assume the other has been updating the client, and neither of them has. A communications plan is worth writing only if it survives a bad month. Keep it to a page, name people rather than roles, and let the weekly update be the thing you protect when everything else slips. ### How to Write an Onboarding Guide or Manual (With Checklist Template) https://projan.ai/blog/how-to-write-an-onboarding-guide-or-manual-with-checklist-template/ Published: 2026-08-10 Write an onboarding guide by listing what a new starter must know, do and be given in their first weeks, then splitting it into two documents: a manual that explains how things work, and a checklist of tasks with a named owner and a date against each. Most guides fail because they mix the two. This is employee onboarding, getting a new hire productive, rather than client onboarding at the start of an engagement. It is written for whoever has been handed the job of documenting it: an HR lead, an office manager, a founder with a second hire arriving on Monday. ## What does an onboarding checklist mean? An onboarding checklist means a list of the concrete tasks that must happen around a new starter, each with an owner and a deadline. It is a tracking document, not a teaching one. If a line on it cannot be ticked by a specific person on a specific day, it belongs in the manual instead. That test separates the three documents organisations habitually merge into one file. | | Onboarding manual or guide | Onboarding checklist | 30-60-90 day plan | |---|---|---|---| | **What it is** | Reference: how things work here | Task list: what must happen, and by when | Expectations for one person in one role | | **Written for** | The new starter, read once then searched | Whoever runs the process: manager, HR, IT | The new starter and their manager together | | **How often it changes** | When something it describes changes | Reused every hire, edited rarely | Written fresh for every hire | | **Fails when** | It becomes a policy dump nobody reads | Tasks are owned by "HR" rather than a person | It sets tasks instead of outcomes | The third column is a different job, covered in [how to build a 30-60-90 day plan that survives contact with the role](/blog/the-30-60-90-day-plan-how-to-build-one-that-actually-works), and the stage-by-stage picture including the first-week schedule sits in [what an employee onboarding plan should include](/blog/employee-onboarding-plans-what-to-include-stages-and-real-examples). This article is about the two documents you write once and reuse. ## How to write an onboarding guide Write the guide backwards, starting from the first thing somebody needs at nine o'clock on Monday and ending with the policies they can look up in month three. Seven steps, in order: 1. **Ask three recent hires what confused them.** Not a survey. Ask three people who joined in the last six months what they had to ask a human about, and what they were told twice by different people. Those are your chapters. Most onboarding manuals are written by whoever has the least recent experience of being new. 2. **Split reference from tasks before you write a word.** Anything with a date and an owner goes on the checklist. Anything that answers a question goes in the guide. Deciding this once prevents the hybrid document that is too long to read and too vague to track. 3. **Write day one in the order it happens.** Where to arrive or which link to click, who meets them, when lunch is, when they can stop. First days fail on logistics, not culture. 4. **Name humans, not functions.** "Contact IT" is a dead end. "Message Sam Okoye in #it-help" is a usable instruction. Accept that this section will need editing every time somebody leaves, and edit it. 5. **Document the things nobody writes down.** How decisions actually get made, which recurring meetings are genuinely optional, what the internal acronyms mean, which channel matters and which is noise. None of it can be looked up, which is why working it out alone takes months. 6. **State what settled in looks like.** Give an observable description at the end of week one and month one: they have shipped something small, they know who to ask about payroll, they have met everyone they depend on. 7. **Delete anything the handbook already says, and link to it.** Duplicated policy text goes stale silently. The guide should be the map, not a second copy of the territory. Keep the tone the same as the way people actually speak internally. A guide written in formal HR register tells a new starter, on their first evening, that the organisation says one thing and writes another. ## An onboarding checklist template Four columns and four phases. The columns matter more than the rows, and the last column is the one most templates leave out. | Phase | Task | Owner (a person) | Done when | |---|---|---|---| | Before day one | Laptop built, tested and delivered | IT lead | Tracking number recorded, or device on desk | | Before day one | Contract signed and any checks your organisation requires completed | HR lead | Signed copy filed | | Before day one | Week one invites sent, buddy confirmed | Hiring manager | Buddy has accepted, calendar is populated | | Day one | Access to every system the role needs, tested by the new starter logging in | IT lead | They have logged into each one themselves | | Day one | Team introductions and a tour of where things live | Buddy | Introductions made to everyone on the dependency list | | Week one | First piece of real work assigned | Hiring manager | Item is in the tracker with a due date | | Week one | Payroll, expenses and leave booking walked through | HR lead | New starter has submitted a test expense or leave request | | Month one | Objectives agreed and written down | Hiring manager | Both parties hold a copy | | Month one | Onboarding review: what was missing, what was wrong | HR lead | Corrections applied to the guide and checklist | "Done when" converts good intentions into evidence. "Set up accounts" gets ticked by the person who created them; "they have logged into each one themselves" gets ticked when it actually works, which is frequently a different day. Two rules keep the rest honest. An owner is a named person, because a task owned by a department is owned by nobody and gets discovered at 9:15 on Monday. And it is ticked as things happen, not reconstructed before the probation review. ## Who owns the onboarding guide once it exists One named person owns the guide, but the content is written by the people who do the work it describes. HR owns the process and the checklist; the page explaining how engineering releases code has to come from engineering, or it will be confidently wrong within two months. That is the failure behind most bad onboarding manuals: one person writes the whole thing alone, describing roles they have never held, and the errors surface one new starter at a time. An hour with the hiring manager, the buddy and whoever provisions the accounts removes the guesswork. [Projan](/landing/onboarding-gaps) is built for that kind of session: it pulls the existing document out of Notion or Confluence as context, asks the group in Slack who owns each provisioning task and what the new starter should be able to do unaided by the end of week one, then writes the answers out as a plan with tasks attached. What matters is that the answers come from the people who hold them, not from whoever had a free afternoon. Maintenance works better as a trigger than a calendar reminder. Make the last item on every checklist the new starter's own list of corrections, and make applying them somebody's task rather than a suggestion. A guide that has never been wrong has never been read. Keeping it current uses the same mechanics as [writing a standard operating procedure](/blog/how-to-write-a-standard-operating-procedure-step-by-step-with-examples). ## Frequently asked questions **How to create an onboarding manual?** Start from the questions new starters actually ask rather than from a table of contents. Collect them for a month, group them into six or seven themes, and write a page per theme. Keep it somewhere people can search, link out to the staff handbook rather than copying it, and put the author's name at the top so corrections have somewhere to go. **How long should an onboarding guide be?** Short enough that a nervous new starter reads it on their first evening. Ten to fifteen pages covers most organisations, and much of that should be links rather than prose. If yours runs to forty pages, you have merged the guide with the staff handbook, and the handbook will win by making the guide unreadable. **Should every role have its own onboarding guide?** No. Write one company guide covering everything common to every hire, then a short role appendix of one or two pages per team. Duplicating the whole guide per role guarantees that eleven versions drift apart and only the one belonging to the loudest team stays current. The appendix is where a team's tools, rituals and jargon go. **Is the onboarding guide written for the new starter or their manager?** The new starter, with a separate short section for the manager. Mixing the two produces a document that reads as instructions to somebody else while the person it was meant for skims past it. If the manager needs a briefing on their own responsibilities, give them a page of their own and say so in the heading. The distinction is worth holding on to: the manual answers questions, the checklist proves things happened. Write both, keep them apart, and let each new starter correct whichever one lies to them first. ### What a Messaging Hierarchy Looks Like, and How to Build the Matrix https://projan.ai/blog/messaging-hierarchy-and-messaging-matrix-pillars-structure-and-how-to-build-both/ Published: 2026-08-10 A messaging hierarchy is a pyramid. One value message sits at the top, three or four pillars sit beneath it, each pillar carries its own proof, and audience and channel wordings sit at the bottom. Written out it is usually one page: a sentence, a row of headings, and the evidence stacked under each heading. This is for marketers building the thing rather than deciding whether they need one. Where positioning ends and messaging begins is a separate argument, handled in [brand positioning vs messaging framework](/blog/brand-positioning-vs-messaging-framework-where-one-ends-and-the-other-begins). What follows is the structure, the pillar anatomy, and the matrix. ## What does a messaging hierarchy look like? It looks like four stacked layers, each one narrower in scope and larger in volume than the one above it. - **The value message.** One sentence, brand level, said to everybody. It is not your positioning statement, which is an internal decision written for the team. This is the outward version, and it should survive being read aloud. - **The pillars.** Three or four themes that the value message rests on. Each is a claim you are willing to be judged on. - **The support.** Under each pillar, the reasons to believe it and the evidence for those reasons. Features, capabilities, references, anything a sceptic could check. - **The expressions.** The audience and channel wordings that get written from the layers above. These are the sentences that end up in a subject line or on a pricing page. There is no canonical number of layers. Some frameworks split support into reasons to believe and proof points, some bolt a tagline layer on top, some skip the value message and start at pillars. Four is the common working shape because it maps to how the artifact gets used: one thing everybody says, a few things the copy keeps returning to, evidence when challenged, and the wording that changes per audience. A skeleton for a rota and scheduling product, cut short: - **Value message:** Publish a rota in minutes that holds up to the rules. - **Pillars:** Live in a week · Compliant before you publish · Swaps without the phone tree - **Support under pillar two:** rules configured per site; breach warnings shown while editing, not after publishing; an audit trail on every published version. Read top to bottom, that is what a hierarchy looks like. Read bottom to top, it is a test: any sentence in your copy should be traceable to a pillar, and any pillar should be traceable to the value message. Copy that cannot be traced anywhere is not necessarily wrong, but nobody agreed to it. ## What is a messaging pillar example? A pillar is a theme with evidence attached, not a slogan. Here is one written out at the level of detail that makes it usable: **Pillar: Compliant before you publish** - **Claim:** The rota is checked against working-time rules and individual contract terms before anyone can see it. - **Reasons to believe:** rules are configured per site rather than globally; breaches are flagged at the point of editing; every published version keeps an audit trail. - **Proof you can show:** the warning state in a live demo, the configuration screen, the version history on a published rota. - **What this pillar does not claim:** that compliance is guaranteed. Anything that reads as a legal assurance goes past someone qualified to sign it off before it goes anywhere near a headline. That last line is the part teams skip, and it is the part that stops a pillar being quietly inflated by whoever writes the next campaign. A pillar with a stated boundary is much harder to overreach. Three to four pillars is the working range most teams settle on. There is no rule behind that number, but there is a practical reason for it: past about five, copywriters stop consulting the list and start picking their two favourites, and the pillars nobody picks die without anyone noticing. If you have eight candidate themes, some of them are proof points that have been promoted above their station. Demote them. ## How do you create a messaging matrix? Put the pillars across the top, the audiences down the side, and write one sentence in each cell that somebody in that audience would recognise as being about their week. That grid is the messaging matrix, and it is the thing briefs and campaigns are actually written from. The wider document it lives inside is covered in [brand messaging framework](/blog/brand-messaging-framework-what-it-is-how-to-write-one-and-examples-that-stick). The build, in order: 1. **Fix the pillars first.** A matrix built on unagreed pillars just spreads the disagreement across more cells. 2. **Choose audiences by decision role, not demographics.** The person who uses the product, the person who signs for it, and the person whose day changes are three different audiences even inside one company. 3. **Write each cell in the audience's own vocabulary.** Not a translation of the pillar. The finance director does not want a friendlier version of the operations message, they want the version about money. 4. **Attach evidence, or mark the cell unproven.** A cell you cannot support yet is useful information. A cell you cannot support and have not flagged is a future correction. 5. **Leave cells empty when the pillar does not apply.** Empty is a legitimate answer and a much better one than filler. 6. **Date it and version it.** Undated messaging documents get quoted years after they stopped being true. Here is the matrix for the same product, at the size a real one should be: | Audience | Live in a week | Compliant before you publish | Swaps without the phone tree | |---|---|---|---| | **Operations manager** | Your first live rota in week one, built from the spreadsheet you already keep | Rest-break and contract breaches flag while you edit, not after payroll runs | Swaps go through the app with your approval, so nobody rings you on a Sunday | | **Finance director** | No implementation project and no consultancy line in the budget | Fewer retrospective pay corrections, because the breach was caught at rota stage | Overtime is approved before it is worked rather than discovered in the payroll run | | **Shift worker** | (no message: rollout speed is not their problem) | You can see your hours and rest gaps before the week starts | Post a shift, take a shift, no group chat at eleven at night | Note the empty cell. That is the most instructive thing on the grid, because completeness is how most matrices fail. A team sits down, produces a tidy nine-cell rectangle, and roughly three of those sentences were written to close a gap rather than because anybody had something to say. Nobody can tell which three afterwards, so the copywriter treats all nine with equal suspicion and writes from the brief instead. The cells worth keeping are the ones somebody argued about. Getting three teams to agree the pillars is the genuinely hard part, and it usually happens in a meeting that produces no record. Run it as a structured session instead, which is what Projan does: it asks each participant which claim they would defend on a customer call and what evidence they would produce for it, so what comes out is a written pillar set rather than one marketer's recollection. Whatever you use, the rule holds: a pillar nobody objected to was probably not read. ## What are the five parts of a message? There is no canonical five in marketing. The phrase comes from communication studies, where the elements usually taught are the sender, the message, the channel, the receiver and the feedback, and that model describes how a conversation travels rather than how a line of copy is built. It will not help you fill in a matrix cell. For a brand message, five parts are worth checking before a sentence goes out: 1. **The claim.** What you are asserting. If a reader cannot disagree with it, it is not a claim. 2. **The relevance.** Why this reader, and why now. This is the part that changes per matrix row. 3. **The reason to believe.** The mechanism that makes the claim plausible. 4. **The proof.** The specific evidence you would produce if challenged. 5. **The ask.** What the reader is meant to do next, including nothing, if the message is a brand message. Treat that as a checklist rather than a standard. Nobody is marking your work, and plenty of good messages carry four of the five. The one that is almost never optional is the claim: strip it out and you are left with description, which reads as accurate and persuades nobody. ## What are the four types of messages? The four types that search results offer are usually verbal, non-verbal, written and visual, which is a communication-studies taxonomy and has nothing to do with a messaging hierarchy. Inside a hierarchy the useful split is by how often each type changes and who is allowed to change it. 1. **The value message.** One of them. Changes when the company changes. Signed off at the top. 2. **Pillar messages.** Three or four. Change roughly annually. Owned by whoever owns positioning, and edits go through them. 3. **Proof messages.** Many. Change whenever the product or the evidence changes, which is often. Anyone can add, but each needs a source. 4. **Audience messages.** One per useful matrix cell. Rewritten freely, tested, discarded when they stop working. That volatility gradient is the practical point. Most messaging documents rot because all four types are stored in one file with no indication of which lines are settled and which are this quarter's experiment, so a copywriter treats a two-year-old value message and a half-tested subject line as equally authoritative. Mark them differently, even if only with a date column. ## What is an example of message framing? Framing is stating the same true claim in a way that changes what the reader compares it to. It is a change of reference point, not a change of fact. One claim from the matrix above, framed four ways: | Frame | The same claim | When it works | |---|---|---| | Gain | Publish a rota you know is legal | Confident buyers, brand-level copy | | Loss | Stop finding breaches in the payroll run | Buyers who have been burned recently | | Effort | One check before you publish instead of a manual audit after | Buyers comparing against a manual process | | Reference point | The rules check happens at rota stage, not at pay stage | Buyers who do not yet know the problem has a stage | All four are the same capability. Which one lands depends on what the reader currently believes the alternative is, which is why framing decisions belong in the matrix cells rather than in a style guide. Loss framing is overused in business software and stops working quickly on an audience that has seen it three times this month. Framing is not permission to bend the claim. If the gain version implies a guarantee the loss version carefully avoids, you have not reframed anything, you have written a claim you cannot support and hidden it in the more optimistic sentence. The claim is fixed before the framing starts, which is another argument for writing the pillar's boundary down. Once a matrix exists, it feeds directly into the [campaign and creative briefs](/blog/campaign-creative-briefs-what-to-include-who-writes-them-and-who-signs-off) that agencies and in-house designers work from. ## Frequently asked questions **What is the structure of a message?** In finished copy the usual order is claim first, relevance second, proof third, ask last. The headline carries the claim, the subhead makes it relevant to this reader, the body supplies proof, and the button asks for something. The parts do not have to appear in that order, but a message with no claim in it reads as description rather than persuasion. **Who owns the messaging matrix?** Usually product marketing, or whoever wrote the positioning. Ownership means keeping the pillars stable and arbitrating changes, not writing every cell alone. Sales and support should be able to propose edits, because they hear the objections that make a cell wrong. If nobody is named as owner, the matrix quietly forks into three versions inside a quarter. **How often should a messaging matrix be updated?** Update it when something real changes: a new segment, a competitor claim you now have to answer, or a product change that alters a proof point. A calendar review once or twice a year catches drift. Rewriting it every quarter for its own sake usually means the pillars were never agreed properly and the team is relitigating positioning. **Do you need a separate messaging matrix for each channel?** No. Keep one matrix of audiences against pillars, and let channel adaptation happen in the brief or in the copy itself. Adding channel as a third dimension turns a readable page into a spreadsheet nobody opens. If a channel needs genuinely different messages rather than different lengths, the audience split is probably wrong. A hierarchy is only worth building if the copy underneath it can be traced back up. Keep the pillars few enough that people remember them, keep the matrix honest enough that empty cells are allowed, and settle the [positioning statement](/blog/how-to-write-a-positioning-statement-formula-four-parts-and-positioning-maps) above it before you start writing rows. ### What Is Another Name for a Project Charter? Charter vs PID https://projan.ai/blog/project-charter-vs-project-initiation-document-are-they-the-same-thing/ Published: 2026-08-10 The closest alternative names for a project charter are the project initiation document (PID), the project brief, the project definition document and the terms of reference. They are not exact synonyms. Each comes from a different method and carries a different amount of detail, and the charter's particular job is authorisation. This matters more than it sounds. Teams routinely spend a fortnight arguing about which template to use when the real disagreement is about who is allowed to approve the project and release the money. ## What is another name for a project charter? The name changes with the method your organisation follows, and the document changes with it. These are the terms you will meet most often: - **Project initiation document (PID).** The PRINCE2 term. Broader than a charter: it absorbs the authorisation job and adds plans, controls and business justification. - **Project brief.** Also PRINCE2, and the nearest true analogue to a charter. It is the short document assembled before full initiation, giving the outline case, scope and roles. - **Project definition document.** An in-house name, common in organisations running a light internal method. Content varies by whoever wrote the template. - **Terms of reference (ToR).** Standard in the public sector, charities and consultancy. Often applies to a board, working group or steering committee rather than a project, so check what it is describing before you copy one. - **Project mandate.** PRINCE2's trigger from the commissioning body, and not a charter. It comes earlier and authorises investigation, not delivery. - **Statement of work.** Supplier-facing and contractual. It defines what a vendor will deliver for a fee. Do not use it as an internal authorisation. Scope statement gets thrown into the same pile too, but it is a section rather than a document. If someone offers you a scope statement in place of a charter, you have been handed one paragraph of a much larger conversation. ## Are the project charter and the project initiation document the same thing? No. They are close relatives from different traditions. The charter comes from PMI's body of knowledge, where its job is to authorise the project's existence, name the project manager and give that person the authority to draw on organisational resources. The PID comes from PRINCE2 and covers far more ground: it is the full initiation-stage record, and it absorbs the charter's role rather than replacing it. | | Project charter | Project initiation document (PID) | |---|---|---| | **Tradition** | PMI, PMBOK Guide | PRINCE2 | | **Primary job** | Authorise the project and the project manager | Show the agreed shape of the whole project before delivery commitment | | **Form** | One document, usually short | A set of components assembled together, which is why PRINCE2 calls it Project Initiation Documentation | | **Written when** | At the start, before detailed planning | At the end of the initiation stage, before delivery starts | | **Contains plans and controls** | High level only | Yes, including the plan, the approaches to risk and quality, and the reporting arrangements | | **Signed by** | The sponsor or the person releasing the funding | The project board | | **Life after approval** | Reissued if the mandate changes, rarely edited | Baselined and version controlled through the project | In practice, an organisation running PRINCE2 does not need a separate charter, because the project brief and then the PID do the same work in sequence. An organisation running a PMI-flavoured method does not need a PID, because the charter plus the project management plan cover it. The mess happens in the middle, where a PMO has borrowed vocabulary from both and nobody can say which document actually carries the sponsor's signature. ## What are project initiation documents? Project initiation documents are the set of records that define a project fully enough for a governance body to commit to delivering it. The plural is not sloppiness. In PRINCE2 the PID is explicitly a collection, assembled from products created during initiation rather than typed out as one file. A PID normally brings together: - The project definition: background, objectives, scope, exclusions, constraints, assumptions and interfaces with other work - The business case, or a reference to it if it lives elsewhere - The project plan, including stages and the point at which the board reviews progress - The organisation structure, with named people against named roles - The approaches to risk, quality, change and communication - The project controls: tolerances, reporting frequency, escalation route That is a shape, not a form to fill in. If you want the section-by-section version, including which parts are usually padding, [our breakdown of what to include in a project initiation document](/blog/project-initiation-documents-what-to-include-what-to-leave-out-and-which-templat) covers it properly. The same applies on the charter side: [who writes the charter and which components it needs](/blog/who-writes-the-project-charter-roles-approvals-and-the-5-components) is a separate question from what the thing is called. ## Is a project charter a project document? Yes. It is a formal project document, and on most projects it is the first one that carries a signature. The distinction people are reaching for when they ask is between a document that plans the work and a document that permits it. The charter is the second kind. That has three practical consequences. It is not part of the project management plan. The charter is an input to planning, not an output of it. Planning happens after somebody has said yes, and the charter is the record of that yes. It is not a living document in the way a risk register is. You do not update a charter weekly. If the objectives, funding or accountable owner change materially, the charter is reissued and re-signed, which forces the sponsor to notice that they are approving something different from what they originally approved. It belongs under version control with the rest of the governance record. Audit, assurance and any subsequent dispute will ask for the approved version and the date. A charter that only exists as an attachment on a nine-month-old email thread is not much use to anybody. A charter with no named approver is a memo. The signature is the entire point of the document, and it should come from whoever controls the budget rather than whoever chaired the meeting. ## What is the standard project initiation document? There is no single cross-industry standard PID. The nearest thing to one is the PRINCE2 Project Initiation Documentation, which most UK templates are descended from, and it is a specified set of components rather than a fixed form with numbered fields. Beyond that, standard means whatever your PMO or your funder says it means. Three versions you will actually encounter: 1. **The PRINCE2 shape.** The components listed above, tailored to project size. PRINCE2 expects tailoring, so a small project producing a six-page PID is following the method, not cutting corners. 2. **The funder's template.** Public bodies, grant funders and large clients often mandate their own format, sometimes with a business case in a prescribed structure attached. If money is coming from outside, their template is the standard, whatever your internal one says. [How to write a business case](/blog/how-to-write-a-business-case-format-structure-and-the-five-cases-model) covers what that attachment usually has to prove. 3. **The in-house one-pager.** Common in software and startups, where the initiation record is a short document covering problem, scope, owner, budget and decision rights. Perfectly legitimate, provided somebody with authority signs it. Be suspicious of any template that runs to forty headings and asks for none of the four things that decide whether a project can start: what it is for, what it costs, who is accountable, and what is out of scope. ## Which name should your organisation use? Pick one and enforce it, because the cost of two names is not confusion, it is two approval routes. Nobody has ever been rescued from a scope dispute by the file name. What rescues them is knowing which person's signature the organisation treats as permission to spend. A workable way to settle it: 1. **Find out which document your finance and governance functions already recognise.** They will have one. Start there rather than from a methodology textbook. 2. **Name the approver, not the role.** "Director of Operations" is a role. A specific person with a delegated financial limit is an approver. 3. **Decide what the approval covers.** A budget envelope, a stage, or the whole project. Charters that approve everything forever are the reason change control gets ignored. 4. **Fix the other names as aliases in the template itself.** One line saying this document is also referred to as the project brief internally kills most of the argument. 5. **Write down what happens when scope changes.** Reissue and re-sign, or raise a change request against the baseline. Both work. Only one of them can be your default. Where the approver is genuinely unclear, a facilitated pass through the initiation questions is more use than another template. Projan holds that discussion in Slack or Microsoft Teams and will not move on until someone names who signs, what the money is being released for and which of the two documents the organisation will actually keep, then writing the agreed answers into a document you can export to Confluence. What settles the argument is the naming decision itself, not the method used to reach it. If none of this is resolved yet, the problem is upstream of documents entirely. [What actually happens during project initiation](/blog/the-project-initiation-phase-what-actually-happens-before-planning-starts) is the better place to start than a template library. ## Frequently asked questions **Is a project brief the same as a project charter?** In PRINCE2 the project brief is the short document assembled before initiation proper, so it sits closer to a charter than the PID does. Outside PRINCE2, project brief usually means something looser: a marketing or design brief describing what the client wants. Ask which meaning is in play before you agree to write one. **Can a project have both a charter and a PID?** Yes, and plenty do, usually because the organisation runs a PMO template while the funding sponsor wants a one-page authorisation to sign. It only causes trouble when the two disagree. Keep the charter as the signed authorisation and treat the PID as the fuller version of the same scope, updated in one place. **What is a project mandate?** In PRINCE2 the mandate is the trigger: the instruction from the commissioning body that a project should be looked at, often a few paragraphs or an email. It comes before both the project brief and the PID. It is not an authorisation to spend, and treating it as one is a common way to start work that nobody has actually approved. **How long should a project charter be?** Short enough that the sponsor reads it before signing, which in practice means two or three pages. If it runs longer, the detail probably belongs in the project plan or the business case. The test is whether a reader can tell what is being approved, who is accountable and what falls outside it. The charter and the PID are not the same document, and swapping the labels solves nothing. Decide which one your organisation signs, name the person who signs it, and make every other term in circulation an alias for that one thing. ### RACI vs RAID vs Risk Register: Which Do You Need? https://projan.ai/blog/raci-vs-raid-vs-risk-register-which-tracker-do-you-actually-need/ Published: 2026-08-10 RACI and RAID answer different questions. A RACI matrix allocates work and decision rights across roles: who is responsible, accountable, consulted and informed for each task. A RAID log is a running record of risks, assumptions, issues and dependencies. A risk register is one quarter of RAID, kept on its own when risk reporting has a separate audience. The three get conflated because they all arrive as a spreadsheet with coloured headers, and because a new project manager is often asked for all of them in the same fortnight. This guide covers what each artefact is for, when a RAID log earns its place, what a risk register goes by elsewhere, and how to avoid holding the same risk in two files. ## What is RACI vs RAID? RACI is about allocation. RAID is about uncertainty. A RACI matrix is a grid of tasks against people that exists to stop two people doing the same job while nobody does the third one. A RAID log is a list of things that might go wrong, have already gone wrong, are being taken on trust, or sit outside your control entirely. Both acronyms get expanded loosely, so here they are in full: - **RACI**: Responsible (does the work), Accountable (answers for the outcome, one name only), Consulted (asked before the decision), Informed (told after it). - **RAID**: Risks (might happen), Assumptions (believed without evidence), Issues (already happening), Dependencies (something outside the team has to land first). | | RACI matrix | RAID log | Risk register | |---|---|---|---| | **Question it answers** | Who does what, and who decides | What could stop us, and what are we relying on | What could go wrong, how badly, and who is watching it | | **Shape** | Tasks down the side, roles across the top | Four grouped lists, each item dated and owned | One list, scored and reviewed | | **Time it points at** | Now: the current allocation of work | Past, present and future at once | Future, until a risk becomes an issue | | **Changes when** | The team, scope or governance changes | Weekly, throughout delivery | Weekly to monthly, plus after any scope change | | **Who actually reads it** | The delivery team, and anyone unsure who to ask | The project manager and the delivery team | Sponsors, steering groups, sometimes audit | | **How it fails** | Filled in without the people it names | Four lists that grow and never close | Written for reporting rather than for action | None of the three is a standard requirement. Plenty of well run projects use a RACI and no RAID log, or a RAID log and no RACI, and some organisations mandate all three because a governance framework in a shared drive says so. Pick them for what they tell you, not for whether they came with the template you inherited. RACI has its own failure modes, mostly too many people in the C column and more than one name in the A column, and [the golden rules for building a matrix that survives contact with a team](/blog/the-raci-matrix-done-right-golden-rules-common-mistakes-and-what-comes-next) are worth reading before you draw the grid. ## When would you use a RAID log? Use a RAID log when things get forgotten between meetings and when a meaningful part of what could stop you sits outside your team. It is a memory device for a project with more moving parts than one person can hold, and it is close to useless on a project small enough to keep in your head. The specific triggers worth watching for: - **Dependencies on other teams or suppliers.** The moment your plan contains the phrase "once platform have finished their migration", you have a dependency that needs a date, an owner and a check-in. - **Assumptions doing structural work.** If the budget assumes the client provides content by a fixed date, that belief is holding up the schedule and should be written where the client can see it. - **A handover coming.** Whoever takes over needs the reasoning, not only the plan. A RAID log carries the reasoning. - **Governance that asks questions.** Steering groups ask what has changed since last month. A log answers that in two minutes; a memory does not. Skip it when the work is short, the team is one room, and nothing you need is being built by someone else. Adding a RAID log to a three week internal task creates an artefact that gets populated once at kickoff and then quietly abandoned, which is worse than not having one, because everyone assumes it is being maintained. ## What is the name of the risk register? The risk register is also called the risk log, and the two names describe the same document. PRINCE2 uses risk register and keeps a separate issue register for things that have already occurred. Some organisations say risk log, some say risk and issue log, and a fair number of teams just call it the risks tab. The name matters only for one reason: when someone asks you for the risk log and you send them the RAID log, they get four lists when they wanted one. What goes in it is more contested than what it is called, and the honest answer is fewer columns than most templates offer. If you are building one now, [the fields worth keeping and the ones that only ever get filled in once](/blog/risk-register-fields-what-to-include-in-a-simple-risk-register-and-what-to-skip) are set out separately. The entry itself matters more than the scoring: a register full of one word risks like "resourcing" cannot be acted on by anyone who did not attend the meeting where it was raised, which is why [writing the risk as a cause, an event and an effect](/blog/how-to-write-a-risk-statement-the-three-part-structure-and-what-makes-a-risk-rea) does more for a register than any heat map. ## Which of the three becomes useful when Each artefact has a phase where it starts paying for itself and a phase where it is premature. Roughly: 1. **Before approval.** Assumptions and dependencies matter most here, because the estimate rests on them. A RACI is premature when the team is still a list of job titles. 2. **Mobilisation.** This is RACI's moment. You have named people, a scope and a set of decisions that will need making. Build it while the team is assembling, not after the first argument about who signs off design. 3. **Early delivery.** The RAID log goes live. Assumptions written at approval get tested, and the ones that fail become issues within the first few weeks. 4. **Mid delivery.** If a steering group or sponsor is reviewing risk monthly, this is where a separate risk register becomes worth the duplication. Before that point, the R section of the RAID log is enough. 5. **Closure.** The RAID log is the more valuable of the two at the end, because assumptions that turned out to be wrong are the cheapest lesson the next project can buy. The ordering is not a rule, and projects with heavy external dependencies often need the RAID log before anyone has agreed the RACI. What is consistent is that RACI answers a question you have at the start, and RAID answers a question you keep having. ## How to run a RAID log without duplicating the risk register Pick one of them as the place a risk is written, and make the other a view of it rather than a second copy. Teams that maintain both properly almost always keep the risk register as the master and let the R section of the RAID log point at it, because the register is the one with the audience. Two arrangements that work: - **Register as master.** Risks live in the risk register with full scoring and mitigation detail. The RAID log holds only assumptions, issues and dependencies, and its R column is a reference: risk ID, one line, current status. Nobody edits the same risk twice. - **Log as master.** Everything lives in the RAID log. The risk register is produced from it for reporting, by filtering to open risks above a severity threshold. This works when the reporting need is monthly rather than continuous. What does not work is maintaining both as independent documents and reconciling them before each steering meeting. That reconciliation is unpaid work, it always slips, and the version the sponsor reads ends up being the stale one. Whichever pattern you choose, the harder problem is keeping the thing current at all, which is a question of [review rhythm and who is expected to update what](/blog/risk-registers-and-raid-logs-how-to-build-one-and-actually-keep-it-alive) rather than of format. ## How many of these do you actually need? Fewer than you have. Most teams carrying all three are maintaining at least one out of obligation, and the obligation is usually to a template rather than to a reader. The test is simple: name the meeting where each document is opened on a screen and someone changes something in it. If no such meeting exists, that tracker is a document, not a control, and its main function is to make an absent stakeholder feel covered. Run the test honestly and you usually find one artefact doing real work, one being updated the morning before a report, and one that has not been touched since week two. The fix is not better discipline. It is deleting the one nobody reads and putting its two live items into the one people do read. The other reliable failure is quieter. Both grids get filled in by one person, alone, after the meeting rather than during it, and the names in them are guesses about what colleagues would probably agree to. An accountable name that its owner has not seen is not accountability, it is a spreadsheet cell. Projan runs the planning conversation in Slack or Microsoft Teams and puts the ownership questions to the group while everyone is still in the thread, so the accountable name against a task and the owner against a risk are settled by the people involved rather than typed in afterwards by whoever holds the file. ## Frequently asked questions **What is the difference between a RAID log and a RACI?** They are not alternatives. A RACI is a static grid of tasks against people that you build once and revise when the team changes. A RAID log is a running record you add to every week. If you can only maintain one, build the RACI first on a project with unclear ownership, and the RAID log first on a project with many external dependencies. **What does the D in RAID stand for?** Dependencies: things outside your team that must happen before your work can proceed, such as another team's release, a supplier delivery or a legal sign off. Some teams read the D as Decisions and the A as Actions instead, which produces a useful log but a different one. Agree which expansion you are using before the first review, because mixed readings produce mixed columns. **Can you keep the RACI and the RAID log in one spreadsheet?** Yes, as separate tabs in the same file, and that is often the sensible arrangement on a small project. Keep them as distinct sheets rather than merged columns, because they update on different rhythms. The RACI changes when the team or the scope changes. The RAID log changes weekly, and merging the two means touching the ownership grid every time a risk moves. **Do small projects need any of these?** A two person, three week piece of work usually needs neither. What it does need is a named owner for each deliverable and a short written list of what you are relying on other people to do. That list is a RAID log in everything but name. Formal artefacts start earning their keep when the number of people involved exceeds the number who attend the same meeting. Choose these documents by the question you keep being asked, not by what the governance template contains. If you are constantly clarifying who decides, build the RACI; if you are constantly rediscovering things you already knew, build the RAID log. Anything you cannot name a reader for is not a control, and dropping it costs nothing. ### How Is a Risk Register Created (and Kept Alive)? https://projan.ai/blog/risk-registers-and-raid-logs-how-to-build-one-and-actually-keep-it-alive/ Published: 2026-08-10 A risk register is created by pulling raw risks out of the plan and the delivery team, writing each one as a cause, event and effect, assessing likelihood and impact against whatever scale your organisation already uses, naming one owner per risk, and agreeing a response with a date. That takes an hour. Keeping it current is the part that fails. This guide covers building a register from scratch, what a basic one looks like, how a RAID log differs from a risk log, who maintains it, and whether anything obliges you to keep one. It is written for whoever has been handed the register and told to look after it. ## How is a risk register created? A risk register is created in one working session, not written up alone afterwards. The steps below are the version most commonly taught and used, in roughly this order. 1. **Decide who reads it.** A register for a steering group holds eight to fifteen live risks in business language. A register for the delivery team can hold forty in technical detail. Deciding this first stops the argument about granularity later. 2. **Harvest before you meet.** Every assumption and dependency in the plan is a candidate risk. So is every lesson from the last project of this shape, and every date you agreed without evidence. 3. **Run the identification session with silent writing first.** Give people five minutes to write risks on their own, then read them out. If you start with open discussion, the first speaker sets the frame and the quiet specialist never mentions the thing that actually sinks you. 4. **Write each risk properly.** A single noun such as "resourcing" is not a risk. The [three-part risk statement covering cause, event and effect](/blog/how-to-write-a-risk-statement-the-three-part-structure-and-what-makes-a-risk-rea) is what makes a row reviewable by someone who was not in the room. 5. **Score likelihood and impact.** Use the scale your organisation already uses, whether that is high, medium and low or a numeric range. There is no universal standard here, and the score's only job is to sort the list. Ten minutes arguing whether an impact is a three or a four is ten minutes not spent on the response. 6. **Name one owner per risk.** A person, not a team and not a department. Two names on a row means nobody is watching it. 7. **Agree a response and a next action.** The common set is avoid, reduce, transfer or accept. Each row then needs one concrete next action with a date, because a response type on its own commits nobody to anything. 8. **Set the review trigger before you leave the room.** Which meeting, which date, who chairs it. This is the step that gets skipped, and it is the reason most of what follows in this article exists. Steps three and six carry most of the quality. Teams that already plan in Slack or Microsoft Teams can run that session in Projan, which pulls the existing project plan in as context, asks each named owner what their first action would be, and exports the agreed actions to tools like Jira or Asana. ## What does a basic risk register look like? A basic risk register is a table with one row per risk and about six columns, sorted so the worst risk is at the top. Here is a fragment of a real-shaped one. | ID | Risk | L/I | Owner | Next action and date | Status | |---|---|---|---|---|---| | R-04 | Supplier response times are running at two weeks, so the test environment may not be ready for user acceptance testing, pushing go-live back by a fortnight | H/H | Priya Shah | Escalate to supplier account director, 22 Aug | Open | | R-07 | Only one engineer knows the payments integration, so any absence in September would stop release work | M/H | Tom Reilly | Pair a second engineer through the next two tickets, 5 Sep | Open | | R-11 | Updated accessibility guidance may be published before launch, so three templates could need late rework | L/M | Dani Okafor | Confirm publication date at the September review | Accepted | Notice what makes those rows usable. Each one says what would go wrong and why, so a director who has never attended a project meeting can read it cold. Each has one name. Each has an action with a date, which is the only column that changes between reviews and therefore the only one that proves the register is alive. Six columns is enough for most projects. If you want the full argument about which fields earn their place, [the fields to include in a simple risk register and the ones to skip](/blog/risk-register-fields-what-to-include-in-a-simple-risk-register-and-what-to-skip) covers it. The short version is that a column nobody fills in makes the register look neglected even when it is not. ## What are the three components of a risk register? No standard defines three components, and anyone presenting a canonical three has made it up. What is true is that a register strips down to three things, and losing any of them makes the document decorative. 1. **The risk, written so a stranger can assess it.** Cause, uncertain event, effect on the project. This is the component people skimp on, and it is why so many registers read as a list of anxieties. 2. **An assessment that ranks it against the others.** Likelihood and impact, on any consistent scale. The purpose is ordering, not precision. You need to know which four rows matter this month. 3. **A response with a named owner and a dated next action.** Without this the register records worry rather than work. Dates, categories, residual scores and links to mitigating actions are all useful additions. They are not what makes the difference between a register that changes behaviour and one that gets attached to a status pack unread. ## How do you keep a risk register updated? Keep a risk register updated by attaching its review to a meeting that already happens, giving it an audience who will ask about specific rows, and making the closing of a risk as routine as the opening of one. Most registers are built in a good workshop and dead inside a month. The cause is almost always the same two omissions. There is no trigger, so review depends on somebody remembering. And there is no audience, so remembering has no consequence. Nobody opens a document because it exists. They open it because on Thursday morning someone senior is going to ask what has changed on row seven. What works in practice: 1. **Bolt the review onto an existing meeting.** A standing thirty-minute risk meeting gets cancelled by week four. Ten minutes inside the weekly delivery meeting survives, because the meeting was happening anyway. 2. **Review by exception.** Read the top five, plus anything whose status or score changed since last time. Reading all forty in order is how attendance dies. 3. **Have one senior person ask about a named row.** Not "any risks?", which reliably produces silence, but "R-07, what happened with the pairing?". Rotate which row so nobody games it. 4. **Close risks out loud.** Give the reason (it happened, the window passed, we accepted it) and move it to a closed section rather than deleting it. A register that only ever grows stops being read, because the reader cannot tell which rows still matter. 5. **Promote risks that have occurred.** Once a risk has happened it is an issue and needs a recovery plan, not a mitigation. Leaving it in the risk list flatters the numbers and delays the response. 6. **Re-read the register after any change of shape.** A slipped date, a scope change, a supplier swap or a person leaving should each trigger a pass through the existing rows. New risks appear less often than existing risks change score. 7. **Check the owners still work here.** Owner turnover is the quietest way a register goes stale. Every row whose owner has moved on is effectively unowned. 8. **Let risks be added between reviews.** If new rows only appear at the review, people are storing them up, and the risks that matter tend to arrive on a Tuesday afternoon. There is a fast diagnostic for a dying register: sort it by last-updated date. Anything that has not moved in three months is usually one of two things. It has already happened and become an issue nobody wanted to declare. Or it was never a risk, just a permanent condition of the work, in which case it belongs in your assumptions and should stop consuming review time. Either way the row is not doing the job it was written for. ## What is the difference between a RAID log and a risk log? A risk log tracks one thing, what might go wrong. A RAID log tracks four: risks, assumptions, issues and dependencies. The risk log is a section of the RAID log rather than a competitor to it. | | Risk log | RAID log | |---|---|---| | **What it holds** | Uncertain future events only | Risks, assumptions, issues and dependencies | | **Time frame** | Future | Past, present and future in one document | | **What creates a row** | Something that might happen | Something you assumed, something that went wrong, something you are waiting on, or something that might happen | | **Common failure** | Grows without ever closing | The assumptions section is written once and never revisited | | **Suits** | Small projects, and programmes where risk reporting is contractual | Projects with cross-team dependencies and a lot of unvalidated assumptions | The D is contested. Some organisations read it as decisions, some as dependencies, and a few teams swap the A for actions. None of those is wrong, but a log whose letters are undefined produces four columns of the same content. Write the definitions at the top of the document. If you are still choosing between formats, [which tracker you actually need](/blog/raci-vs-raid-vs-risk-register-which-tracker-do-you-actually-need) compares them against a RACI matrix. The practical case for a RAID log is that assumptions and dependencies are where most risks come from anyway. Recording them in the same file means the risk conversation starts from the things you have already admitted you do not know. ## Who is responsible for maintaining a risk register? The project manager maintains the register as a document, but each row is maintained by its named owner. Those two jobs are routinely confused, which is how a project manager ends up guessing at updates for risks they cannot influence. The sponsor sits above both. They are accountable for whether the current risk position is acceptable, which means they should be reading the register rather than receiving a summary of it. Where a risk crosses into another team's territory, ownership sits with the person who can act, not the person who spotted it. [Roles, accountability and handoffs on the risk register and RAID log](/blog/who-owns-the-risk-register-and-raid-log-roles-accountability-and-handoffs) works through the boundaries, including what happens at project close. ## Is a risk register a legal requirement? For most projects, no. There is no general legal duty in the UK to keep a project risk register, and nothing obliges a marketing campaign or a software release to maintain one. Adjacent duties often force something equivalent. Employers must assess health and safety risks to workers and record the significant findings once they employ five or more people. Organisations processing personal data in high-risk ways must carry out a data protection impact assessment. Larger charities report on risk management in the trustees' annual report. Regulated sectors, public bodies and listed companies carry their own requirements, usually about the organisation's risks rather than any single project's. In practice the binding requirement is contractual rather than statutory. Funding agreements, framework contracts and public sector procurement routinely specify a risk register, a review frequency and a reporting format. Check the contract before you check the law. This is general guidance and not legal advice, so where a duty might apply, get it confirmed by someone qualified. ## Frequently asked questions **What is another name for a risk register?** Risk log is the most common alternative and means the same thing. You will also see risk repository, risk schedule, and RAID log where risks sit alongside assumptions, issues and dependencies. Risk matrix is used loosely as a synonym but properly refers to the grid of likelihood against impact, which is a scoring aid rather than the list itself. **Who is responsible for the RAID log?** The project manager keeps the document, but each section has a different real owner. Assumptions belong to whoever made them and should be validated by that person. Issues belong to whoever is fixing them. Dependencies belong to whoever is waiting on the other team. If every line in all four sections names the project manager, nobody outside the role is engaged. **What is the difference between a risk and an issue?** A risk might happen and an issue already has. The test is tense, not severity. If the supplier is late today, that is an issue and it needs a recovery plan. If the supplier might be late in October, that is a risk and it needs a mitigation. Keeping the two in separate lists stops the register filling with problems that need action now. **Should a small project bother with a risk register?** Yes, but keep it to a handful of rows in whatever document you already use. Five real risks with named owners beat a forty-row template nobody opens. The value on a small project comes from having said the uncomfortable things out loud and written down who is watching each one, not from the format of the file. **Where should a risk register live: a spreadsheet or a project tool?** A spreadsheet is fine and is what most teams use. Project tools give you history, notifications and an audit trail, which matter when the register is contractual or when several people update it. Whichever you pick, keep one copy. Registers pasted into status packs quietly become forks, and then two versions disagree about what is open. Creating a register is an hour of structured conversation and a solved problem. Whether it is still worth reading in November comes down to two decisions made on the day you build it: which existing meeting reviews it, and who will ask about a named row. The rest is formatting. ### How to Run a Project Review Meeting (and a Design Review) https://projan.ai/blog/running-engineering-review-meetings-design-reviews-project-reviews-and-who-owns/ Published: 2026-08-10 Run a project review meeting by circulating the material at least two working days ahead, opening with the decision you need rather than a status recap, timeboxing each open question, and closing with named owners and dates. A review that ends without a decision was a status meeting with a more serious title. Design reviews and project reviews are forward-looking: they exist to settle something before the work continues. [Retrospectives and blameless postmortems](/blog/postmortems-in-engineering-what-they-are-and-how-to-keep-them-blameless) look backwards at work already done and run on different rules, so nothing below applies to them. ## Design review or project review: two different meetings A design review decides whether a proposed technical approach is sound. A project review decides whether work already underway should continue as planned. Teams that treat "engineering review" as one meeting end up with a room half full of people who have no stake in the question. | | Design review | Project review | |---|---|---| | **Question it settles** | Is this the right way to build it? | Should this carry on as planned? | | **Called by** | The engineer or team proposing the design | The person accountable for delivery | | **Core attendees** | Author, owners of the systems it touches, one approver | Delivery owner, one voice per workstream, whoever controls budget or people | | **Pre-read** | The design document | Progress against plan, risks, decisions needed | | **Typical length** | 45 to 60 minutes | 30 to 45 minutes | | **Exit conditions** | Approved, approved with conditions, or rework with named concerns | Continue, change scope, change the date, or stop | | **Cadence** | Per significant design | Fixed interval, or at phase boundaries | The exit conditions are the part worth copying. A meeting with no defined ways to end will find one anyway, usually "let's pick this up next week", which is the only exit that costs a fortnight. ## Who calls a review, who can block it, and who decides Four roles need naming before the invite goes out: the caller, the required reviewers, whoever holds a block, and the single person who decides when the room does not agree. Most advice stops at "get the right people in the room", which is precisely the part nobody can act on. **The caller** is whoever wants something decided. They own the pre-read, the agenda and the follow-up. This is not a rotating chair duty handed to whoever is free that week. **Required reviewers** are the people whose absence means the meeting is rescheduled. Everyone else is optional and should be told so in plain words. An invite listing twelve people and requiring none of them is the reason none of them prepare. **Blocking rights** should be narrow and written down. A reviewer can reasonably block on security, data protection, backwards compatibility, on-call burden, or a commitment already made externally. Personal taste and "I would have done it differently" are comments, not blocks. Require that a blocking objection state what would resolve it. An objection with no stated remedy is an opinion with a veto attached. **The decider** is named before the argument, not after it. Consensus is a good outcome and a poor mechanism, because when it fails the decision defaults to whoever is most senior or most persistent, and neither correlates with being right. On a design review it is usually the team who will operate the thing once it ships, not the manager who booked the room. Put those four names on the invite. It tells everyone what their attendance means. ## How to run a project review meeting 1. **Write down the decision the meeting exists to make.** One sentence, in the invite. If you cannot write it, what you want is a status update, and a status update should be a document. 2. **Circulate the pre-read two working days out.** Include the specific question each required reviewer is being asked. "Please review" gets skimmed on a phone; "Priya, does the migration window clash with the billing freeze?" gets answered. 3. **Open with the decision, not the recap.** Spend the first two minutes on where the meeting has to get to and what happens if it does not. 4. **Timebox each open question and hold the box.** When a discussion needs data nobody has, park it with an owner and a date rather than reasoning your way through it live. 5. **Take a position from each required reviewer.** Approve, approve with conditions, or block with the condition that would clear it. Silence recorded as agreement is how a reviewer ends up objecting in a pull request three weeks later. 6. **Record decisions as they are made.** Decision, decider, date, and the options rejected with the reason. 7. **Close the loop within a day.** Actions go into the tracker with owners, not into a notes document only the author reopens. Step six is where teams leak the most value. A record written afterwards is written by one person from memory, and the reviewers who disagreed are no longer there to argue with it. Some teams move the capture into the channel where the argument already happens: Projan, for instance, presses for a named owner and a date against each unresolved concern during the discussion, then exports the agreed actions to Jira or Linear. Either way, a working [decision log](/blog/decision-logs-for-engineering-teams-what-to-record-and-how-to-keep-one-current) beats polished minutes. ## Who performs design reviews? Design reviews are performed by the engineers who will have to live with the design, plus at least one person senior enough to say no. Not by a committee, and not by the author's manager alone, which tests for career risk rather than design risk. A workable room: - The author, presenting and answering - One owner from each system the design calls, changes or depends on - A staff engineer or tech lead with authority to approve - Security, where the design touches authentication, personal data or a new external surface - Whoever carries the pager for the affected service - Anyone who wants to learn, on the explicit basis that they do not block Six or seven people is comfortable. Past ten, the meeting becomes a performance and the quiet reviewer with the real objection stays quiet. Where a written process already exists for larger proposals, the review sits at the end of it, and [the RFC process](/blog/the-engineering-rfc-process-what-it-s-for-when-to-write-one-and-who-decides) sets out who signs. ## What to do when nobody has read the pre-read If more than one or two required reviewers arrive unprepared, convert the first fifteen minutes into silent reading with comments open. Reading a design document aloud is the most expensive method of file distribution ever invented, and it buys agreement from a room that has had four minutes to think. Four things reduce the problem: - **Cap the length.** A design document beyond about six pages will not be read by busy people. Put the decision and the trade-offs at the top, detail in appendices. - **Ask each reviewer a specific question**, in the invite, by name. Generic requests get generic attention. - **Make the reading block permanent** if the team consistently arrives cold. It is cheaper than a second meeting and much cheaper than a bad decision. - **Fix the list rather than the people.** A required reviewer who never reads is not a required reviewer. Change what is expected of them, or take them off the list. The temptation is to treat this as a discipline problem. Usually it is a scheduling one. ## Who is responsible for API testing? The team that owns the API is responsible for testing it. QA can design the approach, build tooling and add coverage, but accountability for a broken contract sits with the service team, not with whoever last ran the suite. The layers split like this: - **Unit and contract tests**: the implementing engineer, in the same pull request as the change - **Consumer-driven contract tests**: owned by the provider, with consumers publishing their expectations - **Integration and end-to-end**: shared, with a named owner per suite, otherwise nobody fixes the flakes - **Load and security testing**: often specialist support, still signed off by the service owner - **Exploratory and release regression**: QA where the function exists, the team where it does not Settle this in the design review rather than at release. Ask which layers will exist and who writes them, because "QA will cover it" names no one. It belongs in [an API design review](/blog/how-to-plan-an-api-design-and-get-it-reviewed-before-you-ship-it) alongside versioning and deprecation. ## Frequently asked questions **How do you conduct a review meeting without it drifting into status?** Chair it against the decision, not the agenda. State the decision at the top, hold each item to its timebox, and when a discussion needs data nobody has, park it with an owner and move on. Ask for positions rather than opinions. If the decision is made in the first ten minutes, end the meeting there. **How long should a design review be?** Forty five to sixty minutes for a design of real consequence, with the document circulated beforehand. Anything shorter tends to approve on vibes; anything longer usually means the design was not ready or the room was too big. If you need a second session, book it for a specific unresolved question rather than a general continuation. **Can a design review be done asynchronously?** Yes, and most should be. Circulate the document with a comment deadline and a named approver. Call a synchronous session when the comments start disagreeing with each other rather than with the author, when the decision is expensive to reverse, or when a reviewer has raised a blocking concern that needs negotiating rather than answering. **What should the written record of a review contain?** Four things: the decision, the person who made it, the date, and the options rejected with the reason. Add any conditions attached to an approval, and the owner of each one. Discussion summaries age badly and nobody reads them. A reader six months later needs to know what was decided and what was ruled out. Review meetings fail on ownership far more often than on agenda design. Name the caller, the required reviewers, the people who can block and the one person who decides, then hold the meeting to an exit condition rather than to the end of the hour. ### Strategy vs Plan: Which Comes First, and Why a Plan Alone Isn't a Strategy https://projan.ai/blog/strategy-vs-plan-which-comes-first-and-why-a-plan-alone-isn-t-a-strategy/ Published: 2026-08-10 Strategy comes first. A plan is a sequence of actions, and without a diagnosis of the problem you are sequencing work towards a goal nobody has justified. A plan can be immaculate, fully resourced and on schedule, and still be the wrong plan. The diagnosis is the part teams skip. This is written for tech leads and engineering managers who keep being handed a roadmap and asked to call it a strategy. It covers the order the two things go in, why a plan on its own is not a strategy, what a strategy with no plan degrades into, and the cases where you genuinely only need the plan. ## What comes first, strategy or plan? Strategy comes first, because the plan is downstream of a choice that the strategy makes. Richard Rumelt, in Good Strategy Bad Strategy, describes a strategy kernel with three parts: a diagnosis of what is actually going on, a guiding policy for dealing with it, and a set of coherent actions that follow. The plan is the third part. Written without the first two, it is a schedule. Take a real one. "Migrate to microservices by Q3" is a plan. It has a target, a date and an implied set of tickets. It contains no diagnosis at all, so nobody can tell whether it is the right work. The missing half sounds like this: deploys are coupled, two teams cannot ship independently, and the queue in front of every release is what is costing us. Now the plan is arguable. Someone can reasonably say that a deployment pipeline change would fix the coupling faster than a service split, and that argument is the useful one. Without the diagnosis there is nothing to argue with, only a date to slip. | | Strategy | Plan | |---|---|---| | **Question it answers** | What is our real problem, and what are we choosing not to fix? | What are we doing, in what order, by when? | | **Shape** | A page of argument | A sequence of work with owners | | **How it fails** | It is wrong about the problem | It is late, or it does not deliver what was scheduled | | **What invalidates it** | New evidence about the problem | Changed capacity, dependencies or scope | | **Who should challenge it** | Anyone who can see the system | The people doing the work | The order matters more than the artefacts. Plenty of good teams hold the strategy in three sentences and never write it in a document. What they do not do is start sequencing before they can say what the sequence is for. ## Why is a plan not a strategy? A plan is not a strategy because it contains no choice. It says what you will do, not why that beats the alternative you rejected, and a strategy that rejects nothing is not making a decision. Rumelt's sharpest point is that most bad strategy is goals dressed up as strategy: a statement of where you want to end up, presented as though it explained how to get there. Three things get called strategy on engineering teams and none of them are: - **A roadmap is not a strategy.** It is a strategy with the argument deleted. Quarterly columns of features tell you the sequence and hide the reasoning, which is why roadmap reviews turn into negotiations about dates rather than about problems. A roadmap is still worth having, and [there is real craft in setting its detail, timeframes and dates](/blog/how-to-create-a-product-roadmap-detail-timeframes-and-dates), but it is an output. - **An OKR set is not a strategy.** Objectives and key results measure whether you got somewhere. They do not say why that place is worth reaching or what you are giving up to reach it. Reduce p99 latency to 200ms is a fine key result and a terrible strategy, because it is silent on whether latency is the thing hurting you. - **A goal with a date is not a strategy.** "Zero P1 incidents by December" describes an outcome you would obviously prefer. Every team would prefer it. The strategy is the unpopular part: which class of incident you will invest in eliminating, and which you will accept and page someone for. The test is subtraction. Remove the numbers and dates from the document and see what is left. If what remains is a list of things you would like to be true, you were holding a plan. If what remains is a claim about your situation that a competent colleague could dispute, you were holding a strategy. The same distinction runs through testing, where [a test strategy and a test plan are separate documents with different owners and different lifespans](/blog/test-plan-vs-test-strategy-vs-qa-plan-who-writes-what-and-when). ## What is a strategy without a plan? A strategy without a plan is an opinion. It is the more comfortable failure, because nobody gets blamed for it and the document usually reads well. Six months later the diagnosis is still accurate and nothing about the system has changed. The pattern is familiar. A staff engineer writes a clear-eyed piece about why the deploy pipeline is the constraint. Everyone who reads it agrees. It gets linked in Slack a few times. No work is scheduled against it, no owner is named, no first change lands, and the next planning cycle allocates capacity to feature work as usual. The strategy was correct and had no consequences. Coherent action is the part that makes a strategy real, and coherence is stricter than it sounds. It means the actions reinforce each other and that you can point at each one and say which part of the diagnosis it addresses. If half the roadmap has no line back to the diagnosis, either the diagnosis is incomplete or that work is there for other reasons. Both are worth knowing before the quarter starts. ## When a plan on its own is enough Often, and pretending otherwise is how strategy becomes ceremony. If the diagnosis is already agreed and uncontroversial, you do not need to restate it as a strategy layer. You need a plan and someone to run it. Work that just needs a plan: - The Node runtime reaches end of life in four months and you have to be off it - A vendor deprecates an API with a published shutdown date - Remediation items from an incident, where the postmortem already established the cause - Routine dependency and certificate work with a known cadence What these share is an external constraint doing the diagnostic work for you. The problem statement is not in dispute, the option space is small, and the interesting questions are all about sequencing, risk and cutover. Adding a strategy document to that is theatre, and experienced engineers read it as theatre. The honest signal is disagreement. If you can state the problem in one sentence and nobody in the room argues, go and plan. If two senior people describe the problem differently, stop planning, because you are about to schedule work that only one of them believes in. ## How to pressure-test a plan before you schedule it Run this before capacity gets allocated, not at the review afterwards. It takes about twenty minutes and it is mostly writing things down that people assume are shared. 1. **State the diagnosis in one sentence.** No goals, no solution, just what is going wrong and why. If it takes a paragraph, you have more than one problem and should say which you are attacking first. 2. **Name what you are not doing.** A strategy with no sacrifice is a wish list. Write the two or three credible options you are turning down, so that when someone proposes one in month three there is a record of it having been considered. 3. **Say what would have to be true.** Every plan rests on assumptions about traffic, team size, vendor behaviour or the shape of the existing code. List them. These are the things that will actually break the plan. 4. **Check each work item against the diagnosis.** Take the top ten tickets and mark which part of the problem each one addresses. The unmarked ones are not necessarily wrong, but you should be able to say why they are in this quarter. 5. **Decide what would make you stop.** A signal and a review date. Plans that cannot be abandoned are not plans, they are commitments with Gantt charts attached. The output of that conversation needs somewhere to live where the team can argue with it later. An architecture decision record is the usual home on engineering teams, and [writing an ADR your team actually reads back is a specific skill](/blog/how-to-write-an-architecture-decision-record-adr-that-your-team-actually-uses); at company level the equivalent is [a strategy memo with a real statement at its core](/blog/how-to-write-a-strategy-memo-and-the-strategy-statement-at-its-core). Teams that would rather not book another meeting for it sometimes use Projan, which asks the clarifying questions in Slack, keeps the rejected options recorded next to the chosen one, and exports the agreed work to Jira or Linear. What matters is that the diagnosis is written where the people who will be held to the plan can see it and push back. ## Frequently asked questions **Who owns engineering strategy on a team without a CTO?** Usually the most senior engineer with enough context to see across teams, working with whoever controls headcount. Ownership means writing the diagnosis down and defending it, not deciding alone. If nobody holds the pen, the strategy defaults to whatever the loudest roadmap item implies, which is how teams end up committed to work nobody chose. **What is the difference between a strategy and a tactic?** A strategy is the choice about which problem to attack and what to give up. A tactic is one move that serves that choice. Extracting billing from the monolith is a tactic. Deciding that deployment coupling matters more than latency this year is the strategy underneath it. Tactics are cheap to change and strategies are not. **How often should an engineering strategy be rewritten?** Rewrite it when the diagnosis stops being true, not on a calendar. A strategy built around scaling limits becomes obsolete the moment traffic flattens, however recently you wrote it. Quarterly reviews are useful for checking whether the diagnosis still holds, but a strategy that changes every quarter was probably a set of goals in the first place. **Is a technical strategy the same as a product strategy?** No, though they should agree. A product strategy chooses which users and problems the company serves. A technical strategy chooses what the system must be good at to make that possible, and what it is allowed to be bad at. When they disagree, engineering usually ends up optimising for something the product no longer needs. Strategy first, then the plan, and the join between them is a diagnosis somebody wrote down and other people were allowed to attack. Most engineering plans that go wrong were never wrong about the work, only about the problem. Ask what you are choosing not to fix, and if the answer is nothing, you have a schedule. ### The 30-60-90 Day Plan: How to Build One That Actually Works https://projan.ai/blog/the-30-60-90-day-plan-how-to-build-one-that-actually-works/ Published: 2026-08-10 To make a 30-60-90 day plan, decide which document you are writing. One is a candidate's pitch, drafted before an interview from outside the company. The other is an onboarding ramp, written by a manager and a new starter together. Set three review points, weight the first month towards learning, and phrase every item so it can be marked done. This is employee onboarding, not client onboarding. The reader is a manager writing a ramp for someone starting on Monday, an HR lead standardising the format, or a candidate who has been asked to bring a plan to a second interview. Those are different jobs, and most of the trouble with 30-60-90 plans comes from treating them as one. ## What is a 30-60-90 day plan? A 30-60-90 day plan is a short document setting out what someone will learn, own and deliver across their first three months, with review points at roughly day 30, day 60 and day 90. The format is used for two entirely different purposes, and templates rarely say which one they are. | | Candidate version | Onboarding version | |---|---|---| | **Who writes it** | The candidate, before or during interview | The hiring manager and the new starter, jointly | | **Who reads it** | An interview panel | The starter, their manager, the wider team | | **Information behind it** | A job advert and a few conversations | The actual team, backlog and calendar | | **Judged on** | Quality of reasoning | Whether it happened | | **Typical failure** | Confident promises about a business the writer has never seen inside | Vague items nobody can mark done | The candidate version is an argument. The onboarding version is a schedule. Confusing them produces the worst of both: a manager who hands a new starter something that reads like a pitch, full of ambition and empty of dates. If you are building the wider new-starter process rather than one person's ramp, the 30-60-90 plan sits inside it. It is one artefact among several, alongside the checklist and the first-week schedule covered in [employee onboarding plans](/blog/employee-onboarding-plans-what-to-include-stages-and-real-examples). ## How to structure a 90 day plan Structure it as three review points, not three equal workloads. The first month should be weighted heavily towards learning and meeting people, the second towards owning work with a safety net, the third towards owning an outcome outright. **Days 1 to 30, learning.** The output of this month is understanding, but understanding only counts if someone can check it. Useful items look like this: - Can name the five people whose work most affects this role, and what each of them needs from it - Can explain how the organisation makes its money, or where its funding comes from, without hedging - Has completed one small piece of real work end to end, however trivial - Has attended each recurring meeting once and knows what it decides **Days 31 to 60, owning with support.** The starter takes a recurring piece of work and runs it, with the manager reviewing rather than doing. One inherited process gets improved. The first real feedback conversation happens here, in both directions, and it is far easier at day 45 than at day 89. **Days 61 to 90, owning outright.** By now there should be one thing the person is unambiguously responsible for, with a result attached that someone outside the team would recognise. They should also be able to say what they would change, and be listened to when they say it. A new starter who has no opinion by day 90 was probably never given anything to have an opinion about. A plan that expects delivery in week two is not a ramp. It is a description of the vacancy, written by someone who needed the headcount three months ago. ## How to make a 30-60-90 plan Build it backwards from what the role is supposed to produce, then work out what the person needs to learn in order to produce it. The sequence below takes about an hour and is best done in the week before the start date. 1. **Decide who is writing it, and with whom.** The manager drafts. The new starter rewrites it in week one, once they have met the team, and the rewritten version is the real one. A plan handed over unchanged on day one is a plan the starter never agreed to. 2. **Start from the outcomes, not the tasks.** If nobody has written down what success in this role looks like, do that first. [A role scorecard is the document that answers what good actually means in this job](/blog/role-scorecards-explained-how-to-create-one-for-any-job), and a 30-60-90 plan without one tends to fill up with activity instead. 3. **Turn each outcome into things the person must be able to do unaided.** Not "understand the reporting stack" but "can pull last month's numbers without asking anyone". 4. **Name the person on the other side of every learning item.** Someone has to explain how billing works. If no name is written next to that item, it will not happen, because it depends on a colleague finding an hour for a person they have not met. 5. **Put the three reviews in the calendar before day one.** Thirty minutes each, dated. Reviews that are not diarised do not happen, and day 60 passes in silence. 6. **Cut it until it fits on a page.** Five to eight items for the first month, fewer for each month after. Leave room, because real work will arrive in week two whatever the plan says. Step 4 is the one that gets skipped, because it means asking other teams for time rather than typing. The asking is what [Projan](/landing/onboarding-gaps) is for at this step: it puts the questions to the group in Slack or Microsoft Teams, so the finance lead who has to explain the revenue model is in the thread when the commitment is made, and it writes the agreed items out to Asana or Trello with dates attached. However you do it, the commitments should come from the people making them. ## How detailed should a 30-60-90 day plan be? Detailed enough that a third party could mark each item done or not done, and short enough that the new starter reads all of it. Those two constraints do more work than any template. Detail should decay with distance. Days 1 to 30 can be specific, because you know what exists today. Days 61 to 90 should be directional, because month one will teach both of you things that make month three wrong. Writing precise day-80 deliverables before the person has met the team is confident and useless. A practical test: read each item and ask who says whether it happened. "Build relationships with key stakeholders" has no such person. "Has had a one-to-one with each of the four team leads" has four of them. Items that fail this test are not motivational, they are decorative, and they are the reason so many plans quietly stop being referenced after week three. ## Writing a 30-60-90 day plan for an interview A candidate's 30-60-90 plan is judged on how you think, not on whether you are right. You are writing about a company you have seen from the outside, using a job advert and two conversations, so accuracy is not available to you and pretending otherwise is the trap. The strongest version asks more than it asserts. Structure it as what you would want to find out, what you would expect to be true, and what you would do differently depending on the answer. "In the first month I would want to know how support tickets are currently triaged and who decides priority. If it turns out that engineering triages directly, the first thing I would look at is..." That shows a panel your reasoning and gives them something to react to. The weak version commits to numbers. Promising to increase pipeline by twenty per cent in ninety days, based on a job advert, reads as naive to anyone who has run the function. An experienced interviewer hears a candidate who has not yet realised how much they do not know. Keep the commitments conditional, state your assumptions plainly, and keep it to a page unless you were explicitly asked for a presentation. ## What is the 30-60-90 rule in leadership? Applied to a new leader, it means diagnosing before changing anything, on the grounds that the credibility to make changes is earned in the first month rather than granted at the offer stage. The content shifts from systems and tools to relationships, decision rights and inherited commitments. Michael Watkins's The First 90 Days is the book most managers are half-remembering when they use this language. Its argument is that a transition strategy should be matched to the situation being inherited, since taking over a turnaround is a different job from taking over something that already works. The three-month framing itself is older and more generic than any single book, so treat 30-60-90 as a convenient rhythm rather than a method with an owner. The specific failure for new leaders is the week-three reorganisation. It is usually a signal that someone arrived with a plan formed before they had met anyone, which is exactly what the first thirty days are supposed to prevent. ## What are common mistakes in a 30-60-90 day plan? The most common mistake is writing items nobody can mark done. Every other failure on this list follows from something similar: a plan that looks reasonable on paper and cannot be checked in practice. - **Unfalsifiable items.** "Immerse yourself in the culture" cannot be completed, so it is never completed. - **Delivery expected in the first fortnight.** The person is still working out who to ask about the staging environment. - **Written by one person and handed over.** Authorship is what turns a plan into a commitment. A document received is a document ignored. - **Straight from a template.** Generic plans contain items belonging to a role nobody at your organisation holds. - **Learning goals with no named teacher.** Every learning item is a request for someone else's time, whether or not you asked them. - **No diarised reviews.** Day 60 arrives and nobody notices. - **Ninety days of detail written before day one.** Month three is a guess. Write it as a guess. - **A plan created because there is already a problem.** That is a different document with different rules, and calling it a 30-60-90 plan helps no one. That last point needs care. A 30-60-90 plan is a development tool, and it changes character the moment it is used as evidence about someone's suitability. Probation terms come from the employment contract, and the rules around notice and dismissal vary considerably by jurisdiction, so take that path through your own HR or legal advice rather than through the ramp document. Keep genuine performance concerns in the process built for them, such as [a properly planned review cycle](/blog/how-to-plan-a-performance-review-cycle-phases-timeline-and-owners), where both sides know what the conversation is. ## Frequently asked questions **What is the 30-60-90 onboarding rule?** It is a convention rather than a rule. Someone decided that three review points a month apart was a sensible rhythm for a new starter, and the name stuck. Nothing breaks if your checkpoints land at four, ten and fourteen weeks instead. The useful part is having fixed dates at all, not the specific numbers. **How many pages should a 30-60-90 plan be?** One page for an onboarding ramp, two at the outside. A candidate version for an interview should be one page or a handful of slides, and building a twenty-slide deck for a job you have not been offered signals the wrong thing. If it runs longer, you have written a job description with dates on it. **Can a 30-60-90 day plan be used personally?** Yes, for a career change or a side project, though it loses the thing that makes it work at a job. Nobody else marks your items done. If you use one personally, borrow that mechanism back: name a real person who will ask you at day 30, and pick items they could verify without taking your word for it. **What happens if the day 30 items are not met?** You find out why before you draw any conclusion about the person. The common cause is organisational: access was not granted, the named expert was on leave, the small first task never materialised. Rewrite the plan around what actually happened. A missed item is information about the ramp as often as it is information about the hire. **Do 30-60-90 day plans work for internal promotions?** They work well, and they get skipped because the person already knows the systems. What they do not know is the new authority: which decisions are now theirs, who expects to be consulted, what they must stop doing. An internal 30-60-90 plan should be almost entirely about relationships and decision rights rather than tools and logins. A 30-60-90 day plan is worth having only if someone can tell whether it happened. Write it with the person it belongs to, name whoever owes them an hour of explanation, and book the three reviews before the first day rather than after the first problem. ### What an Event Brief Should Include (With Structure and Example) https://projan.ai/blog/what-an-event-brief-should-include-with-structure-and-example/ Published: 2026-08-10 An event brief should state the objective and how success will be judged, the audience, the budget as a real number, which dates are genuinely fixed, the non-negotiables including accessibility, who approves decisions, and any commitments already made. It is the document a requester hands to whoever will deliver the event, written before planning starts. A brief is not a plan. It is the input to one. The plan, the [event timeline and the run of show](/blog/how-to-build-an-event-timeline-planning-windows-milestones-and-run-of-show) come afterwards and belong to whoever is delivering; the brief is the requester's side of the exchange and it is finished before the first venue is called. This covers what goes in it, the two sections that most briefs get wrong, and a worked example. ## Start with the outcome, not the format The reason most event briefs are useless is that they describe an event the requester has already imagined. A venue, a format, a month, a rough head count. All of it arrived before anyone asked what the event was supposed to achieve. A brief that opens with "a drinks reception for 150 at a central London venue in October" has skipped the only question that matters. Achieve what? Renew fifty accounts that are up in Q4? Get thirty engineers to meet the people whose code they review? Those two events look nothing alike, and neither of them is necessarily a drinks reception. A planner given the outcome can propose something better than the thing you pictured. A planner given the format can only book it. If you want the second thing, you are not writing a brief, you are placing an order. So write the objective first, in one sentence, and write the success measure directly under it. "Sixty per cent of invited renewal accounts attend, and each one has a conversation with their named account manager" is a brief. "A well-received evening event" is a wish. ## What should an event brief include? An event brief should include nine sections. Most fit on one page. 1. **Objective and success measure.** What the event is for, and the specific thing you will look at afterwards to decide whether it worked. Attendance is a measure of logistics, not of success, so pair it with something about what attendees did. 2. **Audience.** Who they are, roughly how many, and, more usefully, why they would give up an evening or a working day for this. If nobody can answer the second part, the format is not the problem. 3. **Budget.** A number or a range. See below. 4. **Dates and constraints.** The dates you want, and separately, which are genuinely immovable and why. A board meeting is fixed. A vague preference for early autumn is not, and labelling it as fixed removes options for no gain. 5. **Format preferences.** Flag these as preferences. If you want a panel, say so and say what you think it achieves, so a planner can propose something that achieves it better. 6. **Non-negotiables.** Accessibility requirements, dietary provision, travel and timing limits, brand or legal constraints, anything that cannot be traded away later. 7. **Approvals.** Who signs off spend, who signs off the guest list, who signs off content, and how quickly each of them responds. A two-week approval loop on a six-week lead time is a scheduling fact, not an inconvenience. 8. **Commitments already made.** Everything you have promised, booked, held or announced before writing this. 9. **Who provides what.** What you will supply (the speaker list, the guest data, the branded assets) and what the planner is expected to source. Assume nothing here is obvious. ## The commitments you have already made This is the field everyone forgets and the one that wrecks proposals. By the time a brief gets written, the requester has usually held a venue, asked a speaker, told a client the date, or mentioned it in an all-hands. None of that reaches the brief, because it does not feel like a requirement. It feels like progress. It is neither. It is a constraint, and an expensive one to find halfway through a proposal. A planner who spends two days on an alternative approach, then hears that the CEO already promised a keynote to a partner, has been wasting time on your behalf. List every commitment with the name of whoever made it and whether it can still be unmade. Prising those out of people's heads is a question-asking job rather than a writing job. Projan can pull the original Slack or Microsoft Teams thread into a planning session as context and then put the questions to the requester and to whoever made the promise, so what was actually committed is written down before anyone proposes something incompatible with it. ## Why refusing to state a budget costs you money Refusing to state a budget is the most common brief failure and the one that most reliably backfires. The theory is that naming a number invites a supplier to spend all of it. What happens instead is three proposals costed at random, none comparable with the others, then a round of rework once everyone learns what you were willing to spend. Write a real number or a real range. "Fifteen to twenty thousand, including venue and catering, excluding staff travel" tells a planner what kind of event they are designing. "Competitive" and "we are flexible for the right idea" tell them nothing, and both usually mean the number exists and is being withheld. If the budget genuinely is not signed off, say that. An unapproved ceiling with a decision date attached is still information. ## Accessibility is a brief item, not a venue question Accessibility belongs in the brief because it constrains venue, format and cost from the first shortlist. Discovered later, at the site visit or worse in the week of the event, it either forces a venue change or produces the retrofit that everyone can see: the accessible entrance round the back, the interpreter booked too late, the step-free route that ends at the stage. Put the specifics in writing. Step-free access to every part of the event including the stage, hearing loop or captioning, a quiet space, dietary provision beyond one vegetarian option, and how far anyone should have to travel between sessions. If there is a registration form or an event website, name who is accountable for those meeting the same standard, because the first barrier most attendees meet is the sign-up page. ## What does an event brief look like? It looks like one page of short labelled sections, written in plain sentences, with numbers where numbers exist. Not a deck, not a form with forty fields, and not prose. The difference between a brief that works and one that does not is rarely structure. It is the specificity of each line. | Section | Weak line | Strong line | |---|---|---| | Objective | Build stronger relationships with key customers | Get the twelve accounts renewing in Q4 into a conversation with their account manager before the renewal call | | Success measure | Positive feedback | Nine of the twelve attend, and each account manager files one note on what the customer said | | Audience | Senior customer stakeholders | Decision makers at twelve named accounts, mostly ops directors, who will not travel more than an hour after work | | Budget | Competitive, open to ideas | 18,000 to 22,000 including venue, catering and AV; staff travel sits on a separate cost centre | | Dates | Autumn, ideally October | Any Tuesday or Wednesday between 6 and 24 October. Nothing after 24 October, the renewal window closes | | Commitments | Nothing noted | Venue held on a provisional 48-hour option until 12 September, our CMO has been told she is speaking | Six lines like the right-hand column beat three pages like the left. A planner reading them can tell you within a day whether October is realistic and which of your assumptions will break first. Once the brief is agreed, ownership moves across and [the planning process, roles and handoffs](/blog/how-to-plan-a-corporate-event-owners-roles-and-the-full-process) take over. ## Frequently asked questions **What are the parts of an event brief?** Nine sections cover most events, but four of them carry the weight: the objective with its success measure, the budget, the fixed dates, and the commitments already made. On a small internal event you can write those four on half a page and skip the rest. On anything with external guests, add accessibility, approvals and the split of responsibilities. **How long should an event brief be?** One page for a routine internal event, two or three for a conference or an external launch. Length is a poor test. The better test is whether a planner who was not in any of your conversations could read it and come back with a proposal you recognise. If they would have to guess at the budget or the deadline, it is too short. **Who writes the event brief, the requester or the planner?** The requester writes it, because it records what they want and what they have already committed to. A good planner will help draft it by asking questions, and that is fine. What does not work is the planner writing the brief alone and sending it back for approval, because the requester then signs off an interpretation rather than stating an intention. **What is the difference between an event brief and an event proposal?** The brief states the problem and the constraints. The proposal answers it with a format, a venue, a schedule and a price. The brief goes from requester to planner; the proposal comes back the other way. If your brief already contains a venue and a running order, you have written a proposal to yourself and left the planner nothing to solve. A brief earns its place by removing guesswork, so agonise over three sections: the objective, the budget, and the list of things you have already promised. Get those right and a competent planner handles the rest. Get them wrong and you find out in week four, when [the errors that cost real money](/blog/common-event-planning-mistakes-and-how-to-catch-them-before-they-cost-you) start surfacing. ### What Good Requirements Look Like (and How to Write Them) https://projan.ai/blog/what-good-requirements-look-like-and-how-to-write-them/ Published: 2026-08-10 A good requirement states one thing that someone can check. It names who does what and under what conditions, and it says what must be true rather than how to build it. The quickest test is to read it back and ask how you would demonstrate it had been met. If nobody in the room can answer, it is a wish. This is about the individual requirement on the page: what a strong one looks like, and how to write one. Which document it belongs in, and how you get the information out of people, are separate jobs. Everything below works one sentence at a time. ## What do good requirements look like? A good requirement is short, singular and checkable. The widely agreed quality attributes are that it should be unambiguous, testable, necessary, feasible, complete, consistent with the rest of the set, and traceable to a reason. They appear in ISO/IEC/IEEE 29148, the requirements engineering standard, though nobody needs the standard in front of them to use them. - **Unambiguous.** Two people reading it separately build the same thing. - **Testable.** You can describe how you would demonstrate it is met. - **Necessary.** Delete it and something a user or the business needs stops working. - **Feasible.** It can be built inside the constraints you have, not the ones you wish you had. - **Complete.** It does not rely on a fact that exists only in someone's head. - **Consistent.** It does not contradict another requirement in the same document. - **Traceable.** Six months later you can say who asked for it and why. That list is easy to nod at and hard to apply. Here it is applied to five ordinary sentences. | Weak version | What goes wrong | Stronger version | |---|---|---| | Users can export and email reports. | Two obligations in one line, so half can fail while the line is ticked. | Split it. "A user can export a report as CSV." and "A user can email an exported report to any address in their own organisation." | | Reports must be approved before publication. | No actor, so at build time somebody picks one. | A finance manager must approve a report before it can be published. | | The system supports relevant file types. | Unbounded set, so the reader decides what relevant means. | Uploads accept PDF, PNG and JPEG files up to 10 MB. Anything else is rejected with a message naming the accepted types. | | A confirmation email is sent when an order is placed. | Silent on failure, so the failure path gets invented under pressure. | A confirmation email is sent within 60 seconds of an order being placed. If the send fails, the order remains valid and the failure is queued for retry. | | Admins can manage users. | "Manage" hides five behaviours with different permissions. | An admin can create, deactivate and reset the password of any user in their own organisation. Admins cannot delete users. | Notice what the stronger versions cost. Each needed a decision: which formats, whose approval, what happens on failure, whether deletion is allowed at all. That is the actual work. The writing is the cheap part, which is why vague requirements are so popular. ## Testability is the test that catches everything else If you cannot describe how you would demonstrate a requirement is met, it is not a requirement. It is a preference, and it should be written down as one so nobody gets held to it in a release review. Two sentences fail this more often than everything else combined. **"The system should be fast."** Fast where, for whom, doing what, under what load? Made testable it becomes something like: "Order search returns results in under two seconds for 95% of queries with 200 concurrent users." Three decisions had to happen to write that. Someone chose the operation that matters, someone chose the percentile, and someone accepted the number. Until then, fast means whatever the reader hopes, and readers are optimistic. **"The interface should be intuitive."** This one does not survive being made testable, which is useful information. It can become a usability target with a task attached: "A user who has not seen the product before completes a booking unaided, verified with five participants in moderated testing." Usually it becomes nothing instead, because someone has to say who the user is and which task counts, and nobody wants to be the person who narrows it. That is the honest part. Making a requirement testable does not improve the writing. It forces a decision someone has been postponing. The vagueness was doing a job: it let a meeting end. The numbers are not really a writing decision either. Somebody has to accept them, and that somebody is rarely the person holding the keyboard. Where getting them all in a room is the obstacle, Projan asks in Slack or Microsoft Teams instead, requesting the figure behind each adjective and recording who agreed to it before the requirement is exported to Jira. Where no target can honestly be stated, write the aim down as an aim, label it, and keep it out of the numbered list acceptance is measured against. Fourteen requirements and three stated aims beats seventeen requirements, four of which nobody can fail. ## What is a detailed requirement? A detailed requirement leaves the builder with no question they would have to answer by guessing. It closes gaps. It does not specify the solution, and confusing those two is the most common failure on this list. Compare these: - "The upload screen must show a progress bar with percentage complete." - "A user uploading a file larger than 5 MB can tell that the upload is progressing and roughly how much remains." The first is not more detailed. It is a design decision that has been given a requirement number. It commits you to a progress bar even if the engineer could chunk the upload and confirm it instantly, which would solve the problem better for less money. State the how and you remove the chance of something better arriving from the person who knows the system best. Sometimes the how genuinely is the requirement. A regulator mandates a control, a contract names a format, a design system fixes the component. Write those as constraints and say where the obligation comes from. Constraints you can justify are fine. Constraints that turn out to be one person's habit from a previous job are expensive. On how much detail is enough: stop when the next question a builder would ask has an answer somewhere in the document. Error paths, empty states and permissions are where the missing answers hide, and [they are not edge cases in any useful sense](/blog/edge-cases-are-not-edge-cases). ## How do you write a good requirements specification? Write each requirement so it can be read, understood and verified on its own, then check the set for contradictions. A specification is not a long requirement. It is a collection of short ones plus the discipline that stops them fighting. 1. **One obligation per statement.** If the sentence contains "and", check whether you have written two things that can pass and fail independently. Usually you have. 2. **Give every requirement a permanent identifier** and never reuse it, even after the requirement is deleted. Reused IDs make old review comments lie. 3. **Reserve one modal verb for obligations.** The formal convention is shall for mandatory, should for desirable, may for permitted. RFC 2119 defines those key words for internet standards, which is why they appear capitalised in protocol documents. 4. **Check the set, not only the sentence.** Two requirements can each be well written and still be impossible together. Most product teams do not use shall, should and may, and do not need to. The value is not the vocabulary. It is that obligations become countable: a reviewer searches for shall and gets the full list of what you are on the hook for. Sprinkle it through every sentence including the nice-to-haves and you get the formal look with none of the benefit, which is worse than plain English because it advertises a discipline the document does not have. The conflict check is the step people skip. One requirement says transaction records are retained for seven years. Another says a user who closes their account has all their data removed within 30 days. Both are reasonable, both were written by someone competent, and they cannot both be true. Nobody finds that reading sentences one at a time. ## The requirements nobody writes down until the last week Non-functional requirements are where most teams are weakest, and the pattern repeats: they surface in the final week, when a load test fails or a customer's security questionnaire arrives. They were never hard to write. They had no author. Functional requirements have an obvious owner, whoever wanted the feature. Non-functional ones belong to everybody, so nobody drafts them. Five categories cover most of what goes missing. - **Performance.** An operation, a target, a load and a percentile. - **Availability.** An uptime target, a measurement window, and what happens to in-flight work during a failure. The last part is the one people forget. - **Security.** Authentication, authorisation rules, data at rest and in transit, retention and deletion. Retention needs a figure. - **Accessibility.** State a level: conformance with WCAG 2.2 at level AA, for instance. UK public sector digital services are required by regulation to meet a stated WCAG level, which is why their specifications name one and most commercial specifications do not. - **Capacity and data.** Expected volumes, growth, maximum file and record sizes, and what happens at the limit. Accessibility shows best why naming a standard beats describing an intention. "The site should be accessible" cannot be tested, argued about productively or signed off. A named conformance level can be audited by someone who has never met your team, and it forces the decision while it is still a design constraint rather than a rebuild. ## What are the 7 steps in requirement analysis? There is no canonical seven. Textbooks and training providers each publish their own count and the number is arbitrary. What follows is the sequence that turns one raw request into one written requirement, which is the part most numbered lists skip in favour of the elicitation that comes before it. Methods, stages and handling ambiguity are the other half of the job. 1. **Restate the need without the solution.** If you cannot, go back and ask. 2. **Name the actor.** Anonymous requirements get built for a user nobody has met. 3. **Ask what would count as failure.** The answer becomes your verification method. 4. **Split until each statement carries one obligation.** 5. **Check it against what you already have.** Duplicate, contradiction, or a special case of something existing. All three are common past about fifty items. 6. **Attach the non-functional limits it depends on.** Volumes, response targets, permissions, retention. This is when they are cheap. 7. **Record the source and the decision.** Who asked, what problem it serves, and what you chose where there was a choice. That is what lets the document survive its author leaving. Where all this lands is a separate decision, and BRD, FRD, SRD and PRD are genuinely different documents rather than the same thing renamed. ## Frequently asked questions **Is must better than shall?** Neither is better. Pick one and use it only for obligations. Teams that write shall in every sentence lose the thing the convention exists for, which is being able to count what they are committed to. If your reviewers are business people rather than engineers, must reads more naturally and does the same job. **What makes a requirement traceable?** A permanent identifier, a recorded source and a stated verification method. You should be able to point at any requirement and say who asked for it, what problem it serves and how it will be checked. Traceability earns its keep when somebody proposes cutting scope, because it shows what breaks. **How many requirements is too many?** There is no number, but there is a symptom. Once people stop reading the list and start asking a colleague what is in it, the list has outgrown its readers. Split it by capability so each reader has thirty or so to care about, and keep the rest addressable rather than in front of them. **Can a mock-up serve as a requirement?** Only alongside a written statement of the obligation. A screen design shows one solution to a problem it never states, and it commits you to every detail on it, including the ones the designer had not thought about. Reference the mock-up and say which parts of it are binding. Good requirements are not better written, they are better decided. Take three sentences from your current spec, ask how you would prove each one, and you will find out quickly which are requirements and which are hopes with a number beside them. ### What Should a Status Report Include? The Four Core Sections (With a Reusable Template) https://projan.ai/blog/what-should-a-status-report-include-the-four-core-sections-with-a-reusable-templ/ Published: 2026-08-10 A status report should include four things: where the project stands overall, progress against the plan rather than against effort, the risks, issues and decisions that need attention, and what happens next including what you need from the reader. The last of those is the one most reports leave out. This piece covers the contents. The craft of writing each line is in [how to write a project status report stakeholders actually read](/blog/how-to-write-a-project-status-report-stakeholders-actually-read), and how often to send one belongs in [a project communications plan](/blog/how-to-write-a-project-communications-plan-with-a-reporting-cadence-that-sticks). ## What is a project status report? A project status report is a short recurring written update on one project, sent on a fixed schedule to people who are not doing the work. It carries health, progress, risk and next steps for a single delivery, which separates it from meeting minutes, a record of one conversation, and from a monthly client or funder report, an accountability document covering a period. Most status reports are written to prove that work happened. A report written to get a decision is a different document, and the difference shows up in every line. The proving version narrates activity, avoids the uncomfortable numbers, and ends with nothing for anyone to do. Six weeks of that teaches the distribution list to skim, and the report nobody reads is almost always the one that never asked anybody for anything. ## What should a status report include? Four sections, in this order: overall status, progress against the plan, risks and decisions needed, and what happens next including your ask. The count is a property of the template rather than of the discipline. No standards body defines four, and there are perfectly good reports running on three and on six. What is genuinely established is the progress, plans and problems shape, usually shortened to PPP, and the red, amber and green convention for signalling health. Everything else is house style. 1. **Overall status.** One colour, one short paragraph, and a named thing the colour refers to. "Amber" on its own means nothing. "Amber against the November release, green against budget" is a status. Put last period's colour beside it so the direction is visible, and if it has moved, say what moved it. Some readers will read this section and nothing else, so it has to work alone. 2. **Progress against the plan.** What has finished since the last report, expressed as things that now exist rather than hours that were spent. Three lists do this better than a single figure: finished and demonstrable, in progress with an expected finish date, and not started although it was due to have started. Add a line for anything that slipped, carrying the old date, the new date and the cause. Slippage recorded with its cause is what lets a reader spot a pattern before you do. 3. **Risks, issues and decisions needed.** A risk might happen, an issue already has, and a decision needed is neither: it is work sitting still because somebody outside the team has not chosen yet. Each line takes an owner, a date and a consequence. Report only what changed or what needs the reader. The full register lives in the register, and copying it across every week is how both documents stop being read. 4. **What happens next, and what you need from the reader.** The items due before the next report, each with a name against it, and then the ask: a specific thing, from a specific person, by a specific date. Write "nothing needed this week" when that is true, so an empty section never gets confused with a forgotten one. Most reports stop at the forecast. A forecast tells the reader what you intend to do. The ask is the only part that changes what they do. If you have to drop a section in a bad week, drop the forecast. If you keep only one, keep the ask. ## A status report template you can copy Keep it short enough that writing it weekly is not resented. A template that takes an hour gets abandoned around week four and replaced by a paragraph in a chat channel, which is worse than the template you started with. ``` PROJECT: REPORT DATE: PERIOD: to STATUS: Green / Amber / Red Refers to: Last period: . Changed because: 1. WHERE WE ARE 2. PROGRESS AGAINST PLAN Finished and demonstrable: In progress: Not started, and due to have started: Slipped: 3. RISKS, ISSUES AND DECISIONS Risk / Issue: Decision needed: 4. NEXT, AND WHAT I NEED FROM YOU Due before the next report: I need: or Nothing needed this week. ``` Keep two variants. The short one, for a week when the plan is holding, is the status block, the three progress lists and "nothing needed this week". Four lines sent on the agreed day beats a page sent on Thursday. The long one, for a steering group or a project in trouble, adds a milestone table showing baseline against forecast dates, a budget line, and a log of what has been agreed since the last version. Everything else goes in an appendix nobody is obliged to open. ## Who is the report actually for? One report rarely serves three audiences well, and pretending otherwise is the main reason reports get long. The same facts have to be assembled differently depending on who is reading. | Reader | What they want from it | What they do with it | What to cut | |---|---|---|---| | Sponsor or exec | Exceptions, decisions, money and dates | Approves, funds, unblocks, or leaves you alone | Workstream detail, tool names, anything that has not changed | | Delivery team | Specifics, sequencing, who is waiting on whom | Plans their own week around it | Commercial framing, stakeholder politics | | Client | An honest picture and early warning | Manages their own stakeholders with it | Internal blame, unconfirmed dates, half-formed risks | | Steering group | Trend against the baseline | Decides to continue, change or stop | Anything that is not a delta since the last meeting | Pick one primary reader per report and write to them. Where two audiences genuinely need different things, two short reports beat one long one that satisfies neither: the team's version can be a channel post, the sponsor's a single page. Failing that, put the sponsor's section on top and push the rest into an appendix. ## Why "percent complete" is the weakest number in the report Percent complete is usually a feeling expressed as arithmetic. Almost nobody measures it. Somebody estimates the effort still left, compares it to the effort they imagined at the start, and rounds to the nearest five. That is why projects sit at eighty per cent for a month, and why the last ten per cent routinely takes as long as the first half: it holds integration, sign-off, data cleanup, accessibility fixes and everything deferred for being awkward. The figure earns its place when it counts something countable. "42 of 60 sites migrated" is worth printing, because the denominator is fixed and a reader can check it. "The build is 80% complete" is not, because the denominator moves every time the scope does, and it moves quietly. Otherwise use the three lists. They take longer to write because they commit you to claims someone could check next week. ## Why reports stay green until they cannot Status colours drift green because amber starts a conversation and green ends one. Amber means somebody senior asks what you need, which is a good conversation to have and an uncomfortable one to schedule, so it slides to next week, and next week carries exactly the same incentive. By the time the report goes red, the decisions that would have helped, more people or less scope or a later date, have mostly expired. Four things make honest colours easier to file: - **Define the colours by what they ask of the reader**, not by how the team feels. Green: nothing needed from you. Amber: a decision or a resource is needed, and it is written below. Red: a committed date or scope has already moved. Print the definitions on the report so nobody has to remember which version you meant. - **Make amber ordinary.** A project that has never once been amber is either very lucky or not being reported. Say that at kickoff, and go amber early on something small, so the first amber is not also the first crisis. - **Record the date the colour last changed.** A colour that has not moved in eight weeks, on a project that has moved a great deal, is not a status. It is a habit. - **Let someone who is not the author challenge it.** A delivery lead, a peer project manager, anyone who has read the plan. Colours set by one person alone drift in that person's preferred direction, and rarely on purpose. What follows an amber is a re-planning conversation, not a longer paragraph. That conversation goes better when it starts from the plan that already exists rather than from a blank page, which is what Projan's import step does: it pulls the current plan document into a planning session in Slack or Microsoft Teams, asks what has actually changed about dates and owners, and writes the revised items back out to a tracker such as [Jira](/integrations/jira). ## What are the common status report mistakes? The mistakes that get reports ignored are mostly about who the report is addressed to and what it asks for. Very few of them are about formatting. 1. **The report has no addressee.** It goes to a distribution list, is addressed to nobody in particular, and so nobody in particular owes it a reply. Name the person who has to act, in the report. 2. **Numbers arrive without a denominator.** "14 tickets closed" is a fact with no meaning attached until the reader knows how many are open and how many were closed last week. 3. **Risks are copied forward unchanged.** The same four risks, same wording, eleven weeks running. A risk nobody has reassessed is decoration, and it teaches readers to skip the section where the real one will eventually appear. 4. **The report is where bad news is broken.** Discovering a two-month slip in writing, alongside twelve other people, is how a sponsor learns to distrust the whole document. Brief them first, then write it down. 5. **Length grows to fill a quiet week.** Weeks with nothing to report often produce the longest ones, because there is nothing to say and an urge to prove otherwise. A quiet week deserves four lines. 6. **Everything sits at the same altitude.** A blocked integration and a booked meeting room get the same bullet, and the reader ends up doing the sorting you were supposed to do. All six are fixed by the same edit. Decide who has to do something because of this report, then cut whatever does not help them do it. ## Frequently asked questions **What are the four key components typically included in a well-structured status report?** There is no canonical four. Most templates settle on overall status, progress, risks and decisions, and what comes next, which is the version used above. The genuinely established shape is progress, plans and problems, usually shortened to PPP. Three, four and six section templates are all in common use, and the count says more about who wrote the template than about the discipline. **Should a status report include a budget line?** Include it if somebody reading the report can act on it, which usually means the sponsor. One line is enough: approved, spent to date, forecast at completion. Skip it on internal projects where nobody in the distribution list controls the budget, and never show spend without a forecast, because spend alone tells a reader nothing about whether the money will run out. **Should risks and issues be in the same section?** Yes in a weekly report, separated by a label. Splitting them into two sections doubles the reading and hides the relationship, since most issues were risks somebody logged and nobody acted on. Mark each line as risk or issue, give it an owner and a date, and keep the full risk register somewhere else. Only report the ones that changed or that need the reader. **How much history should a status report carry?** One period, plus the previous status colour and the original baseline date for anything that has slipped. Readers want the delta, not the archive. If someone needs the full history, keep a running document with each report appended and link to it once, rather than growing every weekly report until it is a project diary nobody opens. **What should I do if a stakeholder disputes the status colour?** Ask which date or deliverable they think the colour is wrong about, then agree the colour against that specific thing rather than in general. Most disputes are about scope, not honesty: they are reading the colour as covering the whole programme while you meant one milestone. Record the outcome in the next report so the disagreement is not repeated silently. Four sections, one page, one fixed day. Write the ask first and build the rest of the report around it, because that is the only part of the document that changes what happens next. ### What to Do With Meeting Transcripts After the Call https://projan.ai/blog/what-to-do-with-meeting-transcripts-turning-raw-text-into-decisions-and-action-i/ Published: 2026-08-10 Pull the decisions and the actions out of it, put a name and a date on each one, circulate that short list, and keep the transcript as the file you go back to when someone disputes what was agreed. The transcript itself is not the deliverable. Nobody reads nine thousand words of speech, including the people who were in the room. Transcription is switched on by default in most conference software now, so teams have more text than ever and no more clarity. This covers the step in between: what you actually do with the file once the call ends. ## What to do with meeting transcripts Treat the transcript as an input to three things people will read, plus one thing they will not. Only the first three are worth producing on purpose. | End state | Who it serves | When to make it | |---|---|---| | **Decision list** | Everyone who attended, and their teams | Same day, while the context is still yours | | **Owned actions in the tracker** | The named owner, and whoever chases them | Same day, before the tracker fills with other work | | **Short summary for absentees** | People who missed it, and anyone downstream | Same day, in the channel they already read | | **The transcript archive** | Whoever disputes something months later | Automatically, then leave it alone | The fourth row is the one people get wrong, because it looks like the most complete artefact and is therefore assumed to be the most useful. It is a search index for a specific sentence, not a record of a meeting. Whether the meeting also needs approved minutes is a separate question, and the answer depends on who has to prove what later: [the three record types differ more than the words suggest](/blog/notes-vs-transcripts-vs-minutes-which-meeting-record-do-you-actually-need). ## A transcript is evidence, not a record The transcript's real job is as an audit trail. It is the thing you open when two people remember the same meeting differently, and it is nearly useless for anything else. Consider what people actually need out of a meeting. What was decided, and who is doing what next. Those are precisely the two things speech expresses worst. Real decisions are almost never stated as decisions. They arrive sideways, as "yeah, ok, let's just do that then" after eleven minutes of circling, or as nobody objecting to a suggestion that was floated as a maybe. A transcript will tell you exactly what was said and leave you to argue about what it meant. The second problem is worse and less obvious. Quite often the room did not agree. Three people left with three readings of the same exchange, and the transcript preserves that ambiguity in high fidelity rather than resolving it. Reading the file back does not produce a decision. It produces the raw material for the argument you are about to have. So the transcript is worth keeping and not worth circulating. Search one for the word "decided" and you will usually find nobody said it. ## How do you turn a meeting transcript into action items? Work from your memory first and the text second, on the same day. The person who was in the room is a better extraction engine than anything reading the file cold, and that advantage expires quickly. 1. **Write the decisions down before you open the transcript.** Getting your version out first gives you something to check the file against, rather than letting whichever sentence you notice first set the frame. 2. **Scan for commitments, not for topics.** The useful phrases are small and predictable: "I'll", "can you", "we should", "let's", "before Friday", "leave it with me". Jump between those and ignore the discussion around them. 3. **Convert each one into something that binds a person.** "We should look at the pricing page" commits nobody and will still be true in six months. "Priya redrafts the pricing page copy by 14 March" is an action. If you cannot name an owner, you have found a decision that was never actually made. 4. **Split decided from discussed, and be strict about it.** Anything you cannot confidently place goes back to the person who said it, as a direct question, today. Two messages now beats a task nobody accepts in three weeks. 5. **Put the actions where the work lives.** A list inside a document gets read once. The same list in the team's tracker turns up in someone's queue on Monday morning. 6. **Circulate the short version.** Decisions, actions with owners and dates, open questions. If it runs past a screen, cut it rather than attaching the transcript as compensation. Step four is where the value is, and it is the step people skip because it means admitting the meeting was less conclusive than it felt. Once the list is out, getting the items done is a different discipline: [chasing without being annoying](/blog/meeting-follow-up-that-actually-sticks-emails-nudges-and-follow-through) has its own rules. ## How do you get action items from a Google Meet transcript? Find the file before you do anything else, because in Google Meet it belongs to the meeting organiser rather than to you. Where transcription is enabled and the edition supports it, Meet writes the transcript to a Google Doc in the organiser's Drive and attaches a link to the calendar event. Two things about that format change how you work with it. The transcript is an editable document, so the sensible move is to write your decision list at the top of a copy, keeping the conclusions attached to the evidence they came from. And speaker labels come from calendar identity, which means guests, shared meeting rooms and anyone dialling in may be attributed vaguely or not at all, so check attribution before you assign anything. The failure specific to this format is quiet. Because the organiser owns the file, everyone else assumes it is being handled, and nothing gets extracted at all. If you called the meeting, the transcript is yours to process. ## How do you summarise a Teams meeting? Start from the meeting itself rather than a file: in Microsoft Teams the recording, transcript and any generated recap sit with the meeting, reachable from the meeting chat and the calendar entry, so the material is already in the place your attendees will look. A usable summary of any meeting is four short blocks, and the discipline is length rather than structure. - **Decided.** One line per decision, in the past tense, with no hedging. - **Not decided.** What was raised and left open, and who is going to close it. - **Actions.** Owner, item, date. Nothing else on the line. - **Changed for you.** What someone who was not on the call now needs to do differently. Keep it under a screen. A summary that runs to three pages has become a second transcript, and it will be read by exactly as many people as the first one. Teams generates its own recap, though the more capable versions of that feature are licensed separately from a standard plan and entitlements change, so confirm what your tenant has before promising it to anyone. Wherever the draft comes from, post the summary into the meeting chat rather than emailing it. The attendees are already there, and it sits next to the evidence. ## Where AI summarisation helps, and where it quietly fails It is good at compression and unreliable at judgement. A model will condense a rambling hour into readable paragraphs and pull out the sentences that look like commitments, which is most of the typing and genuinely worth having. Three things it does not do well, all of which matter more than the typing. 1. **It cannot tell a decision from a suggestion.** Someone proposes an approach, thinks aloud for two minutes, and abandons it. Read as text, the proposal is the confident part and the retreat is the mumbling. The proposal is what survives into the summary. 2. **Attribution goes wrong whenever the room uses pronouns.** "Can you pick that up?" is perfectly clear to nine people looking at each other and completely opaque on the page. Something has to be guessed, and the guess arrives with a name attached to it. 3. **It has no view on what mattered.** Nine things were mentioned. One of them will define the next quarter. Nothing in the text marks which, because the important thing was usually said briefly and in passing. The failure mode is not that the summary is wrong. It is that the summary is plausible and unverified. A wrong action item does not sit quietly in a document: it goes into the tracker, gets assigned, gets chased in a standup, and takes two weeks to unwind because everyone assumed someone had checked it. The fix is cheap and unpopular. A human who was in the meeting confirms the decisions and the owners before anything is circulated, ideally out loud while people are still on the call. Five items take ninety seconds and the entire class of error goes away. Doing that during the conversation rather than after it is the approach Projan takes: the planning discussion happens inside a Slack or Microsoft Teams thread, each item is logged with an owner against it at the moment it is agreed, and the resulting list exports to Jira, Asana or Notion. Any method that produces a confirmed list before people disperse does the same job. Before buying anything for this, it is worth knowing the difference between [software that records a meeting and software that intervenes in one](/blog/ai-note-taker-vs-ai-facilitator-two-very-different-jobs-in-your-meetings). ## Who agreed to be recorded, and how long you keep it Decide both before you switch transcription on across a team, because the archive exists from the first meeting and consent cannot be applied retrospectively. Recording and transcribing people has consent implications, and the requirements vary by jurisdiction, by sector and by organisation. Your own policy is the thing to read, and if there is not one, that is a gap worth raising rather than working around. Practically, put it in the invite and not in the first thirty seconds of the call, so anyone uncomfortable can say so privately instead of in front of eleven colleagues. External attendees have agreed to nothing at all. Retention deserves an actual decision. Transcripts of candid discussion are discoverable, and they outlive their usefulness by a long way. A frank aside about a supplier is fine in a meeting of six and reads very differently eighteen months later to someone who was not there and has no idea it was a joke. Set a retention period, apply it automatically, and stop treating the archive as free because storage is. ## Frequently asked questions **Should you send the transcript to people who missed the meeting?** No. Send them the short version and tell them the transcript exists if they want the detail. Nobody catches up by reading an hour of speech, and the person who missed the meeting is exactly the person least able to tell a decision from a passing suggestion. Give them the conclusions and a name to ask. **How soon after the meeting should you process the transcript?** The same day, and preferably within the hour. Your memory of which moment mattered decays much faster than you expect, and it is the only thing that lets you read a wandering exchange and know how it ended. After a week you are reconstructing the meeting from evidence rather than remembering it. **What if the transcript contradicts what someone remembers?** Read the passage together rather than quoting it at them. Transcripts settle what words were spoken, which is often not the same as what was agreed, and people misremember conclusions far more than sentences. If the words are genuinely ambiguous, treat the decision as never made and make it again properly. **Do you need to correct transcription errors before filing a transcript?** Only the ones that change meaning. Names, product terms, figures and negations are worth fixing, because a missing not inverts a decision and a misheard number gets quoted back at you. Cleaning up filler and false starts across an hour of text is work nobody will ever benefit from. **Who should do the extraction?** Someone who was in the room and understands the subject, usually whoever called the meeting. Handing it to a person who was not there guarantees the ambiguities get resolved by guesswork. If the chair is too senior to do it, they should still read the decision list before it goes out, because their name is on it. The transcript is the thing you keep and the decision list is the thing you send. Do the extraction the same day, put a name on every action before it leaves your hands, and let the raw text go back to being what it is good at, which is settling arguments about what was said. ### Why Meetings Fail, and the Simple Rules That Fix Them https://projan.ai/blog/why-meetings-fail-and-the-simple-rules-that-fix-them/ Published: 2026-08-10 Meetings are not effective because nobody decided what the meeting was for. A meeting can make a decision, surface information that exists only in people's heads, get work done together, or build agreement on something contested. Each of those needs a different length, a different guest list and different preparation. Most bad meetings are the mismatch. This is the general diagnosis rather than a guide to running any particular session. It covers what actually goes wrong, the short set of rules that address it, and two pieces of received wisdom that get quoted more than they deserve. ## Why are meetings not effective? Because the failure happens when the invite is created, not in the room. Someone has a feeling that the group should get together on a subject, picks a length from the calendar's defaults, and invites everyone plausibly connected to it. Nothing in that sequence involves deciding what has to be true when the hour ends. By the time people arrive, the meeting is carrying several incompatible jobs. Half the room came to be informed, two people came to argue, and one came because they always come. The chair cannot satisfy all three, so the meeting drifts to the safest of the three, which is talking about the subject. Everyone leaves feeling it was fine and nothing changes. There are roughly four honest reasons to put people in a room together. Each has different requirements. | What the meeting is for | What has to exist before it starts | Rough size | How you know it worked | |---|---|---|---| | Make a decision | The options in writing, and a named decider | Small enough that everyone speaks | A choice was made and written down | | Surface what only exists in people's heads | A question specific enough to answer | Whoever holds the knowledge, plus whoever needs it | Something was said that nobody could have written in advance | | Do the work together | The work itself, open in front of people | Only the people doing it | The work is further along than when you started | | Build agreement on something contested | An honest statement of the disagreement | Everyone who could block it | The people who disagreed can state the other side accurately | Note what is not on that list. Reporting progress is a broadcast, and a broadcast does not need everyone in the same hour. Nor does approval of something already agreed elsewhere. ## The failures follow from mixing the jobs Almost every recognisable bad meeting is one of the four jobs run with another one's setup. Four that show up everywhere: - **The decision meeting with fifteen attendees.** It was sized like a briefing, so it behaves like one. Past a certain headcount people stop arguing and start being careful, and the choice gets deferred to a smaller conversation that happens afterwards anyway. [Settling who holds the call before anyone is invited](/blog/how-to-run-a-decision-making-meeting-that-actually-ends-with-decisions) is the cheapest available fix. - **The status meeting that could have been a message.** Nine updates delivered live, seven of which concern nobody else present. It survives because it feels like management and asks nothing of anyone. - **The working session where nobody brought the work.** The document was going to be drafted together, and the hour goes on agreeing what should be in the document. Working sessions need the artefact open on screen from minute one, or they turn into planning the working session. - **The alignment meeting run as a presentation.** Contested things do not become agreed because someone presented forty slides at them. Disagreement that is not spoken in the room gets spoken in the corridor, and then in the delivery phase, at much greater cost. The pattern is the same each time. The organiser knew the subject and never chose the job. ## Five rules that cover most of it These are not a methodology. They are the small number of things that, done consistently, remove most of the failures above. Each one exists to prevent a specific failure. 1. **Name one decider for anything that needs a decision.** Prevents the meeting that ends with "let's take that away and pick it up next time". If nobody can say who makes the call, the room will search for consensus, fail to find it, and adjourn. 2. **State what each agenda item has to produce.** Prevents the item that gets discussed for twenty minutes and closed with a nod. "Supplier contract" names a topic. "Agree whether we extend the supplier for six months or go to tender" names a result, and anybody can see whether the item closed. The [handover from agenda to discussion](/blog/meeting-planning-and-follow-through-a-complete-playbook-from-agenda-to-action-it) is where most of this leaks away. 3. **Either the pre-read gets read, or you read it in the room.** Prevents the first half of the meeting being a summary of the document for the people who did not open it. Reading in silence for eight minutes at the start feels strange for about a week and then feels normal. It is also honest about what was happening anyway. 4. **Keep the guest list down to what the job needs.** Prevents the careful, quiet, expensive meeting. A useful test: the right list is the set of people you would have had to consult one by one if the meeting never happened. The rest can read what came out of it, which is a better use of their morning. 5. **Get the decisions and owners into writing before the room empties.** Prevents the account that everybody nods at afterwards and nobody works from. Written later, the record is one person's memory of the discussion, and the qualifications people attached to their agreement are the first thing to fade. Whether you want [notes, a transcript or formal minutes](/blog/notes-vs-transcripts-vs-minutes-which-meeting-record-do-you-actually-need) depends on the meeting, but something has to exist before people disperse. None of that is difficult. It is unpopular, because each rule involves telling someone their meeting is not what they thought it was. ## The two rules everyone quotes that do less than they promise Two lines get repeated in every conversation about meetings. Both contain something true and both stop short of being useful. **"No agenda, no attenda."** It is memorable and it is not much help, because the agenda is usually the problem rather than its absence. Most agendas are a list of nouns: budget, hiring, Q3, AOB. A room can spend an hour on a list of nouns and finish exactly where it started, and the invite was fully compliant. The rule people actually need is stricter. Decline the invite when you cannot tell what the meeting is supposed to produce, whether or not a document was attached. **"This could have been an email."** Frequently true, and worth saying out loud more often than it is said. It also flattens a real distinction. Some things genuinely need argument in real time, because the disagreement is not yet articulate enough to be written down, and email is a poor place to work that out. Broadcasting information asynchronously is easy. Resolving a contested question asynchronously is a different skill, and teams that assume the two are the same end up either meeting about everything or writing long threads that settle nothing. There is a third shape that neither slogan accounts for: a written discussion with structure, where the questions are put in a fixed order and people answer in their own time. Projan is built around that for planning specifically, pulling an existing brief or ticket in as context and then asking the scope and ownership questions in a Slack or Microsoft Teams thread rather than booking an hour to ask them out loud. ## Nobody ever deletes a recurring meeting Meetings are created in about eight seconds and removed almost never. That asymmetry, not any individual bad hour, is what fills a calendar. The weekly that made sense during a launch is still running eighteen months later because cancelling it would be a small act of judgement about someone's work, and nobody wants to be the person who says the thing they set up is no longer needed. The discipline that fixes it is unglamorous: give every recurring slot an expiry the day you create it, written into the invite, and treat that date as a real question rather than an administrative one. Two questions make the review honest. Who would notice if this stopped? And what has this meeting changed in the last month that would not have changed anyway? A meeting that cannot answer either one is a habit with a room booking. Halving the frequency is usually a better first move than deleting the slot outright. It gives you evidence, and people accept it more readily. If nothing breaks at fortnightly, the answer to the original question is now obvious to everybody, and [chasing the actions between meetings](/blog/meeting-follow-up-that-actually-sticks-emails-nudges-and-follow-through) turns out to have been doing the real work all along. ## What is the 10-10-10 rule for meetings? There is no single agreed meeting rule of that name, so treat any confident definition with suspicion. Most often the phrase points at Suzy Welch's personal decision heuristic, which tests a choice against three horizons: ten minutes from now, ten months, ten years. That is about decisions rather than meetings, and it gets borrowed into management contexts fairly loosely. The version people quote as a meeting rule is usually a timeboxing device: split a thirty minute slot into ten minutes of context, ten of discussion and ten of deciding. That is a reasonable shape for a short decision meeting and a poor one for a working session, which needs the whole slot on the work. Use it as a default if it helps, but the split is a scheduling convention, not a finding. ## What are the 3 C's of a meeting? The three C's are a mnemonic rather than a standard, and the letters change depending on who is teaching it. There is no authoritative source, so anyone presenting one version as the definition is guessing. The formulation that circulates most widely is: 1. **Clarity.** Everyone can state what the meeting has to produce before it starts. If the chair and the attendees would give different answers, the meeting has already failed and just has not noticed. 2. **Contribution.** The people with something to add actually said it. A meeting where two people spoke for fifty minutes and six people spoke for none did not need six of them. 3. **Conclusion.** It ended with something written: a decision, an owner, a date, or an explicit statement that the question remains open and who is holding it. Other versions substitute content, context or conduct for one of the three. The variations matter less than the fact that all of them are checking the same three moments: before, during and at the end. If you want the mnemonic to earn its place, apply it as a test after the meeting rather than a plan before it. Clarity and contribution are hard to judge in advance and obvious in hindsight. ## Frequently asked questions **Is it rude to decline a meeting invitation?** No, provided you say why and offer what you can give instead. Reply asking what the meeting has to produce and whether your input is needed live or in writing. Most organisers answer honestly and half of them realise they invited you out of politeness. Declining silently is the rude version, because the organiser cannot tell whether you saw it. **What should you do if the person who has to decide cannot attend?** Move the meeting or get the decision delegated in writing before it starts. A decision meeting without the decider becomes a rehearsal, and rehearsals are expensive. If the decider genuinely cannot come and will not delegate, run the session as a working meeting instead, produce a written recommendation, and give them a deadline to accept or reject it. **Can one person fix meetings in an organisation that runs them badly?** Only the ones they own, which is usually enough to matter. Fix your own invites first: state the outcome, cut the guest list, write the decisions down before people leave. Colleagues notice the difference in the meetings they attend. Trying to reform everyone else's calendar without any authority tends to produce a policy nobody follows. **How do you end a meeting that is overrunning?** Stop five minutes early on purpose and spend the time restating what was agreed and who is doing what. If the discussion is not finished, name the open question, name who takes it forward, and book the follow-up before people disperse. Running over quietly borrows time from whatever people had planned next, and they will remember that more clearly than the discussion. Meetings do not fail because people lack facilitation skills. They fail because the hour was booked before anyone decided what it was for, and no amount of good behaviour in the room recovers that. Decide the job, size the room to it, and write down what came out. ### Will AI Replace Planners? Project, Meeting and Event Roles https://projan.ai/blog/will-ai-replace-planners-what-actually-changes-for-project-meeting-and-event-rol/ Published: 2026-08-10 No, but the job changes, and more than the usual reassurance admits. Scheduling mechanics, status collation, meeting write-ups and supplier admin all compress under AI. Accountability, undocumented information and negotiation do not. The uncomfortable part is that the compressible half is roughly what junior planners are hired to do. This is for people whose job title contains planner, coordinator or manager. It treats project, meeting and event roles separately, because they are automating at different speeds and for different reasons. ## Will planners be replaced by AI? No, not on any timescale worth planning a career around, but the composition of the job is moving fast enough that the question deserves better than it gets. Two answers dominate and both are useless. One says planning is a human craft machines cannot touch, which is sentiment dressed as reasoning. The other says planning is coordination, coordination is information processing, and information processing is solved, which mistakes a planner's documents for their work. The honest position starts with a concession. A real share of planning work is genuinely automatable and is already being automated. Drafting a schedule from a dependency list. Reconciling six status updates into one report. Turning a recording into a list of actions. Chasing a supplier for a certificate. These are mechanical tasks with defined inputs and checkable outputs, and pretending otherwise to protect the profession's dignity helps nobody. None of it was ever purely mechanical, though. | Role | Task already compressing | What that task also did | |---|---|---| | Project | Building and rebaselining schedules, collating status into a report | Forced a weekly conversation with every team lead | | Meeting | Transcribing, summarising, extracting action items | Made one person listen closely enough to notice what was dodged | | Event | Timelines, supplier chasing, budget trackers, delegate lists | Showed which suppliers answer on a Friday and which do not | The right-hand column is the part nobody costed, and it is why the effects of this automation are stranger than the effects on the tasks themselves. ## The three parts of planning that do not automate Three things a planner does resist automation, and none of them resist because they are creative, human or warm. They resist for structural reasons. **Somebody has to be answerable.** Accountability is a property of a person, not of a decision. When a programme slips a quarter, an organisation does not primarily want an explanation. It wants someone who can be asked why, held to the answer, and expected to behave differently next time. Software produces the explanation faster and more legibly than most people. It cannot absorb a consequence. An organisation that puts a system in the accountable column has not delegated accountability, it has quietly stopped holding anyone to anything. **Most of what a planner needs is not written down.** The facts that decide a plan sit in people's heads, and a fair number are unwritten on purpose. The engineer who will not type "we are behind" into a status update will say it standing by the kettle. A client's stated deadline is a negotiating position; the real one is ten days later and known to their operations manager. Getting at that is a social skill: knowing who actually knows, working out what they are protecting, and asking in a way that produces a true answer rather than a defensible one. A great deal of a planner's information does not exist in readable form until they have gone and got it, and the getting is most of the job. **Planning is negotiation with a document attached.** Almost every real planning decision is a disagreement between people who want incompatible things and cannot all be satisfied. Sales wants the date, engineering wants the scope cut, finance wants both without the contractor. The plan is the settlement. Software can demonstrate that the dates do not fit, which everyone in the room already knew. It cannot get the sales director to give up two features, and the reason is not technical. The concession counts because a person with standing made it in front of witnesses and can be reminded of it in March. ## What changes for project managers and project planners For project roles the mechanics compress and the arbitration does not. Building the schedule from a dependency list, rebaselining it when a date moves, collating updates into a status report and assembling the steering group pack are all tasks with a defined input and an output you can check in a minute. Expect more of that, not less. What does not compress is the week two teams both slip and only one can have the contractor. Nothing in the data says which. The answer depends on which commitment was made to whom, which team has absorbed the last three slips, and what the sponsor will tolerate. A tool that resolves that by rule has not resolved it, it has picked a side without anyone noticing. The characteristic failure is not the one people brace for. It is rarely a wrong number; it is a fluent, well-structured plan built on facts nobody verified, such as a timetable assuming legal review takes three days because the last plan said so. Confident wrong answers take longer to catch than hesitant ones. The writing-down half of this does have software behind it now. Projan, for instance, sits in the planning discussion, presses on any item with no date or no named owner, and exports the agreed list to Jira or Asana. It still cannot make the person on the other end of an item mean it, which was always the hard part. ## Will AI replace meeting planners? No, though the most visible part of the job, capturing what was said, is the part furthest along. Transcription and summarising are effectively solved for ordinary meetings in a shared language, and the output is good enough that arguing about it is a waste of breath. Deciding what a room agreed is a different task and it is not close to solved. A transcript records that a proposal was discussed. It does not tell you whether the silence afterwards was consent, or three people deciding privately to raise it with their own managers later. Reading that requires knowing the people, their incentives and what they said last month. The distinction between recording a meeting and shaping one is covered properly in [AI note taker versus AI facilitator](/blog/ai-note-taker-vs-ai-facilitator-two-very-different-jobs-in-your-meetings). The harder half is getting a named commitment from someone who does not want to give one. That is a negotiation conducted in front of an audience, and the audience is the mechanism: a person agrees to a date because six colleagues heard them agree to it. No system has that hold over anyone, and the ones that ask politely in a channel afterwards get the answer politeness earns. If you use meeting planner in the events-industry sense, meaning conference organisers, the next section is yours. ## Will AI take over event planners? No, and events show the reason most clearly: the plan and the event are different objects. Timelines, budget trackers, supplier document collection, delegate lists and the first pass at a run of show are all compressing, and event teams have taken that up quickly, because the admin volume is punishing. Building [an event timeline with realistic planning windows](/blog/how-to-build-an-event-timeline-planning-windows-milestones-and-run-of-show) is genuinely quicker with a machine doing the arithmetic. Then there is the rest of it. Whether a venue works is a set of judgements made standing in it: where the light falls at four in the afternoon, how far it is to the toilets from the back row, whether the loading bay takes a van at seven in the morning. Photographs and floor plans are produced by people who want to let the room. A supplier who has let you down twice and is about to do it a third time is likewise a read on a person, and the recovery is a phone call spending relationship credit you have been accumulating for two years. Then there is the day, when the plan stops being a deliverable and becomes the baseline you improvise against. The speaker is stuck at Gatwick, the AV feed is dead, two hundred people arrive in forty minutes. The job at that point is deciding out loud, in front of people, on partial information, with nothing to consult. Event planners are not paid for the timeline. They are paid for the three hours a year the timeline stops working. ## The bottom rungs are the ones being automated The strongest argument against a comfortable "the job just changes" is not about the job at all. It is about how anyone gets into it. Junior planning roles consist almost entirely of the automatable half. A project coordinator chases updates, maintains the tracker, formats the report and takes the minutes. An events assistant builds timelines, collects supplier paperwork and runs the delegate list. That is not incidental to those roles, it is the whole of them, and the profession has always treated it as an apprenticeship. You learn which risks are real by logging two hundred that were not. You learn who to ask by spending a year chasing everyone. You learn what a room sounds like when it has not really agreed by writing up forty that had not. Automate that and the ladder loses its bottom rungs. The senior judgement everyone agrees is irreplaceable was assembled out of exactly the tasks now being handed over, and "we will hire experienced people" is not a plan, it is an assumption that some other organisation will do the training. There is no tidy resolution. An organisation that automates its coordination work and keeps hiring at the same seniority is borrowing capability from a future it has not funded, and the bill arrives some years later as a shortage of people who can run a difficult meeting. The deliberate version is to keep juniors in the rooms where trades are negotiated, give them an item to own and report on in public, and spend the hours the machine gives back on the parts they used to learn by accident. ## What are the 4 AI team members execs should hire? There is no canonical four, and any article presenting one as established has invented it. The phrase circulates widely in business commentary and its membership changes with whoever is writing, which tells you what it is: a way of talking about delegation rather than a hiring framework. The idea underneath is sound, that it helps to sort work by the kind of thinking it needs rather than by the tool you happen to be holding. A version that holds up for planning work, offered as one way of carving up tasks and not as a standard anyone has agreed: 1. **The researcher.** Gathers and condenses what already exists: prior plans, tickets, transcripts, supplier contracts. Cheap to check, because you can go and look at the source. 2. **The drafter.** Produces a first version of a document, schedule or agenda from your inputs. Cheap to check when structure is what matters, expensive when the numbers are. 3. **The critic.** Reads your plan back and says what is missing, unowned or contradictory. The most undervalued of the four, and the only one that improves as your first draft gets worse. 4. **The clerk.** Formats, converts, chases and files. Dull, high volume, and the one to hand over first. Notice what the list lacks: a decision-maker, or an owner. All four produce material a person has to sign, and the constraint on the arrangement is how much a human can properly read in a week. Hiring is the wrong metaphor for any of it. For the organisational version of this question, see [how to structure humans and AI agents around one plan](/blog/what-is-an-ai-team-how-to-structure-humans-and-ai-agents-around-one-plan). ## What planners should get good at Get good at the three things that do not automate, and treat tool fluency as the entry fee rather than the strategy. Learning the tools is necessary and it is not a moat: everyone in your profession will have learned them by the time it matters, and the skill resets each time the tools change. **Be answerable for something.** Own an item with your name and a date against it, say so in front of people, and report on it when it goes wrong. A track record of having been the person who was asked is the part of a planning career that cannot be transferred to software, and it only accumulates if you take the risk. **Get information that is not written down.** Practise the unglamorous version: talk to people who were not in the meeting, ask the question that makes the room briefly uncomfortable, and notice how differently the same person describes a deadline in a group and on their own. **Run the disagreement.** Learn to chair a conversation in which two people want incompatible things and one of them has to lose. Most planners avoid this and become administrators of other people's decisions, which is the version of the role genuinely at risk. ## Frequently asked questions **Will project managers be replaced by AI?** Not as a role, though the number of them in a coordination-heavy organisation may well fall. What disappears first is the administrative layer that exists to move information between teams. What remains is the person who decides between competing claims on the same resource and answers for the result when it goes badly. **Is project planning still worth entering as a career?** Yes, with one condition attached to the first job you take. Look for a role where you sit in the meetings where trade-offs are argued, not one where you are the person who updates the tracker afterwards. A coordinator job with no exposure to decisions was always a poor apprenticeship and is now a worse one. **Do AI tools mean a team needs fewer planners?** Sometimes, and rarely by as much as expected. Drafting gets cheaper while checking does not, so a team that generates three times the material still needs people to read it. The saving is real in organisations whose planners mostly relay information, and close to nil where planners mostly settle arguments. **What is the difference between a planner and a coordinator now?** The line used to be seniority and is becoming function. A coordinator assembles and distributes; a planner decides and is answerable for the decision. Both titles are still used loosely, so when reading a job advert, count how many of the listed duties involve someone having to agree to something they would rather not. The safe conclusion is that planners will not be replaced, and it is true enough. The harder one is that the work most easily handed over is the work people used to learn on, and nobody has decided who pays for that. Plan for the job you will hold in five years: more argument, less assembly. ### How to Write a Proper PRD: Structure and Best Practices https://projan.ai/blog/how-to-write-a-prd-structure-best-practices-and-mistakes-to-avoid/ Published: 2026-08-09 Write a proper product requirements document (PRD) by stating the problem and who has it, defining what is in and out of scope, listing requirements as testable statements, recording your assumptions and open questions, and setting acceptance criteria. Draft it with engineering and design in the room, not after. Then review it and keep it current. This is a guide for product managers and tech leads writing a PRD for a real feature with a real deadline. It covers the sections a PRD needs, the order to write them in, how to document assumptions properly, when in the cycle to write it at all, and the mistakes that show up as rework six weeks later. ## What should be included in a PRD? A PRD should include the problem, the goals, the scope and non-goals, the users, the requirements, the edge cases, the assumptions, the dependencies and the acceptance criteria. Everything else is optional. Templates that run to twenty headings mostly exist to reassure the author. | Section | The question it answers | What goes wrong without it | |---|---|---| | Problem and evidence | Who is struggling, and how do we know? | The team ships something nobody asked for | | Goals and success measures | What changes if this works? | Nobody can say afterwards whether it worked | | Scope and non-goals | What are we deliberately not doing? | Scope grows by consent, one small yes at a time | | Users and use cases | Who is this for, in what situation? | Requirements written for an imagined average user | | Requirements | What must be true when this ships? | Engineers guess, and guess differently from each other | | Edge cases and error states | What happens when it goes wrong? | Rework in QA, or a support queue after release | | Assumptions and open questions | What are we taking on trust? | A wrong assumption surfaces in week three | | Dependencies | Who or what else is needed, and by when? | Blocked mid-sprint by a team who never heard of the project | | Acceptance criteria | How do we know it is finished? | Sign-off turns into an argument about intent | Non-goals earn their place more than any other section. They are the only part of the document that lets you decline a reasonable request in week four without relitigating the whole plan. How much detail each section needs varies enormously with the size of the change, and getting that wrong in either direction is its own problem. The [question of PRD length and detail level](/blog/how-long-and-how-detailed-should-a-prd-be) is worth settling separately. If you are unsure whether this document should be a PRD at all rather than a technical spec or a functional spec, the [distinctions between the requirements document types](/blog/prd-vs-product-spec-vs-technical-spec-vs-functional-spec-what-each-document-is-f) are clearer than the naming suggests. ## How to write a proper PRD? Write a PRD in this order, because each step constrains the next and doing them out of sequence produces a document that argues with itself. 1. **Write the problem statement and get it agreed before anything else.** Two or three sentences on who has the problem, what it costs them, and what evidence you have. If you cannot get agreement on this paragraph, you will not get agreement on anything downstream, and you have just saved yourself a week. 2. **Define the non-goals.** Do this second, while the temptation to include everything is at its strongest. Writing non-goals early forces the scope argument to happen before people are attached to their favourite additions. 3. **Describe the users and the situations they are in.** Named segments, real scenarios. "A finance lead reconciling invoices at month end, on a laptop, interrupted constantly" produces better requirements than "users". 4. **Write the requirements as testable statements.** Each one describes an observable outcome. "The system rejects a duplicate submission and shows the original submission's reference" is a requirement. "The system handles duplicates gracefully" is a mood. 5. **Work through the edge cases and error states deliberately.** Empty states, permissions, partial failures, what happens on a slow connection, what happens to data already in the system. This is the section engineers read first and PMs write last. 6. **Record assumptions and open questions with owners.** Covered in detail below. Do not let a decision that has not been made hide inside a sentence that sounds settled. 7. **List dependencies with dates and names.** Another team's API, a legal review, a vendor contract, a design system component that does not exist yet. Each one gets a person and a date, not a team name. 8. **Write acceptance criteria and get the review booked.** State what has to be demonstrably true for the work to be accepted. Then put a meeting in the diary with engineering, design and QA before you circulate the draft, because a document sent for comment gets comments, and a document walked through gets objections. The order matters more than the template. A PRD written problem-first tends to end up short. A PRD written solution-first tends to end up describing a feature you have already decided to build, with the problem reverse-engineered to justify it. If your requirements would survive renaming the feature, they are probably describing behaviour. If they would not, you have written a design document and given it the wrong title. ## What are assumptions in a PRD? An assumption in a PRD is anything you are treating as true without having confirmed it, and which would change the plan if it turned out to be false. That second clause does the work. If nothing changes when the assumption breaks, it is background, not an assumption worth recording. They usually fall into three types: - **User assumptions.** How people currently do the thing, how often, and whether they would change behaviour to use what you are building. - **Technical assumptions.** That the existing data model supports the new state, that the third-party API returns what its documentation claims, that the volume fits inside current infrastructure. - **Organisational assumptions.** That a team will be free in the sprint you need them, that legal review takes a week, that the pricing change is already approved. Write each one in a form that can be checked: > We assume support tickets about failed exports are mostly caused by timeouts rather than malformed data. If that is wrong, the retry work does not help and we should be validating input instead. Priya to sample fifty tickets by Friday. Four elements: the belief, the consequence if it is false, the person confirming it, the date. An assumption without a consequence attached gets skimmed. An assumption without an owner gets discovered by the engineer who hits it. Keep assumptions separate from requirements in the document. Teams that blend them end up building a requirement that was never agreed, because it was phrased confidently enough to look like one. ## What constitutes a good PRD? A good PRD is one an engineer who missed every meeting could build from without asking you what you meant. That is the whole standard, and most best-practice lists are attempts to reach it by other means. The properties that make the difference: 1. **Every requirement can fail a test.** If nobody can write a test that the implementation would fail, the requirement is a wish. Rewrite it or cut it. 2. **The problem is separable from the solution.** A reader can tell what you are trying to change and what you have chosen to build, and can disagree with the second without rejecting the first. 3. **What is known is visibly separate from what is assumed.** Confidence in a PRD should be graded, not uniform. 4. **Decisions carry their reasons.** One line on why you chose this option is worth more than a page describing the option. It is also what stops the same debate reopening in three weeks. 5. **It is short enough to be read in one sitting.** Not short for its own sake. Short because a document nobody finishes is not a document, whatever the wiki says. 6. **It has a date and a status.** Draft, in review, agreed. More rework comes from people building against a superseded version than from anything written badly in the current one. Two things do not make a PRD good, despite appearing in most templates: exhaustive completeness, and a full set of headings. A PRD that answers nine questions well beats one that answers twenty-five with a placeholder. ## When should a PRD be created? Write the PRD after discovery has produced a problem worth solving and before design or engineering commit to a solution. Earlier and you are documenting a hunch. Later and the document becomes a write-up of decisions already taken, which is expensive theatre. The practical trigger is a combination of three conditions: - Someone can state the problem and point at evidence for it. - The work is large enough that more than one person's judgement is needed to build it correctly. - The decisions still available are worth arguing about, meaning nothing significant has been committed yet. If the third condition has already gone, you do not need a PRD. You need a decision record and an honest conversation about who agreed what. Not every change earns one. A copy fix, a config change, a bug with an obvious cause: a well-written ticket is the right document. The threshold most teams settle on is roughly two weeks of work or two teams involved, though that varies with how much your codebase punishes a wrong guess. The related question of who should be writing it, and whether the format still fits an agile team, is [covered separately](/blog/who-writes-the-prd-and-is-it-still-relevant-in-agile). ## What are common PRD mistakes to avoid? The common PRD mistakes are almost all failures of process rather than writing. Here are the ones that reliably cause rework, in rough order of expense. 1. **Writing it alone and circulating it for comment.** The comments come back polite and shallow. The real objections arrive in sprint planning, and by then the document has an author who is defending it rather than a team who owns it. 2. **Requirements that describe an interface instead of a behaviour.** "A dropdown listing active projects" locks in a solution before anyone has considered whether a dropdown works at four hundred projects. Say what the user needs to accomplish and let design solve it. 3. **No non-goals.** Without them, every plausible adjacent request is arguably in scope, and the person best at arguing wins. 4. **Assumptions written as statements of fact.** This is the one that costs the most, because it is invisible until the assumption fails. See the section above for the format that prevents it. 5. **Acceptance criteria that restate the requirements.** If your criteria are the requirements with "the user can" in front, sign-off will be a negotiation rather than a check. 6. **Skipping edge cases and calling them implementation detail.** Error states are product decisions. Someone will decide what happens when the upload fails, and if it is not in the PRD it will be decided by whoever is closest to the deadline. 7. **Letting it go stale mid-build.** A PRD that stopped being updated in week two is worse than no PRD, because people still trust it. Either maintain it or mark it superseded and say where the current truth lives. The first mistake causes several of the others. Edge cases get missed because the person who knows them was not asked. Assumptions harden into facts because nobody in the room had the evidence to challenge them. Getting engineering into the questioning stage, before a draft exists to react to, changes the outcome more than any template will. That ordering is what Projan is built around: it puts the scope and edge-case questions to the team in Slack or Microsoft Teams first, then writes up what was agreed and sends the resulting tasks to Jira or Linear. For a first-hand account of what this looks like on a small team rather than in the abstract, [our founder's write-up on PRDs](/blog/how-to-write-a-prd) covers the same ground from inside a specific project. ## Frequently asked questions **What should a good PRD have?** At minimum: the problem with evidence, the non-goals, the requirements as testable statements, the assumptions, and the acceptance criteria. For a small change you can compress that into a page. The test is not which sections are present but whether an engineer who missed every meeting could build the right thing from it. **What are some PRD best practices?** Write it with the people who will build it, keep every requirement testable, and separate what you know from what you are assuming. After that the habits matter more than the writing: review it in a scheduled session rather than by comment thread, date every material change, and delete sections that no longer describe the plan. **Should a PRD include wireframes and designs?** Link them, do not embed them. Designs change faster than requirements, and a PRD carrying screenshots goes stale the week after design review. Keep the document describing behaviour and outcomes, point to the current design file, and note explicitly where a design decision is still open so nobody reads a draft as settled. **What happens to the PRD after the feature ships?** Most teams archive it, which is reasonable if the tickets and acceptance criteria carry the detail forward. Before you do, spend twenty minutes marking which assumptions turned out to be wrong. That record is worth more than the document itself, because the same wrong assumption tends to reappear in the next PRD. **How do you handle a requirement nobody can decide on?** Write it down as an open question with a named owner and a date by which a decision is needed, then say what the team will do if no decision arrives. An undecided requirement left in the requirements list reads as agreed. Moved to an open questions section with a deadline, it stays visible and gets chased. A PRD is not a contract with engineering. It is the record of a conversation, and it is worth roughly what that conversation was worth. Write it with the people who will build the thing, keep the assumptions visible, and update it or retire it the moment it stops being true. ### Technical Documentation Types: What Agile Software Teams Actually Need to Write https://projan.ai/blog/technical-documentation-types-what-agile-software-teams-actually-need-to-write/ Published: 2026-08-07 The most widely used answer is Diataxis, a framework by Daniele Procida that splits documentation into four types: tutorials, how-to guides, reference and explanation. It sorts documents by what the reader is trying to do rather than by subject or author. It is one influential model, not a ratified standard, and other sources answer with a different four. This is for product managers and tech leads deciding what a delivery team should write. It covers the four types, the competing answers, the documents that survive contact with a real sprint, and the ones you can stop producing tomorrow without anyone noticing. ## What are the 4 types of technical documentation? Diataxis divides technical documentation into tutorials, how-to guides, reference and explanation. Daniele Procida developed it out of open-source documentation practice, and it has since been picked up widely by both open-source projects and internal engineering teams. It is popular because it is a diagnosis, not a filing system: it tells you why a page is unsatisfying to read. | Type | Reader's question | Typical form | How it goes wrong | |---|---|---|---| | Tutorial | I am new, take me through it | A guided lesson with a guaranteed working result | Drifts into explaining options the beginner cannot use yet | | How-to guide | Help me do this specific task | Numbered steps for someone who already knows the domain | Restarts from first principles every time | | Reference | What are the parameters and return types | API docs, configuration options, schemas, error codes | Written as prose when it needs to be a lookup table | | Explanation | Why is it built this way | Architecture notes, design rationale, trade-offs recorded | Never written, so the reasoning leaves with the author | The split Diataxis actually draws is between two axes: whether the reader is studying or working, and whether they need practical steps or theoretical understanding. A tutorial is study plus steps. A how-to is work plus steps. Reference is work plus understanding. Explanation is study plus understanding. That is why the model holds up better than most: it describes the reader's situation, which is stable, rather than the document's subject, which is not. Search the same question elsewhere and you will be given a completely different four: user documentation, system documentation, API documentation and process documentation. That split is by subject and audience, and it is equally defensible. Neither is official. No standards body ever ratified a set of four, so if a page presents its list as the industry standard, it is guessing with confidence. Both models are worth knowing for the same reason. When a document is annoying to read, it is usually because two types have been welded together: an API reference with a tutorial embedded in it, or a getting-started page that keeps stopping to explain the architecture. Splitting them is nearly always the fix. ## Which technical documents does an agile team actually need? The ones with a named reader and a specific day that reader opens them. Most technical documentation is written once, read never, and maintained by nobody, and the reason is almost always that it was produced to satisfy a process rather than a person. The test worth applying is not which types exist. It is what breaks if this document does not exist. Ask that of every document your team currently produces and the list gets short quickly. | Document | Who opens it, and when | What breaks without it | Worth maintaining? | |---|---|---|---| | API reference | An engineer integrating against you, while writing the call | Integrations built on guesswork, then support tickets | Yes, and generate it from source where you can | | Runbook | Whoever is on call, at three in the morning | Recovery depends on which person happens to be awake | Yes, edited immediately after any incident that used it | | Decision record | Someone asking why on earth it works this way, months later | The decision gets relitigated, or quietly reversed by accident | Never edited, only superseded by a newer record | | Technical spec or design doc | Reviewers, before the code is written | Design objections turn up as pull request comments | No, it expires when the work ships | | Onboarding and environment setup | A new joiner in their first week | Every hire costs a senior engineer several days | Yes, and the newest joiner should be the one editing it | | Test plan | The team agreeing what tested means for this release | Coverage arguments after release, in public | Per release, not permanently | | Weekly written status for management | Nobody, in practice | Nothing measurable | No | That last row is not a joke. Status documents written for an audience who could get the same information from the board are the largest single category of documentation waste on most teams, and they are the hardest to stop because someone senior once asked for them. Every document you keep is a standing liability. A stale one is worse than a missing one, because a missing document sends people to ask a human, while a wrong document sends them confidently in the wrong direction. Decision records are the cheapest of these to write and the most expensive to reconstruct. The reasoning behind a choice is available for about a week after the meeting and then it is gone. Some teams handle that with a nominated scribe. Others use a tool such as Projan, which puts the clarifying questions to the team in Slack or Microsoft Teams and writes the agreed answers out as a document with the tasks attached. The mechanism matters far less than catching the reasoning while it is still in someone's head, and [what belongs in an architecture decision record](/blog/how-to-write-an-architecture-decision-record-adr-that-your-team-actually-uses) covers the structure that keeps one alive. ## What are the 5 types of documentation best suited for agile environments? There is no canonical five. No agile framework defines a set, and lists claiming otherwise are usually describing whatever their author happens to write. The five below are the ones that consistently earn their place on a team shipping every week or two, offered as a working shortlist. 1. **The requirement, in whatever form your team uses.** A user story, a PRD, a well-written ticket. The document that states what is being built and how you will know it is finished. Form matters less than whether an engineer can act on it without a follow-up conversation. 2. **The design document, for changes big enough to argue about.** Not every ticket needs one. Anything touching a service boundary, a data model or a security control does. [Keeping a technical spec short enough that people read it](/blog/how-to-write-a-technical-spec-without-writing-a-novel-nobody-reads) is most of the skill. 3. **The interface contract.** API reference, event schemas, published error codes. This is the documentation other people build against, which makes it the one where being wrong is most expensive. Generate it from the code or a schema file so it cannot drift. 4. **Operational documentation.** Runbooks, alert descriptions, deployment and rollback steps. Written for someone under pressure, so short numbered steps and exact commands, not narrative. [A runbook has a structure worth following](/blog/how-to-write-a-runbook-structure-steps-and-what-to-include) precisely because nobody wants to interpret prose during an outage. 5. **The decision record.** One short entry per significant decision: context, choice, alternatives rejected, date. Append-only. This is the document that stops a team spending a fortnight rediscovering why the obvious approach was rejected in 2024. Note what is missing. No per-feature wiki page, no meeting notes filed as documentation, no process manual describing how the team works. Those are not banned, but none of them has a reader with a date, and they are the first things to rot. ## Does agile mean you should not write documentation? No. The Agile Manifesto puts working software over comprehensive documentation, and the sentence people leave out is the one saying that while there is value in the items on the right, the items on the left are valued more. It is a statement about priority when the two compete, not a permission slip. The misreading is convenient, which is why it persists. Teams quote it to skip the documents they find boring while continuing to produce the ones they enjoy or the ones a manager checks. That is a preference, not a documentation philosophy. What genuinely changes on an agile team is timing and proximity. You write less, later, and closer to the code. Three habits do most of the work: - **Write it when the reader appears, not before.** A setup guide written before anyone has set the project up is fiction. Write it while pairing with the first person who tries. - **Keep documents in the repository.** A page in the repo gets reviewed in the pull request that invalidates it. A page in a wiki gets found in eighteen months and believed. - **Prefer deletion to updating.** If nobody can name the reader, delete it. Version control means nothing is really lost. ## What is an RFC format? An RFC (request for comments) is a written proposal circulated for review before a decision is made. Two quite different things share the name, and mixing them up causes confusion in engineering conversations. The original meaning is the IETF document series. Those RFCs are numbered, published by the RFC Editor, and follow a set structure: an abstract, a status of this memo section, an introduction, the technical body, mandatory security considerations, any IANA considerations, and references. The important property is that a published RFC is never edited. Changing a standard means publishing a new RFC that updates or obsoletes the old one, which is why the numbers keep climbing. [How public RFCs are written, published and enforced](/blog/rfc-standards-explained-how-public-rfcs-are-written-published-and-enforced) goes into that process properly. The second meaning is internal. Many engineering teams call their design proposals RFCs, borrowing the name and none of the machinery. There is no fixed structure, but the ones that work tend to carry: a title and author, a status, the problem and its context, the proposal, the alternatives considered and why they were rejected, open questions, and the named reviewers whose agreement is needed. The rule worth stealing from the IETF version is immutability. An internal RFC that is quietly edited after approval stops being a record of what was agreed and becomes a description of what someone later wished had been agreed. Supersede it instead, and leave the old one in place with a pointer. ## Frequently asked questions **What is an example of an important RFC?** RFC 2119 is the one most engineers meet without noticing. It defines what MUST, SHOULD and MAY mean in a specification, which is why those words appear in capitals. Others in the same league are RFC 791 and RFC 793, which specify IP and TCP, and the HTTP specifications that have been revised several times since RFC 2616. **What is the difference between user documentation and technical documentation?** User documentation is written for the people using the product: help articles, guides, release notes. Technical documentation is written for the people building or running it: API references, architecture notes, runbooks. The same feature often needs both, written differently. One document trying to serve both audiences usually serves neither, because the two readers arrive with different questions. **Who owns technical documentation on an agile team?** The team that owns the code owns its documentation. Naming a documentation champion works for about a month and then breaks, because the champion is not the person making the changes. Attach docs to the work instead. If a change alters an interface or an operational step, updating the document is part of that change rather than a follow-up ticket. **How do you stop documentation going stale?** Reduce the number of documents first, because fewer pages get updated more reliably than many. Generate whatever can be generated from source. Keep the rest in the repository so edits show up in code review. Give anything that survives an owner and a last-reviewed date, and delete pages nobody has opened in a year rather than reviewing them. **Should documentation be part of the definition of done?** Only where the requirement is specific. A blanket docs updated checkbox gets ticked without thought. A rule saying that a change to a public interface regenerates the reference, and a change to an operational procedure edits the runbook step, is checkable by the reviewer. Broad documentation clauses produce compliance rather than documents anyone reads. The four types are a useful diagnostic and a poor plan. Knowing you have written a tutorial where a reference was needed is worth something; knowing which documents have a reader with a date in the diary is worth considerably more. Write those few properly, keep them next to the code, and be unsentimental about everything else. ### PRD vs Product Spec vs Technical Spec vs Functional Spec: What Each Document Is For https://projan.ai/blog/prd-vs-product-spec-vs-technical-spec-vs-functional-spec-what-each-document-is-f/ Published: 2026-08-05 A PRD states what to build and why. A technical specification states how it will be built. The PRD is owned by product and has to be agreed by the business; the technical spec is owned by an engineer and has to be agreed by other engineers. Both describe one feature from opposite sides. The harder part is that none of these names are standardised, and no body standardises them. Product spec and PRD are the same document at a great many companies. Functional spec is largely a term from an earlier era of software that survives in enterprise and agency work. The question that ends most arguments about them is not which name is correct, but which decisions each document is allowed to make and who has to agree it. ## What is the difference between a PRD and a technical specification? A product requirements document (PRD) defines the problem and the intended outcome; a technical specification defines the implementation that will produce it. That is the whole distinction, and everything else follows from it. Hold them apart by decision rights rather than by section headings. A PRD is allowed to decide what problem is being solved, for whom, what is in and out of scope, and what evidence will show it worked. It is not allowed to decide the queueing strategy. A technical spec is allowed to decide architecture, data model, migration path and rollout, and it is not allowed to decide whether the feature is worth building at all. The reason this matters is approval, not tidiness. The people who sign off a PRD are the ones accountable for the outcome: a product lead, a business owner, sometimes finance. The people who sign off a technical spec are the ones who will be paged when it fails. Put an architecture decision inside a PRD and you have quietly asked a commercial stakeholder to approve something they cannot assess. Sequence follows from that. The PRD comes first because scope is an input to design. The technical spec responds to it, and often sends questions back that change the PRD, which is a healthy sign rather than a failure of planning. For the writing craft of each, [how to write a PRD](/blog/how-to-write-a-prd-structure-best-practices-and-mistakes-to-avoid) covers the product side and [how to write a technical spec](/blog/how-to-write-a-technical-spec-without-writing-a-novel-nobody-reads) covers the engineering side, including how much detail is worth the effort. ## The four documents side by side Read this table by row rather than by column. The rows that decide which document you need are the third and the fifth: who has to agree it, and which decisions it is not permitted to make. | | PRD | Product spec | Technical spec | Functional spec | |---|---|---|---|---| | **Question it answers** | Why build this, for whom, and what counts as done | The same question, usually scoped to one feature | How will it be built, and what breaks if we do | What exactly does the system do, in every case | | **Usually written by** | Product manager | Product manager or designer | The engineer leading the build | Business analyst, or the supplier's lead engineer | | **Has to agree it** | Engineering, design and whoever funds it | The delivery squad | Other engineers, plus security or platform where relevant | The client or sponsoring business unit, often formally | | **Decisions it settles** | Problem, users, scope boundary, success measures | The same, one feature deep | Architecture, data model, rollout, trade-offs accepted | Behaviour, rules, states, error handling | | **Decisions it must not make** | Implementation approach | Implementation approach | Whether the work is worth doing | Why the requirement exists | | **Useful life** | Until the outcome is measured | Until the feature ships | Until the design is superseded | Until the behaviour changes, then it is amended | Two documents in that table describe intent and two describe behaviour. The common failure is not picking the wrong one. It is writing three of them so that the same fact appears in all three, where it will disagree with itself inside a month and nobody will know which copy is current. ## What is the difference between a PRD and a product spec? Usually nothing. At most companies they are two names for the same artefact, and which one is used depends on who set up the template and where they worked before. Where a genuine distinction exists, it is one of altitude. Some teams use PRD for an initiative that spans several releases and product spec for a single feature underneath it. Others reverse that. A smaller group treats the product spec as the version engineers actually read, stripped of the market context that the PRD carries for executives. None of that is a standard, so do not defend one usage. When someone hands you a template with an unfamiliar name on it, ask two questions: what decision does this document settle, and who has to sign it before work starts. If the answers are the same as your PRD's, it is your PRD with a different heading, and maintaining both is a tax you are paying for nothing. ## What is the difference between a functional spec and a PRD? A functional spec describes system behaviour exhaustively; a PRD argues for the change and defines its boundary. A PRD says users must be able to recover an account they have lost access to. A functional spec says which three identifiers are accepted, how many attempts are allowed in an hour, what the system does on the fourth, and what the user sees in each of those cases. The term comes from an earlier era of software delivery, where a specification was written up front, signed, and then built against. It has not vanished. It survives wherever someone is contracted to build to an agreed scope and the result will be checked against a document rather than against an outcome: enterprise programmes, government suppliers, agencies on fixed-price builds, and regulated work where behaviour has to be traceable to a requirement. In those settings the functional spec does a job no PRD does. It is the acceptance artefact. If the delivered system matches it, the supplier has delivered, and any argument about whether the outcome was worth having is a separate argument held in a different room. Product teams building their own software rarely need one, because they can change behaviour next week and nobody is being paid against a signature. If your organisation uses the older three-letter family instead, [BRD, FRD and SRD map onto this landscape](/blog/requirements-documents-explained-brd-vs-frd-vs-srd-vs-prd) more precisely than PRD and functional spec do. ## What is the difference between a product note and a PRD? A product note is a short written argument for one decision; a PRD is the decision plus enough definition to build against. Length is the visible difference and commitment is the real one. A note can be wrong without anything breaking. A PRD gets estimated, scheduled and staffed. Product note is another unstandardised term. Some teams mean a one-page memo proposing a direction, some mean the running commentary attached to a roadmap item, and some mean what other teams call a product brief or a one-pager. Treat it as the format you use before anyone has agreed the thing should exist, and see [product briefs and one-pagers](/blog/product-briefs-and-one-pagers-templates-examples-and-when-to-use-each) for what belongs in that short form. The useful rule is to promote rather than duplicate. When a note gets a yes, it becomes the first section of the PRD instead of sitting beside it as a second account of the same reasoning. ## How to decide which documents you actually need Work from the unmade decision, not from the template library. 1. **Name the decision that is not yet settled.** If nobody can say what is currently open, no document will help. You are being asked for reassurance, not requirements. 2. **Name who has to agree it.** This single answer picks the document. If the answer is a commercial owner, you need a PRD. If it is three engineers, you need a technical spec. If it is a client with a contract, you need a functional spec. 3. **Check whether an existing document is allowed to settle it.** Adding a paragraph to the PRD beats opening a new file, provided the decision is one a PRD may make. 4. **Write the smallest thing that settles it.** A spec that survives review is one people finished reading. 5. **Record where each answer lives, once.** Cross-reference the other documents rather than restating them. 6. **Put an owner and a date on it.** An unowned spec is a draft, whatever the file name says. Step two is the one teams skip. A PRD written alone and circulated for comment collects approval rather than agreement, because reviewing a finished document is much harder work than answering a direct question, so people skim and nod. Getting the scope questions answered by the people who own the answers before the draft exists is the fix; Projan runs that as a conversation in Slack or Microsoft Teams and exports the agreed items to Jira. ## When one document can absorb another Most teams need fewer documents than their process implies. Use these defaults and add only when something forces you to. - **Small team building its own product:** a PRD, plus a technical spec for anything involving a migration, an external dependency or a change that is expensive to reverse. No functional spec. - **Agency or supplier delivering to a signed scope:** a functional spec is the acceptance artefact and cannot be absorbed. The client's PRD may exist and you may never see it. - **Regulated or safety-adjacent work:** keep behaviour specified separately and traceably. This is the one context where duplication is a feature, because the auditor reads the behaviour document. - **A change of a day or two:** a ticket with acceptance criteria. Writing a PRD for it signals that your process cannot tell large work from small. The test for merging is ownership. Two documents with the same author, the same reviewers and the same approval gate are one document that has been split for the comfort of a template. Merge them. Two documents with different reviewers are doing different jobs even when their contents overlap, and merging them means somebody is now approving a decision they cannot evaluate. ## Frequently asked questions **What is the difference between a functional spec and a technical spec?** A functional spec describes what the system does from the outside: inputs, rules, states and error cases, in language the business can check. A technical spec describes how it works inside: architecture, data model, dependencies and rollout. One is written to be verified by the customer, the other to be reviewed by engineers. Plenty of teams combine both and label the sections. **Is a product spec the same thing as a PRD?** At most companies, yes. When you join a team that uses both terms, do not argue about definitions. Ask which document engineering reads before estimating, and which one the business signs off. The answers tell you what each name means in that building, and it takes two minutes rather than a fortnight of quiet mismatch. **What is a design doc, and is it the same as a technical spec?** In most engineering organisations they are the same thing under different names. A design doc is a technical spec: the proposed approach, the alternatives considered, the risks and the rollout plan. Where they differ in practice, a design doc leans towards arguing for one option among several, and a technical spec leans towards recording the choice once it is made. **Does the PRD have to be finished before the technical spec starts?** No, and waiting for a finished PRD wastes calendar time. Engineers can investigate feasibility as soon as the problem and the rough scope are stable. What has to settle first is the boundary, because a technical spec written against a moving scope gets rewritten. Freeze what is in and out, then let the detail firm up in parallel. **What happens when a PRD contains technical decisions?** It usually means no engineer was in the room. A PRD naming a database, a queue or a framework has stopped describing a problem and started issuing instructions, which removes the engineer's chance to propose something cheaper. Move those lines to the technical spec and leave the constraint behind instead, such as a latency target rather than a caching layer. Four names, four jobs, and no authority anywhere that agrees on the vocabulary. Before you open a template, say out loud which decision the document has to settle and who has to agree it. If you cannot answer both, whatever you write next will be read once and never again. ### How to Write a Risk Statement: The Three-Part Structure https://projan.ai/blog/how-to-write-a-risk-statement-the-three-part-structure-and-what-makes-a-risk-rea/ Published: 2026-08-04 A risk statement uses a three-part structure: cause, event, consequence. Written out, it reads: because of [cause], [event] may occur, which would result in [consequence]. The cause is something already true. The event is the uncertain part. The consequence is the damage, stated in money, time or a missed obligation. This is for anyone who maintains a risk register that people are meant to read: project and programme managers, and whoever inherited the spreadsheet. It covers the structure, how to rewrite weak entries, what separates a risk from an issue, and where risk appetite fits. ## What is the three-part structure used to define a risk statement? The three-part structure is cause, event and consequence, joined into a single sentence so that all three are visible at once. 1. **Cause.** A condition that is true today. A supplier on extended payment terms, a contract ending in March, a dependency on one person's knowledge. If you cannot point at it in the world now, it is not a cause. 2. **Event.** The uncertain thing that might follow. This is the only part allowed to be speculative, and it is the part the word "may" belongs to. 3. **Consequence.** What it costs if the event happens. Days, pounds, a missed regulatory date, a deliverable that cannot be accepted. Practitioners often call this risk metalanguage, and the Association for Project Management uses that term for it. The label matters less than the discipline it enforces, which is that you cannot write a complete statement without knowing why you believe the thing might happen. An if-then variant is equally common: if the event occurs, then the consequence, because the cause. Same three parts, different reading order. Pick one and use it consistently across the register, because mixed formats make the log unsortable by eye. The test of a finished statement is whether a person outside the project could read it cold and say what should be done next. A statement with no cause is a prediction, and predictions do not have owners. ## Weak risk statements, rewritten Most registers are filled with nouns. Resourcing. Integration. Adoption. A noun cannot be mitigated, because there is nothing in it to act on. | Weak entry | What is missing | Rewritten | |---|---|---| | Resourcing | Everything. It is a topic heading. | Because two of the four backend developers are on contracts ending in March, the integration work may lose its lead engineer mid-build, delaying launch by a quarter. | | Risk of project delay | A cause and a real consequence. Delay is the effect of a risk, not a risk. | Because the client's legal review has no agreed turnaround time, sign-off on the data sharing agreement may slip past 14 March, leaving the build team idle for two weeks. | | Key person dependency | The event and the cost. It names a condition and stops. | Because only one analyst knows the reconciliation logic, their booked leave in August may leave month-end close unsupported, risking a late statutory return. | | Supplier may go into administration | A cause. Without one this is a headline. | Because our print supplier has renegotiated payment terms twice this year, they may fail before the November mailing, forcing a reprint at short notice and roughly double the unit cost. | | Users might not like the new interface | A measurable consequence. Dislike is not a number. | Because the redesign was tested with staff rather than customers, the new checkout may increase drop-off at the payment step, reducing weekly online orders. | The cause is the part that gets dropped, and the reason is rarely laziness. Writing the cause down usually means naming a decision somebody in the room made: the contract that was signed short, the testing that was cut, the supplier nobody wanted to re-tender. Registers full of causeless risks are often a sign that the register is being written by one person after the meeting rather than during it. Fix that procedurally. Agree the cause with the person who owns it before anyone commits the consequence to a spreadsheet. In a planning session, Projan asks what would have to go wrong and who would notice first, then exports the agreed wording to Jira or Confluence. The mechanism is not the point; getting the cause said out loud by the person responsible for it is. ## What makes something a risk rather than an issue, an assumption or a worry? A risk has not happened yet, has a cause that is already true, and has a consequence you could put a number on. Fail any of those three and it belongs somewhere else. | Item | Has it happened? | The test | What you do with it | |---|---|---|---| | Risk | Not yet | Can you name a cause that is true today? | Assign an owner, agree a response | | Issue | Yes, already | Is it affecting the work now? | Resolve it or escalate it | | Assumption | Treated as true, unchecked | What breaks if this is wrong? | Validate it, or promote it to a risk | | Dependency | Pending, owned elsewhere | Who outside the team has to act? | Track the date, chase the owner | | Worry | Unclear | Can you say what would cause it? | Leave it out until you can | The demotion nobody likes making is risk to issue. A risk that has already occurred is an issue, and leaving it in the risk column with a mitigation plan attached lets everyone keep discussing it in the future tense. If the supplier has already missed the date, stop scoring the likelihood and start managing the consequence. The promotion in the other direction matters more than teams expect. Assumptions are where most late surprises are hiding, because an assumption is a risk somebody decided not to write down. Run through the assumption list at every review and ask what evidence would settle each one. Anything nobody can evidence should be restated with a cause and moved across. If you are deciding which tracker holds which of these, [the comparison between RACI, RAID logs and a plain risk register](/blog/raci-vs-raid-vs-risk-register-which-tracker-do-you-actually-need) covers the trade-offs. New risks are easier to find in a structured session than in a review meeting. A premortem works because the failure is presented as having already happened, which forces people to state a cause rather than a fear. ## What are the three main components of risk? The three components of risk, as taught in most project management courses, are the event, its likelihood and its impact. 1. **Event.** The thing that might happen, described specifically enough to be recognised if it does. 2. **Likelihood.** How probable it is, expressed on whatever scale your organisation uses. 3. **Impact.** The size of the consequence if it occurs. Other disciplines split risk differently and are not wrong. Information security commonly works with threat, vulnerability and consequence, because the useful question there is what could be exploited rather than what might occur. Safety practice tends to use hazard, exposure and harm. If you are working across functions, agree which triple you are using before comparing scores between teams. There is no universal scale for likelihood and impact. Five by five matrices are common, three by three matrices are common, and the bands mean whatever your organisation has defined them to mean. Numbers copied from one organisation's matrix into another's register are decoration. What makes scoring possible at all is the statement: you cannot rate the impact of "resourcing", but you can rate a launch slipping a quarter. If you are choosing which columns the register needs, [the fields worth keeping and the ones worth cutting](/blog/risk-register-fields-what-to-include-in-a-simple-risk-register-and-what-to-skip) are worth settling before you populate anything. ## What are the three main components of a risk profile? A risk profile describes the organisation's stance on risk rather than the anatomy of a single risk, and the three components usually named are appetite, tolerance and capacity. 1. **Risk appetite.** How much risk the organisation is willing to accept in pursuit of its objectives. This is chosen, usually by a board, and it can differ by category. Many organisations are cautious on data protection and adventurous on product experiments in the same year. 2. **Risk tolerance.** The variation around that appetite that can be accepted before someone has to act. Tolerance is where escalation thresholds come from. 3. **Risk capacity.** The maximum the organisation could absorb before something breaks. Capacity is a fact about reserves, insurance and contractual liability, not a preference, and it is the one people confuse with appetite. Be careful with this question, because the phrase gets used two ways. The trio above is the governance sense, and UK public bodies take that vocabulary from HM Treasury's Orange Book. The other sense is descriptive: a risk profile as the current shape of the register, meaning how many risks sit in each likelihood and impact band. Both are legitimate. If someone asks for the risk profile, find out which one they want before you build it. Exposure is the measured counterpart to all three. Appetite is what you said you would accept, exposure is what you are actually carrying. The gap between them is the only number on the page that should worry a board. ## What is a high risk register? A high risk register is not a separate document type in most methods. It is the filtered view of the main register showing risks that have crossed an escalation threshold, and in organisations that keep one formally it is usually the list reported to a board or corporate risk committee. Thresholds are set locally. What matters is what changes when a risk crosses one: - The owner becomes a named executive rather than a project role - The response is reviewed on a fixed cadence rather than at the next convenient meeting - Someone makes an explicit decision to treat, transfer, tolerate or terminate, and records who decided - The risk keeps its wording, so the board reads the same statement the project team wrote That last point gets lost. Risks are frequently rewritten on the way up, softened into something a committee can absorb, and the escalated version loses the cause. If a risk is worth a board's attention it is worth carrying its original sentence. A high risk register that only ever grows is a queue, not a control. Something should leave it every quarter, either because the risk was closed or because the organisation decided formally to tolerate it. [Roles, accountability and handoffs across the register](/blog/who-owns-the-risk-register-and-raid-log-roles-accountability-and-handoffs) matter more here than anywhere else, because escalation without a named receiver is just a heavier email. ## What is the purpose of a risk log? The purpose of a risk log is to make decisions about uncertainty visible, dated and owned, so that nobody has to reconstruct later who knew what and when. It does four jobs: - Records what the team believed might go wrong, and when they first believed it - Names one person accountable for each entry, so that responses have an address - Holds the decision taken, including decisions to accept a risk and do nothing - Gives auditors, funders and incoming staff a defensible account of how the project was run Risk log and risk register generally mean the same artefact, with log being the older term and still widely used. Neither name changes what the document is for. The purpose is easy to state and hard to sustain, because a log that is updated only before steering committees becomes a compliance exercise within two quarters. [Building one and keeping it alive](/blog/risk-registers-and-raid-logs-how-to-build-one-and-actually-keep-it-alive) is a separate discipline from writing good entries, and it is the one that fails more often. ## Frequently asked questions **How do you write a risk statement in if-then format?** If-then is the same three parts in a different order: if the event occurs, then the consequence follows, because of the cause. Some teams find it reads better in a meeting because the event comes first. It carries the same obligation, which is that the because clause has to be a condition that is already true and not a second guess. **Should a risk statement include the mitigation or the score?** No. Keep the statement to cause, event and consequence, and put the response, the owner and the scores in their own fields. Statements that swallow the mitigation are impossible to re-score later, because you can no longer tell whether the rating describes the risk before or after the planned action. **Can an opportunity be written as a risk statement?** Yes, and the structure holds without modification. Because of a condition that is already true, an event may occur, which would produce a benefit rather than a loss. Registers that track only threats tend to lose the upside cases entirely, since nobody has a column to put them in and no owner is asked to pursue them. **How specific should the consequence be?** Specific enough that someone with budget authority would recognise it as a loss. Days, pounds, missed dates, a named obligation. Vague consequences such as reputational damage survive review because nobody can argue with them, which is exactly why they never trigger a decision or attract funding for a response. Write every entry as cause, event and consequence, and the register stops being a list of anxieties and starts being a list of decisions waiting to be made. The three-part structure is not a formatting preference. It is the smallest amount of information from which someone can work out what to do. ### What Are the 4 Types of Operational Plans? A Startup View https://projan.ai/blog/operational-planning-for-startups-the-4-plan-types-and-the-annual-cycle/ Published: 2026-08-03 There is no canonical set of four. Operational plans divide reliably into two kinds: standing plans, which are reused (policies, procedures, rules), and single-use plans, which are made for one purpose and retired (programmes, projects, budgets). The four-type lists are subdivisions of those two, and they vary by textbook. This is for founders at companies small enough that the whole operating plan fits on two pages. It covers the taxonomy question honestly, a worked example, how the annual cycle actually runs, and how much of that cycle is worth your January when the company might look different by March. ## What are the 4 types of operational plans? Four is a convention, not a standard. Search the phrase and you will find lists that disagree with each other: one gives policies, procedures, rules and budgets; another gives standing, single-use, strategic and tactical; a third invents its own. None of them cite a source, because there is no source to cite. What does hold up is the split that mid-century management textbooks made, and which everything else is a rearrangement of: 1. **Policies.** Standing decisions that set the boundary a judgement call has to stay inside. "We refund unused annual seats pro rata" is a policy. It removes the need to decide again. 2. **Procedures.** Standing sequences that fix the order of a repeated task. Your incident escalation path is a procedure. It tells you what happens next, not what is allowed. 3. **Rules.** Standing statements that permit or forbid exactly one thing, with no judgement involved. "No production deploy after 4pm on a Friday" is a rule. 4. **Single-use plans.** Programmes, projects and budgets. Built for one objective, run, then retired. The SOC 2 push is one. This year's budget is one. The fourth item is carrying three ideas while the first three carry one each. That is the tell. Four exists because four is a tidy number for a slide, and the honest version of the taxonomy has two categories, not four. | | Standing plans | Single-use plans | |---|---|---| | **What it is** | A decision made once, applied repeatedly | A plan built for one objective, then retired | | **Typical forms** | Policies, procedures, rules | Programmes, projects, budgets | | **Startup examples** | Expense limits, on-call rota, code review rules | Q3 pricing migration, the SOC 2 project, this year's budget | | **Lifespan** | Until someone deliberately changes it | Until the objective is met or abandoned | | **How it fails** | Goes stale and gets quietly ignored | Outlives the assumption that justified it | The practical value of the distinction is knowing where each thing lives. Standing plans belong somewhere findable by a person who joined last week. Single-use plans belong wherever the work is tracked, with a date on which they stop mattering. Startups get this backwards, keeping the project plan pinned in Slack forever and never writing down the policy that gets re-argued every month. Operational plans are the layer below strategy, and the two get conflated constantly. If you are not sure which one you are writing, [the distinction between a strategy and a plan is worth settling first](/blog/strategy-vs-plan-which-comes-first-and-why-a-plan-alone-isn-t-a-strategy). ## What is an example of an operational plan? An operational plan is a dated list of what gets done, by whom, to what number. Here is one quarter for a hypothetical nine-person B2B SaaS company, at the level of detail that is actually useful. **Objective for Q3:** reach 40 paying teams and show that a team can onboard without a sales call. **The commitments:** - Growth lead: 300 qualified signups, from two channels, one of which must be new. Reports the split weekly. - Product lead: self-serve onboarding shipped by week 6, defined as a new team reaching first shared plan without human contact. - Engineering lead: onboarding work takes priority over the enterprise SSO request until week 6, then reverses. - Founder: 15 customer calls, written up in one place, feeding the week 7 pricing decision. **The constraints:** £48k of spend for the quarter, no new hires, 11 months of runway at the current burn. **The decision points:** week 6, does self-serve work or do we keep the call in the flow. Week 7, does pricing change. That fits on one screen and every line is checkable. What makes it an operational plan rather than a wish list is the second half of each item: the number, the date, or the definition of done. "Improve onboarding" is not a commitment anyone can fail. For a fuller breakdown of what belongs in the document, see [what goes in a startup operating plan](/blog/what-goes-in-a-startup-operating-plan-the-components-that-make-it-usable). Note what is absent. No headcount plan, no departmental budgets, no three-year revenue build. Those become useful when there are enough people to compete over them. ## What is an annual planning cycle? An annual planning cycle is the repeating sequence a company runs each financial year to set targets, fund them, commit to them and check them at intervals. It is a calendar, not a document. In a company that has grown past the point where everyone knows everything, it usually runs like this: 1. **Ten to twelve weeks out.** Leadership agrees the strategic direction and the top-line financial shape. What are we betting on, what are we stopping, roughly what does the money have to look like. 2. **Six to eight weeks out.** Teams draft their own plans against that direction, with headcount and budget requests attached. 3. **Four weeks out.** Reconciliation. The requests exceed the money by some distance, and things get cut. This is where most of the calendar time goes and where most of the politics live. 4. **Start of the year.** The annual planning meeting. Plans are presented, committed to and made visible internally. 5. **Each quarter.** A review that either confirms the plan or amends it in writing, with the amendment recorded rather than absorbed. Step 5 is the one companies skip, and skipping it is what turns an annual plan into a document nobody has opened since February. A plan with no scheduled moment to change it does not survive contact; it just stops being mentioned. ## What is the purpose of the annual planning meeting? The purpose of the annual planning meeting is to turn a pile of drafts into commitments with names attached, in one room where the trade-offs get argued once instead of relitigated all year. It is a decision-forcing event. If nothing is refused in it, it was a presentation. The two things that make it worth the diary time are visible trade-offs and named owners. Every team should be able to see what another team got and what it cost. Every objective should leave the room with one person's name against it, not a department's. Anything that ends with "we'll align on that offline" has failed in the room. There is more on running one in [the guide to annual planning meetings](/blog/what-is-an-annual-planning-meeting-purpose-participants-and-how-to-run-one-that). ## How much annual planning does a startup actually need? Less than the cycle above, and the answer scales with how stable your assumptions are, not with how many people you have. Running a full annual cycle at a company that might change its ideal customer in March is a two-week tax on January, paid in the currency you have least of. The version that works at this stage has three parts: 1. **A short plan.** One page per quarter, in the shape of the worked example above. Short enough that rewriting it costs an afternoon rather than a fortnight. 2. **A named rewrite trigger.** Write down, in advance, the specific events that would make the plan wrong. Not "if things change", which never fires. Something falsifiable: runway drops below nine months, a round closes, average contract value moves by more than half, two consecutive months miss the target by a third. When one fires, you rewrite. When none fire, you stop reopening the argument. 3. **A quarterly checkpoint with teeth.** Confirm or amend, in writing, and say which. Silent drift is the failure, not change. The trigger is the part people skip and the part that does the work. Without it every disappointing week becomes an invitation to relitigate the plan, and the plan gets rewritten by mood rather than by evidence. The other failure is not about length at all. It is that one founder writes the plan on a Sunday and the two people who have to hit the numbers read it on Monday. Whatever forces the argument before the document is finished is the useful part, whether that is a whiteboard or a tool. One option is [Projan](/landing/founder), which runs the planning discussion inside Slack, presses on who owns each number and what would count as missing it, then writes the agreed version out to Linear or Notion. ## Frequently asked questions **What are the types of operational plans?** Rather than memorising a list, sort your own plans by how long they live. Anything you will apply again next quarter is a standing plan and belongs somewhere findable. Anything built for one objective is a single-use plan and should carry an end date. Most startups have too few of the first and too many undated versions of the second. **What is the difference between a strategic plan and an operational plan?** A strategic plan says which game you are playing and what you are refusing to do. An operational plan says who does what by when to play it. Strategy answers why this market and this wedge; operations answer whether pricing ships before or after the enterprise tier. Founders usually have the first in their head and never write the second down. **Who should write a startup's operational plan?** One accountable owner drafts it, usually a founder or the person closest to the numbers, but the targets get agreed with whoever has to hit them before the document is final. A plan drafted alone and circulated for comment collects polite silence. The people who will be measured need to argue with the numbers while they can still change. **Should a pre-seed startup do annual planning at all?** Not in the corporate sense. At pre-seed the useful artefacts are a runway model, one written objective for the next quarter, and a named owner per workstream. That takes an afternoon. A full annual cycle with headcount requests and reconciliation rounds is worth running once you have enough people that departments start competing for the same budget. Treat the four-type question as trivia and the standing versus single-use split as the useful part, because it tells you where each plan should live. Then write the shortest plan that carries numbers, dates and names, and decide in advance what would make you tear it up. ### Epic vs User Story vs Task: How to Break Work Down Without Losing the Thread https://projan.ai/blog/epic-vs-user-story-vs-task-how-to-break-work-down-without-losing-the-thread/ Published: 2026-07-28 An epic is a large piece of work that delivers one outcome and gets split before it is built. A user story is a single change described from the point of view of somebody who uses the product. A task is a unit of execution with no user in it. They differ by scope and by whose language they use. That is the whole answer. The reason the question keeps being asked is that the words are not defined by any standard, and the tools most teams use have quietly redefined them. This piece covers the three levels, where the boundaries actually sit, and why your Jira board disagrees with the book you read. ## What is the difference between an epic, a user story and a task? Scope and audience separate them. An epic covers an outcome too large to finish in one pass, a user story covers one observable change for a user, and a task covers one piece of work an engineer picks up and completes. | | Epic | User story | Task | |---|---|---|---| | **What it is** | An outcome that needs splitting before it can be built | One change stated from a user's point of view | One piece of execution | | **Typical size** | Weeks to a few months, several people | A few days, one or two people | Hours to a day | | **Whose language** | Product and stakeholders | The user's | The engineer's | | **Usual shape** | A goal plus the stories that satisfy it | "As a [role], I want [change], so that [reason]" | An instruction: "Add an index on orders.created_at" | | **Estimated** | Rarely, and only in ranges | At refinement, in points or days | In hours, if at all | | **Done when** | Every story under it is done and the outcome is visible | Its acceptance criteria pass | The work is finished | | **Who reads it** | Anyone asking what the team is doing this quarter | The team, plus anyone reviewing scope | Whoever picks it up | Read that downward rather than across. The rows that decide the level are size and language: a ticket written in the user's words is a story, a ticket written in the team's words is a task, and a ticket that needs several of either is an epic. One caveat before anyone quotes this at a colleague. None of these three terms appears in the Scrum Guide, which talks only about Product Backlog items. Epic and user story come from Extreme Programming and from Mike Cohn's writing on stories, and everything since has been convention. Where the convention is contested, the team's agreement beats the definition. For the writing itself, [there is a real craft to phrasing stories and tickets engineers can act on](/blog/user-stories-use-cases-and-tickets-how-to-write-work-engineers-can-act-on), and it is a separate skill from choosing the level. ## Is an epic the same as a user story? No, but it started as one. In the original usage an epic was just a user story too large to build in one go, which would be split before the team committed to it. It described size, not a rung on a ladder. Two things happened after that. Tools turned the epic into a container with its own issue type, and teams started creating epics up front as planning artefacts rather than discovering them as stories that had grown too fat. Both are workable. Neither matches the original meaning, which is why one person on your team insists an epic is "a big story" and another insists it is "a folder of stories". They are both quoting something true. The practical test is whether the epic names an outcome. "Two-factor authentication" is a subject. "Customers can secure their account with two-factor authentication" is an outcome, and you can tell when it is done. An epic that has been open for eight months is not an epic. It is a category with a burndown chart attached. ## What is the difference between a user story and a task? A user story describes something a person outside the team can notice; a task describes work. That is the whole boundary, and it is more useful than any size rule, because plenty of tasks take longer than plenty of stories. The test that settles most arguments: name the person who is better off when this is done. If you can name them and say what changed for them, it is a story. If the honest answer is "the team" or "the codebase", it is a task. Some work should never be a story. Upgrading Postgres, rotating an expiring certificate, removing a dead feature flag, cutting the build time in half. Forcing those into "As a developer, I want a faster pipeline, so that I can ship faster" produces a sentence nobody believes and acceptance criteria nobody can test. Write them as tasks, put them in the same sprint, and let them compete for capacity honestly rather than in disguise. The reverse mistake is quieter. A story that decomposes into exactly one task was always a task, and wrapping it in story ceremony costs a refinement slot and an estimate for no gain. ## How Jira's issue types changed what these words mean Most of the confusion is a tooling artefact rather than a disagreement about definitions. Jira ships with a default hierarchy where subtasks sit at the bottom, Story, Task and Bug all sit together on the level above, and Epic sits above those. So in Jira, a task is not a smaller unit of a story. It is a peer of a story, at exactly the same level, with no user in it. Teams who learned the vocabulary from the tool rather than from the practice end up with a hierarchy that reads Epic, Story, Subtask, and a floating population of Tasks nobody is sure how to nest. That is not a mistake on their part. It is what the software told them. Other tools tell them something different: - **Jira**: Epic contains Story, Task and Bug; those contain Subtasks. Higher levels such as initiative exist only on the paid tiers. - **Azure DevOps** (Agile template): Epic contains Feature, Feature contains User Story, User Story contains Task. Here a task really is a child of a story. - **Linear**: no epic at all. Projects contain issues, and issues have sub-issues. Three tools, three shapes, one vocabulary. The lesson is not that one of them is right. It is that "epic" means whatever level your tool calls an epic, so pin that down once for your team and stop relitigating the word. If you are setting the structure up from scratch, [the choices about hierarchy, views and grouping are worth making deliberately](/blog/how-to-structure-a-jira-backlog-hierarchy-views-and-ways-to-organize-it). ## One epic, broken down Here is the shape in practice, using two-factor authentication on a business application. **Epic:** Customers can secure their account with two-factor authentication. Stories under it, each with a user who notices: - As an account owner, I can enable app-based two-factor authentication on my account. - As an account owner, I can generate and download recovery codes. - As a user with two-factor enabled, I am prompted for a code when I sign in from a new device. - As an admin, I can require two-factor authentication for everyone in my organisation. - As a user who has lost their device, I can regain access through support. Tasks in the same sprint, with no user in them: - Add TOTP secret storage with encryption at rest. - Add rate limiting to the verification endpoint. - Write the runbook for support-assisted account recovery. Notice what the split reveals. The support recovery path is a story, not a footnote, and the person who spots that is usually the one asked to staff the support rota. The sizing rules for that split, and the limits on how far to take it, are covered in more depth in [breaking an epic into user stories](/blog/how-to-break-an-epic-into-user-stories-sizing-rules-examples-and-limits). Where that split gets argued matters. Done as a quiet edit in the backlog, it gets reopened every sprint; done with the engineers who will take the stories, it gets decided once. Projan runs it as a structured conversation in Slack, asking what would still be missing if each story shipped on its own, then writing the agreed epic and its stories out to Jira or Linear. ## Five signs the hierarchy has stopped working The levels are meant to make work legible. When they stop doing that, the symptoms are consistent. 1. **Epics that never close.** A permanent epic called "Platform" or "Tech debt" is a label. Nothing under it is ever the last thing. 2. **Stories written for the team.** "As a developer, I want a caching layer" is a task in costume. It signals that the team believes only stories get scheduled. 3. **Subtask trees that need their own standup.** If a story has fourteen subtasks and the parent tells you nothing, the story was an epic. 4. **Estimated epics.** Pointing an epic means committing to a number before the work has been split, which is the guess you were trying to avoid. 5. **Bugs promoted to epics for visibility.** When severity gets expressed through issue type, the hierarchy has become a political instrument and the board has stopped describing the work. None of these is fatal on its own. Two or more at once usually means the backlog is being maintained for a reporting view rather than for the people building from it. ## Frequently asked questions **What sits above an epic?** Nothing standard. Many teams put an initiative or a theme above the epic to group several epics under one business goal, and Jira offers that level on its higher tiers. Some organisations add a portfolio level above that. None of it is defined by Scrum, so the number of levels above an epic is a local decision rather than a rule. **Is a bug a user story or a task?** Neither, in most tools. Jira and Azure DevOps both give bugs their own issue type sitting alongside stories, because a bug describes broken behaviour rather than new behaviour. Treat a small bug as a task the team just does, and a large one as a story with acceptance criteria, since a fix nobody can verify tends to come back. **Should a spike be a story or a task?** A task, usually, with a fixed time box and a named output. A spike is investigation, so it has no user-facing outcome and no acceptance criteria worth writing. Give it a question to answer, a deadline and a place to write the answer down. Spikes that produce no artefact are the easiest work in the backlog to repeat by accident. **Can a user story exist without an epic?** Yes, and most should. Small independent changes do not need a parent, and forcing one produces epics that exist only to hold unrelated tickets. Create an epic when several stories together deliver an outcome that none of them delivers alone. If you cannot say what that shared outcome is, you are describing a label, not an epic. **Does any of this matter if the team ships anyway?** It matters at the boundaries of the team. Levels exist so people outside the sprint can see what is being worked on without reading forty tickets. If your stakeholders never look at the backlog and the team plans well without the structure, keep it thin. The cost of a hierarchy is the effort of maintaining it. Size and audience are the only two variables that matter here, and everything else is your tool's opinion. Agree what each level means once, write it down where new joiners will find it, and spend the argument budget on scope instead. Who writes what at each level is a separate question, answered in [who writes user stories](/blog/who-writes-user-stories-po-ba-scrum-master-or-the-whole-team). ### What Should Be Included in a Software Test Plan? https://projan.ai/blog/how-to-write-a-software-test-plan-structure-steps-and-what-to-include/ Published: 2026-07-24 A software test plan should cover scope and what is explicitly out of scope, the test levels and types you will run, environments and test data, entry and exit criteria, roles, schedule, deliverables, defect handling and risks. Everything else is optional. The two sections that settle arguments later are the out-of-scope list and the exit criteria. This is written for engineers and QA leads producing a plan for a real release rather than for an auditor. It covers what belongs in each section, the process for writing one, how much detail your team actually needs, and what the document does once testing has started. ## What should be included in a software test plan? A software test plan should include the sections below, and a plan missing any of the first six will generate an argument at some point in the cycle. The wording of each section matters less than whether someone had to make a decision to write it. | Section | What it settles | What happens without it | |---|---|---| | Scope | Which features, versions, platforms and integrations are under test | Three people test the same happy path and nobody opens the admin views | | Out of scope | What is deliberately not being tested this cycle, and why | Every gap found after release is treated as an oversight | | Test levels and types | Unit, integration, system and acceptance, plus performance, security and accessibility | Non-functional testing is discovered in the final week | | Environments and test data | Which environment, which build, what data, who can reset it | A third of the failures turn out to be environment drift | | Entry criteria | What must be true before testing starts | QA burns two days on a build that does not deploy | | Exit criteria | What must be true before the release ships | The go or no-go call becomes a meeting about how everyone feels | | Roles and owners | Named people for execution, triage and the release decision | Triage stalls because nobody is allowed to set severity | | Schedule and milestones | Test windows, code freeze, the regression run, build dependencies | Testing absorbs whatever time development overran by | | Defect management | Severity and priority definitions, triage cadence, escalation path | The same severity argument, per bug, daily | | Risks and mitigations | What could stop testing, and the response | The one shared test device nobody booked | Add deliverables (where the cases live, what the summary report contains) and an approval line naming who can change the plan mid-cycle. Both are cheap to write and useful when the schedule slips. Of that list, exit criteria are the section teams most often fudge. "No open critical or high defects, all P1 test cases passed, performance within 10 percent of the current release" is a criterion. "Testing complete" is a hope. Exit criteria written after the bugs start arriving are not criteria, they are negotiations. If your acceptance criteria are already specific at the story level, most of this work is done, and [well-written acceptance criteria give you the pass conditions for free](/blog/acceptance-criteria-formats-types-and-how-they-differ-from-definition-of-ready). ## What is the purpose of a test plan document? The purpose of a test plan is to get agreement, before testing starts, on what will be tested, by whom, in which environment, and what result permits the release to ship. It is a decision record more than a procedure. The document does three jobs, in descending order of value: 1. **It forces the argument early.** Writing "out of scope: Safari on iOS 15, single sign-on flows" makes someone object in week one instead of in the release call. Almost all of the plan's value is generated during its review. 2. **It is a reference during execution.** People go back to the environment details, the severity definitions and the exit criteria, repeatedly. 3. **It is evidence afterwards.** When a customer asks what was tested, or a postmortem asks how a defect escaped, the plan says what was in scope and what was not. Nobody reads a test plan cover to cover after the first week. Judge yours by which sections people go back and look up, and cut the ones they never do. A plan that no one disagreed with during review is usually a plan no one read. ## What are the steps of test planning? Test planning runs from understanding the change, through deciding coverage and criteria, to arranging environments and getting the thing reviewed. There is no canonical five steps: templates in circulation count anywhere between four and nine, and anyone who insists on a specific number is counting their own template. The sequence below is the one most of them contain. 1. **Read the requirements and mark the ambiguity.** List what can be tested and, more usefully, the statements that cannot be tested as written. "Fast" and "handles load" are defects in the requirement, not in the code. 2. **Decide levels and types.** Which layers get automated coverage, what needs manual exploratory time, and which non-functional checks apply. Say plainly which ones do not. 3. **Set entry and exit criteria in numbers.** Write the build conditions that let testing start and the defect and coverage thresholds that let the release go out. 4. **Plan environments and data.** Name the environment, the deploy mechanism, the data set, its refresh process and the person who owns it. This is where most schedules quietly break. 5. **Estimate and schedule against the build plan.** Tie test windows to build availability, not to calendar dates invented in isolation. Include the regression run and the time to retest fixes, which is the estimate teams always omit. 6. **Name owners and the escalation path.** One person for execution, one for triage, one who makes the release call. Roles, not a team name. 7. **Review it with the people who will be blamed.** Engineering, product and whoever runs the deploy. Then fix a rule for changing the plan once testing is underway. Step seven is the one worth protecting. The plan gets its value from engineers pushing back on the out-of-scope list and product disputing the exit criteria while there is still time to move something. Where that conversation happens matters less than whether it happens before sign-off: some teams run a 30-minute call, others do it in a thread. [Projan](/landing/engineering) is built for the second, putting the scope and exit-criteria questions to QA and engineering in Slack, keeping the answers attached to the plan, and exporting the follow-up tasks to Jira or Linear. The mechanism is interchangeable. Skipping the review is not. ## How detailed should a test plan be? A test plan should be as detailed as the cost of being wrong, which for most product teams is a page or two rather than a document. Detail costs maintenance, and a plan that goes stale in week two is worse than a short one that stays true. Three rough tiers: - **Routine change to an existing product.** Half a page in the ticket: what changed, the regression surface it touches, the environment, the exit condition. No document. - **New feature, new integration surface, or a release several teams touch.** Two to four pages covering the full section list above. This is the standard case, and it is closely related to [planning QA for a single feature before code ships](/blog/how-to-plan-qa-for-a-new-feature-building-a-qa-strategy-before-code-ships). - **Regulated, safety-critical or contractually specified work.** The full documented set, reviewed and signed, because here the plan is evidence and its format may be dictated by a standard or a customer. What to leave out at every tier: your organisation's testing policy, a tutorial on the test tooling, a glossary, a restatement of the requirements, and the full list of test cases. Link to where the cases live instead. Pasting them in guarantees the plan is wrong within a sprint. ## Does an agile team still need a test plan? Yes, but a much smaller one, and not per sprint. The parts that survive on an agile team are the ones that are still contested: exit criteria for the release, environment and data ownership, non-functional coverage, and who makes the go or no-go call. The rest is either in the tickets or in a standing team convention. The practical form is one short page per release train or per epic, kept next to the work rather than in a documents folder, updated when the scope changes. If your team keeps a broader standing document about how testing is done in general, that is a different artefact with a different owner, and the distinction is worth getting straight: see [test plan vs test strategy vs QA plan and who writes each](/blog/test-plan-vs-test-strategy-vs-qa-plan-who-writes-what-and-when). ## Frequently asked questions **What are the 5 steps to create a test plan?** There is no agreed set of five. Templates count anywhere from four steps to nine, and the numbering is a feature of the template rather than the discipline. If you want a compressed version: understand what is being built, decide what you will test and what you will not, fix entry and exit criteria, arrange environments and people, then get it reviewed by the engineers involved. **Which details are usually documented in a test plan?** The details people look up later are the ones worth documenting: the exact build and environment under test, how to reset the test data, severity and priority definitions, the numeric exit criteria, and who makes the go or no-go call. Narrative sections about testing philosophy are written once and never opened again. **What is the difference between a test plan and a test case?** A test plan describes the whole testing effort for a release: scope, environments, criteria, owners and schedule. A test case describes one specific check, with steps, input data and an expected result. A plan references where the cases live. Pasting hundreds of cases into the plan makes it unreadable and immediately stale. **Do you need a test plan for a small bug fix release?** Not a full one. A patch release needs three things written down: what changed, what regression surface that change touches, and what result lets it ship. That fits in the ticket. The trap is a fix that looks small and sits under shared code, where the honest regression scope is much larger than the diff. **What is IEEE 829 and is it still used?** IEEE 829 was the standard for software and system test documentation, last revised in 2008 and since superseded by ISO/IEC/IEEE 29119-3. Very few teams follow it directly now, but most test plan templates in circulation still carry its section list, which is why so many of them look identical. Treat it as ancestry, not obligation. A test plan earns its place by settling the two questions that otherwise get settled under deadline pressure: what you are not testing, and what result lets the release ship. Write those two sections properly, keep the rest short enough to stay accurate, and put the draft in front of the engineers who will be asked why a defect escaped. ### How to Write a PRD in 2026: The Complete Guide for Product Managers https://projan.ai/blog/how-to-write-a-prd/ Published: 2026-03-10 ## What is a PRD? A Product Requirements Document (PRD) is the single source of truth for what you're building. It defines the problem, the solution, and the acceptance criteria that tell your team when it's done. Good PRDs prevent the most expensive kind of bug: the one that starts in the spec. ## Why most PRDs fail **They're too long.** A 20-page PRD is a document nobody reads. The best PRDs are concise - they capture decisions, not descriptions. **They're written in isolation.** A PM writes a PRD alone, then throws it over the wall. Engineers find gaps on day one. The spec was never pressure-tested. **They use vague language.** "The system should be user-friendly" is not a requirement. It's a wish. Good requirements are specific, testable, and unambiguous. ## The structure of a great PRD ### 1. Problem statement Start with *why*. What user problem are you solving? What evidence do you have that this problem exists? Bad: "Users need a dashboard." Good: "42% of users contact support to check their usage. They need a self-service way to view usage data." ### 2. Goals and success metrics How will you know this worked? Define 2-3 measurable outcomes. - Reduce support tickets about usage by 50% - 80% of users check the dashboard at least once per week - NPS for billing experience improves by 10 points ### 3. User stories and acceptance criteria Break the work into user stories. Each story needs acceptance criteria that developers can test against. **User Story**: As a customer, I want to see my monthly usage so I can understand my bill. **Acceptance Criteria**: - Shows usage data for the current billing period - Updates within 1 hour of actual usage - Displays a comparison to the previous month - Works on mobile (responsive down to 375px) ### 4. Technical considerations Flag anything that will affect implementation decisions: - API rate limits or data freshness constraints - Security requirements (PII, access control) - Performance targets (page load under 2s) - Integration points with existing systems ### 5. Out of scope Explicitly state what you're *not* building. This prevents scope creep and sets expectations. ## PRD template Here's a minimal template you can use today: ```markdown # [Feature Name] ## Problem [2-3 sentences on the user problem and evidence] ## Goals - [ ] [Measurable outcome 1] - [ ] [Measurable outcome 2] ## User Stories ### Story 1: [As a... I want... so that...] **Acceptance Criteria:** - [ ] [Testable criterion] - [ ] [Testable criterion] ## Technical Notes - [Constraints, dependencies, security considerations] ## Out of Scope - [What we're NOT doing] ## Open Questions - [Decisions still needed] ``` ## How AI changes PRD writing The hardest part of writing a PRD isn't the writing - it's the thinking. You need to identify gaps, consider edge cases, and structure your requirements so developers can actually build from them. AI tools like [Projan](https://projan.ai) flip the process. Instead of staring at a blank page, you have a conversation. The AI asks clarifying questions - the same questions a senior PM would ask and structures your answers into a complete PRD with epics, stories, and acceptance criteria. The result: PRDs that take minutes instead of hours, with fewer gaps and a consistent structure every time. ## Common PRD mistakes to avoid 1. **Describing solutions instead of problems.** Let your team propose solutions. You define the problem and constraints. 2. **Missing edge cases.** What happens when the user has no data? When they're offline? When they hit a limit? 3. **No acceptance criteria.** If you can't test it, it's not a requirement. 4. **Writing for yourself.** Your PRD is for developers, designers, and QA. Write for them. 5. **Never updating it.** A PRD is a living document. Update it as decisions are made during development. ## Start writing better PRDs today Whether you use a template, an AI tool, or a blank doc - the key is to be specific, be concise, and involve your team early. Want to skip the blank page entirely? [Try Projan free for 14 days](https://app.projan.ai/create-account) and see how a conversation becomes a spec. ### How to Make AI Coding Tools Actually Useful - Part 2 https://projan.ai/blog/how-to-make-ai-coding-tools-actually-useful/ Published: 2026-03-08 ## Quick recap In [part 1](/blog/ai-coding-tools-are-incredible-until-you-skip-planning), I talked about why AI coding tools produce chaotic results when you skip planning. The tools are brilliant. The problem is we throw vague instructions at them and then act surprised when the output is vague. This post is about the fix. ## The vibe coder spectrum Not all vibe coding is equal. There's a spectrum, and where you sit on it determines whether AI tools help or hurt you. **Pure vibe coder.** "Build me an app that does X." No spec, no criteria, no constraints. The AI decides everything. This works for throwaway prototypes and nothing else. **Guided vibe coder.** "Build me an app that does X, with these 3 user types, this data model, and these 5 core flows." The AI has direction. Output is decent but still misses edge cases and non-obvious requirements. **Spec-driven builder.** "Here are the user stories, acceptance criteria, edge cases, constraints, and what's out of scope. Build this." The AI produces genuinely production-quality work. You spend your time reviewing instead of rewriting. The difference between these three is not the tool. It's the 30 minutes of planning before you open the tool. ## What AI coding tools actually need from you I've been using these tools heavily, and I've noticed a pattern in what separates good results from bad ones. The AI needs five things from you before it can do great work: ### 1. Context about your system The AI doesn't know your codebase, your tech stack, your naming conventions, or your existing patterns. When you start a session without providing context, the AI makes assumptions. Sometimes those assumptions are fine. Often they clash with everything you've already built. Before you start, tell the AI: - What framework and language you're using - What patterns you follow (folder structure, naming, state management) - What existing code this feature needs to integrate with - What external services or APIs are involved This isn't overhead. It's the same context you'd give a new developer on their first day. ### 2. A clear problem statement "Build a notification system" is not a problem statement. It's a solution. The AI needs to know why. "Users miss important updates because they only see them when they log in. We need a way to notify users of critical events within 5 minutes, even when they're not active in the app." Now the AI understands the constraint (5 minutes), the trigger (critical events, not all events), and the user state (not active). It'll make better architectural decisions because it understands the problem. ### 3. Acceptance criteria for every feature This is the single biggest lever you have. Acceptance criteria tell the AI what "done" looks like, and they tell it exactly what to test. Bad: "Users can reset their password." Good: - User receives a reset email within 60 seconds of requesting it - Reset link expires after 24 hours - Reset link is single-use; clicking it twice shows an error - Password must meet minimum strength requirements (8 chars, 1 number, 1 uppercase) - User is logged out of all sessions after resetting - If the email doesn't exist, show the same success message (don't leak user existence) The second version gives the AI everything it needs. It'll handle the expiry logic, the single-use token, the security consideration about not leaking emails. You didn't have to debug any of that after the fact because you thought about it before. ### 4. Edge cases, explicitly listed As I covered in part 1, AI tools don't think about edge cases on their own. You need to hand them a list. For any feature, spend 5 minutes asking yourself: - What happens with zero data? - What happens with a massive amount of data? - What happens when the user does this twice? - What happens when two users do this at the same time? - What happens when the network drops partway through? - What happens when the user doesn't have permission? - What happens on mobile? On a slow connection? With a screen reader? Write these down. Include them in your prompt or your spec. The AI will handle them. But it won't think of them. ### 5. What's out of scope This one surprises people, but it's critical. Without a scope boundary, AI tools will gold-plate. They'll add features you didn't ask for because they seem related. They'll build a full notification preference system when you just wanted email alerts. They'll add internationalisation support because "it's best practice." Tell the AI what you're NOT building. "No push notifications in v1. No notification preferences UI. English only. No batching/digest emails." Constraints make the AI faster and more focused. Just like they do for human developers. ## A practical workflow Here's what actually works for me when using AI coding tools on real projects: **Step 1: Write a mini spec (15 minutes).** Problem, users, core user stories, acceptance criteria, edge cases, out of scope. Doesn't need to be pretty. A markdown file is fine. A conversation in Slack is fine. A bullet list in a notes app is fine. The format doesn't matter. The thinking does. **Step 2: Feed the spec to the AI.** Start your coding session by giving the AI your spec as context. "Here's what we're building. Here are the requirements. Here are the edge cases. Here's what's out of scope." **Step 3: Build in focused chunks.** Don't ask the AI to build the entire feature at once. Break it into stories and build one at a time. Review the output. Run the tests. Move to the next one. **Step 4: Test against your acceptance criteria.** This is where the spec pays for itself ten times over. You have a checklist. Go through it. Does the feature actually meet every criterion? The AI probably got 80% right on the first pass. Fix the remaining 20% with targeted follow-ups. **Step 5: Check the edge cases.** Go through your edge case list one by one. Empty state? Handled. Concurrent access? Handled. Permission boundary? Handled. This takes 10 minutes and catches the bugs that would have taken hours to find in production. ## The planning is the product Here's the uncomfortable truth about AI coding tools: they've made the "writing code" part almost trivially fast. Which means the bottleneck has shifted entirely to "deciding what to write." Planning was always important. But when coding took days, you could sometimes get away with figuring things out as you went. The cost of a wrong decision was a day of wasted work. Now that coding takes minutes, the cost of a wrong decision is still a day of wasted work. Because you'll spend that day debugging, rewriting, and discovering edge cases you should have caught up front. The teams and solo builders who are getting the most value from AI coding tools aren't the ones who prompt the fastest. They're the ones who plan the best. ## Where this is going I think we're heading toward a world where "software developer" means something closer to "software planner." The ability to define requirements clearly, think through edge cases, and specify what done looks like will matter more than the ability to write a for loop. The developers who thrive with AI tools will be the ones who can think through a feature completely before a single line of code gets written. The ones who struggle will be the ones who skip that step and wonder why their AI-generated code keeps breaking in production. Planning isn't the boring part anymore. It's the entire game. If you're finding that the planning step is the bottleneck, that getting requirements out of conversations and into something structured takes too long, [Projan](https://projan.ai) is built specifically for this. It turns your product discussions into structured specs with acceptance criteria and edge cases. The kind of specs that make AI coding tools actually work. [Try it free for 14 days](https://app.projan.ai/create-account). ### AI Coding Tools Are Incredible (Until You Skip the Planning) - Part 1 https://projan.ai/blog/ai-coding-tools-are-incredible-until-you-skip-planning/ Published: 2026-03-05 ## AI coding tools are genuinely amazing I need to say this up front because the rest of this post is going to sound critical. AI coding agents, tools like Cursor, Copilot, Claude Code, Windsurf, and the rest of them, are some of the most impressive technology I've ever used. I watch them scaffold entire features, write tests, refactor code, and solve problems I would have spent hours debugging. They are not the problem. The problem is us. Specifically, the problem is what happens when you hand a powerful tool to someone who hasn't decided what they're building yet. ## The rise of vibe coding There's a term floating around now: vibe coding. It means sitting down with an AI agent and just... going. No spec. No plan. No acceptance criteria. You describe what you want in plain English, the AI writes the code, you look at the output, you adjust, you keep going. It feels incredible. You're shipping features in an afternoon that would have taken a week. You feel productive. You feel like the future arrived early. Then you show it to users. Or your cofounder. Or your team. And you realise you built something that technically works but doesn't actually solve the problem. ## The AI doesn't know what you know Here's the thing about AI coding tools that people forget: they are extraordinary at the "how" and completely blind to the "what" and "why." When you tell an AI agent "build me a user authentication system," it will build one. It'll probably be pretty good. It'll have login, registration, password hashing, maybe even JWT tokens. But it won't ask you: - Do users need to log in with Google? Microsoft? SSO? - What happens when someone forgets their password while they're on a plane with no email access? - Is there a free tier? What can free users access? - Do you need to support multiple users per organisation? - What about GDPR? Do you need a data deletion flow? - Can users have multiple sessions? Should logging in on one device log them out elsewhere? - What happens when a user's trial expires mid-session? An experienced PM or engineer would ask these questions within the first ten minutes. The AI just builds what you described and moves on. ## Edge cases are where products live or die This is the part that really gets me. AI coding tools are almost comically bad at thinking about edge cases unprompted. And edge cases aren't rare situations. They're the situations your users will absolutely hit. Here's a partial list of edge cases I've seen AI-generated code completely miss: **Empty states.** What does the dashboard look like when a new user has no data? The AI builds a beautiful dashboard that shows charts and tables, but with zero data it renders a broken mess. Nobody thought about the first-time user experience because nobody wrote it down. **Error handling.** The AI builds the happy path perfectly. But what happens when the API returns a 500? When the database connection drops? When the user submits a form twice? When their session expires between loading the page and clicking submit? The AI doesn't think about these scenarios unless you explicitly describe them. **Permissions.** The AI builds an admin panel. Great. Can regular users see it? Can they access admin API endpoints directly? What about users whose role changes while they're logged in? The AI built what you asked for. You didn't ask for permission boundaries. **Data migration.** You asked for a new feature that changes the data model. The AI wrote the new code. It did not write a migration for your existing 10,000 users who have data in the old format. Their accounts are now broken. **Concurrency.** Two users edit the same document at the same time. The AI built a document editor. It didn't build conflict resolution. Last write wins, and someone just lost 30 minutes of work. **Accessibility.** The AI built a custom dropdown component. It looks great. A screen reader user can't interact with it at all. No ARIA labels, no keyboard navigation, no focus management. **Rate limiting.** The AI built an API endpoint that calls an external service. Under normal load it works fine. Under heavy load it burns through your API quota in 20 minutes because nobody specified rate limits. I could keep going. I could fill an entire article with just edge cases. And that's exactly the point. The list is endless, and AI tools will miss almost all of them unless you tell them what to look for. ## The AI is a mirror of your preparation The quality of AI-generated code is directly proportional to the quality of the instructions it receives. Give it a vague prompt, get vague code. Give it detailed acceptance criteria with edge cases specified, get something genuinely useful. I've seen the exact same AI tool produce terrible output and brilliant output in the same afternoon. The difference wasn't the model. It was the prompt. And prompts are just requirements by another name. ## Vibe coding isn't building. It's prototyping. There's nothing wrong with vibe coding as an exploration tool. Sitting down with an AI agent and riffing on ideas is a fantastic way to prototype. You can validate a concept in an hour. You can see if an approach feels right before investing real time. The problem is when people treat the prototype as the product. When "it works on my machine with test data and a single user" becomes "ship it." Prototyping without a plan is creative exploration. Building without a plan is expensive chaos. ## What's actually missing Every vibe coding disaster I've seen traces back to the same root cause: nobody wrote down what they were building before they started. Not a 50-page requirements document. Not a formal PRD. Just the basics: - What problem are we solving? - Who is the user? - What does "done" look like? - What are the known edge cases? - What is explicitly out of scope? Five questions. Takes 20 minutes to answer properly. Saves days, sometimes weeks, of building the wrong thing. In part 2, I'll cover exactly how to set up AI coding tools for success. Because the answer isn't to stop using them. The answer is to stop using them blind. ### Why Sharing Your Product Roadmap Publicly Builds More Trust Than You'd Expect https://projan.ai/blog/transparent-planning-builds-trust/ Published: 2026-03-01 ## The Polished Roadmap Nobody Believes Most public roadmaps are marketing documents. Vague categories like "Q2: Enhanced Collaboration" that could mean anything. Timelines that never slip. No mention of what got cut or delayed. Users look at these and mentally file them under "we'll believe it when we see it." An honest roadmap is different. It says: "Here's what we're building, here's why we chose it, here's what we're not building yet, and here's what might change." It feels risky to share. But it builds the kind of trust that polished marketing never can. ## What Transparency Actually Looks Like I'm not talking about dumping your internal project board on a public page. Transparency in roadmapping means sharing three things: **What you're working on now, and why.** Not just the feature name. The reason behind it. "We're building team permissions because 40% of our paid users have asked for multi-user access, and it's the number one reason prospects don't convert." **What's coming next, with honest timelines.** "We're planning to ship bulk export in Q2. This might slip if the permissions work takes longer than expected." Users can handle uncertainty. What they can't handle is silence followed by surprise delays. **What you're explicitly not building yet.** "We know many of you want a mobile app. It's not in our plan for this year because we want to get the web experience right first. Here's why." ## Why Users Trust Honest Plans More When you share the reasoning behind your priorities, something shifts in how users relate to your product. **They feel heard.** Even if their feature request isn't on the roadmap, seeing that you have a structured decision-making process is reassuring. It's the difference between "they don't care about my request" and "they considered it, and here's why something else comes first." **Feedback quality improves.** When users can see your roadmap, they give you feedback in context. Instead of "you should build X," they say "I see you're planning Y, but have you considered that X would solve the same problem more directly?" That's a much more useful conversation. **Advocates emerge.** Users who feel included in the product's direction become advocates. They share your updates. They defend your prioritization decisions in community threads. They tell other people "this team is transparent about what they're building." That kind of word-of-mouth is hard to manufacture. ## The Fears (And Why They're Overblown) ### "Competitors will copy our roadmap" If a competitor can beat you by reading your public roadmap, your roadmap wasn't your advantage in the first place. Execution, speed, customer relationships, domain knowledge: those are moats. A list of planned features isn't. Most competitors are too busy with their own priorities to monitor your roadmap closely. And if they do copy a feature, you'll have shipped it first and learned from real user feedback before they even start. ### "Users will complain about missing features" They're already complaining. The difference is whether they're complaining into a void (frustrating) or complaining in the context of a visible plan (productive). When users can see that their request is on the "later" list, most are satisfied. When they can't see any plan, they assume you've forgotten them. ### "We'll look bad if we miss a deadline" You'll look worse if you quietly miss deadlines and pretend they never existed. A quick update that says "permissions took longer than expected, here's the new timeline" builds more trust than silence. ## How to Share Your Roadmap Publicly A few practical approaches that work: **Keep it simple.** Three columns: Now, Next, Later. Move items between columns as priorities shift. You don't need roadmap software for this. A public Notion page or a section on your website works fine. **Update it regularly.** A stale roadmap is worse than no roadmap. Set a reminder to update it every two weeks. Even if nothing changed, confirm that the priorities are the same. **Include context, not just names.** "Team permissions" means nothing to a user. "Multi-user access so your whole team can collaborate on projects" tells them whether this matters to them or not. **Add a feedback mechanism.** Let users upvote, comment, or submit requests. This gives you data on what actually matters versus what's loudest. **Be honest about changes.** When you cut something or reprioritize, explain why. "We moved mobile app from Next to Later because our analytics show 96% of active usage on desktop" is a perfectly acceptable explanation. ## The Trust Compound Transparency compounds. Each honest update builds a little more trust. Over time, your users stop asking "when is X coming?" because they know where to check. They stop worrying that the product will pivot away from their needs because they can see the plan. This trust translates directly into retention and referrals. Users stay longer with products they believe in. And they believe in products that treat them like partners, not just customers. Sharing your roadmap feels vulnerable the first time. But once you see how users respond to honesty, you won't go back to the polished, empty alternative. ### How Scope Creep Nearly Killed Our Startup https://projan.ai/blog/scope-creep-nearly-killed-our-startup/ Published: 2026-02-25 ## Saying Yes to Everything In our first three months after launch, we had about 50 active users. For an early-stage startup, that felt incredible. People were using the thing we built. And they had opinions. "Can you add a calendar view?" "Would be great if this exported to PDF." "Any plans for a Slack integration?" "We'd love custom branding on the reports." Every request felt reasonable. Every user who asked felt important. We were so excited that people cared enough to ask for features that we said yes to almost everything. By month three, our product did 20 things. None of them well. ## The Slide Into Chaos The codebase became a maze. Every new feature had been bolted on to a foundation that wasn't designed for it. Adding the calendar view meant restructuring the data model. The PDF export worked for simple reports but broke on anything complex. The Slack integration was half-finished because we'd pivoted to custom branding midway. Our bug count tripled. Load times crept up. The core feature, the thing people originally signed up for, got worse because every sprint was spent on shiny new additions instead of polishing what existed. Users started churning. Not because they were missing features. Because the features they relied on stopped working reliably. The irony was brutal: we'd added features to retain users, and the features were driving them away. ## The Week That Saved Us We called a full stop. No coding for a week. The team sat down and asked one question: "What problem does this product solve?" Not "what can it do." What problem does it solve. We went back to our original user interviews. The core problem was clear: teams needed a faster way to create and share project briefs. That was it. Calendar views, PDF exports, custom branding; none of that was core. Some of it was tangentially useful. Most of it was distraction. We made a list of every feature in the product and sorted them into three buckets: 1. **Core:** directly solves the main problem (5 features) 2. **Supporting:** makes the core better (4 features) 3. **Noise:** nice to have, not essential (11 features) We cut everything in bucket three. Removed it from the codebase, the UI, the marketing site. Eleven features, gone. ## What Happened Next Usage went up. Not immediately. The first week after the cuts, we got a few complaints from users who relied on removed features. We emailed each one personally, explained the decision, and offered to help them find alternatives. Most understood. A couple left. That was okay. Within a month, the product was faster, more stable, and easier to explain. New users could understand what it did in 30 seconds instead of 3 minutes. Our trial-to-paid conversion rate doubled because the first experience was focused instead of overwhelming. The team's velocity increased because they were working on a smaller, cleaner codebase. Bugs dropped. Morale improved. We shipped meaningful improvements to the core features every week instead of spreading thin across a dozen half-built additions. ## The Lesson: A Spec Is a Shield Scope creep doesn't announce itself. It arrives disguised as good ideas, customer requests, and market opportunities. Each addition seems small. "It's just a calendar view." "PDF export is only a few days of work." But the compound effect is devastating. The fix isn't willpower. It's a written spec. When you have a document that defines what you're building, who it's for, and what's explicitly out of scope, every feature request gets filtered through that document. "Does this serve the core problem?" If yes, prioritize it. If no, add it to a "future" list and move on. Without the spec, every conversation about new features is a negotiation. With the spec, it's a reference check. ## How to Prevent Scope Creep Before It Starts Three practices that work: **Write down your out-of-scope list before you launch.** Not just what you're building. What you're not building. Review it monthly. It's your first line of defense. **Create a "parking lot" for feature requests.** Every request goes in the parking lot. Review the parking lot quarterly, not weekly. This creates a buffer between "a user asked for it" and "we're building it." **Tie every sprint to the core problem.** Before committing to work, ask: "Does this make us better at solving the core problem?" If the answer is "not really, but it's a nice addition," it can wait. Planning isn't just about what you build. It's about what you choose not to build. That choice, made deliberately and early, is the difference between a focused product and a feature graveyard. ### 5 Conversations Every SaaS Founder Should Have Before Writing Code https://projan.ai/blog/5-conversations-before-writing-code/ Published: 2026-02-20 ## The Most Expensive Code Is Code You Didn't Need to Write I've watched founders burn three, six, even twelve months building something nobody wanted. Not because they were bad engineers. Because they skipped the conversations that would have told them what to build, what to skip, and whether to build at all. Before you write a single line of code, have five conversations. They'll take a week or two. They'll save you months. ## Conversation 1: Five Potential Users About the Problem Not about your solution. About the problem. Find five people who you believe have the problem you want to solve. Don't pitch them. Don't show them mockups. Just ask about their current workflow and where it breaks down. **What to ask:** - "Walk me through how you handle [process] today." - "What's the most frustrating part?" - "How have you tried to fix it?" - "What does this problem cost you in time or money?" **What to listen for:** Are they describing the problem with emotion, or is it just a minor annoyance? Do they already have workarounds? How much effort have they put into solving it themselves? If five people describe the same pain in similar terms, you're onto something. If they all shrug and say "it's fine, I guess," reconsider. The critical thing here: don't mention your solution during these conversations. The moment you pitch, people stop telling you the truth and start being polite. ## Conversation 2: Your Technical Cofounder or CTO About Feasibility If you have a technical partner, sit down and talk through the core technical risks before committing to anything. **What to discuss:** - What's the hardest technical problem in this product? - What are we uncertain about? - Where will we need third-party services versus building our own? - What's the minimum we could build to test the core assumption? **What to listen for:** Where does your technical person hesitate? What makes them say "that depends"? Those are your risk areas. Better to find them now. If you're a solo technical founder, have this conversation with yourself, but be brutally honest. Write your concerns down. The act of writing makes it harder to hand-wave. ## Conversation 3: Someone Who Tried to Solve This and Failed This one is harder to arrange, but it's gold. Find someone who built a product in the same space and didn't make it. Buy them a coffee. Ask what happened. **What to ask:** - "What was your original thesis?" - "When did you first realize it wasn't working?" - "If you could do it over, what would you change?" - "What do you know now that you wish you knew at the start?" **What to listen for:** Patterns. Was it a distribution problem? A pricing problem? Did they build too much before validating? Were they solving a problem people said they had but wouldn't pay to fix? These conversations are humbling and incredibly valuable. The failure patterns in your space are usually well-known to people who've experienced them. ## Conversation 4: A Competitor's Customer About What's Missing If competitors exist (and they almost certainly do), find someone who uses a competing product. LinkedIn is great for this. Most people are willing to chat for 15 minutes about tools they use at work. **What to ask:** - "What made you choose [competitor]?" - "What do you wish it did differently?" - "What's your biggest workaround?" - "If you could change one thing about it, what would it be?" **What to listen for:** The gaps. Not the minor complaints, but the structural limitations. "I wish it integrated with X" is a feature request. "I export everything to a spreadsheet because their reporting can't do what I need" is a gap you can build a product around. If the competitor's customers are mostly satisfied, that's important data too. It means you'll need a strong differentiator, not just a slightly better version of the same thing. ## Conversation 5: Yourself, Honestly, About Why You're the One to Build This This is the conversation most founders skip. Sit down with a blank page and answer these questions: - Why am I the right person to solve this problem? - Do I have an unfair advantage (domain expertise, distribution, technical edge)? - Am I willing to work on this specific problem for 3 to 5 years? - If a better-funded competitor copies my approach in 6 months, what's my moat? - Am I building this because I'm excited about the problem, or because I'm excited about being a founder? Be honest. There are no wrong answers, but there are answers you need to face before investing a year of your life. ## Turning Conversations Into a Plan After these five conversations, you'll have something most founders lack when they start coding: context. You'll know the real shape of the problem, the technical risks, the market gaps, the failure patterns, and your own motivations. The next step is capturing all of that into a structured product spec before you build. Tools like [Projan](https://projan.ai) are designed for exactly this: you talk through what you've learned, and it helps you structure it into a clear plan with user stories, priorities, and scope boundaries. [Start building your spec](https://app.projan.ai/create-account). The conversations gave you the insight. Now turn it into something you can execute against. You can't shortcut the conversations. But you can make sure the insights from those conversations don't get lost in a pile of scattered notes. Write the spec, then write the code. ### What Investors Actually Look for in Your Technical Roadmap https://projan.ai/blog/what-investors-look-for-in-technical-roadmap/ Published: 2026-02-16 ## The Roadmap Slide That Makes Investors Tune Out I've sat in on pitch reviews with accelerator mentors and angel investors. The technical roadmap slide is almost always the weakest part of the deck. Not because the founders aren't technical. Because they present the wrong information. The typical founder roadmap looks like this: a timeline with feature names. "Q1: Build API. Q2: Launch mobile app. Q3: Add integrations. Q4: Scale infrastructure." Maybe some icons. Maybe color coding by workstream. Investors glance at it and move on. It tells them nothing useful. ## What Investors Actually Care About After dozens of these conversations, the pattern is clear. Investors evaluate your roadmap on four criteria, none of which are about technology. ### 1. Can You Articulate What You're Building and Why? This sounds basic, but many founders describe their roadmap as a feature list without connecting features to problems. "We're adding team collaboration" is a feature. "Our top 10 customers all asked for multi-user access, and three said they'd upgrade to annual plans if we shipped it" is a business rationale. Every item on your roadmap should have a "because" attached. Investors want to see that you're building things for reasons, not just building things. ### 2. Are Milestones Tied to Business Outcomes? The best roadmaps connect technical milestones to metrics investors understand. **Weak:** "Q2: Launch self-serve onboarding" **Strong:** "Q2: Launch self-serve onboarding (target: reduce time-to-first-value from 3 days to 30 minutes, increase trial-to-paid conversion from 8% to 15%)" The second version tells an investor that you understand how the technical work drives the business. It also gives them something to evaluate: are those targets realistic? Are they ambitious enough? ### 3. Can You Explain the Trade-offs You've Made? Investors know you can't build everything. They want to see evidence that you're making deliberate choices. What did you decide NOT to build, and why? "We're not building a mobile app in year one because 94% of our users access the product on desktop during work hours. Mobile can wait until we've nailed the core experience." That sentence demonstrates customer understanding, data-driven thinking, and discipline. A feature wish list demonstrates none of those. ### 4. Is the 6-12 Month Plan Realistic? Experienced investors have seen hundreds of roadmaps. They can spot the ones that are aspirational fiction. If your 3-person team plans to launch a mobile app, an API platform, an AI assistant, and international expansion in 12 months, you've lost credibility. A realistic roadmap has 2 to 3 major milestones per quarter, not 8. It accounts for the fact that things take longer than expected. It has clear dependencies ("we can't do X until Y is in place"). ## What to Show Instead of a Feature List Structure your investor-facing roadmap like this: **Now (current quarter):** - What you're building, tied to specific customer or growth problems - Key metric you expect to move - What's already validated versus what's an assumption **Next (following quarter):** - 2 to 3 priorities, connected to "Now" outcomes - What needs to be true for these to make sense (e.g., "if trial conversion hits 12%, we'll invest in...") **Later (6-12 months):** - Strategic direction, not specific features - Market triggers that would change the plan - Hiring needs tied to roadmap phases This structure tells investors you think in outcomes, you plan with dependencies, and you're adaptable. That's far more reassuring than a beautiful Gantt chart. ## The Question Behind the Question When an investor asks "what's your roadmap," they're really asking: "Can this founder think clearly about priorities, make hard choices, and execute systematically?" Your tech stack doesn't answer that question. Your feature list doesn't answer it either. A roadmap that connects technical work to business logic, shows deliberate trade-offs, and feels honest about timelines? That answers it. ### Shipping AI Features Without a Spec Is Like Flying Without Instruments https://projan.ai/blog/shipping-ai-without-spec-flying-without-instruments/ Published: 2026-02-11 ## Clear Weather Flying When AI features are simple, you can get away without a spec. A sentiment analysis label on support tickets. A basic text summarizer. These are clear-weather flights. You can see where you're going, the inputs are predictable, and the outputs are easy to evaluate. But the moment you're building something complex, a multi-step agent, a RAG system, a fine-tuned model for a specific domain, you're flying in clouds. Without instruments, you're guessing. And in AI, guessing means weeks of "is this good enough?" debates with no resolution. ## Why Traditional Specs Don't Work for AI A traditional product spec assumes deterministic behavior. "When the user clicks Submit, the form data is saved to the database." Either it works or it doesn't. You can write a binary test. AI features are probabilistic. The output is different every time. "Good" is a spectrum, not a boolean. A spec that says "the AI should generate helpful summaries" is meaningless. Helpful how? Helpful compared to what? Helpful for whom? Teams that skip AI-specific requirements end up in a loop: build something, show it to stakeholders, get vague feedback ("it's not quite right"), adjust, repeat. There's no finish line because nobody defined what "good enough" looks like. ## What an AI Feature Spec Should Include Beyond the standard sections (problem, users, scope), AI features need additional specifics. ### Performance Benchmarks Define measurable quality targets before you build. "The summarizer should produce summaries that are rated 4+ out of 5 by domain experts on a sample of 100 documents." Or: "The classifier should achieve 92% precision on our test set." Without benchmarks, you'll ship when the team gets tired, not when the feature is ready. ### Acceptable Error Rates Every AI system makes mistakes. The spec should define which mistakes are tolerable and which aren't. For a medical triage system, a false negative (missing a serious condition) might be unacceptable, while a false positive (flagging something as urgent that isn't) might be fine. For a content recommendation engine, occasionally surfacing irrelevant content is okay; surfacing offensive content is not. Write these down. Different team members will have different intuitions about what's acceptable unless you specify it. ### Fallback Behaviors What happens when the AI fails? This is the section most teams forget entirely. - If the model returns low-confidence results, do we show them with a warning, or hide them? - If the API times out, what does the user see? - If the model produces harmful or nonsensical output, is there a filter? - Can the user override or correct the AI's output? Fallbacks aren't edge cases. In AI features, they're core behavior. ### Data Requirements Specify what data the model needs and where it comes from. - Training data: source, size, labeling approach, refresh frequency - Runtime data: what context gets sent to the model, privacy constraints, data retention - Evaluation data: the held-out test set you'll use to measure performance Half the AI projects I've seen stall do so because of data problems that nobody anticipated. A few sentences in the spec about data requirements prevents that. ### Evaluation Criteria How will you decide if this feature is ready to ship? Define the evaluation method, not just the metric. - Who evaluates: domain experts, end users, automated tests, or a combination? - How many samples: 50 documents, 200 queries, 1000 interactions? - What's the process: blind evaluation, A/B test, side-by-side comparison with the existing solution? ## The "Is This Good Enough?" Problem Without these sections in your spec, every review meeting becomes a philosophical debate. Someone thinks the AI is "pretty good." Someone else thinks it "needs more work." Nobody has a framework for deciding. A spec with clear benchmarks, error tolerances, and evaluation criteria turns that debate into a measurement exercise. Either the system meets the bar or it doesn't. If it doesn't, you know specifically where it falls short. That's the difference between a team that ships AI features confidently and a team that iterates in circles. It's not better models. It's better specs. ### Why Solo Founders Need Requirements More Than Teams Do https://projan.ai/blog/why-solo-founders-need-requirements-more/ Published: 2026-02-06 ## "I'm the Only One, Why Would I Write a Spec?" I hear this from solo founders constantly. Writing requirements feels like corporate overhead when you're a team of one. You know what you're building. You're the PM, the designer, the developer, and the QA team. Who are you writing the document for? Yourself. You're writing it for yourself. Here's the counterintuitive truth: solo founders need requirements MORE than teams, not less. When you're on a team, someone catches your blind spots. An engineer asks "what happens when the user has no payment method?" A designer says "this flow doesn't work on mobile." A PM pushes back on scope. When you're alone, nobody asks those questions. Your blind spots ship to production. And you don't find out until users do. ## The Cost of Skipping Planning Solo I've built several products solo. The ones where I skipped planning followed the same pattern: 1. Start building with excitement 2. Realize halfway through that the data model is wrong 3. Rebuild the data model, which breaks three other things 4. Discover an edge case that changes the core flow 5. Spend a weekend refactoring instead of shipping Every. Single. Time. The ones where I spent 30 minutes writing a mini spec before coding? They shipped faster. Not because the spec was perfect, but because the act of writing it forced me to think through the problems I'd otherwise discover mid-build. Thirty minutes of planning saves weeks of rebuilding. That ratio only gets better when you're solo, because there's no team to help you recover from bad decisions. ## What a Solo Founder's Mini Spec Looks Like You don't need a 10-page PRD. You need five sections, each a few sentences long. ### 1. The Problem Who has this problem, and why does it hurt? Write it in plain language. "Freelance designers waste 2 to 3 hours per week manually creating invoices from their project tracking tool." If you can't articulate the problem clearly, you're not ready to build. ### 2. The Users Who specifically will use this? Not "everyone." Be precise. "Freelance designers who use Notion for project tracking and send 5 to 20 invoices per month." The more specific you are, the better your decisions will be. ### 3. The Core Flow Walk through the main user journey in 5 to 8 steps. "User connects their Notion workspace. Selects a project. Reviews auto-generated line items. Adjusts if needed. Sends invoice via email." That's it. This is your MVP scope. ### 4. What "Done" Looks Like Define the minimum bar for launch. "Done means: a user can connect Notion, generate an invoice, and send it. No recurring invoices yet. No payment processing. Just generate and send." ### 5. What's Out of Scope This is the hardest section for solo founders. Write down the features you're NOT building yet. "Not building: payment processing, multi-currency support, team accounts, mobile app, API access." Put it in writing. Refer to it when you get the urge to add "just one more thing." Out of scope is your shield against your own ambition. ## The 30-Minute Investment The whole exercise takes about 30 minutes. You can write it in a text file, a Notion doc, or even on paper. The format doesn't matter. The thinking does. What you'll notice: you'll catch problems before they become code. You'll make scope decisions when they're free instead of when they're expensive. And you'll have something to come back to next Saturday when you've forgotten what you were building and why. Solo doesn't mean unplanned. It means you're the only person who can do the planning. So do it. ### Product Managers Are Not Typists: The Documentation Burden Is Real https://projan.ai/blog/product-managers-are-not-typists/ Published: 2026-02-01 ## The Job Description vs. The Actual Job Ask a product manager what their job is and you'll hear things like: understanding users, identifying opportunities, making trade-offs, aligning stakeholders, defining strategy. Important, high-judgment work. Now ask that same PM how they spent their Tuesday. The answer is usually some version of: "I was in Confluence all day writing up the spec for the notifications feature." There's a gap between what PMs are supposed to do and what they actually spend their hours on. A big chunk of that gap is documentation. ## The Documentation Tax I've talked to dozens of PMs about their workflows. The pattern is consistent. They spend 4 to 6 hours on a single PRD. Not because the thinking takes that long, but because the formatting, the structure, the templates, the cross-linking, the diagrams, the edge case tables, and the stakeholder-specific versions eat up enormous time. A PM might make the core product decision in 30 minutes: "We need to add team-level permissions because three enterprise prospects asked for it, and here's how it should work." That's the valuable part. The insight. The judgment call. Then they spend the rest of the day turning that decision into a 12-page document with screenshots, user flow diagrams, a data model section, and an FAQ that nobody will read. Something's off. ## The Real Value of a PM The best PMs I've worked with share a trait: they're fast at capturing decisions and slow at making them. They take their time talking to users, studying data, debating trade-offs. But when it's time to write the spec, they don't produce a novel. They produce a clear, concise artifact that communicates the decision and moves the team forward. The worst PM workflows I've seen treat the PRD as the deliverable. As if the document IS the work. It's not. The document is a byproduct of the work. The work is the thinking. ## PRDs Are Communication Tools, Not Literature Here's a test: if your PRD takes longer to write than the feature takes to build, something is wrong. A PRD needs to answer a small number of questions clearly: - What problem are we solving, and for whom? - What does the solution look like at a high level? - What are the acceptance criteria? - What's out of scope? - What trade-offs did we make, and why? That's it. If an engineer can read your spec in 10 minutes and start building with confidence, the PRD did its job. The length is irrelevant. ## Stop Optimizing the Wrong Thing Teams invest in PRD templates, documentation tools, spec review processes. All of that optimizes the document. Very little of it optimizes the thinking. What if you could skip the formatting entirely? What if you could have a conversation about the feature, and the spec wrote itself? That's the idea behind tools like [Projan](https://projan.ai), which turns a conversation into a structured spec with user stories, acceptance criteria, and technical notes. You talk through what you're building. It handles the structure. You're back to doing PM work in minutes instead of hours. [Try it free](https://app.projan.ai/create-account) and see how fast a spec can come together when you stop typing and start thinking. ## Reclaim Your Time If you're a PM reading this, do an honest audit of your week. How many hours went into formatting documents versus talking to users, analyzing data, or making product decisions? The fix isn't to stop writing specs. Specs are valuable. The fix is to stop treating them as the primary output of your job. Make them fast. Make them clear. Move on to the work that actually requires your judgment. Your team doesn't need a beautiful document. They need a clear decision, communicated quickly. Everything else is overhead. ### The Requirements Template That Reduced Our Client Revisions by 60% https://projan.ai/blog/requirements-template-reduced-client-revisions/ Published: 2026-01-27 ## We Were Drowning in Revisions A few years ago, the agency I worked with had a revision problem. Every project went through three, four, sometimes five rounds of client feedback before anything shipped. Timelines ballooned. Margins shrank. The team was frustrated because they kept rebuilding things that "weren't what the client wanted." The problem wasn't our design or development quality. It was that we started building before the client and the team had the same picture in their heads. We rewrote our requirements template from scratch. Within two quarters, average revision rounds dropped from 4.2 to 1.7. Here's the template and why each section matters. ## The Template ### Section 1: Project Goals (What Success Looks Like) Most project briefs start with "build a website" or "create an app." That's a task description, not a goal. We start with outcomes. **What we write:** - "Increase online appointment bookings by 40% within 3 months of launch" - "Reduce customer support calls about order status by half" **Why it works:** When the client signs off on goals, every design and development decision has a filter. "Does this help us hit the goal?" If not, it's a nice-to-have, not a must-have. ### Section 2: User Stories (Who Does What) We list every user type and what they need to accomplish. Not technical specs. Simple sentences. **Format:** As a [user type], I need to [action] so that [outcome]. **Examples:** - As a new patient, I need to book an appointment online so that I don't have to call during office hours. - As a clinic admin, I need to see all bookings for the week so that I can plan staffing. We typically write 10 to 20 of these for a mid-sized project. The client reviews them and often says "you forgot about [user type]." That's exactly the point. Better to discover that now than during QA. ### Section 3: Acceptance Criteria (How We Test It) For each major feature, we write testable statements. **Example for online booking:** - User can select a date from a calendar showing available slots - User receives a confirmation email within 60 seconds of booking - Admin can cancel a booking, which sends the patient a notification - System prevents double-booking the same time slot This section kills ambiguity. "Make the booking experience smooth" means nothing. "User can complete a booking in under 3 clicks" means something specific. ### Section 4: Constraints (Timeline, Budget, Tech) We list every constraint explicitly: - **Timeline:** MVP launch by March 15, full feature set by May 1 - **Budget:** Fixed at £X, with £Y contingency for change requests - **Technical:** Must integrate with existing Salesforce instance; hosting on AWS required by IT policy - **Regulatory:** GDPR compliance required; accessibility to WCAG 2.1 AA Constraints that aren't written down get forgotten. Then they surface mid-project as surprises. ### Section 5: Out of Scope (What We're NOT Building) This is the section that changed everything. We explicitly list features and work that are excluded from this engagement. **Examples:** - Mobile app (web responsive only for v1) - Migration of historical data from the legacy system - Ongoing SEO or content creation post-launch - Multi-language support (English only for initial release) Before we added this section, clients assumed things were included that we'd never discussed. "I thought the redesign included migrating all our old blog posts?" That single misunderstanding could add two weeks of unplanned work. The out-of-scope section reduced revision rounds by roughly a third on its own. Not because it prevented feature requests, but because it set expectations before anyone started building. ## How to Use This You don't need to copy this template exactly. The principle is what matters: write down what you're building, why, how you'll test it, what limits exist, and what's excluded. Get the client to sign off on all five sections before design starts. The 2 to 3 hours spent writing this document saves 20 to 30 hours of revisions later. Every time. We've run this template across 40+ client projects now, and the pattern holds. Revisions aren't a design problem or a client problem. They're an alignment problem. Fix alignment upfront, and the rest of the project runs smoother than you'd expect. ### The 10-Minute Planning Session That Keeps My Side Projects Alive https://projan.ai/blog/10-minute-planning-session-side-project/ Published: 2026-01-22 ## Side Projects Don't Die From Lack of Time They die from lack of direction. You sit down on a Saturday morning with two free hours, open your editor, stare at the codebase, and think: "Where was I? What was I doing? What should I work on?" Twenty minutes of context-switching later, you pick something semi-random, make partial progress, and close your laptop feeling like you wasted the session. I've killed at least a dozen side projects this way. Not because I ran out of motivation, but because every session started with friction. The fix is embarrassingly simple: a 10-minute planning ritual before you touch any code. ## The Five Steps ### Step 1: Read Your Last Session Notes (2 minutes) Before your previous session ended, you wrote a few sentences about where you left off. Read them now. This is the single biggest time saver. Without it, you'll spend 15 minutes re-discovering what past-you already knew. If you didn't leave notes last time, spend these 2 minutes scanning your recent git commits or open files to rebuild context. ### Step 2: Pick the One Thing You'll Ship Today (1 minute) Not three things. One. The temptation with side projects is to jump between features because everything feels equally important. Resist that. Pick the smallest thing that moves the project forward in a visible way. "Get the login page working" beats "refactor the auth module" every time. ### Step 3: Write Down What "Done" Looks Like (2 minutes) This is the step most people skip, and it's the most important one. Write one to three sentences describing what the finished state looks like. "Done means: a user can type their email, click submit, and see a confirmation message. No styling needed yet." Without this, you'll gold-plate. You'll rabbit-hole into edge cases. You'll end the session with something 80% complete instead of something 100% shipped. ### Step 4: List Your Blockers (2 minutes) Write down anything that might stop you. "I need to figure out how to send emails from Next.js." "I'm not sure how the database schema should work for this." If a blocker looks like it'll take more than 20 minutes to resolve, that's a signal: either pick a different task for today, or timebox the blocker research. ### Step 5: Set a Timer and Go (3 minutes) Set a timer for your available coding time. Not because you need pressure, but because the timer makes the session feel finite and real. You're not "working on the side project." You're doing a specific thing in a specific timeframe. ## Why This Works The entire ritual takes 10 minutes. But it converts a vague "I should work on my project" session into a focused sprint with a clear goal. I've shipped more in 2 hours a week with this system than I used to ship in 8 hours of unfocused weekend coding. The secret isn't working more. It's removing the decision-making overhead that eats your limited time. One more thing: at the end of each session, spend 2 minutes writing notes for next time. What you finished, where you stopped, what's next. Your future self will thank you. ### How I Turned My Changelog Into a Growth Channel https://projan.ai/blog/how-i-turned-my-changelog-into-a-growth-channel/ Published: 2026-01-17 ## Nobody Reads Changelogs (Until You Write Them Differently) For the first few months of building my product, my changelog looked like every other changelog on the internet. "Fixed bug with login flow." "Improved dashboard performance." "Added CSV export." Useful for exactly nobody except maybe myself, two weeks later, trying to remember what I shipped. Then I tried something different. I started writing each entry as a tiny story: what problem a user had, what I built to fix it, and why it matters. Within a few weeks, the changelog page became one of the most visited pages on my site. ## What a Good Changelog Entry Looks Like Here's the difference. **Before:** > Added email notifications for team invites. **After:** > **Team invites now send email notifications.** Three users reported that they'd invited teammates but nobody showed up. Turns out the invite was buried in a dropdown menu that new users never found. Now, when you invite someone, they get an email with a direct link. Acceptance rate went from 34% to 78% in the first week. The second version does three things. It tells a story. It shows you're listening to users. And it gives a concrete result. People share entries like that. ## The SEO Flywheel Nobody Talks About Each changelog entry is a piece of indexed content. When you write entries that mention specific problems ("team invite acceptance rate," "CSV export for billing data"), you start ranking for long-tail searches that your marketing pages never would. One of my entries about improving search filtering started ranking for "how to filter search results by date range." It wasn't even a competitive keyword. But it brought in 30 to 40 visitors a month, and a handful of those converted because they were clearly looking for the exact feature I'd just built. Multiply that across 50 or 60 entries over a year and you've got a steady stream of organic traffic from people who are already experiencing the problem your product solves. ## The Hidden Benefit: It Forces You to Plan Here's what surprised me most. Writing the changelog well forced me to think about what I was shipping and why. If I couldn't write a compelling entry about a feature, that was a signal. Maybe the feature wasn't solving a real problem. Maybe I was building something because it was fun to build, not because anyone needed it. The changelog became a planning tool in disguise. Each week I'd ask myself: "What will I write about on Friday?" If the answer was boring, I'd reprioritize. ## How to Start You don't need a fancy system. A markdown file works. A section on your landing page works. The format I settled on: - **What changed** (one sentence) - **Why it matters** (the user problem it solves) - **The result** (metric, quote, or observation) - **What's next** (optional teaser for upcoming work) Keep entries between 100 and 200 words. Post weekly or biweekly. Link to them from your social channels. That's it. The changelog is already something you should be maintaining. The only change is writing it for your users instead of for yourself. The growth part happens on its own. ### We Wasted 3 Months Building the Wrong Thing https://projan.ai/blog/we-wasted-3-months-building-wrong-thing/ Published: 2026-01-13 ## The project that looked fine until it wasn't I want to tell you about a team that lost three months of work. Not because they were lazy or incompetent. Because they were moving fast, communicating constantly, and still building the wrong thing. The team was five people: two founders, two developers, and a designer. They were building a B2B onboarding tool. The idea was solid, the market was real, and they had early interest from a handful of potential customers. They kicked things off with a few whiteboard sessions, some Slack threads, and a quick verbal walkthrough of what they were building. Then the developers started coding. For three months, they shipped features, fixed bugs, held standups, and made steady progress. When they showed the product to their early customers, the response was lukewarm at best. ## Where the misalignment started Nobody on the team realized they had different pictures in their heads. The CEO had pitched the product to prospects as a self-serve onboarding builder. Think: drag-and-drop, no-code, customers set it up themselves. The CTO had understood it as an onboarding workflow engine. Powerful, flexible, but requiring technical setup. The developers had been building based on what they understood from Slack conversations, which was a mix of both. Some features were self-serve. Others assumed a technical user. The UI was inconsistent because nobody was wrong, exactly. They were all building what they thought was agreed upon. The designer had created flows based on early wireframes that were never formally approved. They looked great, but they didn't match the CTO's mental model of how the system worked. Three months of parallel work, all slightly off from each other. ## The real cost Half the frontend had to be rebuilt. Two major backend features were designed for a workflow that the final product didn't use. The designer's work on three key screens was scrapped entirely. But the time wasn't even the worst part. The worst part was the morale hit. Five people who'd been working hard, making sacrifices, and feeling good about progress suddenly realized that a big chunk of their work didn't matter. That's a gut punch. The CTO told me afterward: "We were talking every single day. I genuinely thought we were aligned." ## The communication illusion This is the part that catches people off guard. The team wasn't failing to communicate. They were communicating constantly. Daily standups. Slack channels. Weekly syncs. By any measure, they were a well-coordinated team. But there's a fundamental difference between talking about what you're building and writing down what you're building. Conversation is great for brainstorming, debating, and making quick decisions. It's terrible for creating a shared, persistent, unambiguous record of what you agreed on. Here's what happens in practice. Two people have a Slack conversation about a feature. They think they agree. But one person interpreted "simple onboarding flow" as three steps, and the other interpreted it as seven steps with conditional logic. Neither is wrong. They just never specified. Multiply that by 50 conversations over three months and you get a product where every piece works individually but nothing fits together. ## What they should have done After the painful reset, the team implemented a simple rule: nothing gets built until it's written down in a shared doc. Not a 20-page spec. A one-pager per feature. It covered: - **What it does:** in plain language, one paragraph - **Who it's for:** which user type, in what situation - **How it works:** step-by-step flow, covering the main path and the most likely alternate paths - **What success looks like:** how they'd know it was working - **What it doesn't do:** explicit scope boundaries Each doc took 30 to 60 minutes to write. Before any code started, the whole team reviewed it. Not a rubber-stamp review. A real discussion where the developers would ask "what happens when X?" and the designer would say "this flow doesn't work on mobile." The conversations they used to have mid-sprint now happened before the sprint. And the disagreements that used to show up at demo time showed up during the review, when they were cheap to fix. ## The math that convinced them The team estimated that writing a spec for each feature added about 2 hours of work per week across the team. That's roughly one person-day per month of "overhead." The rebuild cost them approximately 6 person-weeks of thrown-away work, plus 2 weeks to replant and rebuild. So the question became: would 1 day per month of writing have prevented 8 weeks of waste? The answer was obviously yes. Writing things down isn't slow. It feels slow compared to jumping into code. But jumping into code without alignment is the slowest thing you can do, because you don't find out you're off track until the end. ## How to avoid this If you're a founder or team lead, here are three practices that prevent the three-month disaster: **Write it before you build it.** Even a short doc forces clarity. The act of writing down "the user clicks X and sees Y" exposes assumptions that conversation hides. **Review it with the builders.** Don't just share the doc. Sit down with the people who will implement it and ask them to walk you through their understanding. Where their understanding differs from yours, you've found a misalignment that would have cost you weeks later. **Keep it alive.** The spec isn't a contract. It changes as you learn. But changes should be deliberate and documented, not whispered in Slack. ## Where Projan fits This is actually the exact problem that led me to build [Projan](https://projan.ai). Too many teams communicate well but document poorly. Projan captures requirements through conversation, the way teams naturally discuss things, and turns that into structured specs with clear acceptance criteria. You talk about what you're building. Projan writes it down in a format the whole team can reference. It's designed for teams that are moving fast and don't have time for heavyweight documentation, but can't afford to waste months building the wrong thing. If your team is relying on Slack threads and verbal agreements for your product requirements, [try Projan before your next feature](https://app.projan.ai/create-account). A few minutes of structured conversation now saves weeks of rework later. ## The three-month test Ask yourself this: if your team kept building for three months with no written spec, would everyone ship the same product? If you're not confident the answer is yes, write it down. Today. Before the next line of code. It's the cheapest insurance in software. ### From University Project to Y Combinator Application https://projan.ai/blog/from-university-project-to-yc-application/ Published: 2026-01-08 ## The capstone project that became something bigger Four students built a scheduling tool for their final-year capstone project. It was technically solid. Clean architecture, good test coverage, a working demo. Their professor gave them top marks. Then one of them said: "What if we applied to YC with this?" They submitted an application. It wasn't great. They took the feedback, rewrote it, and resubmitted the following batch. The second time, they got an interview. Here's what changed. ## What academic documentation looks like Their original project had thorough documentation, the kind universities require: - A literature review covering existing scheduling tools - UML diagrams and entity-relationship models - A methodology section describing their agile process - A testing chapter with unit test results and coverage reports - A conclusion discussing "future work" All technically correct. All completely useless for a YC application. The problem isn't that academic documentation is bad. It serves its purpose. But that purpose is to demonstrate learning methodology, not to convince someone that a real problem exists and your team can solve it. ## What startup documentation needs to be YC's application is deceptively simple. A few short questions. But the answers need to convey things that academic papers never touch. ### A problem that real people have Their academic paper described the scheduling problem in abstract terms. "Coordination of multi-party scheduling presents challenges in distributed environments." Their startup version: "Small business owners waste 4 to 6 hours per week going back and forth on scheduling. We interviewed 30 of them. 27 said they'd pay for something that fixed this." The difference is evidence from real people, not citations from research papers. YC wants to see that you've talked to potential users and that the problem is real, not theoretical. ### A focused scope The capstone project had a broad scope because the rubric rewarded ambition. They'd built scheduling, calendar sync, automated reminders, team management, and a reporting dashboard. For the YC application, they narrowed it down to one thing: appointment scheduling for service businesses (salons, clinics, consultants). One user type, one workflow, one clear value proposition. Startups that try to be everything are startups that build nothing well. Narrowing the focus was the hardest part for the team, because it felt like throwing away work. But it made the application ten times stronger. ### Evidence of user need Academic projects can survive on hypothetical users. Startups can't. Before resubmitting, the team spent three weeks doing something their coursework never required: talking to potential customers. They visited 15 small businesses in their city. They watched how those businesses handled scheduling. They asked what tools they'd tried and why they stopped using them. They compiled this into a one-page user research summary. Not a formal study. Just: who they talked to, what they heard, and what it meant for the product. This single page carried more weight in the application than their entire technical architecture. ### Measurable milestones The academic project timeline was structured around deliverables: "Week 4: complete database design. Week 8: implement core features. Week 12: write dissertation." The startup roadmap needed to be structured around outcomes: "Month 1: 20 paying customers. Month 3: $1,000 MRR. Month 6: expand to second vertical." This shift from deliverables to outcomes is one of the biggest mental adjustments for student founders. In school, you're graded on what you produce. In startups, you're evaluated on the impact of what you produce. ## The four things they rewrote If you're a student team thinking about turning a project into a real startup, here's what to focus on: **1. Problem statement.** Replace academic framing with real user pain. Use specific numbers and quotes from actual conversations. "27 out of 30 small business owners said X" is more compelling than any literature review. **2. Scope.** Cut your feature list by 70%. Pick the one thing that matters most to one type of user. You can expand later. Right now, focus wins. **3. Traction or evidence.** If you have users, show numbers. If you don't, show research. Interviews, surveys, waitlist signups. Anything that proves you've engaged with real people about a real problem. **4. Roadmap.** Replace deliverable timelines with outcome milestones. What will be true about your business in 3, 6, and 12 months? Make the milestones specific enough that you could look back and clearly say "we hit it" or "we didn't." ## What stays the same Not everything from the academic project was wasted. The technical skills transfer directly. Understanding how to architect a system, write tests, and manage a codebase is exactly what you need to build a startup product. The team dynamics matter too. If you've already worked together under pressure (deadlines, difficult problems, disagreements about approach), you've tested the founding team relationship in a way that most first-time founders haven't. ## The real difference Academic documentation proves you can build something. Startup documentation proves you should build something, that real people want it, and that you have a plan to reach them. If you're sitting on a university project that solves a genuine problem, the technical work is done. The next step isn't more code. It's talking to people who have the problem, writing down what you learn, and making the case that this is worth building for real. That's a very different document than a dissertation. But the skills you used to write the dissertation will help you write it well. ### Edge Cases Are Not Edge Cases. They Are the Product. https://projan.ai/blog/edge-cases-are-not-edge-cases/ Published: 2026-01-03 ## The thing your spec didn't cover A developer raises their hand during sprint review. "What should happen when the user has no data?" Silence. Nobody thought about that. It's called an "edge case," and that label is part of the problem. Calling it an edge case implies it's rare, unlikely, someone else's problem. But the empty state isn't rare. Every single new user hits it. It's literally the first thing they see. This isn't an edge case. It's the product. And it should have been in the spec. ## Why "edge cases" keep showing up in development When PMs write requirements, they tend to describe the happy path. The user has data. The connection is fast. The input is valid. Everything works as expected. That's the easiest scenario to think about and the one that matches the demo in your head. But your users don't live on the happy path. They live in a messy world where they mistype emails, lose WiFi on the bus, use your product in ways you never imagined, and hit back when they shouldn't. Every "edge case" discovered during development is a planning failure. Not because PMs should predict everything. They can't. But the common ones? Those should be in the spec before the first line of code. ## 5 "edge cases" that should be in every spec ### 1. The empty state What does the user see when they have no data? No projects, no messages, no results. This isn't an edge case. It's the new user experience. A good spec defines: what message does the user see? Is there a call to action? Does the UI change once they add their first item? ### 2. The slow connection Your product works great on your office WiFi. What about on a 3G connection in a train tunnel? What about when the API takes 8 seconds instead of 200 milliseconds? Specify: what happens during loading? Is there a timeout? What does the user see if the request fails? Can they retry? ### 3. The invalid input Users will paste emoji into number fields. They'll submit forms with spaces where you expect URLs. They'll upload a 200MB file when you expected 2MB. Specify the validation rules. What's accepted, what's rejected, and what error message appears. Don't leave it to the developer to make up error copy on the fly. ### 4. The concurrent action Two people edit the same document. A user clicks "submit" twice. Someone deletes an item while another person is viewing it. These aren't obscure scenarios. In any collaborative or multi-device product, they're daily occurrences. Define the behaviour: last write wins? Conflict resolution? Optimistic locking? ### 5. The permission boundary What happens when a user tries to access something they don't have permission to view? Do they see a 404 (pretend it doesn't exist) or a 403 (you can't access this)? What about when their permissions change while they're in the middle of a session? These decisions affect security and user experience. They deserve deliberate choices, not whatever the developer implements at 5pm on a Friday. ## How to think about edge cases during requirements You don't need to anticipate every possible scenario. That's not realistic. But you can build a habit of asking three questions for every feature: **What if there's nothing?** Empty states, zero results, no data, new user with no history. **What if something goes wrong?** Network failure, server error, validation failure, timeout. **What if the user does something unexpected?** Double submission, back button, browser refresh, unusual input, concurrent access. These three questions catch 80% of the "edge cases" that show up during development. They take 10 minutes to think through per feature and save hours of back-and-forth later. ## The cost of not thinking about it When edge cases aren't in the spec, one of two things happens. The developer makes a decision. Sometimes it's a good one. Sometimes they hard-code an error message that says "Something went wrong" and move on, because they have a sprint to finish and the PM didn't specify what should happen. Or the developer raises it, the PM thinks about it, a conversation happens, maybe a designer gets involved, and a decision gets made mid-sprint. That's rework. It's unplanned work that disrupts the flow and extends the timeline. Neither outcome is good. Both are avoidable. ## Reframing the language I'd encourage every product team to stop using the phrase "edge case." Call them "alternate paths" or "failure states" or just "requirements we haven't written yet." The language matters because it changes how seriously people take them. An "edge case" sounds optional. A "requirement we haven't written yet" sounds like a gap that needs filling. Your product isn't just the happy path. It's every path. And the paths you don't plan for are the ones that frustrate your users the most. Write them down. Before the sprint starts. ### The Spec That Saved Our Series A https://projan.ai/blog/the-spec-that-saved-our-series-a/ Published: 2025-12-27 ## "Come back when you have a plan" The meeting was going well. Two cofounders, a lead investor, and a partner at a mid-tier VC in London. The product demo was solid. Metrics were good: 400 paying customers, 15% month-over-month growth, low churn. The team was strong. Then the investor asked the question: "Walk me through your product roadmap for the next 12 months." The CEO started talking. He mentioned a few features. Enterprise tier. API. Some kind of marketplace. The CTO added context, but contradicted the CEO on timing. They went back and forth for a minute, clearly thinking out loud rather than presenting a plan. The investor nodded politely and said: "Sounds like you have a lot of ideas. Why don't you come back when you can show me the plan in writing?" The meeting ended. The deal didn't. ## What they had wrong This team wasn't incompetent. They were busy. They'd spent the last year building a product, acquiring customers, and keeping the servers running. Documentation felt like a luxury they'd get to "someday." The problem wasn't that they didn't have a strategy. They did, roughly. The CEO thought about it constantly. The CTO had a mental model of the technical evolution. But none of it was written down, organized, or stress-tested against reality. In a pitch meeting, that gap is fatal. Investors aren't just evaluating your product. They're evaluating your ability to think clearly and execute deliberately. If you can't articulate your plan, they'll assume you don't have one. ## The week that changed everything After the meeting, the cofounders blocked out a full week. No customer calls, no feature work. Just planning and writing. Here's what they produced. ### The product roadmap Not a feature list. A structured document with three time horizons: **Q1 (immediate):** Ship self-serve onboarding and usage-based billing. Goal: reduce sales-assisted signups from 80% to 40%. **Q2 to Q3 (medium-term):** Launch API and integration marketplace. Goal: increase average contract value by 30% through platform stickiness. **Q4 (end of year):** Enterprise tier with SSO, audit logs, and dedicated support. Goal: land 10 enterprise accounts at 5x the standard price. Each initiative had a clear rationale tied to a business outcome. Not "we think an API would be cool" but "our top 20 accounts have asked for API access, and 3 have said it's a blocker for expanding their usage." ### Dependencies and risks They mapped out what each initiative required. The API needed a dedicated backend developer they hadn't hired yet. Enterprise features required SOC 2 compliance, which would take 3 to 4 months. They were honest about what they didn't know: whether the marketplace would gain traction was an open question. This section impressed the investor more than anything else. It showed they understood the difference between a plan and a wish list. ### Success metrics For each quarter, they defined how they'd measure progress. Not vanity metrics. Specific, falsifiable targets. - Q1: Self-serve signups reach 60% of total. Activation rate above 40%. - Q2 to Q3: 15 active API integrations. ACV increases to £X. - Q4: 5 enterprise contracts signed. Net revenue retention above 120%. These numbers gave the investor something to check in on. They also gave the cofounders something to hold themselves accountable to. ## The second meeting They went back to the same investor two weeks later with the document. Printed copies, because some investors still prefer paper. The conversation was completely different. Instead of "tell me about your roadmap," the investor said "I see you're planning to launch the API in Q2. What's your go-to-market for the marketplace?" They'd moved from defending the existence of a plan to discussing the details of the plan. That's a fundamentally different conversation. It's the one investors want to have. They closed the round six weeks later. The same investor led it. ## Why this matters beyond fundraising The cofounders told me something interesting afterward. Writing the spec didn't just help with the raise. It changed how they made decisions day-to-day. Before, every new idea got debated in isolation. "Should we build X?" "I don't know, maybe?" Now they had a framework: does this move us toward Q1 targets? If not, it goes on the backlog. The engineering team noticed too. For the first time, they understood why they were building certain things and could push back when requests didn't align with the roadmap. One document changed the operating rhythm of the entire company. ## The lesson Documentation isn't busywork. When you're raising money, it's proof that you know what you're doing. When you're not raising money, it's how you make better decisions. You don't need a 50-page strategy doc. You need a clear, structured roadmap that answers: what are we building, why, in what order, and how will we know it's working? If that document doesn't exist for your company, write it this week. You'll be surprised how much clarity comes from the act of writing it down. And if an investor ever tells you to "come back with a plan," know that it's not a rejection. It's an invitation. Take it seriously, put in the work, and go back with something worth reading. ### AI Projects Need Better Requirements, Not Better Models https://projan.ai/blog/ai-projects-need-better-requirements-not-models/ Published: 2025-12-20 ## The model is fine. The requirements aren't. Every week I see the same pattern. A team ships an AI feature, and it disappoints. Not because the model is bad, but because nobody agreed on what "good" meant before they started building. The team spent three months prompt-engineering and fine-tuning. They benchmarked against GPT-4, Claude, and Llama. They optimized latency. They tweaked temperature settings. The model performed well on their test set. Then it went to real users, and the feedback was: "This isn't useful." The model did exactly what it was asked to do. The problem is that nobody clearly defined what it *should* do in the context of the actual product. ## AI features still need requirements There's a strange belief in some teams that AI features are somehow exempt from normal product planning. "We'll just throw the data at the model and see what it does." That's experimentation, not product development. AI features need the same things every other feature needs: - **What's the input?** Not "user data." Specifically what data, in what format, from where? - **What's the expected output?** A summary? A classification? A recommendation? How long, how structured, how confident? - **What does "good enough" mean?** 80% accuracy? 95%? Does it depend on the use case? - **What's the error tolerance?** What happens when the model is wrong? Is a wrong answer worse than no answer? - **What's the fallback?** When the AI can't produce a useful result, what does the user see? Most teams I talk to can answer maybe one or two of these clearly. The rest is vibes. ## Real example: AI-powered summarization A team built an AI feature that summarized customer support tickets for managers. The model worked great technically. But the requirements were vague: "Summarize the ticket." After launch, the complaints rolled in: - Some managers wanted a one-sentence summary. Others wanted three paragraphs. - The summary didn't include the customer's sentiment, which managers considered essential. - When the model couldn't determine the issue (ambiguous tickets), it still produced a confident-sounding summary that was misleading. - Nobody had defined what should happen for tickets in languages the model wasn't trained on. Every one of these problems could have been caught with proper requirements. "Summarize the ticket" is not a requirement. It's a direction. Better requirements would look like: - Output: 2 to 3 sentence summary including the core issue, customer sentiment (positive/negative/neutral), and urgency level - If confidence is below 70%, display: "Unable to summarize. Please review the full ticket." - Supported languages: English, Spanish, French. For other languages, show the original text without summary. - Maximum response time: 3 seconds per ticket ## The "good enough" conversation This is the hardest part for teams working on AI features, and it's the most important. Traditional features are binary. The button either works or it doesn't. AI features exist on a spectrum. The model will sometimes be brilliant and sometimes be wrong, and you need to decide where on that spectrum is acceptable. Have this conversation early: - For a medical application, 95% accuracy might be dangerously low. - For a social media content suggestion, 70% accuracy might be perfectly fine. - For a code review tool, a false positive (flagging good code) might be acceptable, but a false negative (missing a bug) might not be. If you don't define these thresholds before building, the team will optimize for the wrong thing. Usually they optimize for general accuracy when what matters is accuracy on specific, high-stakes cases. ## Writing requirements for AI: a template For every AI feature, document these six things: 1. **Input specification:** What data goes in, including format, size limits, and edge cases 2. **Output specification:** What comes out, including format, length, and structure 3. **Quality threshold:** What accuracy or quality level is acceptable, measured how 4. **Error handling:** What happens when the model fails, is uncertain, or produces harmful output 5. **Fallback behaviour:** What the user sees when AI can't help 6. **Evaluation method:** How you'll measure whether the feature is working after launch This isn't bureaucracy. It's the difference between an AI feature that ships and one that ships and actually helps people. ## The team alignment problem Here's what often happens without clear requirements: the ML engineer optimizes for model performance metrics. The product manager evaluates based on user satisfaction. The designer assesses the output formatting. Each person has a different definition of success, and nobody realizes it until late in the process. Written requirements align everyone. The ML engineer knows what "good enough" means numerically. The designer knows the output constraints. The PM knows what to test with users. One document, shared understanding. ## Better requirements first, better models second If your AI feature isn't working, resist the urge to immediately swap models or add more training data. First, check whether your requirements are clear enough to build against. Most of the time, they aren't. If you're finding it hard to articulate requirements for AI features (and it is genuinely hard), tools like [Projan](https://projan.ai) can help. It's built for exactly this kind of structured requirements gathering, walking teams through the right questions in a conversation and producing clear specs as output. [Give it a try](https://app.projan.ai/create-account) if your team is building AI features and struggling to align on what "done" looks like. The models are getting better every month. Your requirements won't improve unless you put in the work to write them. ### The Documentation Checklist Every Accelerator Team Needs 8 Weeks Before Demo Day https://projan.ai/blog/accelerator-documentation-checklist/ Published: 2025-12-16 ## Your demo is in 8 weeks. What's written down? You've been heads-down building for months. The product works. The pitch is coming together. Mentors are giving feedback. Everything feels like it's on track. Then an investor asks for your product roadmap, and you realize it only exists as a collection of sticky notes and half-finished Notion pages. This is where most accelerator teams stumble. Not because they don't have good ideas, but because those ideas live in people's heads instead of in documents that others can read, evaluate, and give meaningful feedback on. Here's what you need to have written down, well before demo day. ## 1. Product vision document (1 page) This is the "what and why" in the simplest possible terms. One page. Not ten. Cover these four things: - **The problem** you're solving and who has it - **Your solution** and what makes your approach different - **Where you are now** (what's built, what traction you have) - **Where you're going** in the next 12 months Investors and mentors should be able to read this in 3 minutes and understand your startup. If they can't, the pitch won't land either. Resist the urge to include everything. This document is a filter. It should make someone want to ask questions, not answer all of them upfront. ## 2. Technical architecture overview You don't need a full system design document. You need a clear, one-page diagram and explanation of how your product works. What to include: - High-level architecture (frontend, backend, database, third-party services) - Key technology choices and why you made them - Current scale (users, data volume, traffic) - Known technical debt or risks - What changes when you need to scale 10x This matters because technical investors will ask about it, and "we'll figure it out when we get there" isn't a reassuring answer when they're writing a cheque. ## 3. User research summary Compile what you've learned from users into a single document. This doesn't need to be academic. It needs to be honest. Include: - How many users/customers you've talked to (be specific) - The top 3 problems they described in their own words - What surprised you (things you didn't expect to hear) - How user feedback has changed your product decisions - Direct quotes that capture the pain points well This document proves you're building based on evidence, not assumptions. That matters enormously to investors who've seen too many startups build in a vacuum. ## 4. Product roadmap with milestones This is where most teams are weakest. You might have a backlog or a list of features you want to build. That's not a roadmap. A roadmap should show: - **Now (next 4 weeks):** What you're shipping before or at demo day - **Next (months 2 to 3):** Your immediate priorities post-funding - **Later (months 4 to 12):** Directional bets and bigger initiatives For each phase, include specific milestones with measurable outcomes. Not "improve onboarding" but "reduce time-to-first-value from 15 minutes to under 5 minutes." Dependencies matter too. If feature B requires hiring a data engineer, say so. Investors want to see that you understand the sequence and the bottlenecks. ## 5. Financial model assumptions You don't need a sophisticated financial model at the accelerator stage. You need to show that you've thought about the numbers. Document your assumptions: - How you plan to acquire customers and at what cost - Your pricing model and expected revenue per customer - Monthly burn rate (current and projected post-raise) - How long your runway lasts at current spending - What milestones you'll hit before needing the next raise Be honest about what's an assumption and what's backed by data. Investors respect founders who can say "we're assuming a 3% conversion rate based on our landing page tests, but we haven't validated it at scale." ## Why this matters now, not later Every document on this list serves a dual purpose. First, it helps investors and mentors evaluate your startup and give you better advice. Second, it forces you to think clearly about things you might be fuzzy on. I've watched teams go through the exercise of writing a product roadmap and realize halfway through that their cofounders don't agree on the priorities. Better to discover that 8 weeks before demo day than during the investor Q&A. ## The process Don't try to write all five documents in one weekend. Spread it over two weeks: - **Week 1:** Product vision and user research summary (these draw on what you already know) - **Week 2:** Technical architecture, roadmap, and financial assumptions (these require more analysis) Share drafts with your mentors. Ask them to tell you where they're confused, not where they agree. Confusion in the document means confusion in the pitch. ## The bottom line Documentation isn't overhead for accelerator teams. It's the difference between "interesting idea" and "fundable company." The plans in your head are invisible to everyone who could help you. Write them down, and you'll be surprised how much sharper everything gets. ### Stop Building Features Nobody Asked For https://projan.ai/blog/stop-building-features-nobody-asked-for/ Published: 2025-12-11 ## You're doing it again You have 12 users. You're building an API. Nobody asked for an API. Nobody even hinted at wanting one. But it's a fun engineering problem, and you can already picture the docs page. So you spend two weeks on it instead of fixing the onboarding flow that's losing you 80% of signups. This is the indie hacker's curse. When you're the founder, the PM, and the developer, there's nobody to stop you from building whatever feels most interesting on a Tuesday morning. ## The symptoms You know you're in feature creep territory when: - You're adding dark mode before you have 50 users - You're building integrations with platforms none of your users are on - You redesigned the settings page three times but haven't talked to a customer in a month - Your changelog has 10 entries and your MRR hasn't moved These are all real examples from indie hackers I've talked to. Smart people, building well-crafted features that nobody needed. ## Why it happens Building is comfortable. Talking to users is not. When you build, you're in control. You pick the problem, you pick the solution, you see progress. It feels productive. Ship a feature, commit the code, tweet about it. Dopamine. When you talk to users, you might hear things you don't want to hear. "I don't understand what this does." "I tried to sign up and gave up." "I'm using your competitor because they do X." That's not fun. But it's the only information that matters. ## The rule: 5 users before any feature Before you build anything new, talk to 5 users. Not a survey. Actual conversations. Ask them: 1. What's the most frustrating part of using this? 2. What were you trying to do last time you used it? 3. Is there anything that almost made you stop using it? If your planned feature doesn't come up in any of those conversations, it's a hobby project. That's fine. Just don't confuse it with product work. ## What to build instead Open your support inbox, your feedback channel, your analytics. Write down the top 3 things users actually complain about or struggle with. That's your roadmap. It'll probably be boring stuff. Confusing onboarding. A broken flow on mobile. Missing CSV export. Nothing that makes for an exciting launch tweet. But here's the difference: fixing real problems retains users. Building fun features entertains you. ## The hard question Ask yourself honestly: am I building a product or a portfolio piece? If it's a product, the users decide what gets built. Your job is to listen, prioritize, and execute on their problems. If it's a portfolio piece, build whatever you want. Just don't be surprised when the user count stays at 12. ## Make it a habit Every Monday, before you write any code, answer two questions: 1. What is the biggest problem my current users have? 2. Is the thing I'm about to build solving that problem? If the answer to the second question is no, stop. Go talk to someone who uses your product. Then come back and build the thing that actually matters. Your users are telling you what to build. You just have to stop long enough to listen. ### The Client Said 'Build What You Think Is Best.' It Was a Trap. https://projan.ai/blog/client-said-build-what-you-think-is-best/ Published: 2025-12-07 ## The dream brief The email from the client read: "We trust you guys. Just build what you think is best. You're the experts." If you've worked in an agency, your pulse just went up. Maybe from excitement, maybe from dread, depending on how many times you've been through this. On the surface, it's the perfect client. No micromanagement. No 47-page requirements doc. Total creative freedom. The team gets energized. The designers go bold. The developers build something genuinely clever. Six weeks later, the client sees the first demo. Their face says everything. "That's... not what we had in mind." ## What went wrong Nothing went wrong with the build. The team did excellent work. The problem started before a single line of code was written. When a client says "build what you think is best," they don't mean it literally. They mean: "I have a picture in my head, but I can't articulate it, and I'm hoping you'll just guess correctly." They're not being dishonest. They genuinely believe they're giving you freedom. But there's always an expectation hiding underneath. Maybe they want it to look like a competitor's product. Maybe they're imagining a specific workflow they saw at a conference. Maybe their CEO has opinions they haven't shared yet. If you don't dig those expectations out early, you'll discover them at the worst possible moment: during the review. ## The revision spiral Here's how the next two months typically go. The client gives feedback. It's contradictory because they're reacting emotionally, not evaluating against agreed criteria. "Can we make it simpler but also add more features?" The team revises. The client is happier with some parts, but now has new feedback on things they approved before. Scope changes, but the timeline doesn't. The budget conversation gets awkward. By the end, the agency has done three times the work for the original price, and the client feels like they overpaid for something that should have been simpler. Nobody's happy. All because nobody wrote down what "best" meant before starting. ## The fix: structured discovery, even when they don't want it I've seen agencies handle this well, and the approach is always the same. When a client offers total freedom, the agency politely refuses it. Not the project. The ambiguity. Here's what that looks like in practice. ### Ask the questions they haven't thought about Before any design work starts, run a structured discovery session. Even a short one, 60 to 90 minutes, changes everything. Cover these: - **Who is this for?** Not "our users." Specific people. What are they trying to do? What frustrates them about the current solution? - **What does success look like?** If this project goes perfectly, what's different in 6 months? More signups? Fewer support tickets? A specific conversion rate? - **What should this NOT be?** This question surfaces hidden constraints faster than anything. "We don't want it to feel like Salesforce" tells you more than 20 pages of requirements. - **Who else has opinions?** Find out if there's a CEO, board member, or department head whose preferences will show up at the review. Get those people into the room early. ### Document it in their words Write up what you heard, using their language, not yours. Send it back within 24 hours. Ask them to confirm or correct it. This document becomes your insurance policy. When the feedback starts shifting later, you can point to it and say: "Here's what we agreed on. Do you want to change direction? That's fine, but let's update the plan and talk about what that means for timeline and budget." ### Show work early and often Don't wait six weeks for a big reveal. Show rough work in week one. Ugly wireframes. Basic flows. The earlier they see something, the earlier they can react. Early reactions are cheap to act on. Late reactions are expensive. ## The relationship angle Some agency people push back on this. "If we make the client go through all this upfront work, they'll think we're difficult. They chose us because we're easy to work with." I understand the instinct. But here's what actually damages client relationships: delivering something they didn't want and then telling them it'll cost more to fix. Clients remember agencies that nailed it on the first try. They don't remember the kickoff meeting being thorough. They remember the result feeling like exactly what they needed. Structured discovery isn't overhead. It's how you earn "they just get us" status. ## The one thing to take away When a client gives you total freedom, treat it as a yellow flag. Not a red one. Just a signal that the real requirements are hiding and it's your job to find them. Ask the questions. Write down the answers. Get sign-off. Then go build something great. The freedom to build well starts with the discipline to define clearly. ### Acceptance Criteria Developers Actually Thank You For https://projan.ai/blog/acceptance-criteria-developers-thank-you-for/ Published: 2025-12-02 ## The spectrum of bad acceptance criteria I've reviewed hundreds of user stories over the years, and acceptance criteria tend to fail in one of two directions. Too vague: "The feature should work well and be user-friendly." Too prescriptive: "Use a blue (#2563EB) button, 14px font, positioned 24px from the right edge, which triggers an API call to /api/v2/submit." The first gives developers nothing to work with. The second gives them no room to think. Both lead to the same outcome: multiple rounds of rework because expectations weren't clear. Good acceptance criteria sit in the middle. They describe what success looks like without dictating how to get there. ## The pattern that works: Given / When / Then If you take one thing from this post, let it be this format: - **Given** [a specific context or starting state] - **When** [the user takes an action] - **Then** [this observable outcome should happen] It works because it forces you to think about context, actions, and outcomes separately. You can't be vague when you have to fill in all three parts. Let's look at five real examples. ## Example 1: User registration **Bad AC:** "Users should be able to register. Validation should be good." What does "good" mean? Does it check email format? Password strength? Duplicate accounts? A developer reading this has to make dozens of assumptions. **Rewritten:** - Given a visitor is on the registration page - When they submit a valid email and a password with at least 8 characters (including one number and one uppercase letter) - Then an account is created and a verification email is sent within 60 seconds - Given a visitor submits an email that already exists in the system - When they click Register - Then they see an error message: "An account with this email already exists" and no duplicate account is created Notice how each scenario covers one path. Don't try to cram every case into one AC statement. ## Example 2: Search functionality **Bad AC:** "Search should return relevant results quickly." "Relevant" and "quickly" are opinion words, not requirements. **Rewritten:** - Given a user types a query of 3 or more characters into the search bar - When they press Enter or wait 300ms after typing stops - Then results matching the query in the title or description fields are displayed, sorted by relevance score, within 2 seconds - Given a user searches for a term with no matching results - When the search completes - Then a message is displayed: "No results found for [query]. Try different keywords." along with 3 suggested alternatives ## Example 3: File upload **Bad AC:** "Users can upload files. Supported formats should be handled." Which formats? What size limits? What happens when an upload fails? **Rewritten:** - Given a user selects a file in PNG, JPG, or PDF format under 10MB - When they click Upload - Then the file is uploaded, a progress indicator is shown during upload, and a thumbnail preview appears on completion - Given a user selects a file that exceeds 10MB or is in an unsupported format - When they click Upload - Then the upload is blocked before it starts and a message explains the limitation: "Files must be PNG, JPG, or PDF and under 10MB" ## Example 4: Notification preferences **Bad AC:** "Users should be able to manage their notification preferences." This describes a feature, not criteria for success. **Rewritten:** - Given a user is on the Notification Settings page - When they toggle off email notifications for "Weekly digest" - Then no weekly digest emails are sent to that user starting from the next scheduled send - Given a user has all email notifications turned off - When a critical security event occurs (password change, new device login) - Then a security alert email is still sent regardless of preferences That second scenario is the kind of thing that gets missed in vague AC. Security notifications aren't optional, and your developers need to know that upfront. ## Example 5: Checkout flow **Bad AC:** "Checkout should be smooth and handle errors gracefully." Every PM has written something like this at least once. It says nothing actionable. **Rewritten:** - Given a user has items in their cart and a valid payment method on file - When they click "Place Order" - Then the order is created, payment is charged, a confirmation page is shown with the order number, and a confirmation email is sent within 2 minutes - Given a user's payment is declined during checkout - When the payment gateway returns a failure response - Then the user sees "Payment declined. Please check your card details or try a different payment method." and their cart contents are preserved ## Tips for writing AC that sticks **One behaviour per statement.** If your AC has the word "and" connecting two different outcomes, split it into two statements. **Include the sad paths.** What happens when things go wrong is just as important as when they go right. Developers will encounter these paths whether you document them or not. Better to decide the behaviour now than debate it during code review. **Use real numbers.** "Fast" isn't a requirement. "Under 2 seconds" is. "Short" isn't testable. "Maximum 160 characters" is. **Skip implementation details.** Don't specify the database query, the CSS class, or the API endpoint. That's the developer's domain. Your job is to describe what the user experiences. **Read it out loud.** If your AC sounds like a legal document, simplify it. If a new team member couldn't understand it in one read, it's too complex. ## Writing good AC takes practice, not just process The Given/When/Then format is a great starting point, but the real skill is learning to think like both the user and the developer at the same time. What would a user expect here? What would a developer need to know to build it right the first time? If you want a shortcut for generating solid acceptance criteria, [Projan](https://projan.ai) can help. You describe what you're building in a conversation, and it generates structured acceptance criteria automatically, complete with Given/When/Then formatting and edge cases you might miss. It's particularly useful when you're writing a lot of stories at once and don't want quality to slip. You can [try it free for 14 days](https://app.projan.ai/create-account). But tool or no tool, the principle stays the same: tell developers what done looks like, and let them figure out how to get there. ### Your Cofounder Disagrees About the Roadmap. Now What? https://projan.ai/blog/your-cofounder-disagrees-about-the-roadmap/ Published: 2025-11-28 ## The argument that won't end Two cofounders. One thinks the next quarter should be all about growth features. The other wants to rebuild the backend before it collapses. They've had this conversation six times. Each time, whoever feels more strongly that day wins. A week later, they're back arguing again. Sound familiar? If you're building a startup with a cofounder, you've been here. Maybe you're here right now. Here's the thing: disagreement about what to build next isn't a red flag. It's a sign that both of you care. The red flag is when you don't have a way to resolve it. ## Why most cofounder disagreements go in circles The pattern is almost always the same. You have a conversation, usually over coffee or in Slack. Both people make their case. The discussion gets heated, or it stays polite but nothing gets decided. You move on to other work. A few days later, it comes up again. The core problem: you're debating in the air. Nothing is written down. There's no shared framework for deciding. So every conversation starts from scratch. And there's a second problem that nobody likes to admit. In verbal debates, the more persuasive speaker wins. Not the better idea. If one cofounder is more articulate or more assertive, they'll win most arguments by default. That's not a strategy. That's a personality contest. ## The framework that actually works I watched two cofounders go through this exact cycle for months. They were building a B2B tool and couldn't agree on whether to invest in integrations or improve onboarding. Both had valid points. They'd debate it every Monday and change direction every other week. What broke the cycle was embarrassingly simple: they started writing things down. Here's what they did, and what I'd recommend for any founding team stuck in this loop. ### Step 1: Write down the options separately Each cofounder writes a one-page brief for their preferred direction. Not a pitch. A brief. It should cover: what you'd build, who it serves, what you'd expect to happen (new users, retention, revenue), and what the risks are. Writing forces clarity. It's easy to say "we need integrations" in a meeting. It's harder to write down exactly which integrations, why those ones, and what the expected impact would be. ### Step 2: Agree on the decision criteria first Before you argue about the options, agree on how you'll judge them. This is the step most people skip, and it's the most important one. Pick 3 to 4 criteria. These might be: user impact (how many current users does this help?), revenue potential (does this unlock new customers or pricing?), effort (how long will it take with our current team?), and risk (what happens if we're wrong?). Weight them if you want, but even unweighted criteria give you a shared lens. ### Step 3: Score each option honestly Go through each option against the criteria together. Where you agree, mark it and move on. Where you disagree, talk about it. But now you're disagreeing about something specific ("I think integrations help 60% of users, you think 20%") instead of something vague ("I just think integrations matter more"). ### Step 4: Make the call and set a review date Pick the winner based on the scores. If it's close, the cofounder with more domain expertise in that area gets the tiebreaker. Set a date, usually 4 to 6 weeks out, to review whether the decision was right. This last part matters. Knowing there's a review date makes it easier to commit. You're not signing up forever. You're running an experiment. ## Why writing changes everything The two cofounders I mentioned? Once they started writing down their options, they realized they actually agreed on the priority about 70% of the time. The disagreements were mostly about scope and timing, not direction. They also stopped re-litigating old decisions. When you have a written record of why you chose option A, you don't have to defend it again three weeks later. The document is the defense. Writing doesn't slow you down. Repeating the same argument every week slows you down. A few hours spent on a structured decision saves you weeks of flip-flopping. ## The uncomfortable truth If you and your cofounder can't write down your perspectives and evaluate them against shared criteria, the problem might be bigger than the roadmap. It might be a trust issue or a values misalignment. But most of the time, it's not. Most of the time, it's just two smart people who never set up a process for making decisions together. Fix the process, and the arguments become productive conversations. Write it down. Define how you'll decide. Make the call. Review it later. That's it. ### The Weekend Project Trap: Why Most Side Projects Die on Monday https://projan.ai/blog/the-weekend-project-trap/ Published: 2025-11-24 ## Saturday Energy, Monday Amnesia Here's a cycle I've lived through more times than I'd like to admit. Saturday morning. Coffee, laptop, excitement. You open the project and code for six hours straight. Real progress. The feature works, the tests pass, you're on a roll. Sunday you put in another solid session. By Sunday night, you've got momentum. Monday arrives. Work takes over. Meetings, PRs, deadlines. Tuesday is the same. By Wednesday you've forgotten the details of what you built over the weekend. Thursday you briefly think about the project but you're tired. Friday you tell yourself you'll pick it up tomorrow. Saturday comes. You open the project. You stare at the code. What was I doing? Where did I leave off? Why did I name this variable that? What was the next step? You spend 45 minutes re-reading your own code, trying to rebuild the mental model that was so clear six days ago. The momentum is gone. You make a little progress, but it feels like starting over. A few weekends of this and the project quietly dies. ## The Problem Isn't Motivation I used to think my side projects failed because I wasn't motivated enough. If I really cared about the project, I'd find time during the week. I'd push through the context-switching friction. That framing is wrong. The problem isn't caring. It's that human brains aren't designed to hold complex context across a week of doing something completely different. Your day job fills your working memory with its own codebase, its own problems, its own decisions. By the weekend, your side project's context has been fully evicted. This is a memory problem, not a motivation problem. And memory problems have a simple solution: write things down. ## The 10-Minute Session Closer The fix is almost embarrassingly simple. At the end of every coding session, spend 10 minutes writing down three things: **1. Where I am.** What did I just finish? What state is the code in? Is anything broken? Are there uncommitted changes? "Finished the auth flow. Login and signup both work. Logout is half-done, the endpoint exists but the frontend doesn't call it yet. All changes committed on the auth-flow branch." **2. What's next.** What's the very next thing to do when I sit down again? Not the big picture. The specific next task. "Wire up the logout button in the navbar to call /api/logout. Then test the full flow: signup, login, logout, login again. After that, start on the profile page." **3. Decisions I made.** Any choices I made that I might question later. Why I did something a specific way. "Used JWT in httpOnly cookies instead of localStorage. Reason: more secure by default, and we don't need to access the token from JavaScript. If I need to show user info in the UI, I'll add a /api/me endpoint instead of decoding the token client-side." That's it. Three paragraphs. Maybe five minutes of writing. It completely changes what happens when you open the project next time. ## What Changes When You Do This Instead of staring at code on Saturday morning, you open your notes. In 60 seconds you know exactly where you left off, what to do next, and why the code looks the way it does. You skip the 45-minute re-orientation phase and go straight to productive work. The psychological difference is huge. When you sit down and immediately know what to do, starting feels easy. When you sit down and have to figure out what to do, starting feels hard. Most side projects die in that gap. ## Keep a Running "State of the Project" Doc Take this a step further. Keep a single document, a README, a Notion page, a text file in the repo, that tracks the overall state of the project. It doesn't need to be fancy. Mine looks like this: ``` ## Project: Bookmarks Extension ## Last session: Nov 17 ### Current state - Chrome extension popup works, can save bookmarks - Storage layer uses chrome.storage.sync - Tagging UI exists but tags aren't persisted yet - No search functionality yet ### Next session priorities 1. Persist tags to storage (should be ~30 min) 2. Basic search by tag name 3. If time: keyboard shortcut to open popup ### Open questions - Should search be in the popup or a separate page? - How to handle tag suggestions? Local frequency-based or something smarter? ### Done (v1 checklist) - [x] Save bookmark with one click - [x] Custom popup UI - [ ] Tag bookmarks - [ ] Search by tag - [ ] Keyboard shortcut - [ ] Export/import ``` This document takes two minutes to update. It gives future-you everything needed to sit down and start working immediately, even after a two-week gap. ## The Real Killer: The Two-Week Gap Weekend projects are fragile because life happens. One weekend you're busy. The next you're traveling. Suddenly it's been two or three weeks since you touched the project. Without notes, a two-week gap is usually fatal. The context is so far gone that resuming feels like starting over. With a state doc, a two-week gap is a minor inconvenience. You read your notes, re-orient in five minutes, and pick up where you left off. The projects I've actually finished all have one thing in common: I kept notes. The ones I abandoned don't. The correlation is near-perfect. ## Start Today If you have a side project that's been gathering dust, try this before you give up on it. Open a new file. Write down what state it's in, what's next, and any decisions you remember making. It'll take ten minutes. Then, next time you sit down to work on it, see how different it feels to start with a clear picture instead of a blank stare. Your side project doesn't need more of your time. It needs more of your context. Write it down before you close the laptop. ### Building in Public Is Not Free Marketing https://projan.ai/blog/building-in-public-is-not-free-marketing/ Published: 2025-11-19 ## The Promise vs. the Reality The pitch for building in public goes something like this: share your journey, attract an audience, convert followers into customers. Free marketing. No ad spend required. I bought into this completely when I started sharing my build process online. Tweeted updates, posted revenue numbers, shared architecture decisions, wrote threads about lessons learned. After six months of consistent posting, here's what I had: 2,000 followers, mostly other indie hackers. About 12 actual signups from social media. The rest came from SEO and direct outreach. Building in public wasn't bad. It just wasn't what I thought it was. ## Your Audience Is Other Builders This is the part nobody talks about honestly. When you build in public, the people who pay attention are overwhelmingly other people who are also building in public. Founders follow founders. Developers follow developers. Indie hackers follow indie hackers. Your actual customers, the people with the problem you're solving, are usually not scrolling Twitter looking for someone's build updates. A product manager at a mid-size company isn't following your "day 47 of building my SaaS" thread. They're Googling their problem and reading blog posts that rank well. There are exceptions. Some builders have genuinely converted their audience into customers. But look closely at those success stories, and you'll notice the audience was already the target market. A developer building dev tools for developers. A designer building design tools for designers. The audience and the customer were the same person. If your target customer isn't a builder, your build-in-public audience probably isn't your target customer. ## The Hidden Value Is Discipline Here's what building in public actually gave me, and it's more valuable than marketing. **It forced me to plan.** When you commit to sharing weekly updates, you need something to update people on. That means you need a plan for the week. Before I started sharing publicly, my weeks were reactive. I'd work on whatever felt urgent or interesting. Once I had an audience expecting updates, I started the week by deciding what I'd build and ended the week by reporting what I actually shipped. **It forced me to articulate decisions.** Writing a tweet about why I chose Postgres over MongoDB made me actually think through the tradeoffs. Explaining a pricing decision publicly meant I had to have real reasons, not vibes. The act of writing for an audience clarified my own thinking. **It created accountability.** I told 2,000 people I'd launch the beta by March. When February came and I was behind, the public commitment pushed me to cut scope and hit the date. Without that accountability, I'd have quietly slipped the timeline like I always had before. **It created a decision log.** Six months of public updates gave me a searchable history of every major decision I'd made and why. When I questioned a choice later, I could go back and read my own reasoning. That's worth more than any audience metric. ## The Planning Discipline Is the Product Think about what building in public actually requires: - A roadmap (even a rough one) to share - Weekly goals to update on - Clear reasoning behind decisions - Honest assessment of progress - A definition of what "done" looks like for each milestone These are all planning activities. The public sharing is just the mechanism that forces you to do them. I've met builders who stopped sharing publicly but kept the habits. They still write weekly internal updates to themselves. They still articulate their decisions in writing. They still set weekly goals and review them. The audience went away. The discipline stayed. And here's the thing: the discipline is what actually moves the product forward. Not the followers. ## When Building in Public Does Work for Marketing I'm not saying building in public has zero marketing value. It does, in specific situations: **Social proof for early users.** When someone Googles your product and finds months of transparent updates about how you built it, that builds trust. It's not direct acquisition, but it helps convert people who've already found you. **Networking with other builders.** My build-in-public audience introduced me to three people who became design partners, two who gave me critical feedback on pricing, and one who became a collaborator. That wasn't marketing. It was community. **Content that ranks.** Some of my build-in-public posts became blog posts that actually rank for useful keywords. The public sharing created raw material for real content marketing. The tweet got 20 likes; the blog post gets 500 visits a month from Google. ## Be Honest About Why You're Doing It If you're building in public for marketing, measure it like marketing. Track signups from social, track conversion from followers to users, track whether the time you spend posting is more effective than the same time spent on SEO or outreach. If you're building in public for discipline and accountability, great. Own that. It's a legitimate reason, and probably the more honest one. Just don't confuse the two. The followers feel like progress. The planning discipline *is* progress. And you don't need an audience to benefit from writing down your plans, documenting your decisions, and holding yourself accountable to a timeline. A blank notebook works too. ### The One Question That Saves Every PRD https://projan.ai/blog/the-one-question-that-saves-every-prd/ Published: 2025-11-11 ## The Question Every vague requirement I've ever seen can be fixed with five words: "How will we know this is done?" That's it. That's the whole trick. When you force yourself (or your team) to answer this question for every line in a PRD, vague wishes turn into testable criteria. It's embarrassingly simple, and it works every time. ## Why Requirements Stay Vague Product managers write vague requirements for understandable reasons. You're thinking about the big picture. You know what you mean. The words feel clear enough when you're writing them. The problem shows up later, when an engineer reads "make the dashboard more intuitive" and has to turn that into code. What does intuitive mean? Fewer clicks? Faster load times? Different layout? Better labels? All of the above? Without a clear definition of done, the engineer picks an interpretation. The PM had a different one in mind. The review meeting goes badly. The sprint slips. One question prevents all of that. ## Four Vague Requirements, Transformed ### "The onboarding flow should be user-friendly" Ask: How will we know this is done? **Becomes:** A new user can complete account setup and reach the main dashboard in under 3 minutes without contacting support. The flow has no more than 4 steps. Each step has a single primary action. Drop-off rate between steps is under 20%. Now an engineer knows exactly what to build. A QA engineer knows exactly what to test. A designer knows the constraints. Everyone is working toward the same target. ### "Improve search performance" Ask: How will we know this is done? **Becomes:** Search results return in under 200ms for queries up to 50 characters against our current dataset (2.3M records). Results are ranked by relevance using the updated scoring algorithm. The first result matches the user's intent for at least 85% of the top-100 most common queries. "Improve" is the most dangerous word in a PRD. It means nothing without a number. The question forces you to define what improvement looks like, specifically. ### "Users should be able to easily export their data" Ask: How will we know this is done? **Becomes:** Users can export all their data (projects, tasks, comments, attachments) as a CSV or JSON file from the account settings page. The export completes within 60 seconds for accounts with up to 10,000 records. The exported file includes all fields visible in the UI. Users receive an email with a download link when the export is ready. "Easily" disappeared entirely. It was replaced by specific behaviors: what formats, what data, where in the UI, how long it takes, and how the user gets notified. ### "The notification system should be reliable" Ask: How will we know this is done? **Becomes:** 99.5% of notifications are delivered within 30 seconds of the triggering event. Failed notifications are retried 3 times with exponential backoff. Users can see a log of all notifications sent in the last 30 days. Zero duplicate notifications per event. "Reliable" is a feeling. 99.5% delivery within 30 seconds is a testable requirement. ## How to Use This in Practice You don't need a new process or a new template. Just a habit. After you write any requirement, read it back and ask yourself: if an engineer shipped this tomorrow, how would I check whether it's right? If the answer is "I'd know it when I see it," the requirement isn't done. Some practical ways to apply this: **In PRD reviews:** Go through each requirement as a team and ask the question out loud. The discussion it generates is often more valuable than the document itself. **In ticket writing:** Before a ticket leaves the backlog, add a "definition of done" section. Three to five bullet points. Each one should be verifiable without subjective judgment. **In design critiques:** "How will we know the new design is better than the old one?" If you can't answer that, you can't evaluate the design. ## The Uncomfortable Part This question sometimes reveals that you don't actually know what you want. That's uncomfortable, but it's better to discover that ambiguity while writing the requirement than during the sprint review. If you can't answer "how will we know this is done?" for a requirement, that requirement isn't ready for development. It needs more thinking, more user research, or more conversation with the team. That's not a failure. That's the question doing its job. ### What I Wish I Knew Before My First Hackathon https://projan.ai/blog/what-i-wish-i-knew-before-my-first-hackathon/ Published: 2025-11-06 ## The Mistake Every First-Timer Makes My first hackathon, our team of four opened our laptops at 9:01 AM and started coding immediately. We had a vague idea (something with maps and local events) and figured we'd work it out as we went. By hour six, we had three separate codebases that didn't connect, no shared understanding of what the app was supposed to do, and a heated argument about whether the backend should use Firebase or Express. We presented a half-broken demo that the judges politely sat through. The team next to us spent the first two hours in a conference room with a whiteboard. No laptops. They came out with a clear plan, split up the work, and built a polished demo that won second place. I've since done a dozen more hackathons and judged a few. The pattern is always the same: teams that plan first, win. Teams that code first, struggle. ## The First Two Hours Are Everything A 24-hour hackathon sounds like a lot of time. It isn't. By the time you subtract meals, fatigue, debugging, and the inevitable "nothing works" panic at 2 AM, you have maybe 14-16 productive hours. Spending two of those hours planning feels expensive. It's actually the cheapest investment you'll make. Here's how to use that time. ### Pick a Problem, Not a Technology "Let's build something with computer vision" is a technology looking for a problem. "Students waste 20 minutes finding open study spaces on campus" is a problem looking for a solution. Judges evaluate whether your project solves a real problem. Start there. Technologies are tools. Pick them after you know what you're building. ### Sketch the User Flow Grab a piece of paper and draw the screens. Not wireframes, just boxes with words. "User opens app, sees a map, taps a building, sees available rooms, books one." This takes ten minutes and prevents the single biggest hackathon time-waster: building features that don't connect into a coherent experience. Every screen should lead to the next. If you can't sketch the flow, you don't understand the product yet. ### Agree on the Demo Story This is the tip most hackathon guides miss. Your demo is 3-5 minutes. That's it. Plan the demo *before* you build. Write down the exact story you'll show the judges. "We open the app, we're a student looking for a study space, we see the map, we tap the library, we see room 204 is free, we book it, done." Now build exactly what you need for that demo to work. Nothing more. If a feature doesn't appear in the demo story, it doesn't get built. ### Split the Work Cleanly With a clear plan, you can divide work without stepping on each other. One person does the frontend. One does the backend. One handles the data layer or API integrations. One prepares the presentation and handles design. Agree on the interfaces between each piece early. "The backend will return a JSON array of rooms with name, building, and available boolean." That's enough for the frontend person to start building without waiting. ## During the Hackathon A few things I've learned the hard way: **Get something working end-to-end early.** A ugly, hardcoded version of the full flow is more valuable at hour eight than a beautiful, polished version of one screen. You can polish later. You can't debug integration issues at 3 AM. **Fake what you can't build.** Your AI model doesn't need to actually work for the demo. Hardcode the responses if you run out of time. Judges are evaluating the idea and the execution of the overall experience, not whether your ML pipeline is production-ready. **Stop coding one hour before presentations.** Use that hour to practice the demo, fix the flow, and prepare for questions. I've seen technically brilliant projects lose because the demo was disorganized and confusing. **Commit your code regularly.** Nothing is worse than losing work because someone's laptop crashes at midnight. Push to GitHub every hour at minimum. ## What Judges Actually Look For Having sat on the judging side, I can tell you: we're not impressed by complexity for its own sake. We're looking for three things: 1. **Does it solve a clear problem?** Can you explain who this is for and why they need it in one sentence? 2. **Does the demo work?** A smooth, working demo of a simple idea beats a broken demo of an ambitious one every time. 3. **Did the team understand what they built?** Can you answer questions about tradeoffs, limitations, and what you'd do next? All three of those things come from planning, not from writing more code. ## Your First Hackathon Checklist Before you write a line of code: - [ ] Define the problem in one sentence - [ ] Sketch the user flow on paper - [ ] Write out the demo story (what you'll show judges) - [ ] Agree on the tech stack as a team - [ ] Define the interfaces between each person's work - [ ] Set a "code freeze" time for one hour before demos Do this, and you'll already be ahead of 80% of the teams in the room. The best hackathon project isn't the most technically impressive. It's the most coherent. And coherence comes from planning. ### Planning AI Features When the Tech Changes Every Week https://projan.ai/blog/planning-ai-features-when-tech-changes-weekly/ Published: 2025-11-01 ## The Moving Target Problem Last year I watched a team spend three weeks writing a detailed spec for an AI summarization feature. The spec included the model they'd use (GPT-4), the prompt architecture, the token budget, the fallback logic for rate limits, and the caching strategy. Two weeks into development, a new model dropped that was faster, cheaper, and better at summarization. The team rewrote half the spec. A month later, the API pricing changed. More rewrites. They spent more time updating the spec than building the feature. This is the unique challenge of planning AI features. The underlying technology moves so fast that any spec tied to a specific model, API, or framework risks being outdated before you ship. ## The Mistake: Specifying the "How" Too Early When teams write requirements for AI features, they naturally gravitate toward implementation details. It makes sense. The model choice feels like the most important decision. The prompt design feels like the core of the feature. But model choice and prompt design are implementation details. They're the "how." And the "how" is the part that keeps changing. Here's what a typical AI feature spec looks like: *"Use GPT-4 to summarize customer support tickets into 2-3 sentences. Prompt should include the full ticket text plus the last 5 messages. Cache responses for 24 hours. Cost target: under $0.02 per summary."* Every part of this spec is coupled to a specific model's capabilities and pricing. When the model changes, the prompt strategy changes, the cost assumptions change, the caching logic changes. ## Separate the "What" From the "How" The fix is straightforward: write your requirements at the problem level, not the implementation level. The "what" is stable. Users have a problem. They need a solution. There are constraints around quality, speed, and cost. Those things don't change when a new model launches. The "how" is volatile. Which model, which prompt structure, which API, which framework. Those are engineering decisions that should stay flexible. Here's the same feature spec rewritten at the problem level: **User problem:** Support agents spend 3-4 minutes reading each ticket before responding. They need a quick summary to triage faster. **Success criteria:** Agents can accurately triage a ticket within 30 seconds of opening it. Summary captures the core issue and customer sentiment. **Quality bar:** Summaries should be accurate enough that agents don't need to read the full ticket for 80% of cases. Factual errors are unacceptable. **Constraints:** Latency under 2 seconds. Cost under £0.03 per ticket. Must work for tickets up to 10,000 words. **Not specified:** Model choice, prompt architecture, caching strategy. Those are implementation details for the engineering team to determine based on current options. ## What Stays Stable, What Stays Flexible Think of your AI feature spec in two layers: **The stable layer (write this down, commit to it):** - What user problem does this solve? - Who is the user and what's their workflow? - What does a good output look like? (Include examples.) - What does a bad output look like? (Include failure cases.) - What are the hard constraints? (Latency, cost, accuracy thresholds.) - How will we measure success? **The flexible layer (document decisions, expect to revisit):** - Model selection - Prompt design and chain-of-thought architecture - Fine-tuning vs. few-shot vs. zero-shot approach - Specific API provider - Caching and optimization strategy The stable layer is your product requirement. The flexible layer is your technical approach. Keep them in separate documents, or at least separate sections, so updating one doesn't require rewriting the other. ## Practical Advice for AI Product Specs **Write evaluation criteria early.** Before you pick a model, define what "good enough" looks like with concrete examples. This becomes your benchmark for testing any implementation, current or future. **Include example inputs and expected outputs.** Five or ten real examples of what goes in and what should come out. These are worth more than paragraphs of description, and they survive any technology change. **Set cost and latency budgets, not model mandates.** "Under 2 seconds and under £0.03" is a better requirement than "use GPT-4 Turbo." The first lets your team pick the best available option. The second locks them into today's landscape. **Plan for the model to change.** Build abstraction into the requirement itself. "The summarization service should be model-agnostic" is a valid product requirement if you expect to swap models as better options emerge. The technology will keep moving. Your understanding of the user's problem shouldn't have to move with it. ### How We Stopped Losing Money on Fixed-Price Projects https://projan.ai/blog/how-we-stopped-losing-money-fixed-price-projects/ Published: 2025-10-27 ## The Project That Lost Us £30k A client came to us with what sounded like a straightforward request: "Build us a customer portal." We had a one-hour call, scribbled some notes, and quoted £45k based on what we thought they meant. Eight months and £75k of billable time later, the project was still in progress. The "customer portal" had turned into a full CRM with custom reporting, role-based permissions across three user types, an API integration with their legacy ERP system, and a mobile-responsive redesign that wasn't discussed until month four. We ate the difference. Not because the client was unreasonable, but because we never pinned down what "customer portal" actually meant. And by the time we realized the gap, we were too deep to renegotiate without damaging the relationship. This wasn't a one-off. It was our pattern. ## Why Agency Scoping Fails Most agencies scope projects the same way: have a call, take notes, build an estimate based on experience and gut feel. It works when the project is genuinely simple. It falls apart on anything with complexity. The problem is that clients describe what they want in terms of outcomes ("I need a customer portal") while agencies estimate in terms of effort ("that's about 6 weeks of dev work"). The gap between the outcome and the effort is filled with assumptions. The client assumes things are included. The agency assumes things are excluded. Nobody writes any of it down. Three specific failure modes keep repeating: **The "obvious" feature.** The client mentions it once in passing during the discovery call. The agency doesn't capture it. Three months in, the client asks where it is. "We talked about this." **The undefined user.** "Customers will use the portal" could mean ten customers or ten thousand. It could mean tech-savvy developers or retired accountants. The design, the infrastructure, and the support model all change depending on the answer. **The integration surprise.** "It needs to connect to our system." That system turns out to be a fifteen-year-old on-premise database with no API, a custom authentication layer, and data quality issues that require a migration project before any integration work can start. ## What We Changed After three painful fixed-price projects in a row, we overhauled our scoping process. The changes were simple, but the impact was significant. ### Discovery calls became structured interviews We stopped having freeform conversations about what the client wanted. Instead, we built a question framework that we walked through systematically: - Who are the users? How many? What's their technical comfort level? - What can they do today? What should they be able to do after this project? - What systems does this need to connect to? Who manages those systems? - What does "done" look like from a user perspective? Walk us through the ideal experience. - What's explicitly out of scope for this phase? The last question was transformative. Clients almost never volunteer what they don't want. But when you ask directly, you get answers that prevent months of misalignment. ### Outputs became documented specs Every discovery session now produces a written scope document. Not a proposal. A scope document that both sides sign off on before we estimate anything. It lists every feature, every user type, every integration, and every explicit exclusion. It includes rough wireframes for any screen that could be interpreted multiple ways. It's usually 3-5 pages. The document becomes the contract's technical appendix. When a client asks for something that's not in the spec, we have a productive conversation about scope changes instead of an argument about expectations. ### Estimates became accurate With clear specs, our estimates improved dramatically. We went from regularly overrunning by 40-60% to coming in within 10% of the original quote. Not because we got better at estimating, but because we finally knew what we were estimating. Our profit margins on fixed-price work went from negative (yes, negative) to a consistent 25-30%. ## The Structured Scoping Session Here's what a typical scoping engagement looks like now: **Session 1 (90 minutes):** Walk through the question framework. Record the call. Capture every feature request, assumption, and concern. **Between sessions:** Write up the scope document. Flag ambiguities and unknowns. Prepare follow-up questions. **Session 2 (60 minutes):** Review the scope document with the client. Resolve ambiguities. Agree on what's in and what's out. **Deliverable:** Final scope document, signed off by both parties, attached to the contract. This adds about a week to the sales process. It has saved us hundreds of hours of unbillable rework. ## The Uncomfortable Truth The reason most agencies don't do structured scoping is that it feels slow. You're adding time before the project starts, and clients want to start yesterday. There's pressure to skip the process and just begin. But the time you "save" by skipping scoping is borrowed time. You'll spend it later, in status calls explaining delays, in internal meetings debating what the client actually wanted, in free rework to keep the relationship alive. Good scoping isn't overhead. It's the foundation that makes fixed-price work profitable. If you want to take this further, tools like [Projan](https://projan.ai) can help structure these requirement gathering conversations automatically, turning a client discussion into an organized spec you can hand to your team. It's especially useful when you're running multiple discovery sessions a week and need consistency. [Give it a try](https://app.projan.ai/create-account) if your scoping process could use more structure. ### I Shipped 4 Side Projects Last Year and Finished None of Them https://projan.ai/blog/shipped-4-side-projects-finished-none/ Published: 2025-10-21 ## The Pattern Here's my 2024 in side projects: **January:** A CLI tool for managing dotfiles. Got the core working in a weekend. Never added the sync feature that was the whole point. **April:** A habit tracker with a twist (location-based reminders). Built the UI, wired up geolocation, never figured out the notification system. Moved on. **July:** A Markdown-based CMS. Actually got pretty far on this one. Then I saw someone launch something similar on Product Hunt and lost all motivation. **October:** A browser extension for bookmarking with AI tags. Built the popup, the storage layer, half the tagging logic. Thanksgiving happened. Never touched it again. Four projects. Hundreds of hours. Nothing shipped. ## Why This Keeps Happening I used to think it was a discipline problem. I'd tell myself to focus, to push through the boring parts, to stop chasing new ideas. That framing never worked because it treated the symptom, not the cause. The real problem was simpler: I never defined what "done" meant before I started. Each project began with an exciting idea and an immediate jump to code. The first few days were great. Everything was new, progress was visible, momentum was high. Then I'd hit the messy middle, the part where you're wiring up boring stuff, handling edge cases, writing the features that aren't fun but are necessary. Without a clear picture of what v1 looked like, every hard task felt optional. "Do I really need the sync feature for launch? Maybe I'll skip it for now." Skip enough "optional" things and there's no product left. ## The Fix Isn't Discipline After four abandoned projects, I tried something different for project number five. Before writing any code, I spent thirty minutes writing down exactly what v1 was. Not a grand vision. Not a roadmap. Just a list: - What does it do? - Who is it for? - What are the 5-7 features in v1? - What is explicitly NOT in v1? - How will I know it's done? That last question mattered most. "Done" became concrete: when a user can do X, Y, and Z, it's done. Not perfect. Not polished. Done. When I hit the boring middle on project five, something was different. The boring tasks weren't optional anymore. They were on the list. I could see exactly how many were left. The finish line was visible. I shipped it. ## What Changes When You Define Done Three things shift when you write down what v1 looks like: **You can say no to yourself.** New feature ideas still pop up. But now you have a list, and the new idea isn't on it. "Cool idea. That's v2." Back to the list. **The boring parts feel purposeful.** Setting up auth is tedious. But when it's item 4 of 7 on your v1 list, finishing it feels like progress instead of a chore. **You know when to stop.** This is the big one. Without a definition of done, you're never done. There's always one more thing to add, one more thing to fix. With a list, you check off the last item and ship. ## Thirty Minutes That Save Thirty Hours I'm not suggesting you write a formal spec for every side project. That would kill the fun. But thirty minutes of "what is this thing, specifically?" before you open your editor will save you from the cycle. Write it in a note, a README, the back of a napkin. Doesn't matter. Just answer: what does done look like? Your future self, the one who's tired on a Tuesday night and debating whether to keep going, needs something to point at. Give them a list to finish instead of a vision to chase. ### Why Your MVP Takes 6 Months Instead of 6 Weeks https://projan.ai/blog/why-your-mvp-takes-6-months/ Published: 2025-10-16 ## The 6-Week MVP That Took 5 Months A founder I know planned a straightforward MVP. A marketplace connecting freelance designers with small businesses. Simple listings, basic messaging, Stripe payments. He estimated six weeks to launch. Five months later, the app had a review system, a portfolio builder, a recommendation engine, an admin dashboard with analytics, and a notification system with email digests. The marketplace still didn't work properly because the core matching flow kept getting deprioritized for new features. He never wrote down what the MVP actually was. So every conversation with his dev team became an opportunity to add "just one more thing." This story isn't unusual. It's the default. ## Why MVPs Bloat The word "minimum" is doing a lot of heavy lifting in "minimum viable product," and most founders never define what it means for their specific case. Here's what typically happens. A founder has a vision for the complete product. It's a big, beautiful vision. They know they should start small, so they call it an MVP. But the vision is still the reference point. Every feature decision gets evaluated against the full picture, not the minimum one. Then the conversations start: "While we're building the profile page, shouldn't we add portfolio uploads?" "If we're doing messaging, we should probably add read receipts." "Users will expect email notifications. That's table stakes." Each addition sounds reasonable in isolation. None of them are strictly necessary to test the core hypothesis. But nobody defined what "necessary" means, so there's no way to say no. The scope grows by accretion. Nobody makes a single decision to build a big product. They make fifty small decisions that add up to one. ## The Real Problem Is Skipping Requirements Founders skip the requirements phase because it feels like bureaucracy. Writing specs is what big companies do. Startups move fast. You don't need a document; you need a product. Except you do need a document. Not a fifty-page PRD. Not a formal spec. Just a clear, written answer to a handful of questions: **What hypothesis are we testing?** If you can't state this in one sentence, you're not building an MVP. You're building a product. **Who is the first user, specifically?** Not "small business owners." Something like "solo freelancers who currently find clients on Instagram and want a dedicated platform." **What is the smallest thing we can build to test the hypothesis with that user?** This is where discipline matters. Not "what would be nice." Not "what would be competitive." What is the absolute minimum? **What are we explicitly NOT building?** This is the most important section and the one founders skip. Write it down. "No admin dashboard. No email notifications. No review system. These are v2." ## A One-Page Spec Changes Everything Here's what a useful MVP spec looks like. It fits on one page: **Hypothesis:** Freelance designers will pay $20/month for a platform that connects them with pre-qualified small business clients. **First user:** Solo freelance designers doing under $5k/month in revenue. **Core flow:** Designer creates profile. Client posts a brief. Designer gets matched and sends a proposal. Client accepts. Payment happens off-platform for v1. **Success metric:** 10 designers sign up and send at least one proposal within 30 days. **Not building:** Reviews, portfolios, in-app payments, analytics, email digests, mobile app. That's it. Everything the dev team needs to make decisions is on one page. When someone suggests adding portfolio uploads, you point at the page. "That's in the 'not building' section. Let's revisit after we hit our success metric." ## How to Say No to Features The one-page spec gives you something to point at, but you also need a decision framework for the features that aren't on either list. Ask three questions about any proposed feature: 1. Does removing this feature prevent us from testing the hypothesis? 2. Will users literally not be able to complete the core flow without it? 3. Will we learn something critical from including it that we can't learn without it? If the answer to all three is no, it's not in the MVP. Put it on a "v2 ideas" list so people feel heard, and move on. ## Ship the Minimum, Then Learn The founder I mentioned eventually shipped a stripped-down version of his marketplace. It took two more months after he finally cut scope. The thing that actually mattered, the matching algorithm, turned out to need a completely different approach than he'd planned. He would have discovered that five months earlier if he'd shipped the minimum first. Your MVP isn't a small version of your product. It's a test. Treat it like one. Write down what you're testing, build only what you need to run the test, and ship it before you're comfortable. The features you're desperate to add will still be there after you've talked to real users. And you'll have actual data to decide which ones matter. ### Why Sprint Planning Feels Like Groundhog Day (And How to Break the Cycle) https://projan.ai/blog/why-sprint-planning-feels-like-groundhog-day/ Published: 2025-10-12 ## The Same Meeting, Every Two Weeks You've been in this meeting before. The PM pulls up a Jira ticket that says something like "Improve the onboarding flow." An engineer asks what "improve" means. Someone references a Slack thread from three weeks ago. Another engineer asks about edge cases that nobody's thought through. Forty minutes later, the team commits to a sprint that everyone quietly knows is underscoped. Two weeks later, it happens again. Sprint planning has this uncanny ability to feel productive while accomplishing very little. The ceremony exists, the tickets get moved, the sprint starts. But the actual *clarity* that's supposed to come from planning? It's rarely there. ## Why It Keeps Happening The root cause isn't bad process. It's that requirements arrive at sprint planning half-baked. Think about the typical flow. A PM writes a ticket sometime during the previous sprint. They capture the gist of what they want. Maybe there's an acceptance criteria section, maybe not. The ticket sits in the backlog until planning day, when everyone reads it for the first time. That's the problem. Sprint planning becomes the first moment the team encounters the requirement in detail. Of course there are questions. Of course there are gaps. The meeting becomes a live requirements gathering session disguised as a planning ceremony. Three patterns show up repeatedly: **Vague acceptance criteria.** "User can easily navigate the dashboard" is not a testable requirement. It's a hope. Engineers need to know specific behaviors, states, and boundaries. **Missing context.** Why are we building this? Who asked for it? What data supports it? Without this context, engineers make assumptions. Different engineers make different assumptions. The sprint diverges from what the PM intended. **Scope that shifts mid-sprint.** This usually happens because the requirement wasn't specific enough to begin with. When someone finally builds the thing and shows it to stakeholders, the response is "that's not what I meant." Back to square one. ## Three Fixes That Actually Work I've watched teams break out of this cycle, and it always comes down to the same three changes. ### 1. Pre-sprint requirement reviews Hold a 30-minute session two or three days before sprint planning. The PM walks through the top priority tickets with one or two engineers. Not the whole team. Just enough people to pressure-test the requirements. This is where the "what does 'improve' mean?" questions get answered. The PM updates the ticket *before* planning day. When the full team sees it, the obvious gaps are already filled. ### 2. Write acceptance criteria before planning, not during This sounds obvious, but I've seen dozens of teams where acceptance criteria get written during sprint planning or, worse, after the sprint starts. Acceptance criteria should be done before a ticket enters planning. The format doesn't matter much. "Given/When/Then" works. Bullet points work. What matters is that someone has written down the specific conditions that make this ticket "done." If you can't write acceptance criteria for a ticket, that ticket isn't ready for sprint planning. Put it back in refinement. ### 3. Get engineering input during discovery, not just delivery The biggest shift I've seen teams make is pulling engineers into discovery earlier. Not as a formal process. Just a quick conversation: "Hey, I'm thinking about this feature. What am I missing?" Engineers think about edge cases, technical constraints, and integration points that PMs often don't. When they're involved early, the requirements that come out are dramatically better. Sprint planning becomes a formality because everyone already understands what they're building. ## The Real Goal of Sprint Planning Sprint planning should be a commitment ceremony, not a discovery session. The team reviews work that's already well-understood and agrees on what they can deliver. If your sprint planning meetings regularly run over time, if engineers are asking basic clarifying questions, if scope shifts every sprint, the meeting itself isn't the problem. The work that happens *before* the meeting is the problem. Fix the inputs and the meeting fixes itself. It's not exciting advice. But it's the kind that actually works.