Reflection · Transformation
Looking back: what Client Product Success taught me about Forward-Deployed Product
Customer-facing teams and Product organizations saw different parts of the same customer problem. Recurring demand could be resolved case by case without becoming a clear Product, process, or ownership decision.
The cases below show how the work changed my point of view and how I apply it now.
What I did
The work behind the question.
At J.P. Morgan Payments, I translated a senior vision into Client Product Success: a working customer-to-Product model with shared intake, prioritization, immediate resolution, slower pattern learning, governance, and explicit roles across independently managed functions.
How my view changed
The shift in my thinking.
The model improved visibility and coordination, and it operated for approximately two years. It also exposed a structural limit: a shared process can make the work legible without giving one leader authority over every roadmap, resource, commitment, or incentive required for the end-to-end outcome.
Cases behind the view
Work that shaped or complicated my thinking.
Changed
J.P. Morgan Payments body of work
Client Journey, Product-to-market work, CPS, and GTM Digital Transformation progressively exposed the same outcome system from different seams—and the limit of coordination without sufficient authority.
See the workSupports
Wells Fargo Innovation Group
Virtual Assistant Product and Experience work and an R&D operating mechanism showed how emerging technology, human experience, organizational process, and receiving-team ownership interact inside enterprise innovation.
See the workSupports
Flishworks
Current work connects Product, workflow, human authority, measurement, acquisition, and reuse questions inside one operating business.
See the workLeadership lesson
What I carried forward.
I learned to distinguish orchestration from ownership. Durable outcome accountability needs sufficient decision rights and a mechanism that can stay with the customer problem through execution—not only coordinate the handoffs around it.
My point of view
AI transformation redesigns the outcome-producing and learning system of the business; it is not the distribution of AI tools across inherited functions.
I now recognize Forward-Deployed Product as one modern structural response to a similar problem when customer novelty, deployment work, and Product learning need closer integrated ownership. CPS was not historically FDPM, and I did not hold an FDPM title; the comparison is explicitly retrospective.
Most customer and business outcomes cross Product, Experience, Marketing, GTM, operations, policy, data, and organizational authority. A function can improve its own step while the end-to-end system remains fragmented, expensive, or unowned.
AI increases the leverage of that fragmentation. It can interpret, generate, route, and act across boundaries, but it can also automate a broken handoff, optimize the wrong objective, or make accountability harder to see. The leadership problem is therefore to redesign the work, context, authority, economics, and learning around a meaningful outcome.
- 01
Begin with the outcome-producing system
Map the customer outcome, actors, work, handoffs, tools, policy, context, costs, failures, and ownership before selecting AI interventions.
Leadership implication
The intervention can be bounded, but its success standard cannot stop at local activity or tool adoption. - 02
Redesign work and authority together
Decide what should disappear, remain deterministic, stay human, be augmented, or be delegated—and who remains answerable when the system acts.
Leadership implication
Human review is only meaningful when the person has evidence, competence, time, and real authority. - 03
Make production evidence change the system
Deployment should reveal exceptions, customer behavior, operating friction, economics, and reusable patterns that alter the next Product or organizational decision.
Leadership implication
A dashboard is observation. A learning loop has an owner, a decision, an action, and retained capability.
In practice now
How I am applying the point of view.
Can one real operating business make the system legible?
Flishworks is being used to keep Product behavior, human review, offer architecture, instrumentation, acquisition work, and learning decisions in one view.
Current state
Current experiment — implementation exists; customer, quality, and economic outcomes are not yet established here.
When does repetition become reusable capability?
Foundry asks whether a capability can improve a second Product rather than merely look reusable inside one build.
Current state
Emerging hypothesis — a second measured reuse case is required.
Questions in practice
What I’m still working through.
- What minimum authority must an end-to-end outcome owner hold inside a matrix?
- Which context should travel across functions, and which must remain bounded by permission, relevance, or risk?
- When should a transformation remain a legitimate service rather than become a Product or platform?