How I run product: one deliverable, everything else parked
Every internal AI tool gets one committed deliverable. Everything else is parked with a reason to come back to it, so no idea is lost and none of them block delivery.
committed deliverable per project
tiers every piece of scope falls into
issues per milestone, each one demoable
days without progress before a milestone is flagged
Shape priority, don’t set it
The portfolio owner decides what matters and in what order. My job is to turn that into the smallest set of requirements that gets the job done, and to keep the record honest the whole way through.
Three tiers, in order
Every piece of scope falls into exactly one tier. A higher tier is finished before a lower one comes in.
| Tier | The test | When it gets built |
|---|---|---|
| 1. Functionality | Does the app do the job end to end, correctly? | By default |
| 2. Efficiency | Does it make existing steps cheaper, with less time or fewer steps? | Only when the portfolio owner pulls it in |
| 3. Automation | Does it take a person out of the loop? | Only when the portfolio owner pulls it in |
When it’s close between two and three: efficiency makes a step cheaper, automation removes a person. Cheap isn’t a reason to automate.
Park it, with a trigger
Good ideas show up mid-project all the time. They don’t get deleted, and they don’t sneak into scope. Each one goes on a parked list with its tier and a concrete condition for coming back to it. Nothing is lost, and nothing blocks delivery.
Every piece of work traces up
Company priority, then portfolio outcome, then milestone, then the work. If something can’t trace up, it isn’t committed, and I flag the gap. Milestones are demoable slices of three to seven issues, named for what’s true for the user when they’re done, not for the system they touch.
What done means
- Shipped. Committed and pushed, with the commit or pull request linked.
- Real input. Run at least once against real data, not mocks.
- Looked at. Any screen that changed, someone actually opened.
- Demoable. A milestone closes only when every issue under it is closed and the slice works end to end.
Catching drift early
I run a health check whenever a project syncs, and across a whole portfolio on request.
- Stalled milestone. No progress in 10 days gets flagged. At 15, it’s escalated.
- Orphan work. An issue that doesn’t belong to a milestone.
- Bloat. More than seven issues in one milestone.
- Sideways progress. Small tasks closing for two weeks while nothing real ships.
- Phantom completion. A milestone marked done with open issues under it.
- Blocked pile-up. Two or more items stuck on the same thing. The blocker becomes its own issue, with an owner.
Cutting scope is never silent, either. Anything that comes out gets a dated note saying why.
What agents build, and what they don’t
Agents help with low-risk app and UI work, and I verify everything they produce. Anything touching secrets, credentials, sign-in, production infrastructure or security I write by hand. That line doesn’t move.
Lean updates
A status update says what changed, what’s blocked and what’s needed, with a name next to each. I log one even on a quiet day: “No material change since Monday.” If it isn’t written down, it didn’t happen.