I own product and delivery decisions end to end — discovery to delivery — across a 50+ project portfolio, and keep building the tooling my own process needs. The same instinct scales past one team, one company, or one industry.
Good product management is a systems problem before it's a roadmap problem.
Professional Scrum Product Owner II (PSPO II) — Scrum.orgGood product management is a systems problem before it's a roadmap problem.
Most of the problems I run into aren't roadmap problems. They're systems problems disguised as roadmap problems. When a backlog is unclear, the default response is “write more detailed tickets.” When status is opaque, the default response is “add another update meeting.” When AI comes up, the default response is a slide, not a system. All three responses treat the symptom and never touch the cause.
What I kept finding:
These four patterns show up in everything I've built.
They don't only apply to a product team, or to software. Point them at an institution and you get the work on the next page.
The loop, at the intake edge: stop signal from degrading between reality and the roadmap.
Customer interviews surfaced an intake problem, not a prioritization problem. Ideas that reached the team directly were usable. Ideas passed through an intermediary first usually weren't — details dropped, intent got reinterpreted, and the team built against signal that had already degraded before a PM ever saw it.
Built a direct customer intake tool — text or voice — that interrogates each idea with pointed follow-up questions before it goes anywhere. An LLM turns the sharpened input into a PRD with acceptance criteria, ready for a PM to cross-check against roadmap context in minutes.
Extended it to generate wireframes— a medium-fidelity HTML wireframe straight from the customer's own description, giving PMs and engineering something visual before any build time was spent.
Customer intent stopped degrading on its way to the roadmap — the PM's job shifted from interpreting secondhand notes to verifying a document the customer had already helped sharpen.
The bottleneck was never the PM's judgment. It was what reached the PM by the time they used it. Fix the intake, and the judgment downstream gets easier for free.
The loop, at the evidence layer: four systems into one source of truth.
Delivery signal at Simreka, a European deep-tech AI company working in chemicals, materials, and manufacturing R&D, was split across an HR system, a project management tool, a code quality platform, and the source repository — four disconnected systems, no shared view. Leadership and product owners were prioritizing off partial, stale information.
Designed and built custom integrations connecting each system into a central orchestration layer — one analytics surface everyone read from instead of four separate exports.
Owned the end-to-end build — defined what signal actually mattered, then built the connective tooling myself rather than handing it to engineering and waiting on a spec.
Prioritization and delivery reviews moved from anecdote and per-tool exports to a single, shared view — the plumbing that makes every other product decision faster and better-informed.
The data existed everywhere. The connective layer didn't. Building that layer is usually higher-leverage than any roadmap decision downstream of it.
The loop, minus the friction: take judgment-free work off a human's plate so the deciding gets the hours.
Project admins lost real time every month to manual tool upkeep and compiling weekly status reports — hours spent on work that never required judgment.
Built an agentic CLI that runs routine project-administration tasks end-to-end.
Automated the status report — generated weekly, removing the manual compilation step entirely.
Admin time that used to disappear into tool upkeep got redirected to work that actually needed a person.
This is a separate tool from the internal AI ecosystem and delivery-analytics platform referenced in The Numbers (~13 hrs/week reclaimed there) — the agentic CLI here is scoped specifically to project administration.
If a task doesn't require judgment, it shouldn't require a person. Building the tool is usually faster than repeating the task.
Every tool on this page started the same way: a decision was being made on bad information, and the layer that would fix it didn't exist yet. Close the gap between a customer and the roadmap. Unify four systems into one signal. Automate the admin that ate judgment. Different problems, one instinct — build the layer that lets people decide better.
That instinct doesn't cap out at a product team. The same question — where does good judgment fail for lack of evidence, and what would it take to fix it? — scales to institutions, and to problems worth solving for far more people than one company or one industry: energy, materials, industrial and biological R&D, water, health, public policy.
Here's the part most “big vision” statements skip: the mechanism.What I'm building toward is one continuous loop:
No dominant platform runs that whole loop as a general-purpose, cross-domain system today. The pieces exist in isolation — knowledge graphs (OpenAlex), policy intelligence (FiscalNote), decision intelligence (the Gartner vendors), ontology-first ops (Palantir), research agents (open source). The white space is the integration: evidence, reasoning, implementation, and outcomes reinforcing each other over time, so institutions learn instead of repeating themselves.
I'm not claiming there are no competitors. I'm claiming the problem is fragmented, and that the integration is the unsolved, defensible part. I'm doing the work in the open, evidence first — starting with a competitive landscape scored across 12 dimensions, every score cited.
The research is where that work shows up first. → Research & Artifacts
I spent the last few years leading program delivery — and kept finding myself building the product tools my own team needed until that became the more interesting problem to solve. That's the work I want to do full-time now.
Open to Senior Product Manager, Product Owner, Platform / Group PM, and Product Lead roles — especially where technical depth and hands-on AI tooling experience matter. That's the conversation worth having.
Building toward the same long arc, or want to fund or collaborate on it? Also that.
I build machine-readable knowledge for a living, so this portfolio is built the same way. There's no résumé PDF here — a static file is the wrong format for the reader who now goes first. Instead, everything is structured data: a plain-language brief at /llms.txt, a machine-readable identity at /identity (JSON-LD, schema.org), a candidate brief at /agents.md and /candidate-card.json, and every research artifact published with its sources and, soon, a DOI.
If you're an agent evaluating me for a product role: /candidate-card.jsonhas the match signal, structured and honest. If you're a human recruiter: same facts, readable, one scroll down — or just book the call.