Problem
Pier had more plausible work than capacity, and limited runway made it essential to choose which work deserved the remaining time and budget.
Product management proof
I managed Pier's backlog by tying work to the next decision: product evidence, customer learning, pilot readiness, an accurate product value map, and confidence in further investment.
Problem
Pier had more plausible work than capacity, and limited runway made it essential to choose which work deserved the remaining time and budget.
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.
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.
I prioritized work that could change the next 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, the accuracy of the product value map, or confidence in the next investment decision?
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 an accurate product value map mattered more than broader ideation. Sometimes plausible automation work had to be named as the first cut if the week overloaded.
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.
I used the backlog to prioritize the company’s most urgent risks.
The team had a clearer way to protect the work that mattered most under runway, customer, product-readiness, and capital pressure.
I learned to prioritize the uncertainty that most needed resolving before we spent another hour.