Work

I turn ambiguous problems into shipped products — across hardware and software, in enterprises and startups, and now in AI-native teams where the product owner's job is changing fast. Here's the point of view, the track record, and a work sample.

01 Point of view

What Does a Product Owner Look Like in the Age of AI?

The four primitives of any AI system are the model, the prompt, the tools — and context. Context is the one primitive shared across every role, and someone has to own it. That's the product owner: not a knowledge holder but a knowledge curator, governing the pool of decisions, constraints, and history the whole team's agents build against. Own the context, own the product.

Read the essay →

02 Case studies

Three proofs of one claim — that owning the context is the job: judgment on an AI product, building the agents myself, and governing a complex decision-context at enterprise scale.

Judgment

Nexartis · Cubicube Build Prompt Analyzer

Problem: Variance in cost of agentic website building tools is a pain point for our target user, creators who are not technical. We needed a way to classify their prompt based on four build tiers (tweak, small, large, complex). Solving this not only made it clearer to the user what they will be charged, but allowed us to have a more accurate cost of goods sold.
Action: I identified this as a piece of critical technology as it impacts customer satisfaction as well as our cost of goods sold, so extra time was spent scoping out this feature. How it will work and how it would integrate into the rest of the build flow. We dedicated several working sessions to the customer journey and several to the technical flow. In order to improve the accuracy of our rubric, I constructed a recursive reinforced learning loop, allowing the LLM to tweak its rubric, comparing test results to the previous best in search of improvements.
Result: The classifier was bundled into the 1.0 release which shipped to production in June of 2026. At release the classifier met our accuracy threshold with a normalized distribution centered on 0 (meaning we were not over or undercharging on average when we miscalculated). The Prompt Analyzer continues to be refined at regular intervals as new data comes in.

Build

Meeting-transcript automation

Problem: Important decisions get made, and action items get assigned, yet without quality meeting notes it's inevitable that people forget them. I needed a tool that took meeting notes, assigning action items to specific individuals, recording decisions and capturing conversations.
Action: I built the AI automation myself. All of my meetings use the following automated workflow: Meetings are recorded and then transcribed locally. From there, a project-manager agent I built reads the transcript and produces structured notes — capturing every decision and assigning each action item to the person who owns it — then updates each attendee's record automatically. The only thing I touch is a quick confirmation that the speaker names mapped correctly; the raw transcript is filed into a searchable store I can pull from later.
Result: With this in place, I walk away from a meeting and the follow-up is already handled — notes written, decisions logged, and each person's action items waiting for them. Nothing falls through the cracks the way it used to, and I get my attention back for the work that actually needs me. I didn't just spec the tooling that made this happen — I built and shipped them.

Scale

Alliant Energy · IBM Maximo deployment

Problem: A large utility was rolling out IBM Maximo — a new enterprise asset-management platform — and needed it embedded into the daily operations of a cross-functional organization split across six sub-teams. The rollout carried real budget exposure and no shortage of competing priorities: every sub-team had its own dependencies, its own risks, and its own definition of "done." Someone had to hold the whole picture.
Action: As the project manager, I owned that context end-to-end. I ran structured risk and issue management in Jira — surfacing dependencies early, escalating them before they became blockers, and driving each to resolution. In every meeting I assigned a named owner to each benefit so accountability never blurred, and I ran team-wide and program-wide retrospectives that kept all six sub-teams aligned to a single source of truth.
Result: The platform landed in routine operations across the whole organization, with materially fewer budget overruns and substantial recurring operational savings to show for it — and by tightening the release cadence we clawed back weeks on a major bundle. It's the same muscle I use today: owning the context so a complex, multi-stakeholder effort moves as one. This was just one enterprise, before the AI era made owning the context a job title.

03 Work sample — an internal product spec

A public sample of an internal PRD I built — the product spec for an OCME tool (a spec-as-database MCP server). It leaves out the security and access-model details, but what's here shows how I frame a problem, hold scope, and write testable acceptance criteria. The full spec is structured on twelve fixed sections — problem, vision, out-of-scope, principles, constraints, goal, criteria, tests, and a decision log.

Problem framing

Specifications written as prose are designed for humans. In the era of agentic engineering, specs need to be written for agents. When a coding agent reads prose, it has no reliable way to know which statement is current and authoritative — so it makes stale pulls (a superseded decision returned as co-equal), wrong-section pulls (the same feature described in several places, blended), and read-time re-derivation (intent re-inferred, and re-misread, on every read).

Scope discipline (anti-scope)

Deliberately not:

A project / issue tracker — it backlinks to execution but never owns tasks or status.
The meeting or authoring tool — it serves only the approved record.
A drafting assistant for new specs — authoring assistance is out of the tool entirely.
A prose doc renderer — the structured record is the source of truth, no prose mirror.
A general knowledge base — it governs functional specs only, not runbooks or notes.

Acceptance criteria authoring

check_functional_spec returns exactly one row — the current version — from the materialized current-spec table.
The returned rule includes the atomic-rule fields: functional_definition, acceptance_criteria, anti_scope.
get_archive returns the prior version rows for that spec, ordered by version / effective_date.
Anti: the read path NEVER returns a superseded version, and never more than one current row for a given spec.

Architectural decision record

Storage: git-authored YAML as the source of truth, a derived read-projection as the serving layer — not the database as primary, not files as the serving layer. Two independent design reviews converged on it; the deciding factor was audit and review, not scale. The projection is a pure function of the approved commit, so the served record can never silently drift from what was reviewed and merged.

Test strategy / definition of done

Check	How	Type
Serve one current row	call on a seeded spec; assert exactly one current row	integration
Atomic-rule fields	assert response carries definition + acceptance + anti-scope	integration
Archive retrieval	spec with ≥2 versions returns prior versions in order	integration
Anti: no stale reads	spec with archived versions returns 0 archived in current path	integration (anti)

04 Credentials

PMP — Project Management Professional (PMI)
Six Sigma Green Belt
BS, Mechanical Engineering — Ohio Northern University
Trust over IP (Linux Foundation) — Human Experience WG co-chair

Building something where this fits? Email me →