The work behind delivery.

1 / 6 · Operating model

Enterprise strategy to sprint board — and back up again

Five layers, each with its mechanisms and its review. Intent flows down; evidence flows up.

1. Layer 01 · Enterprise strategy
2. Layer 02 · Portfolio
3. Layer 03 · Release train
4. Layer 04 · Team
5. Layer 05 · Release

My planning and review framework; employer-specific processes are generalized.

Layer 01 · Enterprise strategy

Where the product line fits the company's plan, and what it asks for

What happens

• The company sets themes and the metrics it will track; product lines write narratives that connect their work to them.
• The three-year plan sets the arc; the annual operating plan sets the year's goals, headcount and funding.

What I owned

• I wrote planning narratives for applied AI and enterprise integrations.
• I connected product direction with a platform investment and funding case.

Artifacts

• three-year plan
• annual planning narrative
• vision document
• product strategy

Layer 02 · Portfolio

Epics ranked by cost of delay over size — so the fight is about inputs, not rankings

What happens

• Business owners and product score epics on value, time criticality and risk reduction; job size divides them; weighted-shortest-job-first ranks them.
• Enabler work (platform, data, security) is funded explicitly alongside business-value features.

What I owned

• I prioritized across data migration, enrollment, claims and policy capabilities.
• I used risk to compare alert-quality investments instead of ranking solely by message volume.

Artifacts

• epic backlog
• WSJF sheet
• portfolio Kanban
• QBR deck

Layer 03 · Release train

Every team in one room for two days, every quarter

What happens

• Program increment planning: teams draft objectives against the ranked features; dependencies are drawn as strings on the program board; risks are resolved, owned, accepted or mitigated in the room.
• A system demo at the end of every increment shows integrated, working software — not slides.

What I owned

• I led product work across a release train and mapped cross-team migration dependencies.
• I have earned SAFe Product Owner/Product Manager, Agilist and Lean Portfolio Manager credentials and completed DevOps training; current certification is not asserted.

Artifacts

• PI objectives
• program board
• risk board (ROAM)
• release calendar

Layer 04 · Team

Two-week sprints for planned work; Kanban for the work that arrives on its own schedule

What happens

• Sprint planning pulls stories against capacity; no story enters without acceptance criteria; demos to stakeholders every sprint.
• Kanban boards run compliance, support and on-call flow — columns as states, work-in-progress limits, aging visible.

What I owned

• I wrote stories and acceptance criteria, participated in design reviews and made decisions visible in delivery.
• I owned channel-review insights across funnel behavior, onboarding and partner needs.

Artifacts

• sprint backlog
• Kanban board
• demo notes
• WBR

Layer 05 · Release

Deployment and release are different events — the flag is the difference

What happens

• Code deploys behind feature flags; release is a dial the product manager turns after the go/no-go.
• Pilot → pilot → evidence-based expansion, with the launch announcement written against the pre-set criteria.

What I owned

• I brought partner functions and evidence into launch-readiness decisions.
• I connected integration launches with partner review and customer adoption.

Artifacts

• go / no-go record
• dial-up plan
• launch announcement
• MBR

Two kinds of door. One kind of loop.

Reversible decisions get made fast and cheap; irreversible ones get the full gate. And the systems that compound do so because each turn makes the next one easier.

Two-way · Dial-up percentage

Increase exposure only while the evidence supports it

Why this kind of decision. A bounded traffic setting can be changed without rebuilding the product. How I approach it. I connect the change to observed quality and user effort. Safeguard. Define the stopping condition and recovery before expansion.

Two-way · A pilot configuration

Compare a reversible behavior within a bounded pilot

Why this kind of decision. A configuration can be evaluated without committing the entire product to it. How I approach it. I work with operations to understand what changes for users. Safeguard. Both states need explicit expectations; observe exceptions as well as the normal path.

Two-way · Prompt scope

Reduce a broad refactor to a testable increment

Why this kind of decision. A narrow prompt change can be evaluated and reversed independently. How I approach it. I challenged the scope before committing to the broader refactor. Safeguard. Compare evaluation examples before and after; retain a way back.

Two-way · Versioned assistance

Keep the earlier version available for comparison

Why this kind of decision. A versioned artifact separates introducing a change from discarding the previous behavior. How I approach it. I treat reversibility as a product requirement for bounded assistance. Safeguard. Evaluate changes before they affect consequential work.

Two-way · Pilot cohort

Protect time for feedback before expanding

Why this kind of decision. The initial scope can grow as the evidence and operational capacity improve. How I approach it. I favored learning per interaction over maximum initial exposure. Safeguard. Give exceptions an owner and examine them before expanding.

Two-way · An interim pricing measure

Keep an interim response distinct from the long-term design

Why this kind of decision. A bounded interim can be retired when the intended capability is ready. How I approach it. I connected customer impact with the time needed for the permanent change. Safeguard. Document the boundary and the reason to retire it.

One-way · Synchronous versus asynchronous

Responsiveness and freshness belong in the same decision

Why this kind of decision. The interaction model shapes expectations, failure behavior and technical dependencies. How I approach it. I brought alternatives and the professional’s task into the design discussion. Safeguard. Set the responsiveness requirement and test representative conditions.

One-way · The key of a review record

Define what a decision covers before designing the screen

Why this kind of decision. Downstream reporting and interpretation depend on what the record represents. How I approach it. I worked with engineering and specialist partners on the relationship between context and decision. Safeguard. Preserve understandable history when relevant context changes.

