PM Hub

I run three to five technology projects at once, at different stages, for different clients, across multiple time zones.

The delivery work itself is not the hard part. The hard part is that the information needed to make decisions is scattered across six or seven systems — Otter and Google Meet, Asana, Confluence, Slack, email — and each of them now has its own AI layer summarising things at you. That should help. Mostly it adds noise. You end up with more outputs to read rather than one picture you can act on.

A commercial constraint agreed on a client call sits in a transcript. The dependency it creates sits in a task tracker. The person who needs to know about it is in a Slack channel. The document that should reflect it was last updated three weeks ago.

Keeping that picture current is a real cost. My estimate before I started building was that somewhere between a quarter and a third of my week went on collation rather than on the judgment the role is actually for — moving a transcript summary into a format that's actually usable, and chasing down what was agreed across three systems before I could write a status anyone could act on. The worse failure is quieter: a risk surfaces in a call or an email, never gets named as a risk, and disappears into the volume of running several projects at once. Nobody tracks it because nobody wrote it down.

That's the problem PM Hub exists to solve. Not "automate project management" — sift what's actually happening across every system, extract the part that matters, put it where it belongs, and start tracking it.

I built it for myself first, deliberately. I'm the user I understand best, I can evaluate output immediately because I know what the right answer looks like, and I have a real workload to test against rather than a synthetic one.

The broader user is a delivery-side project or programme manager running multiple concurrent projects in an organisation with a mature but fragmented toolchain. That profile has three characteristics that matter for the product:

• They don't control their tools. The stack is whatever the organisation and its clients already use. A product that requires a team to move to a new system has already lost.
• Their output is judgment, but their time goes on collation. The valuable thing they do is decide; most of the day is spent assembling the basis for deciding.
• They're accountable for accuracy. A status report that's subtly wrong is worse than no status report. This sets a high bar for what the product is allowed to assert.

That third point is the one that shaped the product most. Almost every constraint further down — what the model is allowed to decide, what gets written without review, what it flags rather than resolves — comes from it.

The temptation with a tool like this is to build the impressive thing — an assistant that does everything. I started instead with the task I could see costing me the most repeated effort: meeting close-out.

Every call generated the same work afterwards. Write up what was said. Pull out what was decided. Work out who owes what. Update the places that need updating. Same shape every time, several times a day, and almost none of it requiring judgment I couldn't specify.

Reasoning:

• It's a bounded problem. One transcript in, a structured set of outputs out.
• It's high frequency. I'm in several client and internal calls a day, so I'd get feedback constantly rather than occasionally.
• Its output is immediately verifiable. I was in the meeting. I know within seconds whether the summary is right.
• It has a clear failure mode I could watch for — inventing an action item nobody agreed to.

What I deliberately left out of the first increment: anything client-facing, and anything that made a commercial judgment. It could write to internal systems only, and only through a review step — nothing went anywhere without me approving it first.

The division between code and AI

The single most important design decision was where the language model is allowed to operate.

Anything that has to be exactly right is deterministic code: fetching data, resolving which project a conversation belongs to, dates, identifiers, API calls, anything that touches another system. The model never handles these, because something right 97% of the time is unusable where the remaining 3% is silently wrong.

The model handles interpretation and synthesis: what was actually agreed in this conversation, what this change implies for the plan, what a person reading it should notice first. These are judgment tasks with no single correct output, which is exactly where a model earns its place.

The test I apply: if I can write the rule, it's code. If the rule would take longer to write than it saves, it's a model.

What it does

Approval gate. Every write to every tool is proposed, never sent silently. Three modes, selectable per task per project: review each change by hand, approve a batch at once, or let it write automatically. This is the feature the rest of the product is built around — the question "what happens when it gets it wrong" has to have an answer before anything is allowed to touch a system other people read.

Tool-agnostic by role. Tools are organised by role — documentation, chat, task board, budget, meetings, calendar, email — each with a pluggable provider, and a role can have more than one live provider. A new tool slots into the workflows that already exist rather than requiring them to be redesigned. This follows directly from the user: delivery managers don't choose their stack, so a product that requires them to move has already lost.

Project context. A standing brief per project that everything else reads from: how this client behaves, what's been tried, what keeps slipping. Written at setup, then kept current by an unattended sweep across every system that carries new information — calls, email, Slack and Teams.

