PendomoniumX London: An Operating Model for AI Products

If your AI portfolio has plenty of prototypes but little habitual use, the gap is probably not access to better models. It is operating design. A team can ship an impressive assistant and still fail because it chose a weak workflow, buried the feature, measured clicks instead of changed behavior, or treated trust as a post-launch review.

At PendomoniumX London, more than 350 software leaders gathered around AI transformation and product innovation. The useful signal for product leaders was the move from broad enthusiasm to execution: clearer customer problems, measurable adoption, faster learning, and explicit governance. You can turn that signal into an operating model for your own AI roadmap.

Transform a customer workflow, not a feature list

An AI feature generates, summarizes, classifies, recommends, or takes an action. An AI product transformation changes how a person completes a meaningful job. The distinction matters because customers do not adopt model capabilities in isolation. They adopt a faster, easier, or more reliable way to get something done.

Starting with the model usually produces a familiar failure mode: the team finds technically plausible places to insert AI, ships several disconnected experiences, and then struggles to explain why customers should change their behavior. Starting with the workflow forces the team to identify the user, the moment of friction, the desired behavior, and the evidence that would justify further investment.

I would not approve an AI roadmap item until the team can complete this sentence:

For a specific user completing a specific workflow, the product will use AI to remove a named source of effort or uncertainty, leading to an observable behavior change and a defined customer or business outcome, within explicit trust boundaries.

Build the statement in this order:

1. Describe the current workflow. Write the steps a customer takes now, including any handoffs, repeated decisions, manual checks, or places where work is abandoned.
2. Isolate one consequential friction point. Avoid vague problems such as “the workflow is inefficient.” Name the decision, delay, rework, or uncertainty that prevents progress.
3. Define the assistance. State whether AI will draft, recommend, retrieve, classify, predict, or act. These modes create different expectations and require different controls.
4. Name the behavior that should change. Examples include completing a setup step, accepting or editing a recommendation, resolving a case, or returning to use the capability again.
5. Connect the behavior to an outcome. A click is not an outcome. Faster time-to-value, lower abandonment, greater task completion, and sustained use are closer to the value you need to establish.
6. Write the boundary before the prototype. Specify what data the system may use, what the user must verify, when a human remains responsible, and what happens when the system cannot produce an acceptable result.

This framing also gives you a useful way to reduce an overcrowded AI roadmap. Reject ideas that cannot name a recurring workflow, an observable behavior, and a credible path to customer value. A clever demonstration without those elements is an experiment, not yet a product commitment.

Run one evidence loop from discovery through go-to-market

AI work becomes slow when discovery, delivery, analytics, and go-to-market operate as separate projects. Research identifies one problem, engineering explores another, marketing promises a broad capability, and analytics arrives after launch. Each function can appear busy while the product accumulates uncertainty.

The better unit of management is one evidence loop:

1. Discovery identifies the costly moment. Combine customer interviews with behavioral data. Interviews explain the user’s reasoning and workarounds; analytics shows where the behavior occurs, which segments encounter it, and whether the problem is frequent enough to matter.
2. Prioritization exposes the assumptions. Compare bets using problem severity, workflow frequency, data readiness, trust burden, reach, and speed of learning. Do not hide weak evidence behind a single calculated score. Record why each factor received its assessment.
3. Sprint planning targets uncertainty. A prototype should answer a specific question: whether customers want assistance at this moment, whether the available context supports an acceptable output, or whether users understand how to review the result. Building the full workflow before answering the riskiest question creates expensive evidence.
4. Go-to-market explains the changed job. Lead with what the customer can now accomplish. “AI-powered” describes an implementation choice; it does not tell a customer when to use the capability, what input it needs, or what outcome to expect.
5. Post-launch behavior changes the roadmap. Compare actual use with the original baseline and bet statement. Look at starts, completions, acceptance or editing of outputs, abandonment, repeated use, and downstream outcomes. Feed those observations into the next discovery decision.

A lightweight decision log keeps this loop honest. For every AI bet, record the customer problem, riskiest assumption, evidence collected, decision made, owner, and next review condition. The log prevents a prototype from quietly becoming a permanent commitment simply because significant effort has already been spent.

A prototype that misses the mark can still be valuable if it retires uncertainty. If customers do not recognize the problem, stop. If they value the workflow but distrust the output, change the interaction or control model. If the output is useful but discovery is weak, address distribution and onboarding. Those are different diagnoses, so they should not all produce the same response of adding more features.

Make adoption part of the product itself

Launching an AI capability does not teach customers when to trust it, what information to provide, or how it fits into an existing routine. That education is part of the experience, especially when the product asks someone to replace a familiar manual process with a probabilistic system.

