Monetization and post-sales intelligence, owned by one person.

Customer health and renewal risk

Operational health per cluster as a customer-facing deliverable, then two models: account-level renewal risk, and per-opportunity renewal risk. Two granularities on purpose, because opportunities inside one account differ by business unit, budget, product, and partner. An account can look healthy while one renewal is at risk, and a CSM has to act on the opportunity, not the average.

• Fuses structured telemetry with unstructured human judgment: account executive, solution engineer, and CSM free-text notes modeled alongside usage and support signals.
• Champion count and seniority as a modeled feature. Certified-professional presence as a leading indicator of whether a customer can absorb what they are renewing.
• Channel partner health trend folded into customer risk.
• Churn-risk and cross-sell propensity at 73% accuracy, embedded in live renewal workflows rather than in reporting, so risk surfaces as an action.

Identity resolution, at three levels

Weighted field-level survivorship for account merges, deterministic and probabilistic contact matching, third-party enrichment, and continuous runtime resolution between batch merge cycles, so every consumer works from one resolved entity the source systems could not produce on their own. The approach became the reference pattern for the enterprise customer, contact, and product master.

• Roughly 1,500 duplicate account clusters were diagnosed not as a hygiene failure but as an unmet product requirement: business units needed entitlement isolation and were creating duplicate accounts to get it.
• Shipped support-portal multi-tenancy, which removed the reason the duplicates were being created.
• Resolution does not stop at the account. Entitlement records what a customer bought. Telemetry reports from the clusters actually running. The two are joined on cluster identity, which is what makes activation and consumption computable per customer rather than per contract.
• Three resolutions have to hold at once for a single activation number to mean anything: the account (who this customer is, across every source system), the cluster (which deployment a license is running on), and the product configuration model (which meter and license metric a telemetry signal maps to). Any one of them wrong and the number is wrong in a way nobody can see.

Three stakeholders, and a different job with each

• Product managers. I defend the definition to them, during data modeling and design review. They know their own product's telemetry better than anyone and will find the case where the rule does not fit.
• Customer experience managers. I defend it to them after rollout, where the test is not whether the metric is theoretically correct but whether it is usable in front of a customer.
• Corporate strategy. Here I advise rather than defend. And when corporate challenges a definition, I bring in the product manager who already approved it to make the case, instead of making it myself.

That last move is what makes a definition durable. A metric defended by the person who owns the product survives. A metric defended only by the person who built the pipeline is one reorganization away from being redefined.

A number is not a signal until you know why it moved

• Every metric is tracked year over year and quarter over quarter. When an account moves, the report says whether it moved because usage changed or because the customer bought more. A ratio can improve for reasons nobody should be congratulated for, and it can fall for reasons worth celebrating.
• Reported by license age: under six months, six to twelve, twelve to eighteen, and beyond. A license bought last month and one bought two years ago are not the same adoption question, and averaging them hides both.
• Reported by renewal year cohort, grouping licenses by the year they expire. This shows how one expiry cohort is performing against earlier and later ones, and it tells customer success where to spend attention first: the licenses coming up for renewal soonest, where there is still time to change the outcome.
• Campaigns and customer engagements report against before-and-after product usage and license activation, closing the loop between intervention and result.

The product configuration model

The canonical mapping of families, bundles, products, SKUs, license types, and meters, in a four-level hierarchy of product, tier, capability, feature, with marketing and CPQ decoupled from it, version ranges, and underlicensed-mode grace periods. It is what makes activation, consumption, and adoption measurable at all, and it gates how fast a new product can be quoted, provisioned, metered, and supported. The four-level rollup behind the adoption metrics is only possible because I owned it.

Four things it has to get right, and where most implementations fall down:

