The Work That Lives Between Projects

Sprint planning ends. The canvas looks clean. Every card has a status, an owner, a due date. You know exactly what the team is building this cycle.

Then the Slack message arrives. A customer wants a specific export format. A sales rep needs a configuration option by end of month. Someone files a bug that isn’t quite critical enough to halt the sprint but too important to ignore. Your head of ops has “just one small thing.”

None of this fits on the canvas. The canvas is for planned work. This is something else.

Two kinds of work

Every product team operates with two distinct streams of work.

The first is planned work: features on your roadmap, projects with names and owners and milestones. This is the work that gets canvases, specs, and kickoff meetings.

The second is reactive work: inbound requests, opportunistic fixes, internal asks, customer feedback that doesn’t quite fit any existing project. This work tends to accumulate in Slack threads, support queues, email chains, and sticky notes on monitors. It exists, but it doesn’t live anywhere.

Teams typically handle this by picking a spot — a board, a Notion page, a dedicated channel — and parking everything there. The problem is that parking lot lives completely separately from planned work. You end up with two views of what the team is doing, and neither is complete.

The cost of the split

When reactive work lives in a different system, it creates a coherence problem. You can see what’s planned. You can see the inbound queue. You cannot easily see what the team is actually responsible for in total — which things are urgent, which are waiting, whether anyone is overloaded.

This matters most when you’re prioritising. A feature might look like the obvious next thing on the roadmap, but if you’re also carrying fifteen open tasks across three customer escalations and a broken internal tool, the picture changes. You need to see everything before you can make a reasonable call about anything.

Standalone tasks are not a workaround

A task that isn’t attached to a project isn’t a second-class citizen. It’s a task. Some work genuinely doesn’t belong to a project — it’s too small, too early, or deliberately cross-cutting. Forcing it into a project just to have somewhere to put it creates fake structure that obscures more than it clarifies.

The right model is to let a task exist on its own until it’s clear what to do with it. Log the customer request, assign it, give it a due date. Then, if it grows into something that belongs on the canvas, attach it to a project. The task carries its history — comments, votes, status changes — into its new home.

Filtering as a weekly discipline

A cross-project task list becomes useful when you treat it as a weekly ritual, not a reference document.

Filter for everything assigned to you: that’s your personal picture of the week. Filter for everything overdue across all projects: that’s your escalation review. Filter by space to give a team lead their slice of the work without touching anyone else’s view. Filter by tag to see all customer-reported issues, or all items flagged for a specific release.

The filter state lives in the URL. Share it with a stakeholder and they see the same slice you’re seeing. No dashboard to build, no extra permission to configure.

Voting as a prioritisation signal

Most teams already have a way to collect requests. What they lack is a way to rank them without a meeting.

When a task is upvotable, team members can signal what matters without lobbying for it in a thread. Sort the list by votes and you have a rough-cut priority order that reflects collective preference — not whoever was loudest in the last retro.

This works inside the team. It also works externally.

The public side of task management

An organisation’s public profile can expose a Tasks tab. Visitors see the same list — title, status, tags, vote count — and the signal flows in the other direction: people who care about your product can upvote tasks without signing up.

This turns a routine list of open work into a lightweight feedback mechanism. The vote distribution tells you things that surveys and interviews can miss: what people care about enough to actually click a button for.

It also closes a loop that most roadmap pages leave open. “Here’s what we’re building” is one-way communication. “Here’s what we’re tracking, and here’s how much each thing is wanted” is a conversation.

One place for all of it

The value of a cross-project task view isn’t that it replaces the canvas. The canvas stays — it’s still the best way to see planned work and the relationships between things. The task list sits alongside it, giving you a filterable, sortable picture of everything else.

Planned work and reactive work in one place, with a shared vocabulary — status, assignee, due date, tags — so you can filter across both without switching contexts.

The work that shows up uninvited doesn’t disappear because you put it somewhere tidy. But it does become something you can actually manage.