Heuristic Planning Systems

pono“I set”

Practical programme management, built for teams where AI does the building.

AI-driven development moves the constraint. Implementation stops being the bottleneck, and two things take its place: deciding what is actually worth building next, and proving that what was built works. pono is a delivery platform organised around those two problems rather than around ticket hygiene.

What changes when agents do the work

Most delivery tools assume the expensive part is writing the code. Once that stops being true, the process has to be rebuilt around what is still scarce: judgement about priority, and proof of completion.

Prioritise by economics, not volume

When a team can produce ten times the output, choosing the wrong work costs ten times as much. Work is ranked by cost of delay over effort, scored relative to the rest of the backlog, so the answer to "what next" is a calculation you can show a steering committee rather than a preference you have to defend.

Agents are actors, not tooling

Agents plan, pick up, update and close work through the same API and the same rules as people. A delivery process that only humans can participate in quietly forces the AI work to happen off the record, which is where governance goes to die.

Nothing is done without evidence

Completion criteria are written before the work starts, and closing one requires posting what changed, how it was verified, and the commit it landed in. When output is cheap, a claim of completion is worth exactly as much as the evidence attached to it.

Portfolio depth, not a task list

Organisation, programme, release train, project, and the work beneath, with roll-up, so an epic reports what its children actually did rather than what someone estimated at the start.

Six ways to look at the same work

A portfolio question and a standup question are not the same question, and neither is served well by forcing both through one screen. The hierarchy runs organisation, programme, release train, project, and the work beneath it, and each view reads that hierarchy at a different altitude.

Dashboard

Portfolio health at a glance, with the items that have slipped surfaced rather than buried.

Board

Kanban by status, for the people doing the work this week.

List

A filterable, sortable table for when you need to interrogate rather than browse.

Gantt

Timeline and sequencing, for the conversations that are about dates.

Priorities

The backlog ranked by economic value, which is the view that decides what happens next.

Portfolio

Epics rolled up across projects, reporting what their children actually did.

Prioritisation as arithmetic

Work is ranked by weighted shortest job first: cost of delay divided by the effort to deliver it:

WSJF = (Business Value + Time Criticality + Risk Reduction) ÷ Job Size

Inputs are scored relative to the rest of the backlog rather than in the abstract, and job size rolls up from the estimates on the actual work rather than being asserted at the top. The output is often uncomfortable: small unblocking decisions outrank large flagship features, which is the point. That discomfort is the information.

Work is not finished because someone says it is finished.

When output is cheap, a claim of completion is worth exactly the evidence attached to it.

We build on it

pono runs our own delivery, including the build of the other two platforms: planned, prioritised and closed under the same evidence rules described above, by the same mix of people and agents.

That is not a marketing line about eating our own cooking. It is the reason the evidence requirement exists at all: it was written because an agent will otherwise mark work complete on the strength of having attempted it.

Why we build

When anything can be built quickly, building the wrong thing simply costs more, faster. The scarce judgement is no longer how to do the work. It is whether the work was worth doing, and whether it was truly done.

Priority you can show. Completion you can evidence.