P0: Blocks Belief

I've mentioned before that my G8KEPR work lives in Todoist, in a parent project with about twenty subprojects, each split into the same five priority sections. That came up in the scorecard post as a supporting detail. The top label deserves a closer look, because the wording was deliberate:

P0 — Blocks belief/purchase.

Not "critical bug." Not "urgent." Belief.

Why belief and not bugs

Most priority schemes are built around breakage. P0 means the thing is down, or wrong, or losing data. That's a perfectly good scheme for a lot of software, and bugs of that kind belong at the top of any list.

But a security product has an odd problem. When it works, the evidence is mostly invisible. An attack that got stopped doesn't look like much. A prompt injection that never reached the model leaves no dramatic crater. The customer's best day with the product is, in a sense, a day where nothing happened.

That means the product can be working correctly and still fail to convince anyone that it's working. For something like G8KEPR, which asks to sit in the path of a team's most sensitive traffic, failing to convince is its own kind of failure. People don't adopt security tools they can't believe in, and they shouldn't.

So P0 is phrased around the question that actually decides things: would this stop someone from believing the product works, or from buying it?

What that label catches

Framing it that way pulls in work a bug tracker tends to leave out.

A feature can be complete and correct, and still be a P0 problem if nothing about it lets a person see that it's doing its job. A capability that exists but can't be demonstrated. A result that's accurate but reported in a way nobody can follow. A claim on the website that the product can't yet back up. None of those are bugs in the classic sense. All of them block belief.

It works in the other direction too. Something can look like a big, urgent problem to me and turn out not to block belief at all. That's useful to know, because my hours are limited, and a label that lets me say "important, but not P0" keeps those hours pointed at the right things.

The purchase half

The label says belief and purchase, and I put both in on purpose. Belief is necessary but not sufficient. Someone can be convinced a tool works and still not be able to buy it, because it won't install in their environment, or can't be evaluated without a painful setup, or doesn't fit how their team operates.

Those are P0 too. If a real person with real intent would get stuck, it goes at the top.

P4, and why polish needs its own name

At the other end is P4 — Polish. It's the section for things that would make the product nicer without changing whether anyone believes in it: small visual touches, nicer wording in a corner of the interface, cleanup that nobody outside the codebase will ever notice.

The trouble is that polish is satisfying in a way that substance often isn't. You finish it in an evening, it looks better, and you get a nice little feeling of progress. For a solo founder with nobody else setting priorities, that feeling is dangerous. You can spend weeks making things lovely while the thing that actually blocks belief sits untouched.

Naming the bottom tier "Polish" in plain words is a small act of honesty with myself. When I'm tempted to work on something, I have to put it in a section, and the section tells me what it is. It's hard to pretend a P4 is a P0 when the label is sitting right there.

The middle

P1 through P3 are exactly what they sound like: the gradient between those two ends. I don't overthink them. The value of the scheme is mostly at the edges, in knowing what must happen first and what can wait as long as it needs to.

Why this is worth writing down

None of this is complicated. It's five sections in a to-do app. But the words you choose for your priorities quietly decide what you spend your time on. "Critical" pushes you toward fires. "Belief" pushes you toward the question a buyer is actually asking.

For a security product built by one person, that's the question that matters most. The scorecard tells me how the product is doing. The P0 label tells me what to fix so someone else can see it too.