Do Programmers Need a Demand Pool? The Key to Being Reliable

Problem

Programmers often rely on memory to capture ad‑hoc requests from leaders, testers, or teammates. Human memory is limited, tasks are uncertain, and the brain cannot store fragmented information long‑term, leading to forgotten work and lack of accountability.

What a Demand Pool Is

A demand pool is an external, structured list of everything you need to do. It is not a specific tool or formal process; it can be a Notion page, an Excel sheet, a memo, a Feishu document, or a simple table. Every request, bug, or improvement must have a clear “landing point”.

Core Fields of a Demand Pool

Demand name : concise description.

Demand type : bug, feature, adjustment, etc.

Priority : high, medium, low.

Delivery date : expected completion.

Status : pending, in progress, completed, etc.

Owner : responsible person.

Notes : additional context.

Three‑Layer Granularity

Demand – answers “why” a task exists.

Task – answers “what” pieces need to be done.

Todo – answers “what exactly I will click next”.

Only when the three layers are aligned does a programmer move from merely “doing” to reporting progress to leadership.

Practical Habits

Daily update : at the end of each day, reconcile completed todos, update task status, and add any new demands.

Weekly review : assess overall demand‑pool progress, identify missing items, and adjust priorities.

Periodic cleanup : remove stale tasks that no longer add value.

Benefits

Improved work efficiency: nothing is forgotten and priorities are visible.

Increased sense of responsibility: clear ownership and visible progress earn trust.

Smoother communication with leaders: concise status updates replace vague explanations.

Implementation Example (Feishu Spreadsheet)

A typical sheet includes the columns:

Demand ID

Demand name

Demand status

Priority

Proposer

Propose time

Demand description

Owner

Planned completion time

Each demand can be split into multiple tasks, and each task can be split into multiple todos. Completing a todo advances its task; completing a task fulfills its demand.

What to Record in a Demand Pool

At least five categories should be captured:

Definite actions (e.g., “modify this interface”).

Possible actions that may be needed later.

High‑priority but non‑urgent items (dangerous if forgotten).

Items awaiting external feedback (product confirmation, test results, leader decision).

Self‑discovered issues that are not yet scheduled.

Why the Three Layers Matter

When only a flat todo list is used, programmers can list many items (e.g., “change interface”, “check logs”) but cannot explain the underlying demand, making progress reporting impossible. Conversely, recording only the demand without breaking it into tasks leaves the work unexecuted. Aligning demand → task → todo ensures every action is traceable to a business need.

Maintenance Routine

Daily : after work, verify completed todos, update task statuses, and add new demands.

Weekly : review the whole demand pool, check that tasks are on schedule, and identify any missing or forgotten items.

Regular cleanup : delete tasks that have become irrelevant to keep the pool manageable.