Product development on a board, in docs and in chat

What problem does this solve?

Building a product involves more than a backlog. There is the spec that explains why a feature exists, the discussion that changed its scope, the bug reports, the standup notes and the release date. In many teams those live in four different tools, and the reasoning behind a decision is the first thing to get lost.

When a new developer joins, or a feature comes back for a second round, the team has to dig through old chat threads and scattered documents to remember what was decided.

Who has this problem?

• Small software teams and startups that want structure without the weight of an enterprise tracker.
• Agencies and studios that build products for clients and need the client to see progress.
• Product-minded founders who write the specs, run the board and answer customer questions in the same week.

How is it usually handled?

A typical setup is an issue tracker for tickets, a wiki or document tool for specs, a chat tool for standups and a calendar for releases. Larger teams add a roadmap tool on top.

What are the limits of that?

• The "why" lives apart from the "what". Tickets rarely link back to the discussion or spec behind them.
• Heavy trackers slow small teams down. Configuring workflows and fields can take more time than the work.
• Standups repeat what the board already shows. People read out status that is written down somewhere else.
• Non-developers stay outside. Designers, support and clients do not log in to the tracker, so they ask in chat instead.

How does Emitii solve it?

A product or team gets a space created with the Project type, which starts with a Board, Tasks, Schedule, Timesheet, Posts and Activity, plus Pulse chat. Turn on Docs & Files for specs.

• Board for features and bugs. Columns are free text, so you name them to match how you work: Backlog, Ready, In progress, Review, Done. Cards carry assignees, due dates, priority (Urgent, High, Medium, Low), labels such as "Bug" or "Sprint 12", checklists and a "blocked" flag with a reason. A column can have a card limit to keep work in progress small.
• Filters and search. Filter the board by people, labels, columns, priority or blocked, and search across card descriptions, checklists and comments.
• Rules for the repetitive moves. Board automation runs rules such as "when a card enters Done, mark it complete" or "when a card with the Bug label is created, set priority to High". Rules have a dry-run preview, a run log and undo.
• Docs & Files for specs and decisions. Write specs in the doc editor, comment on them, and keep release notes and architecture notes in folders. See document management.
• Pulse for standups. Post a short standup in a thread each morning, or ask Emit, the space AI, to summarise what is in progress from the board. Emit can also write a sprint recap into Docs & Files, after you approve it.

For developers, the Emitii CLI can connect coding agents such as Claude Code, Codex, Cursor and OpenCode to your tasks, docs and timesheet through MCP. It is off by default and switched on per organisation by the Emitii team.

What does the workflow look like?

1. Create a space for the product or project and choose the Project type.
2. Name your columns and agree what each one means, including when a card counts as done.
3. Turn on Docs & Files and add a folder for specs and one for release notes.
4. Fill the backlog with cards, using labels for type (Feature, Bug, Chore) and for the current sprint.
5. Add a recurring event in Schedule for the weekly planning session, and use Pulse threads for daily standups.
6. Set up a few Rules so routine moves happen by themselves.
7. Close the sprint by archiving done cards and posting a recap in Posts.

The software development template has this setup in full. Teams comparing trackers can read Emitii vs Jira, and software companies covers the wider picture.

Bringing non-developers in

Because the board, docs and chat share a space, designers, support staff and managers can follow development without learning a separate tracker. Support can add a bug card with a label, and a designer can comment on a spec directly.