Problem
Pier had more plausible work than capacity, and limited runway made activity volume less useful than better allocation.
Product management proof
Backlog Management Under Runway Pressure
I managed Pier's backlog by tying work to decision value: product evidence, customer learning, pilot readiness, value-map truth, and commitment confidence.
What I owned
I used ranked assumptions, product evidence requests, kill / continue / double-down decisions, and explicit cut rules to keep work tied to the next real decision.
Result
The backlog reflected the company's actual risk instead of becoming a neutral list of useful tasks.
Internal planning records and founder context have been summarized for public use.
The situation
Pier had more possible work than capacity, and runway was limited. That made backlog management a strategic problem, not an administrative one.
The question was not whether a task was useful. Many tasks were useful. The question was whether the work changed what the team could decide, ship, validate, or trust next.
That is the uncomfortable part of prioritization under pressure: useful work still has to lose when it does not change the next commitment.
The approach
The operating rule I used was simple: better allocation, not more activity. Work had to change a real decision. Did it reduce the most important uncertainty? Did it produce product evidence Brandon could build from? Did it create customer or investor signal David could use? Did it improve pilot readiness, customer learning, value-map truth, or commitment confidence?
If not, it had to move down the list, even if it looked reasonable.
Sometimes direct customer validation mattered more than acquisition infrastructure. Sometimes pilot communication and value-map truth mattered more than broader ideation. Sometimes plausible automation work had to be named as the first cut if the week overloaded.
What I built
- ranked assumptions
- priority product evidence requests
- dated kill / continue / double-down decision points
- sprint cut rules for overloaded weeks
- a backlog habit centered on decision value instead of task volume
Why it matters
In search mode, the backlog is a model of uncertainty. A task is high priority only if it changes the next commitment, customer outcome, product truth, or learning loop.
The point was not to keep the backlog tidy. It was to make the backlog reflect the company’s actual risk.
Result
The team had a clearer way to protect the work that mattered most under runway, customer, product-readiness, and capital pressure.
What I learned
Backlog management is not tidiness. It is deciding which uncertainty deserves the next hour.