Examples at PendomoniumX paired Pendo’s in-app guides and product tours with behavioral analytics to improve activation and reduce friction around important onboarding moments. The transferable lesson is not to add a tour to every AI release. It is to place guidance at the moment of intent and measure whether it helps the customer reach value.

Instrument the adoption path before you publish the guidance:

• Eligible: the right user reaches the relevant workflow and has permission to use the AI capability.
• Exposed: the user can see the entry point or receives contextual guidance.
• Started: the user initiates the AI-assisted action.
• Delivered: the system returns an output or completes the requested action.
• Evaluated: the user accepts, edits, rejects, retries, or reverses the result.
• Completed: the user finishes the larger workflow in which the AI action sits.
• Repeated: the user chooses the capability again when the relevant need returns.

This sequence prevents a common measurement mistake. A guide view shows exposure, not activation. A button click shows curiosity, not value. Even a generated output may not matter if the user discards it or fails to complete the surrounding task. Define activation at the first point where the customer receives meaningful value, then monitor whether that behavior repeats.

Keep the guidance proportional to the decision:

• Use a short contextual prompt when the customer only needs to notice a new action.
• Use a tooltip when the customer needs one local explanation, such as what information the model will use.
• Use a multi-step tour only when the workflow itself spans multiple unfamiliar steps.
• Show an example input when output quality depends heavily on how the request is framed.
• Explain review and fallback behavior next to the action, not in a distant help page.
• Let experienced users dismiss education that no longer helps them.

If traffic and risk permit a controlled experiment, compare eligible guided and unguided cohorts on workflow completion and repeated use. If you cannot create a credible control group, use a documented baseline and staged rollout. In either case, do not claim that guidance caused adoption merely because guide views and feature use rose at the same time.

Make trust boundaries and decision rights explicit

Trust is not a legal checklist appended to an otherwise finished AI experience. It affects what the system may do, what the interface must explain, which events need monitoring, and whether the customer remains in control. Deferring these decisions creates rework because the team may later need to change data flows, permissions, interaction design, or the scope of automation.

For each workflow, answer these questions in language the product team can implement:

• What customer, account, or third-party data may enter the system?
• What context is necessary, and what data should be excluded even if it could improve the output?
• What is retained, for what purpose, and who can access it?
• Which outputs are suggestions, and which can cause an action in the customer’s environment?
• What must the user review or confirm before an action becomes consequential?
• How does the experience communicate uncertainty, missing context, or inability to complete the task?
• What fallback lets the customer continue when the AI path fails?
• Which signals trigger investigation, rollback, or a narrower release?
• Who owns customer feedback, incidents, and changes to the evaluation criteria?

When personal data, sensitive customer information, or regulated decisions are involved, bring privacy, security, and legal reviewers into discovery. The safe alternative to making assumptions is to narrow the data and action scope until the appropriate review is complete.

Governance must be matched by clear decision rights. An empowered product team is not an ungoverned team. It is a team that knows which decisions it can make, the evidence expected, and the boundary at which another owner must participate.

A practical division is to distinguish three layers:

• Team-owned decisions: workflow design, contextual education, experiments within approved boundaries, evaluation cases, and roadmap changes supported by product evidence.
• Cross-functional review: new data access, material changes to retention, model-provider changes, higher-impact automation, and controls that affect security, privacy, support, or compliance.
• Leadership decisions: risk tolerance, strategic investment across portfolios, shared platform choices, and conflicts that cannot be resolved within the product outcome.

Write these rights into the AI bet rather than relying on organizational memory. Also define the conditions for continuing, reworking, pausing, or stopping the work. The exact thresholds should come from your baseline and risk context, but the decisions should exist before launch. Otherwise, encouraging signals will be celebrated while contradictory evidence is explained away.

Key takeaways

• Frame every AI investment around a recurring customer workflow, not a model capability.
• Require a bet statement that connects assistance, behavior change, customer value, and trust boundaries.
• Use one evidence loop across discovery, prioritization, sprint planning, go-to-market, and post-launch learning.
• Measure the full adoption path from eligibility to repeated use; guide views and feature clicks are intermediate signals.
• Treat in-app education as contextual product design, not a substitute for a clear value proposition.
• Set data boundaries, human-review points, fallback behavior, decision rights, and stop conditions before broad release.

In your next planning cycle, choose one live AI initiative and rewrite it as a workflow bet. Add its behavioral baseline, activation event, trust boundary, decision owner, and stop condition. Then instrument the path before expanding the feature set. If the team cannot agree on those elements, the roadmap item is not ready. If it can, AI has started to become a managed product capability rather than a collection of prototypes.

References

• Pendo – Perspectives – Inside PendomoniumX London: AI Transformation, Real-World Wins, and Product Innovation