Backlog and Priority
KANO categories plus a scoring rule, instead of whoever shouts loudest.
The point of prioritizing isn't to produce an absolutely correct order—it's to make every cut in line require a reason.
What you'll run into:
- The loudest voice gets built first
- The backlog holds dozens of items, and the longer it grows, the more afraid you are to touch it
- A version ships, and the basics are still missing while the flashy stuff went first
Bucket with KANO first
Five categories—bucket first, then rank. Bucketing answers "should we do it at all"; ranking answers "which one first." The KANO model sorts requirements by the difference having them makes: kano-wiki
| Type | Difference it makes | Example and treatment |
|---|---|---|
| Must-have | Its presence adds nothing; its absence costs you | Payments must be safe, content must not be lost. One gap is an incident—fill them first |
| Performance | The better, the more satisfaction | Live traffic in navigation. Add when resources allow—it's where you compete |
| Delighter | A pleasant surprise; missing one isn't disappointing | Synchronized lyrics in a player. Pick one per release, don't hoard |
| Indifferent | Nobody cares either way | Text-to-speech in a reader. Cut it without hesitation |
| Reverse | Its presence actively annoys | Auto-marking emails as read. Build it and you'll get complaints |
Buckets aren't permanent. Today's delighter becomes tomorrow's must-have—QR payments were a surprise when they arrived; now you can't do without them. So re-bucket the pool regularly.
Then apply the scoring formula
After bucketing, you still have to rank within each bucket. The value of this formula isn't the precise number—it's that it puts every relevant factor on the table.
Priority = value ÷ cost. Value = user value × (company value + strategic fit + leadership will). Company value covers four things: user growth, revenue, cost savings, and new business. User value is the multiplier—if it's zero, the result is zero. Cost = development time + technical risk + policy risk. When one person builds with AI, development time shrinks dramatically and the other two terms don't change at all—so the real cost now is judgment, not implementation.
Writing "leadership will" explicitly into the formula is where this method is honest. It exists; putting it on paper at least lets it be discussed. Hide it and it will cut the line under some other name.
Maintaining the pool
- Every entry needs a source and the original context. Without these two columns, three months later you can't judge whether it should still be done, so it just stays forever.
- When the same item comes up a second time, add a counter. The count says more than a single mention's wording, and it blocks the illusion created by "one person keeps bringing up the same thing."
- Prune regularly; don't let it only grow. Once a month, archive entries nobody has mentioned in three months and that have no data behind them. A backlog's value is that it can be read to the end.
- What you cut, keep a record of. Write down why you cut it at the time. Half a year later when someone revives the same item, you can pull up the previous judgment instead of re-arguing from scratch.
When you're building solo, this table can shrink to five columns: need, source, context, bucket, status. Use whatever tool you like—the point is that every new entry fills these five cells. If it can't be filled, it isn't thought through yet, so don't queue it.
How to verify this ranking works. Three months later, check whether the items that sat at the top are the ones users actually adopted first and complained about first. If the top items go unnoticed while lower ones get pulled forward, your value estimate was off—probably the frequency and pain were miscalibrated, and re-interviewing beats continuing to rank.