Product Operations consulting, installed in the tools you already run.

I map the recurring workflows that carry your planning, status, reporting and coordination, with the people who run them, and cost each one on your real numbers: hours, frequency, loaded labor, error and risk.

Then I ask seven questions of each workflow: should it exist, can it be eliminated, can it be simplified, who should own it, what needs human judgment, what can be automated, and what fixing it is worth after a year of building and maintaining it.

Alongside that, I review the AI tools you already own: what each one can see, what the team uses, and where each one helps the workflow or slows it down. Any AI output I recommend keeping has to pass the same check as my own agents: a person confirms anything it infers.

• The costed map of your recurring workflows
• A ranked fix list, with the reasoning written down so you can disagree with it or hand it to someone else
• A verdict on each AI tool: keep, reconfigure, retire, or add
• The implementation spec. Give it to me, or to anyone.
• The recommended next step: the Sprint or the Build

• Building the fix. The audit ends at the spec; the Sprint builds the prototype and the Build installs it.
• Buying or licensing tools on your behalf
• Changes to your systems. I work with read-only access during the audit.

End of week one: the costed map of your recurring workflows. End of week two: the ranked fix list, the tooling verdict and the spec, walked through with you in one session.

Before the session I read the planning artifacts you already have and talk with the leader sponsoring it. In the room, your leaders work through the areas that decide how product work runs: planning and portfolio, OKRs and prioritization, capacity, launch readiness, executive reporting, dependencies and decision rights, and the Product and Engineering cadence.

Each area gets a rating, a named problem and a first move. The session closes on the ranked roadmap and who owns each item.

• A prep call with the sponsoring leader
• The facilitated half-day session
• The written roadmap, with owners, after the session
• A recommendation for the first workflow to take into the audit or the Sprint

• Carrying out the roadmap. The Build and Embedded Consulting do that work.
• Training for the wider team

Half-day, in person in New York or remote. Up to 12 people. It works best with the product, engineering and operations leaders who own the decisions.

I read the current OKR set against the company strategy and score each objective and key result for outcome focus and measurability. I trace how goals travel from leadership to team boards.

Then I map the planning cycle itself: who sets the goals, when they are reviewed, where the data comes from, and where the process stalls.

• The scored OKR set, with suggested rewrites
• A map of the planning cycle, with the fixes ranked
• A cadence recommendation for check-ins and reviews
• A readout session with the leaders who own planning

• Running your next planning cycle. Embedded Consulting covers that.
• Moving your goals to a new tool

Week one: the goals scored and the planning cycle mapped. Week two: the rewrites, the ranked fixes and the readout.

On day one, the owner of the workflow and I agree the one measure that proves the fix works. I build inside the stack you already run (Jira or Linear, Confluence or Notion, Slack, your spreadsheets), with AI doing the repetitive part and a person owning every decision.

Every agent I build runs guarded. My first one hallucinated a project status: green, when nobody had said green. Now missing information stays missing, and every inferred field is stamped needs_human_confirm and flagged before a decision-maker sees it. AI drafts. A human owns the truth.

• A working prototype in your environment, running on your data
• The needs_human_confirm guardrail on every inferred field
• A before and after measure on the one workflow, where the data allows
• A go or no-go for the Build, with the build spec

• Production rollout, training and adoption. Those belong to the Build.
• More than one workflow per Sprint

Week one: the prototype running on real data. Week two: your team using it, the measure taken, and the go or no-go.

The fix is often a redesign first: a workflow with fewer steps, a dashboard leadership opens, a planning cadence with clear decision rights. Automation and AI agents take the repetitive part.

Every automation ships with its manual fallback, the simplified flow from the redesign, so the team can run the work by hand if the automation stops.

• The training session for the people who will run it
• The runbook, written so the next hire can operate it without me
• The needs_human_confirm guardrail on every inferred field, flagged before a decision-maker sees it
• Thirty days of adjustments after handover, while the team settles into it
• If your team is not using the workflow every week 30 days after handover, I keep working on it at no charge until they are. Two conditions: I get the access I ask for, and the people who will run it come to the training.

• New software products or platforms
• Tool licenses
• Support after the 30 days of adjustments

Four to eight weeks, set by the spec. One workflow across two systems sits at the short end. A redesigned cadence with reporting across several teams sits at the long end.

• Redesigning the product operating model: planning, portfolio, OKRs, capacity, launch readiness, executive reporting, dependencies and decision rights
• Embedding AI into how your teams run, where it earns its place, with guardrails
• Interim Product Operations leadership while you hire the permanent role

• A scoped plan for each month, with the measures agreed up front
• Weekly working sessions with the leadership sponsor
• Everything built along the way (runbooks, dashboards, automations), handed over as it ships
• A handover plan for the permanent owner

• Unlimited development or open-ended support. Scope is agreed each month.

Three months minimum, reviewed monthly against the measures agreed at the start.