• Aggregation is a commercial decision, not a technical one. Every usage metric carries its own aggregation function (sum, maximum, average, 95th percentile, count) and every license metric carries its measurement basis (peak, monthly average, cumulative, high watermark). The same telemetry stream rated on peak rather than average is a different invoice, so these belong in a reviewed model, not buried in a rating job where nobody can see them.
• Enforcement has gradations. A feature can be licensed, compliance-checked, or hard-blocked at runtime, with a grace period in days and a fallback minimum tier when a customer is underlicensed. Blocking every unlicensed call is the naive design, and it converts a commercial conversation into an outage.
• Telemetry arrives at two levels, feature and platform, and platform metrics carry the scope they were measured at: account, cluster, node, or virtual machine. Both paths join to the same license metric, which is what makes usage ratable against entitlement rather than merely reportable.
• It tracks usage that is not billable. Whether a feature emits telemetry is a separate property from whether it is licensed, so usage is collected for capabilities nobody is charged for. That is what makes adoption measurable rather than only consumption, and it is why the same model serves the rating engine and the four adoption metrics.

The product configuration management system

The application I built on top of the model. Product managers define their product's configuration there and put it through review by the other stakeholders in the product lifecycle process, with named owners and governance roles recorded against each product, so a configuration becomes an approved artifact rather than a spreadsheet someone maintains.

• It manages the full lifecycle of a configuration: adding, updating, and removing features, and recording the version from which a feature belongs to a tier and the version at which it was retired from that tier or from the product entirely.
• That version awareness is what keeps entitlement correct over time. Two customers on the same tier and different releases do not have the same feature set, and a system that cannot express this will quietly measure the wrong thing.
• Every entity is audited and nothing is hard-deleted. Each record carries who changed it and when, and retirement is a soft delete rather than a removal. When entitlement data settles a billing dispute or feeds a compensation plan, the question is never only what the configuration says now, it is what it said last quarter and who changed it.
• Populated as part of New Product Introduction, where I hold the licensing seat for every product launch and every pricing model launch.

Licensing Reimagined

The portal had always applied earliest-expiring licenses first, which is correct if you are managing license inventory. But customers buy hardware and software together, and when they add capacity it arrives with matching software capacity. Their mental model is that the licenses bought with a machine live with that machine. At renewal, once previously purchased licenses were co-termed, customers could not tell which hardware was running which license.

• The portal now prioritizes the licenses purchased alongside the hardware they run on.
• Collapsed 5 to 6 annual renewal events per customer to 2 or 3 across the customer base, along with the approval cycles each carried.

Partner data entitlement

Attributed license capacity to the selling reseller through order lineage: licenses map to sales orders, orders carry the reseller ID, and quotes, orders, and licenses all live in the data lake. The hard part is that multiple partners' licenses frequently sit on the same customer hardware. A 1,000-core cluster might carry 500 cores from one reseller, 300 from another, 200 from a third.

• Each reseller sees only their own licensed capacity, but sees the full cluster's utilization, so they understand their influence on performance without seeing another partner's entitlement.
• Replaced a manual internal reporting process that carried real risk of unintentionally leaking another partner's data.

Virtual CSM

An agentic solution that executes customer lifecycle and adoption workflows with no human in the loop. Phase 1 launched to roughly 3,000 accounts, driven by a success plan co-authored by an AI agent, the customer success manager, and the customer.

• Grew out of the digital engagement motion I designed and shipped for every account below the threshold for a dedicated CSM, which supplemented lifecycle-triggered workflows with signal-triggered workflows drawing on governed platform data.

Entitlement-aware guidance in product

Extended the in-product AI agent platform from the management console onto the licensing and support portals, connecting entitlement and usage data to contextual guidance so the agent surfaces unactivated licenses and under-used entitled features at the point of work. Activation strategy becomes an in-product motion rather than only an outbound campaign.

Document Center

Every customer-facing deliverable is authored with AI, version-controlled, and retained: dossiers, success plans, renewal progress checks, health reports, and custom statements of work, including the deliverables of the 170-person paid services organization. Human and AI collaborative authoring, deliberately not unattended generation.

• The part that matters: the repository is re-ingested. A CSM updates a success plan year over year as the customer's own business plans change, and that accumulated unstructured history lets the AI answer with real historical context rather than a snapshot.
• Deliverables become the memory of the relationship instead of files in a folder.

Success plan generation

Runs a supervisory agent that decides when to pull installed-base data through MCP and when to call a search-grounded frontier model for external data, and then resolves conflicts between the two sources. Conflict resolution is the part most teams handle late and badly.