One-way · The customer-facing exception

Choose a clear experience for unresolved conditions

Why this kind of decision. An unexplained delay or an irreversible customer action can affect trust. How I approach it. I worked through the disagreement with safety and legal partners. Safeguard. Make the reason, responsibility and next step understandable.

One-way · The interpretation of an obligation

Resolve the meaning before automating the behavior

Why this kind of decision. A product decision may embed an interpretation that is costly to change later. How I approach it. I involved counsel and domain experts before committing to requirements. Safeguard. Keep the product boundary and the evidence for it explicit.

One-way · Shared-data migration sequencing

Prioritize the capabilities that depend on the information

Why this kind of decision. A convenient migration order can disrupt users elsewhere. How I approach it. I challenged the initial sequencing with consumer-dependency evidence. Safeguard. Validate continuity for each affected capability.

One-way · A new service delivery model

Connect authorization, updates and support with the business model

Why this kind of decision. Foundational service choices shape ongoing reliability and operating effort. How I approach it. I worked with engineering leads on the program and its business rationale. Safeguard. Consider transition and connectivity needs alongside the target experience.

Learning that informs the next decision.

The safety flywheel

Every turn makes the next one cheaper. Clean data cuts false alerts; fewer false alerts earn trust; trust speeds acknowledgement; freed capacity lets the check run more often; more checks catch more real events; real events improve the data and the rules.

1. Live, clean data
2. Fewer false alerts
3. Professional trust
4. Capacity freed
5. Better coverage
6. Learning improves the data

Conceptual learning loop; outcomes require measurement.

1 · Live, clean data

I investigate whether information represents the intended clinical context before changing the message it produces.

2 · Fewer false alerts

Tracing a message to its cause can reduce avoidable interruption while preserving useful coverage.

3 · Professional trust

Clearer signals make attention more useful; sentiment and interpretation matter alongside volume.

4 · Capacity freed

Less avoidable work can create capacity, provided the resulting workload is measured rather than assumed.

5 · Better coverage

Capacity and better information can support a more useful review experience, with specialist judgment retained.

6 · Learning improves the data

Exceptions and professional feedback identify the next information-quality question.

The integration flywheel

An integrated account spends more than one that is not. So every platform integrated makes onboarding cheaper, brings more accounts, which brings more spend, which brings more partner investment — which integrates more platforms.

1. More useful integrations
2. Clearer onboarding
3. More active customers
4. Customer value
5. Partner investment
6. A better integrated experience

Conceptual learning loop; outcomes require measurement.

1 · More useful integrations

An integration is valuable when it supports the customer’s purchasing task, not simply when the connection exists.

2 · Clearer onboarding

Self-service guidance and a shared readiness definition can reduce avoidable setup dependency.

3 · More active customers

Adoption measures whether the available capability becomes useful in practice.

4 · Customer value

A useful integrated experience can support continued use; measure that relationship rather than assume it.

5 · Partner investment

Evidence of value supports decisions about catalog, quoting, search and pricing capabilities.

6 · A better integrated experience

Clearer terms, useful responses and dependable adoption make the next customer’s experience easier.

The numbers I run product on

And the analyses that changed a decision — one per industry.

Dimension	Metric	Why this and not something softer
Unit economics	cost to serve / unit	Every initiative is modelled in cents per prescription or per contact before it gets a roadmap slot.
Safety	risk score / failure mode	Lets a noise reduction and a new safety check be compared on one scale.
Quality	automated success · parity %	A new engine matches the old one field-by-field before it sees traffic.
Throughput	transactions / hour / operator	The adoption guardrail — a new <abbr title="user interface">UI</abbr> that slows the operator has failed, however it looks.
Automation	net rate paired with defect rate	An automation rate without its downstream error rate is half a number.
Growth	conversion · <abbr title="ordered product sales">OPS</abbr> / account · glance views	Integration adoption and continued use connect the product experience with customer value.

Industry	What the data said	What changed
Pharmacy	Reviewed context differed from later activity.	Clarified the scope of the review with specialist partners.
Pharmacy	Avoidable alerts reflected information interpretation.	Investigated causes while preserving useful coverage.
B2B	Quoting eligibility and unit representation limited usefulness.	Reconsidered the response path and corrected interpretation.
Payer	Expected and processed claims did not reconcile.	Extended the investigation and made completeness visible.
Shared data	Consumers depended on a proposed platform change.	Revised sequencing using dependency evidence.
Planning	Bottom-up analysis challenged the initial estimate.	Re-scoped before committing the roadmap.

Work across three regions

B2B integrations and internal procurement across three regions; offshore delivery partnerships before that.

North America

US · CA

• Enterprise procurement integrations and pharmacy product work in the United States.
• Internal-procurement expansion and pilot learning involving Canada.

Europe

UK · DE · FR · IT · ES

• Procurement integration, partner onboarding and launch requirements across European markets.
• Regional purchasing and invoicing needs considered alongside common product capabilities.

Asia

IN · JP

• Enterprise procurement and regional invoicing work involving Japan.
• Internal-procurement expansion involving India and experience coordinating distributed delivery partners.
• Product enablement across regions, with local needs connected to a shared direction.

One portfolio review covered all of it. The quarterly business review I authored and presented to executive stakeholders tracked portfolio goals across regions — hosted catalog, automated ordering, partner expansion, Japan e-procurement, Spain business-to-government (B2G), an EU integration program, Japan tax reform and e-invoicing.