Meeting close-out. Transcript to structured notes to a documentation page to a chat summary to tasks. One trigger, resumable, nothing written twice.

Living documentation maintenance. A daily read of each project's correspondence, proposing updates to the RAID log, Q&A, change requests, scope and tech stack pages, and tickets on the internal board. Everything reviewed before it's written, and nothing auto-published to a client-facing page — a constraint, not a limitation.

Project startup wizard. It uses a brief to create the documentation space, the timeline and kanban boards and the chat channel — or links existing ones — pre-fills the documentation and seeds a delivery checklist. Review level is set per project, as with everything else.

Model routing. Mechanical work — classification, extraction, structured transforms — goes to a fast, cheap model. Judgment calls go to the strong ones. There's no reason to pay for frontier reasoning to pull a date out of a transcript.

Context assembly. The naive approach is to give the model everything. That fails on cost, on accuracy as irrelevant material crowds the window, and eventually on hard limits. Context is assembled per task instead, with rolling summaries holding a project's history in compressed form. A project eight months in doesn't need eight months of raw material to produce today's briefing.

Activity log. A plain-English record of every run. Nothing fails silently, and a recurring problem doesn't arrive as forty identical alerts.

Provider independence. Prompts, routing rules and output schemas sit separately from application logic, so the model provider is configuration rather than something baked in. Partly practical — the landscape moves and I don't want a rewrite when it does. Mostly a product position: any organisation adopting a tool like this has its own view on which provider it trusts, often for procurement or data-residency reasons rather than capability. A tool that assumes one provider is a tool most enterprises can't adopt.

It reads and writes across the systems a delivery team already uses.

What I've deliberately not built

Full autonomy. The product could write without review and would be more impressive for thirty seconds. It would also be unusable by anyone accountable for what it produced.

This is where AI products differ from ordinary software, and it's the part I've spent most time on.

You can't test a synthesis task the way you test a function. There's no single correct summary of a meeting. So the question isn't "does it produce the right output" but "does it produce output I'd be willing to act on, consistently, across the range of cases I actually encounter."

What I do in practice:

A held-out set of real material. Transcripts and project states from work I know well, with my own notes on what the important points were. When I change a prompt or swap a model, I run against these rather than trusting an impression from one good result.

Watching for specific failure modes rather than general quality. The ones that matter for this product are invention (an action item nobody agreed), omission (a commitment that got missed), and false confidence (a hedged discussion reported as a decision). These are more useful to track than a general accuracy score, because they're the failures that change what someone does — a missed commitment isn't caught until it's late, and an invented one sends people off doing work nobody asked for.

Bias toward flagging over deciding. Where the system isn't sure, it says so rather than resolving the ambiguity itself. This makes the output slightly less impressive and considerably more useful.

Roughly ten hours a week. That figure is my own reconstruction — I know what these tasks used to take because I did them manually for years, and I know what they take now.

The more meaningful change is harder to quantify: I notice things earlier. A risk that would previously have surfaced when someone raised it now tends to surface when the signal first appears somewhere in the stack.

This is currently a tool that works for one person who understands its limits. The distance between that and something an organisation could adopt is mostly not technical.

Access and data. A personal tool inherits my permissions. A team tool needs its own identity, scoped access, and an auditable record of what it read. In a regulated environment that's a precondition, not a feature.

Oversight. My evaluation is that I check the output because I know what's right. A team version needs that to be structural rather than personal — clear boundaries on what it asserts without review, and a visible trail from any output back to the source material it drew on.

Accountability. If a status report produced by a tool is wrong and a decision is made on it, someone owns that. Answering it properly is an organisational design question, not a product feature, and it's the question I'd expect any serious adopter to ask first.

Adoption. The hardest part, and the one most AI tooling underestimates. The barrier is at the start: using a tool like this changes how someone operates, and that's a real cost to pay upfront against a benefit they can't yet see. Tools that clear it are the ones that give something back immediately.

So the design works against that barrier rather than around it. It reads from the systems people are already in, so there's nothing to migrate to. The interface is deliberately minimal — clear navigation, no dashboards of metrics nobody asked for — because a tool that adds cognitive load on things that don't matter is just another tab to keep open. The aim is something that behaves like a PM companion from the first week, not another system to feed.