Service recommendation agent

When an account executive creates an opportunity, they attach the services relevant to what is being purchased. What existed before was a thin one-to-many product-to-service mapping; what actually happened in practice was that AEs consulted service sales managers and solution architects. This automates that consultation.

• The retrieval corpus is the services catalog, the opportunity record, operational constraints, and past intake forms containing the questions the experts habitually ask. The questions the experts habitually ask are the decision logic.
• Budget is the clearest decision parameter: if the customer can fund professional services, recommend those; if they cannot, recommend a workshop service that teaches their own IT team to set the product up.
• The services eventually selected are ingested back in, closing the loop.

Statement of work generation

Triggered when the catalog does not contain what the customer needs, or the default offering is impractical: the standard offering covers five clusters to production in a month, and the customer wants a hundred in three.

• Generative for language, deterministic for numbers. The model writes the statement of work; a region-specific calculator supplied by the services team computes human resource and travel needs. Never let a language model produce a figure that becomes a commercial commitment.
• Generated documents land in Document Center, versioned, so each custom scope becomes context the system can draw on later.

Typed ontology over emergent schema

I evaluated and rejected emergent-schema GraphRAG in favour of a typed Neo4j ontology with schema-guided extraction. The reasoning is a quality-control argument rather than a modelling preference.

• With an emergent schema, a wrong extraction just becomes another node and looks entirely reasonable. Nothing in the system can tell you it is wrong.
• With a fixed schema, a wrong extraction fails against the type and you can see it. The schema is the first line of defence, not a constraint on expressiveness.
• Extracted values are validated before they are written: dates must match a known format or are dropped rather than stored malformed, and unrecognized categories are stored as OTHER alongside the original raw value rather than silently discarded.
• Free-text fields use a denylist rather than an allowlist, which preserves specific real signal instead of flattening it into a generic bucket.

Provenance, conflict, and time

• Provenance on every fact. Each node and relationship links back to the document and text chunk it came from, with the extracting model and timestamp recorded, so every answer is citable and every extraction is auditable.
• Conflict tracking over silent resolution. When two sources disagree, both claims are kept with their own provenance and raised for review. Silently picking a winner destroys the only evidence that there was a question.
• Temporal versioning, not overwrites. Facts are merged on a composite key that includes the as-of date, so re-ingestion accumulates a genuine time series rather than overwriting the latest value. Trend questions become answerable with no separate versioning layer.
• Idempotent re-ingestion. Already-fetched URLs are skipped, so a re-run pays only for what is genuinely new.

Intent routing, and the context graph

A question is classified into one of 17 intents, the company name is resolved against the names actually in the graph rather than trusted as typed, and the intent dispatches to a scoped Cypher template. A second call turns the retrieved facts into prose with inline citations.

• Inference runs on a context graph, not on the whole knowledge graph. The knowledge graph is the record: everything extracted, kept. The context graph is the slice a given question is permitted to reason over, and it is narrower on purpose. A catalog question traverses only the nodes a vendor's own product listings and datasheets put there. A product named in a press release stays in the graph with its provenance intact; it is simply not eligible to answer "what does this vendor sell".
• So provenance is not only there to cite an answer. It decides which facts are allowed to form one. Source authority is enforced twice: at ingestion, deciding what may create a product, and again at retrieval, deciding what may describe one.
• If no facts are found, the system short-circuits to a plain "nothing found" without calling the model at all. Handing an empty context to a language model and asking it to answer is how a retrieval system learns to invent things.
• Every backend implements the same contract, question in and a standardized context, citations and trace bundle out, so retrieval strategies can be swapped and compared without touching the interface.

Use the model for language, use code for structure

A pricing table already contains its own answer in its shape: the column headings are the tiers, the row labels are the features, and a mark in a cell means that tier includes that feature. That grid is walked with plain code and every mark recorded. No model sees it.

• The model was tried first. On a table of five tiers and forty rows it reliably got the first column right and drifted after that, filling the remaining tiers with generic description rather than what the page said.
• Counting marks in a grid is not a reasoning task. Anything a page states structurally is taken structurally, and the model is asked only for the things that are genuinely language.
• This is the same rule as generative for language, deterministic for numbers on the licensing side. Every time I have broken it, in either system, I have paid for it.

