Why P0 Requests Are Rare and Used to Jump the Queue

In our organization a true P0 request—an emergency that must be started immediately—should be extremely rare; otherwise the IT or product rhythm collapses.

P0 requests are used to cut in line; most of the time we only have P1 items.

A P0 typically comes from the founder or CEO, and regardless of its correctness it is treated as critical. The CTO and business units execute it after discussion.

Execution.

The author emphasizes that if P0s become frequent, the whole department loses planning discipline. P1 requests represent key projects, and only a few should appear each quarter; many P1s also indicate a lack of roadmap.

If many P1s appear, the company has no planning and reacts ad‑hoc.

The ideal cadence is to tell the IT team the top priorities for the quarter, break them into iterations, and focus the team on a fixed sprint of those projects.

Let the team concentrate on a few fixed‑time sprints for key projects; this is vital.

The author, as the development team lead, monitors the CTO’s pacing and reminds him when necessary, because maintaining team rhythm is his responsibility.

During a job interview the CEO asked how to decide whether to undertake a project and what criteria to use. The author answered by citing a case where he dropped a technical project in favor of a business project that could generate more GMV, which satisfied the CEO.

The CEO added that growth is a primary evaluation dimension. The author later confirmed this insight while running his own side‑media business.

Other judgment dimensions mentioned include boosting brand momentum, improving user experience, and saving money.

Finally, the author asks readers how their companies handle such prioritization and whether they follow a similar approach.