Two different questions, kept apart

Extraction quality gets measured, not asserted. The harness separates two things most projects conflate: is the graph structurally valid, and is the extraction correct. The first needs no labelled data and runs after every ingestion; the second needs an answer key and runs before and after every prompt or model change.

• Structural checks are Cypher queries that must return zero rows, and every check exists because that bug actually happened, with the docstring recording which and when.
• Three severities kept deliberately separate: error fails the run, warning flags a probable problem with legitimate exceptions, and smell is worth a glance but never fails. Mixing "look at this" in with "this is broken" is how teams learn to ignore their own checks.
• Ground truth comes from the human-verified lock state: locking an item you have checked is the entire labelling workflow, and when extraction disagrees with the golden record, extraction is wrong until a human consciously decides the source page changed.
• Precision and recall are always read together. Precision catches invention, recall catches drops, and a run that invents nothing while finding half the catalog scores perfectly on one and terribly on the other. Reporting either alone is how a system gets graded on the failure it does not have.
• The honest caveat: the eval set scored perfectly the day it was written, because the graph had just been corrected by hand into exactly that state. That proves nothing yet. It starts earning its keep on the next ingestion, when the numbers move and something broken surfaces without anyone spotting it by eye.

Stack and working method

Built solo and AI-native end to end, with Claude Code as the primary development agent. Open-weight models run locally on an RTX 5090 through vLLM, alongside frontier APIs, behind a provider-agnostic adapter so extraction, generation, embeddings, and evaluation judging can each move between local and cloud without touching call sites.

• Neo4j for the typed graph, Postgres for evaluation golden records and run history, Docker for the model serving stack, FastAPI and vanilla JavaScript for the interface. Acquisition runs Playwright and trafilatura first, then Firecrawl, then Gemini with Google Search grounding as the last resort.
• Config as data. Source toggles, model provider selection, backend selection, and schema definitions live in a versioned config store surfaced through an admin portal, so they change without a redeploy.
• Shared ingestion, pluggable indexing. Fetching and chunking happen once and several indexers consume the same store, so a later comparison between retrieval architectures is not confounded by different chunking. The planned benchmark measures the typed graph against a vector-only baseline and an unconstrained GraphRAG baseline on the same source material, with a stratified golden question set and blind grading.
• Started with off-the-shelf orchestration tooling and moved off it within a week once the abstraction cost exceeded what it saved.
• Self-funded and self-directed, on my own hardware, in evenings and weekends. A product leader who has not built with these tools is guessing at what they cost, where they break, and how long they actually take. I would rather know, and the only reliable way to know is to ship something with them.

Externally sold products and analyst recognition

Principal Product Manager at HPE Software and Micro Focus, owning strategy and roadmap for four externally sold products spanning IT process automation, robotic process automation, and DevOps release orchestration.

• Led Hybrid Cloud Management to a top-5 critical capabilities score in the 2018 Gartner Magic Quadrant for Application Release Orchestration, in its first year of nomination.
• Strong Performer in The Forrester Wave: Continuous Delivery and Release Automation, 2018.
• Represented the products externally with analysts, partners, and customers, and partnered with go-to-market teams on launch and enablement.

Chief Architect, HP Software

• HP OpenView Self-Healing Services, 2005. Product-embedded automated support. A client inside the customer's environment detected faults, collected diagnostic state at the moment of failure, transmitted it for central analysis against known solutions and patch status, and returned the resolution to the customer. Case deflection through automated diagnosis, two decades before the tooling caught up with the idea.
• Service-oriented redesign of the support ecosystem: a four-layer architecture of capabilities, services, processes, and views that decoupled support business processes from underlying IT capability, including the first taxonomies defined for the support domain.
• Supportability Platform: unified licensing, self-healing, and patch distribution on shared infrastructure, surfacing extended license revenue opportunities from support telemetry.
• Identity access management: SAML, OAuth, OpenID Connect, WS-Security.