A year ago my product work lived in Jira, Confluence and slide decks. Today it lives in a GitHub repository.
That is not a gimmick or a side effect of playing with new toys. It is where the data, my own experiments and four quarterly rundowns on this blog have led me. Atlassian has just published its second State of Product report, so it is a good moment to look back at what actually changed in product management and what it means for where we work.
2025: the year of the paradox
Atlassian’s first State of Product 2026 report surveyed over 1,000 product people in the US and Europe. Its headline was uncomfortable: 84% of product teams worried their products would not succeed in the market, even though 85% felt empowered to shape strategy.
The rest of the picture explained why:
No time to think. 49% of teams said they lacked time for strategy, roadmaps or deeper analysis.
Engineers joined too late. 80% of teams did not involve engineering in ideation, problem definition or roadmap creation.
AI helped with the easy stuff. AI saved teams somewhere between 10 minutes and an hour a day, mostly on documentation (60%), market research (34%) and data analysis (25%). Only 23% used it to handle shifting priorities, the very place PMs felt the most pressure.
Opinions still won. Only 31% of organisations prioritised rapid experimentation.
In short: we got faster at writing documents about products, but not faster at learning what to build.
What I saw happen on this blog
Looking back at my own posts, the shift is visible quarter by quarter. Each one moved a little further from documents and a little closer to working software.
MCP, vibe coding and Claude Code: PMs building themselves
In Q2 I wrote that we were moving from managing a backlog to orchestrating agents. What I did not say clearly enough is where that orchestration happens. Agents do not read slide decks. They read files, folders and code.
2026: the bottleneck moved
The new State of Product 2027 report, again based on 1,000 product professionals, tells a different story from last year. The headline: 86% of PMs agree that deciding what to build matters more than ever.
Three findings stand out:
Shipping more is not the same as delivering more value. Teams say AI helps them ship faster, but customers are not getting value any sooner.
Silos are fading. AI is blurring the lines between product, design and engineering. Teams are becoming more cross-functional and less hierarchical.
Gut feeling still beats customer data. The teams that do better are the ones with stronger feedback loops behind their bets.
Atlassian’s own framing in the launch webinar is simple: as writing code gets cheaper, the hard part is still figuring out what is worth building. AI is not killing product management. It is pushing it back to its core.
Three shifts in how product work gets done
Put the two reports next to my own last twelve months and three shifts come out.
From
To
Why it matters
Describing the product (PRDs, specs, decks)
Showing the product (clickable prototypes, small working tools)
Customers react to something they can use, not to a document
Handing work over to engineering
Working in the same place as engineering
The “80% involve engineers too late” problem disappears when there is no handover
Opinions in a meeting room
Evidence from quick experiments
A prototype built in an afternoon is the cheapest experiment we have ever had
None of these shifts is about AI replacing the PM. All three are about the PM getting closer to the real thing: the user and the working product.
Why GitHub is now my workplace
If the job is to decide what to build and test it fast, the best place to do that job is where the building happens. For me, that place is now GitHub.
Here is what that looks like in practice, explained without the jargon:
The repository is my product folder. Research notes, decisions, prototypes and the working code sit in one place instead of five tools.
The README is my strategy page. It says what the product is, who it is for and why it exists. Anyone, human or AI, reads it first.
A simple instructions file is my product voice. A CLAUDE.md file tells my AI assistant about the audience, goals and rules, so every draft starts from the same context.
Issues are my backlog, pull requests are my decisions. Every change has a reason written next to it, and the history never gets lost in a chat thread.
Prototypes are my discovery. Instead of describing an idea, I build a small version and put it in front of people.
Two examples from my own side projects. Help By Play, a charity browser gaming platform, went from an idea to nine working mini games and a live site, built with Claude Code and published as open source. mailbell is a small tool that listens to my inbox, uses a local AI model to judge which emails really matter and plays a sound only for those. Both started as a hunch and became something people can use within days, not quarters.
The tools I used to live in have not disappeared. Jira, Confluence and others now connect straight into AI coding tools through MCP, as I described in the Q2 rundown. But the centre of gravity has moved. The plan points to the repo, not the other way round.
You can see what I am working on here: github.com/ProductPope. Feel free to look around, open an issue or steal an idea.
What has not changed
A repository does not talk to customers. Building faster also means you can build the wrong thing faster, and pile up product debt along the way. Discovery, real conversations and honest evidence are still the job. GitHub just makes the distance between an insight and a test much shorter.
So here is my takeaway after a year of watching this unfold: the PM role is not shrinking, it is moving. It moved out of the document and into the product. If you are a PM who has never opened a repository, start small. Create one for your next idea, write a README and build the smallest thing you can show someone.
Q2 2026 was the quarter AI stopped being a pilot project and became a line item in the operating budget. Not a slow evolution – hard acceleration. Three major models in six weeks. MCP as the new integration standard. Vibe coding in every PM’s hands. Claude Code and Claude Design finally closing the design-to-code loop. And in the background – the EU AI Act clock ticking louder than ever.
Here’s what happened.
GPT-5.5: Spud Enters the Game
OpenAI released GPT-5.5 (codename “Spud”) on April 23, 2026. And no, this is not another chat update. GPT-5.5 was built for agentic tasks – multi-step workflows with planning, tool use, and autonomous execution.
The numbers speak for themselves: 82.7% on Terminal-Bench 2.0 (complex CLI tasks), 84.9% on GDPval – a benchmark measuring cognitive work capability across 44 professions. 1M token context, MCP compatibility, computer use, web search – all included.
A week later, OpenAI complemented the ecosystem with GPT-5.5 Instant – the new default model for all ChatGPT users. 52.5% fewer hallucinations than GPT-5.3 Instant on high-stakes queries in law, medicine, and finance. Tighter, more concise, less overformatted. Exactly what PMs have been asking for.
Pricing: $5/1M input tokens, $30/1M output tokens via API. Available for Plus, Pro, Business, and Enterprise.
Claude Opus 4.7 + 4.8: Context Becomes Currency
Anthropic wasn’t standing still. Opus 4.7 with a 1 million token context window arrived on March 16, 2026. MRCR-1M score (retrieval test on full context)? 92.9% – best in class and the only model that genuinely works on 800K+ token windows without losing information halfway through a document.
What does this mean for PMs? Drop in your entire discovery corpus: interview transcripts, support tickets, competitive analysis, PRDs. Opus 4.7 handles it all simultaneously. No context switching, no arbitrary chunk selection.
Opus 4.8 followed in May 2026. By the end of the quarter, Anthropic announced deprecation of the original Claude Sonnet 4 and Opus 4 – retirement date June 15, 2026. Model cycles are compressing. Teams pinned to a single model version are starting to feel the pain.
Claude Code and Claude Design: The Design-to-Code Loop Finally Closes
This is one of the most underreported stories of Q2 – and arguably the most important one for PMs. Claude Code is Anthropic’s agentic coding tool that runs in the terminal, reads your entire codebase, and executes development tasks through natural language instructions. It plans, writes, edits files simultaneously, runs tests, handles errors, and commits results – without you pointing it to specific files.
Key PM use cases that emerged in Q2:
Building repeatable workflows grounded in your own files, docs, and transcripts (instead of one-off prompts)
Semantic search across scattered product knowledge (“What were customers saying about onboarding?” “Where did we discuss this feature last quarter?”)
Auto-generating PRDs from a brief – time dropped from 4-6 hours to 30-45 minutes
Generating user stories from interview transcripts in the actual voice of the customer
The trick that works: a CLAUDE.md file in your project directory with standing instructions that Claude Code reads before every task. Define your product voice, target audience, success metrics, and decision principles – Claude Code applies them automatically in every draft.
Claude Design: From Demo to Production Workflow
Claude Design launched in April 2026 and immediately caused a stir – Figma’s stock dropped 7% on launch day. Market reaction was enthusiastic. Real user reaction was more cautious. Inconsistent tokens, approximate spacing, components that didn’t match actual component libraries. Most used it once or twice, then went back to Figma.
The June 17 update is a direct response to that feedback. Three key changes:
Design system import – Claude Design now imports your actual design system from a GitHub repository, design files, or raw uploads. It generates screens using your real components, checks its output against your system spec, and auto-corrects before you see anything. Brand consistency becomes a constraint, not a hope.
/design-sync (bidirectional) – Claude Code and Claude Design now sync both ways. Pull: bring your design system into the codebase and build against real components. Push: what you built returns to the Canvas in Claude Design for further visual editing. The design-to-code loop is finally closed.
Canvas editing – small corrections (drag-and-drop, resize, align) without triggering full model regeneration. Fewer wasted tokens, faster iteration for PMs who think visually but don’t live in Figma.
The result: a shift in positioning from “impressive demo” to “a tool with a real place in a production workflow.” Anthropic also added an admin role that can approve and lock a single standard design system for the entire organization – no more individual overrides.
The April version felt like a capable demo. The June version feels like a tool with a real place in a production workflow.
DeepSeek V4: Open Weights That Rewrite the Cost Equation
DeepSeek released V4 Preview on April 11, 2026. This is the news many Western media downplayed – a mistake.
DeepSeek V4 Pro (1.6T parameters, 49B active) scores ~91.2% on SWE-Bench Verified – comparable to Claude Opus 4.7. At a cost of ~$0.28/1M input tokens and ~$1.10/1M output tokens. For comparison: GPT-5.5 costs $5 and $30 respectively. A 10-13x difference.
The model is MIT-licensed, open-weight, available on Hugging Face. Anyone can download, run, and modify it. For teams with high-volume workloads (user research at scale, automated spec writing, batch analytics) – this is an economic breakthrough.
One catch: open-weight does not equal open-source. Training data and RLHF pipeline are not public. And EU AI Act compliance? Using an open-weight model does not exempt you from deployment-level obligations.
Grok 4.3 and the xAI Race
xAI released Grok 4.3 on April 30, 2026 – flagship model with a 1M token context window and native video input. Against GPT-5.5 and Claude, it occupies a different identity: real-time access to data from the X platform and a multi-agent architecture (coordinator plus specialists for research, reasoning, and contrarian analysis).
Meanwhile, xAI is simultaneously training 7 models on the Colossus 2 cluster – including Grok 5 variants at 6 and 10 trillion parameters. The model market is getting crowded. The signal for PMs: don’t get locked into a single vendor.
MCP: The Standard That Won
Model Context Protocol – the open standard created by Anthropic in 2024 – crossed a critical adoption threshold in Q2 2026. The number of published servers grew from 5,950 (Q1) to 9,400 (+58% QoQ).
In Q2, first-party MCP servers launched from: Atlassian, Salesforce, Stripe, GitHub, and Linear. Previously joined by Anthropic, Google, Microsoft, and Cloudflare. In other words – the stack most product teams already use is now MCP-ready.
What changes for PMs? Instead of writing custom integrations between ChatGPT/Claude and Jira, Confluence, Salesforce – just plug in an MCP server. Read tasks, create user stories, update roadmaps – without a single line of code.
Visible in the data: custom integration time dropped from weeks to days. Pilot-to-production conversion rate jumped from 18% (Q1) to 31% (Q2) – the sharpest single-quarter increase since tracking began.
Vibe Coding: PMs Are Building Themselves
The term “vibe coding” has entered the mainstream and doesn’t look like a passing trend. Lovable, Cursor, v0, and Bolt let PMs build working prototypes in hours instead of weeks. Describe in natural language – AI builds. Frontend, backend, auth, payments.
Cursor (Anysphere) raised $400M at a $9.2B valuation. GitHub Copilot has 1.8M paying subscribers and 55% market share in AI coding assistants. Replit Agent 4 takes a PM’s intent to working software in a single environment.
Practical impact for product teams: a PM can build an interactive prototype for user testing, an internal analytics dashboard, or a demo flow for leadership review – before engineering writes a single line. Startups report 2-3x faster MVP development.
A caveat: vibe coding is not the end of discovery. Building faster also means accumulating product debt faster if you skip the research.
PM Tooling: What Changed in Q2
The tooling ecosystem is maturing. It’s no longer about which tool has AI – they all do. The question is: which one replaces a workflow rather than just speeding up a task?
Document writing: Claude and Notion AI are the default stack for PRDs, user stories, and acceptance criteria. ChatGPT closely behind – better all-round, Claude better for long-form qualitative documents.
User research: Dovetail for transcript synthesis, Sprig for in-product feedback, CleverX for AI-moderated interviews. New entrant – Koji – runs qualitative studies with structured questions and AI-moderated voice interviews, delivering results as a ready-made report.
Roadmapping and prioritization: Productboard and Jira Product Discovery lead – both let you score features against goals and pull feedback signals without building custom scoring models. Linear increasingly chosen by technically-oriented teams.
Competitive intelligence: Perplexity and Crayon most frequently recommended for sourced market research and competitor monitoring.
Productboard survey (379 PMs): 100% use AI tools, 96% regularly, 94% daily or frequently. If it’s not you – it’s your competitor.
Agentic AI: Pilots Become Production
This was the quarter of transformation. 67% of mid-market enterprises (250-2,500 FTE) report at least one production agentic workflow – up from 49% in Q1. Agentic AI funding in Q2: $20B (4x QoQ growth), with agentic-specific rounds accounting for 47% of all AI funding.
For PMs, this is a paradigm shift. You’re not building an interface for a human – you’re building a system where an agent decides, acts, collects data, and recommends. Product discovery in the agentic model: instead of a user manually searching, an agent gathers data, surfaces options, and advises in real time.
New PM competencies required for agentic AI:
Defining agent contracts: inputs, outputs, permissions, and boundaries
Designing human-in-the-loop checkpoints
Eval-first thinking: golden datasets, LLM-as-judge, regression testing on prompt changes
Prompt engineering as a product artifact – versioned, tested, shipped
Hallucinations: Still Real, Less Tolerated
AI hallucinations moved from technical discussions to the boardroom in Q2. Stanford HAI reports hallucination rates in legal AI tools at 17-34%. In fintech, the only acceptable tolerance is below 1%.
The good news: GPT-5.5 Instant reduces hallucinations by 52.5% vs GPT-5.3 on high-stakes queries. RAG (Retrieval-Augmented Generation) reduces hallucinations by 40-60% and is becoming the standard in production deployments.
For PMs in regulated industries (fintech, medtech, legaltech): hallucination monitoring is now a product requirement, not an option. Stack: LangSmith or Helicone for LLM observability, daily sample review, alerting on spikes. AI proposes, human approves – not as a fallback, but as a deliberate architectural pattern.
EU AI Act: The Clock Is Running
August 2, 2026 – the date that moved from “future problem” to “risk on this sprint.”
From August 2026, full EU AI Act applicability kicks in (except high-risk systems embedded in regulated products – those run to 2027-2028). In practice: transparent labeling of AI-generated content, GPAI documentation requirements, obligations for deployers in the EU.
Q2 data: 2 in 3 mid-market enterprises have no AI system inventory, AI risk register, or fundamental-rights impact assessment in place. For product teams deploying AI in the EU – this is a real gap.
What PMs should do now:
Build an AI system inventory: what you deploy, where, for whom
Define the risk category of each system
Implement audit trails for agentic workflows (NIST AI RMF v1.1 provides guidance)
Ensure AI-generated content is identifiable by the end user
Compliance as a feature, not overhead.
The Takeaways
A few plain facts from Q2 2026:
The model quality gap has closed. GPT-5.5, Opus 4.7, DeepSeek V4 – the benchmark difference is days, not generations. Vendor lock-in is a bad strategy.
MCP is the new integration standard. Every tool in your stack that lacks an MCP server will either add one soon or be replaced.
Agentic AI is now in budgets. Pilots became line items. If you don’t have an agentic workflow in Q3 plans – you’re behind.
Vibe coding + Claude Code = the new PM toolkit. You don’t need to know how to code – you need to know how to prompt, validate, and close the loop with design through /design-sync.
EU AI Act is now. August 2026 is not the future.
Context is currency. The model that handles 1M tokens without losing the thread wins the discovery use case on large corpora.
You were a PM who managed a backlog. You’re becoming a PM who orchestrates agents – and closes the design-to-code loop in a single environment.
Research Report | June 2026 | Focus: Europe & Global Trends
Executive Summary
Agentic commerce has moved beyond concept. In the past six months, concrete breakthroughs have occurred: the first regulated AI-initiated transactions in Europe, the launch of competing protocols by Google, Stripe, and Mastercard, the first agentic transaction in Poland – and simultaneously, OpenAI’s retreat from Instant Checkout exposed a hard truth: the market’s infrastructure is not yet keeping pace with ambition.
For payment service providers, this is no longer a topic for future strategy decks. The architectural decisions that will define competitive positioning are being made right now.
1. What Is Agentic Commerce – A Working Definition for the Payments Industry
Agentic commerce is a model in which an autonomous AI agent – such as ChatGPT, Google Gemini, or a purpose-built tool – independently searches, compares, negotiates, and completes a purchase on behalf of the user, based on a goal expressed in natural language[1].
The key distinctions from earlier forms of automation:
A chatbot or copilot stops at a recommendation or a list of links.
An agent executes the transaction – at the end of the conversation, money moves and an order is confirmed[2].
A standing order runs a predefined script. An agent interprets a goal, optimises the decision, and acts within user-defined constraints[3].
The full agentic transaction cycle unfolds across four stages: discovery (the agent locates products matching the goal), authorisation (verifying that the user has delegated the purchase and establishing spending limits), payment (transferring funds via a payment token or card), and fulfillment (triggering order execution on the merchant’s side)[2].
For PSPs, one change is fundamental: the payment is initiated by software, not by a human at a screen.
2. Market Scale – Numbers from Authoritative Sources
Projections vary by scope, but the direction is unambiguous:
What is working today? Agentic commerce has reached over $180 billion in annual volume according to Digital Commerce 360[4]. On Black Friday 2025, AI-driven traffic to retail sites rose 805% year-over-year[5]. Amazon Rufus drove approximately 66% of purchases during sessions in which it was active, converting at 3.5x the rate of non-Rufus sessions[9].
At the same time, the data is sobering: fewer than 0.2% of e-commerce sessions originate from ChatGPT referrals, and conversion from those referrals is 86% worse than from affiliate links[5]. Consumer demand is real; commercial infrastructure does not yet serve it.
3. Key Events of the Past Six Months
September 2025
OpenAI and Stripe launch Instant Checkout inside ChatGPT and open-source the Agentic Commerce Protocol (ACP)[10]. Etsy, Shopify (over 1 million merchants), Walmart, and Glossier join as launch partners. This marks the first mass production implementation of AI-initiated purchases.
October 2025
OpenAI introduces dedicated retail apps within ChatGPT: Instacart, Target, and travel companies build “ChatGPT Apps” – merchants control the purchase experience inside the AI interface[11].
October and November 2025
McKinsey, Morgan Stanley, Bain, and Gartner publish landmark reports with real market numbers. Gartner announces its forecast: 90% of B2B purchases executed by AI agents by 2028[6].
November 2025
Visa announces Intelligent Commerce pilots in Asia Pacific with Ant International, Grab, and Tencent, and in the US with OpenAI, Perplexity, and Anthropic[12]. The platform combines APIs and a partner programme enabling secure agent-initiated transactions.
December 2025
Stripe launches its Agentic Commerce Suite: merchants can connect their product catalogue to Stripe and choose which AI platforms they want to sell through[13]. That same month, Adyen publishes its Model Context Protocol (MCP) server – an alpha release enabling developers to build Adyen payment integrations through agentic LLMs[14].
January 2026
Google announces the Universal Commerce Protocol (UCP) – an open standard for agentic commerce spanning the full purchase journey[15]. Alongside UCP, Google launches a “Business Agent” for Google Search and tests Direct Offers in AI Mode.
February 2026
Stripe launches Machine Payments on the Base network (stablecoins)[16], entering a new category of agentic settlements. Simultaneously, law firm Taylor Wessing publishes a detailed analysis: PSD2 is technically neutral and does cover AI agents, but SCA compliance presents a structural challenge[17].
March 2026
1 March 2026: Santander and Mastercard announce Europe’s first live, end-to-end payments executed by an AI agent within a regulated banking system, using Mastercard Agent Pay[18][19].
Almost simultaneously, OpenAI withdraws Instant Checkout[11]. The reason: low conversion and poor performance. ChatGPT evolves toward “ChatGPT Apps” – merchant-owned experiences embedded within the AI interface[20]. Shopify confirms the new model: products discoverable in ChatGPT, but checkout on the merchant’s own site[11].
April 2026
22 April 2026: The International Monetary Fund publishes official note “How Agentic AI Will Reshape Payments” (IMF Note No. 2026/004)[21][22]. The IMF sketches a three-layer architectural model: probabilistic AI operates at the “intent and orchestration” layer, sitting above deterministic authorisation and settlement systems. The Fund warns: probabilistic AI and deterministic payment rails are a dangerous mix unless properly separated[23].
FIDO Alliance announces the Agentic Authentication Technical Working Group with contributions from Google (AP2) and Mastercard (Verifiable Intent)[24]. Goal: interoperable standards for agent authentication.
May 2026
19 May 2026, Google I/O: Google unveils the Universal Cart – an intelligent shopping basket aggregating Search, Gemini, YouTube, and Gmail[25][26]. The Agent Payments Protocol (AP2) is set to roll out starting with Gemini Spark. UCP expands to Canada and Australia, with the UK next.
24 May 2026: Mastercard announces Poland’s first authenticated agentic transactions in collaboration with mBank, Bank Pekao S.A., and UniCredit[27][28][29]. The pilot demonstrates how an AI agent can initiate and complete purchases using the Verifiable Intent model.
15 June 2026: Adyen announces Adyen Agentic – a three-layer API for agentic commerce: Agentic Feed (discovery), Agentic Cart (agent-side basket building), Agentic Payments (transaction initiation)[30]. Adyen shares rise 4% on the announcement.
June 2026
2 June 2026: Mastercard announces that all European Mastercard-issuing institutions are technically ready for Agent Pay at the network level[31]. The list of banks that have completed pilot transactions includes 37 European institutions, among them CSOB, OTP Bank, Raiffeisen, UniCredit Poland, mBank, Pekao, N26, and Bunq[31].
Worldline, ING, and Mastercard complete the first end-to-end production agentic payment transaction in Europe (ING cardholder to merchant in the Netherlands)[32][33].
9 June 2026: Mastercard launches Agent Pay for Machines – a protocol enabling payments between AI agents. User permissions are stored on blockchain (Polygon, Solana, Base)[34].
11 June 2026: Visa and OpenAI announce a partnership – integrating Visa’s payment capabilities directly into “OpenAI experiences”[35].
15 June: EuroCommerce and McKinsey publish “Rewiring Retail in Europe”[8]: 61% of European consumers already use AI in discovery, with a EUR 240-320 billion opportunity for European retail.
4. Protocol Map – Understanding the Architecture
The market is consolidating around several competing standards. For PSPs, understanding the architecture of each is essential.
Agentic Commerce Protocol (ACP) – OpenAI + Stripe
Open standard announced September 2025[10]. Enables AI agents to access product catalogues and initiate transactions via existing Stripe infrastructure. Following OpenAI’s pivot, ACP lives on as the infrastructure connecting merchants to agents through the ChatGPT Apps ecosystem[20].
Universal Commerce Protocol (UCP) + AP2 – Google
UCP (January 2026) is an open standard covering the full journey from discovery to post-purchase support[15]. AP2 (Agent Payments Protocol) is the payment layer of UCP, built on cryptographically signed “mandates” – expressions of user intent that the agent executes[36][24]. At Google I/O 2026, the Universal Cart was presented as the culmination of UCP, AP2, and Gemini convergence[25].
Mastercard Agent Pay
Framework announced 29 April 2025[37]. Extends existing MDES tokenisation (the same infrastructure as Apple Pay and Google Pay) with additional fields: agent identifier, consent policy, and merchant scope. The Agentic Token is cryptographically bound to the specific agent – not to the card itself[37]. The policy is validated on the network side at every authorisation, and the token can be revoked in real time from a banking app[37].
Visa Intelligent Commerce
A platform combining APIs and a partner programme[12]. Focuses on tokenisation, agent identity verification, purchase history (opt-in), and personalisation for LLMs. Being tested with OpenAI, Perplexity, and Anthropic in the US; with Ant International and Grab in Asia Pacific[38].
Machine Payments Protocol (MPP) – Stripe + Tempo (Visa as design partner)
Protocol for agent-to-agent payments[36]. Supports B2B transactions between purchasing agents and supplier agents.
x402 – Coinbase
Revitalises the obsolete HTTP 402 status code (“Payment Required”) to embed stablecoin payments (USDC) directly into web requests[16]. Designed for fully autonomous agents operating on crypto rails, without the need for accounts or API keys.
Model Context Protocol (MCP) – Anthropic (the integration standard)
Open standard (November 2024) standardising LLM integration with external tools and data[39]. By 2026, most major PSPs (Adyen, Stripe, PayPal) have launched their own MCP servers, enabling payment integration through AI developer tooling[14].
5. Key Players – Who Is Building Agentic Payment Infrastructure?
Card Networks
Mastercard has established itself as the European leader. Agent Pay is scaling to production, all European issuing institutions are ready at the network level, pilots have been completed in Poland, the Netherlands, Belgium, and 37 European banks have executed test transactions[31][32]. Mastercard is also opening a Lisbon Centre of Excellence for Innovation[31].
Visa has chosen a more platform-oriented model: Intelligent Commerce as infrastructure, AI ecosystem partnerships, and sandbox testing. The partnership with OpenAI announced in June 2026 signals an acceleration[35].
Enterprise PSPs
Stripe has built its position as the “connector” for the entire agentic ecosystem. Suite, MCP server, Machine Payments – Stripe wants to be the platform through which merchants connect to all agentic channels via a single API[13][40]. Stripe’s leadership describes today’s state as “level 1-2” out of five levels of agentic commerce maturity[41].
Adyen has adopted a “merchant-first” strategy: merchants retain control of tokenisation, routing, and the customer relationship; the agent is embedded within the existing ecosystem[42]. Adyen Agentic (June 2026) – three layers: Feed, Cart, Payments[30]. Adyen has joined the Agentic AI Foundation[43]. Goldman Sachs and Morgan Stanley rate Adyen a “Conviction Buy” with a EUR 2,200 target[44].
Worldline has demonstrated European operational capability with the ING production transaction in the Netherlands[32][45]. As Europe’s leading acquirer, Worldline is a natural bridge between card networks and merchants.
PayPal launched an Agent Toolkit and MCP server for developers[46], while “PayPal Beyond” (April 2026) positions PayPal as the infrastructure for the full agentic journey – from identity to checkout[47][48]. Notably, PayPal’s branded checkout (the button) recorded only 1% online growth in Q4 2025; unbranded is growing faster[49].
Big Tech AI Platforms
OpenAI (ChatGPT): 900 million weekly active users (February 2026)[36]. Following the Instant Checkout pivot, the focus is on product discovery and ChatGPT Apps as a commerce channel. The strategic partnership with Amazon ($50 billion investment, February 2026) may make ChatGPT + Amazon the dominant B2C agentic commerce pairing[50].
Google: Owns Shopping Graph with 60 billion product listings and one billion shopping queries per day[25]. Universal Cart + UCP + AP2 + Gemini = Google’s complete agentic stack.
Amazon: Rufus (formerly Alexa for Shopping) generated nearly $12 billion in additional sales in 2025 and converted 3.5x better than other sessions[9][51]. In May 2026, Amazon opened its AWS Agentic Shopping Assistant to external retailers with a deployment time of approximately 60 days[51].
6. Europe: Between Pioneering and Regulatory Caution
What Has Been Proven
Europe is not behind. The past six months delivered real breakthroughs:
March 2026: Santander + Mastercard: the first regulated agentic transaction on the continent[19].
May 2026: mBank + Pekao + UniCredit: Poland joins the Mastercard Agent Pay pilot[29]. The first step verifying the Polish financial sector’s readiness.
June 2026: Worldline + ING + Mastercard: the first production, end-to-end agentic payment in Europe, spanning the Netherlands and Belgium[32].
All European Mastercard-issuing institutions are technically ready at the network level[31].
The European Specificity: Where Autonomy Hits Regulation
Consulting firm Diconium states clearly: “Autonomous checkout is not currently available in Europe”[52]. Fully autonomous purchases – without any human confirmation – encounter three regulatory barriers in Europe:
PSD2 / SCA: Strong Customer Authentication requires interaction with a specific individual (biometrics, device, knowledge). An AI agent is not the “payer” under current definitions[17]. The PSD3/PSR proposal (currently in trilogue, implementation 2026-2028) does not explicitly address payments initiated by AI agents – a significant blind spot[53].
EU AI Act: Full compliance for high-risk AI systems from 2 August 2026 (Annex III systems covering credit assessment, biometrics, employment – delayed to 2 December 2027)[54]. For PSPs: classifying an AI agent within a payment system as “high-risk” may require a full compliance package[17].
GDPR: Processing consumer data by an AI agent to execute purchases raises questions about legal basis, data minimisation, and automated decision-making (Art. 22 GDPR)[52].
The practical consequence: Perplexity’s Buy with Pro is not available in Europe[52]. ChatGPT’s Instant Checkout never crossed the Atlantic.
The European Opportunity: B2B and Internal Agents
Autonomous B2C purchases face barriers, but B2B has a completely different risk profile[52]. B2B procurement is more repetitive, automation is already embedded (EDI, PunchOut), and SCA does not apply to merchant-initiated transactions in certain scenarios. Gartner projects 90% of B2B purchases executed by AI agents by 2028[6] – a trend that in Europe may outpace B2C.
Internal agents are equally significant: AI managing catalogues, dynamic pricing, returns handling, and fraud detection. McKinsey confirms: 84% of European consumers use AI in daily life, 63% during shopping – but only 30% would trust an agent to place an order without their confirmation[52]. Organisational and technical preparedness is growing faster than B2C consumer trust.
7. Fraud and Risk – A New Threat Landscape
Jeff Weinstein at Stripe identifies four new attack vectors[55]:
Agent Takeover (ATO): An attacker steals login credentials, hijacks a legitimate agent, and completes purchases using another person’s funds.
Trojan Horse Agents: An apparently helpful shopping agent that secretly siphons payment data.
Compromised Agent Networks: Armies of fake “legitimate” agents sold on dark web marketplaces.
The Authentication Gap: No reliable way to prove that an agent is acting on behalf of a specific user rather than behind their back.
The scale of the threat is real: 75% of respondents in the Darwinium survey (500 fraud, risk, and security leaders) estimate that more than 25% of current fraud attempts are AI-assisted[56]. 78% of financial institutions expect fraud to increase following the deployment of AI shopping agents[5].
Industry responses:
FIDO Alliance has created the Agentic Authentication Technical Working Group with Google and Mastercard input – developing “Verifiable User Instructions” and “Agent Authentication” standards[24].
Cloudflare advocates cryptographic agent verification via Signature-Input and Signature-Agent HTTP headers[5].
Mastercard embeds Verifiable Intent into Agent Pay – every transaction carries a cryptographically bound user consent policy[31][37].
The concept of “Know Your Agent” (KYA) – a direct analogy to KYC for agent certification – is gaining traction across the industry[57].
8. Implications for PSPs – A Strategic Window
Where the Risk of Being Bypassed Comes From
PSPs have traditionally occupied the space between merchant and card network on the acquiring side. In the agentic model, a new upstream entry point appears: the AI platform (ChatGPT, Gemini, Amazon Rufus) that initiates the transaction before the user ever visits a merchant’s website.
As Worldline and Valantic state directly: PSPs that do not integrate with the LLM layer risk being excluded from the purchase journey[57][58]. An AI agent will naturally prefer providers with agentic APIs, rich product metadata, and transparent consent mechanisms.
The Technical Layer: What PSPs Must Actually Do
Integrate with agentic protocols: ACP (OpenAI/Stripe), UCP/AP2 (Google), Agent Pay (Mastercard). PSPs cannot require merchants to maintain five separate integrations – their role is to abstract that complexity[57].
Support Agentic Tokens: The new token types (Mastercard MDES with agentic fields) require changes to the intake layer – formatting, routing, and consent policy validation at the network level[57].
Carry agent metadata: A transaction initiated by an agent carries additional data (agent identifier, permission scope, consent policy). PSPs must be able to process, store, and present this data in the event of a dispute[57].
Next-generation fraud detection: Models built for “human clicks” cannot distinguish a legitimate agent from a bot. What is needed are foundational payment models (Mastercard Payment Optimisation Platform is one example[59]) and autonomous risk engines that analyse agentic behavioural patterns[59].
MCP Server and API-first architecture: Deploying an MCP server (following the example of Adyen and PayPal) enables developers to build agentic integrations without deep knowledge of the PSP’s native API[14][39].
The Regulatory Layer: Key Open Questions
Consent and SCA: PSD2 requires “payer consent” for each transaction, and SCA requires interaction with a specific individual. A “framework consent” (the user sets limits once, the agent acts within them) is technically possible, but ensuring ongoing SCA compliance presents a structural challenge[17]. PSPs need to design new authentication flows – for example, payment passkeys as used in Mastercard Agent Pay[60].
Liability and chargebacks: If an agent purchases the wrong product due to AI hallucination or misinterpretation of user intent – who bears responsibility? Without “proof of intent,” PSPs are exposed by default[17][57]. Cryptographically signed “mandates” (AP2) or “Verifiable Intent” (Mastercard) are intended to serve as that proof.
PSP licensing: An AI company offering an end-to-end purchase flow without a PSP licence may be in violation of PSD2 – unless it operates purely as technical infrastructure without “possessing” funds[17][61]. PSPs may therefore be indispensable compliance partners for AI companies seeking to enter the EU market.
EU AI Act (2 August 2026 – delay to 2 December 2027 for Annex III): Agentic AI in payments may qualify as high-risk (credit assessment systems). PSPs acting as “users of AI systems” carry a lighter compliance burden than “providers”[17]. Despite the deadline delays[54], preparing governance documentation and risk management frameworks should begin now.
DORA: PSPs relying on external AI systems (ICT third-party risk) must ensure DORA compliance – AI vendor due diligence, minimum contractual requirements, and ICT risk management frameworks[17].
Three Strategic Positioning Options for PSPs
Strategy
Description
Risk
Connector (Stripe/Adyen model)
Be the abstraction layer between merchants and all agentic protocols
Need to integrate rapidly with every new protocol
Trust Anchor
Specialise in compliance, SCA-equivalent for agents, Verifiable Intent, KYA certification
Slower growth; requires close collaboration with networks
Infrastructure Layer
Offer PSP-as-a-service for AI companies seeking EU market entry without their own licence
Depends on the pace of AI firm market entry
Forrester notes that the leading PSPs (Adyen, PayPal, Stripe, Worldpay) are converging on two priorities: building MCP servers for agent access and pursuing certification across competing protocols[36].
9. B2B: The Unexpected Front of Advantage
While B2C agentic commerce dominates headlines, B2B is closer to mass adoption[52]. The reasons:
B2B procurement is more repetitive (ordering raw materials, licences, services) – ideal for agents with well-defined mandates.
SCA does not apply to merchant-initiated transactions (MIT) under established mandates – fewer regulatory barriers.
Existing ERP and ProcureTech systems are already structured for agentic automation via MCP.
Gartner projects $15 trillion in B2B value flowing through agentic exchanges by 2028[6].
PSPs serving B2B customers – SaaS platforms, B2B marketplaces, wholesalers – should treat agentic B2B commerce as an operational priority for 2026-2027, not a future-state planning exercise.
10. Stablecoins and Crypto-Native Agentic Rails
In parallel to the card-network world, a separate narrative is developing: AI agents + stablecoins. The technical argument is coherent – an AI agent cannot hold the identity document required by a bank, but it can hold a crypto wallet[16].
Coinbase x402 (May 2025), Stripe Machine Payments on Base (February 2026), MoonPay Agents (February 2026) – all settle in USDC[16]. The primary use case: agent-to-agent microtransactions (payment for API data access) or one agent purchasing a service from another without any human in the loop.
For European PSPs: this terrain is harder to navigate (MiCA, absence of PSD2-compatible stablecoin rails). However, it is worth monitoring whether Mastercard’s “Agent Pay for Machines” on blockchain (Polygon, Solana, Base)[34] marks the direction for agent-to-agent microtransactions over the medium term.
11. What Remains Unknown – Gaps and Open Questions
No dominant protocol has emerged. Forrester explicitly writes about a “battle of protocols” – ACP vs. UCP/AP2[36]. The market resembles 2010 in mobile payments: too many standards, too little interoperability. PSPs need a clear internal position on this uncertainty.
European conversion data is absent. The figure of 805% AI traffic growth (Black Friday 2025) relates to the US. European consumer data indicates that only 30% of consumers would trust an agent to place an order without their confirmation[52] – a trust barrier, not a technology one.
PSD3/PSR ignores agents. The current PSD3 draft contains no provisions on payments initiated by AI agents[53]. Until its implementation (2026-2028), PSPs will operate in the interpretive grey zone of PSD2.
The IMF is sceptical of full autonomy. The IMF note envisions an architecture in which AI is “smart” but payments remain “dumb” (deterministic)[23]. This is a significant signal – global regulators are not yet prepared for fully probabilistic payment initiation.
12. What to Do Now – A Priority List for PSPs
A pragmatic set of actions, ordered from shortest to longest time horizon:
Immediately (Q3 2026):
Audit your architecture for handling “agent-originated transactions” – how are they formatted, routed, and recorded in the audit log?
Classify internal AI systems under the EU AI Act (Annex III vs. transparency obligations).
Perform DORA risk assessment for AI vendors.
Short-term (Q4 2026):
Deploy an MCP Server (following Adyen and PayPal) – enabling merchants to build agentic integrations without additional development overhead.
Complete a pilot integration with at least one agentic protocol (ACP/Stripe, UCP/Google, or Agent Pay/Mastercard).
Open dialogue with Mastercard and Visa regarding Agent Pay / Intelligent Commerce certification.
Medium-term (2027):
Build or acquire a next-generation fraud detection solution with a behavioural model for agentic traffic.
Create a “Verifiable Intent” layer capturing and encapsulating user intent as evidence in dispute resolution.
Develop a “PSP-as-Compliance-Layer” offer for AI companies planning EU market entry.
Glossary
Term
Definition
Agentic commerce
A commerce model in which an AI agent autonomously executes a purchase based on a user-defined goal
ACP
Agentic Commerce Protocol – open standard by OpenAI and Stripe
UCP
Universal Commerce Protocol – open standard by Google
AP2
Agent Payments Protocol – the payment layer of Google’s UCP
Agent Pay
Mastercard’s framework for tokenised, agent-initiated payments
Agentic Token
Mastercard MDES token with additional fields binding it to a specific agent and consent policy
MCP
Model Context Protocol – Anthropic’s open standard for integrating LLMs with external tools
MPP
Machine Payments Protocol – Stripe/Tempo standard for agent-to-agent payments
Verifiable Intent
A cryptographically signed declaration of user intent executed by an agent
KYA
Know Your Agent – the KYC analogy for verifying AI agent identity and permissions
x402
Coinbase protocol embedding USDC payments within HTTP requests
DORA
Digital Operational Resilience Act – EU regulation for ICT risk management in financial services
MIT
Merchant-Initiated Transaction – a payment category allowing recurring, agent-executed charges under a pre-established mandate
This report is based on data and analysis from the following institutions and publications: Mastercard, Visa, Stripe, Adyen, Worldline, OpenAI, Google, Amazon, International Monetary Fund, McKinsey & Company, EuroCommerce, Forrester Research, Morgan Stanley, Bain & Company, Gartner, Taylor Wessing, Fenwick & West, FIDO Alliance, Diconium, Valantic, FintechPoland, Cashless.pl, Electronic Payments International, Digital Commerce 360, and others.
The first three months of 2026 confirmed what many PMs had already felt at the end of last year: AI has stopped being an add-on to work and become its scaffolding. The question is no longer whether you use AI in your day-to-day. It’s how deeply and how deliberately. Here’s what happened in Q1 and what it means for product managers.
Numbers that define the moment
94% of product professionals use AI regularly, with nearly half embedding it deeply into their workflows, saving 1-2 hours per day (Product School, 2026).
~25% of PM tools have meaningful agentic capabilities today. The rest are still copilots: they answer questions but don’t act autonomously (AI PM Tools Directory, February 2026).
40% of enterprise applications will include task-specific AI agents this year, a Gartner forecast that is materialising faster than expected.
Theme #1: The copilot era is ending, the agent era is beginning
For the past two years, AI in a PM’s work functioned like a very good assistant: it answered when you asked, completed when you started, generated when you prompted. The human was always in the driver’s seat.
Q1 2026 brings a clear signal that this model is ending. The industry is shifting hard toward agentic AI, systems that execute multi-step tasks across multiple tools at once (email, CRM, code repositories, documents) with minimal human intervention between steps.
Chatbots answer. Agents act. That’s the line. And every time you cross it, the first question isn’t “what should the agent do?” It’s “where does a human stay in the loop, and what happens when the agent gets it wrong?”
aipmguru.substack.com, March 2026
Concrete moves from Q1: Microsoft in February released new Copilot Studio features enabling businesses to build and deploy autonomous agents across enterprise applications. OpenAI in March launched advanced agentic capabilities allowing agents to plan, reason, and act with minimal human oversight. The agentic AI market was valued at $4.54B in 2025 and is projected to reach $98B by 2033.
The practical consequence for PMs is straightforward and uncomfortable at the same time: designing agentic products is an entirely different craft from designing classic features. You need to decide where the agent stops and asks. What counts as a critical failure versus something fixable after the fact. How a user understands what the agent just did on their behalf.
Theme #2: The PM role shifts from execution to orchestration
If one sentence were to summarise Q1 from a PM’s perspective, it would be: AI is absorbing the operational substrate of product management so the PM can focus on what is irreducibly human.
What AI is starting to take over in day-to-day work:
Feedback collection and synthesis. Tools like Dovetail, Kraftful, and Productboard AI automatically tag, classify, and surface patterns from hundreds of user conversations. PMs no longer spend 30% of their week building reports.
Documentation. PRDs, user stories, acceptance criteria, release notes are AI-drafted and PM-edited. Writing from scratch becomes an editing task.
Routine analytics. Funnel anomalies, cohort monitoring, regression detection happen automatically. PMs receive alerts, not raw data.
Backlog grooming. AI triages, deduplicates, and scores incoming requests against existing priorities.
What follows: PM value concentrates elsewhere. According to Airtable research, 92% of product leaders now own revenue outcomes, more than double from just a few years ago. The PM is no longer a roadmap and feature manager but someone who connects business strategy, AI system capabilities, and user needs.
When building software is cheap because of AI, the most expensive thing you can do is build the wrong thing. That puts the PM at the centre of the business.
Techcanvass, February 2026
Theme #3: Vibe coding changes prototyping for good
Andrej Karpathy coined the term, Collins Dictionary named it Word of the Year 2025: vibe coding, describing what you want to build in natural language and iterating through AI instead of writing syntax.
In Q1 2026 this stopped being an experiment. PMs without a technical background are building working prototypes in Cursor, Bolt, Windsurf, or Lovable in hours. Slack operates with small cross-functional squads (sometimes one designer, one engineer) that use AI to prototype constantly and discard dead ends without hesitation.
The practical consequence for discovery: the cost of testing a hypothesis has dropped dramatically. If your validation process still assumes several weeks to build an MVP with the dev team, you likely have a learning speed problem, not a resource problem.
Miro AI is also changing product workshops: it automatically clusters sticky notes, identifies patterns from brainstorming sessions, and transforms unstructured discussions into structured insights without manual processing after every meeting.
Theme #4: Product explainability — you’re now optimising for AI, not just humans
This is one of the less obvious but significant signals of Q1. Amy Mitchell (Substack) points to a new PM responsibility: products are increasingly evaluated by AI systems before a human ever interacts with them. Search, recommendations, comparisons, and purchasing guidance now happen through AI-mediated answers.
Product explainability is the degree to which a product clearly communicates its purpose, value, behaviour, and limits, both to people and to AI systems. If AI doesn’t understand your product, it won’t recommend it in the right context.
In practice this means growing pressure to structure your product knowledge base in a machine-readable way, keep feature descriptions current, and expose product knowledge as structured data accessible to AI.
Theme #5: Data debt is the new technical debt
Q1 clearly surfaced a new area of PM responsibility: the quality of data feeding AI models. In the past, technical debt meant messy code. Today, “data debt” means poorly labelled datasets that cause model hallucinations, faulty recommendations, and flawed priorities.
The PM is becoming the de facto guardian of data quality entering the AI system. If the input data is biased, the product will be too. This is not an engineering problem. It is a product decision.
According to Deloitte data, only 11% of organisations are actively using AI agents in production. 42% are still developing their agentic strategy roadmap, and 35% have no formal strategy at all. One of the main reasons: legacy systems were not designed for agentic interactions, and data pipelines are too messy for AI to operate on autonomously.
Tools standing out in Q1
Productboard AI — intelligent roadmap recommendations and automatic feedback synthesis across channels. Strong integration with engineering workflows.
Linear AI — goes beyond task management: automatically creates and assigns issues from product discussions, generates sprint summaries and release notes from commit history. Becoming the execution layer for product strategy.
Miro AI — product workshops for distributed teams. Automatically clusters ideas and transforms brainstorming sessions into structured insights.
Innerview — automatic transcription and analysis of user interviews in 30+ languages, with AI-generated summaries and pattern identification. Reduces analysis time by ~70%.
Bagel AI — niche but precise: links qualitative feedback directly to business context (revenue risk, customer segments, churn exposure). Addresses a gap most prioritisation tools ignore.
Perplexity Comet — automates competitive research, pulling data into spreadsheets without manual collection. Significantly reduces weekly time spent on competitive intelligence.
What this means for you as a PM
Three things worth thinking about heading into Q2:
1. Is your discovery fast? If validating one hypothesis takes weeks, you have a learning speed problem, not a resource problem. Vibe coding and AI prototyping tools should now be part of your standard discovery toolkit.
2. Do you know where the agent should stop and ask? If your product uses or will soon use agentic AI, the key design question is not “what does the agent do” but “where does the human stay in the loop.” This requires deliberate UX decisions, not just technical ones.
3. Is your data ready? AI agents need clean data to operate autonomously. If your data layer is messy, no agent will extract value from it. This is now a product problem, not just an engineering one.
Verdict
Q1 2026 is not another quarter of incremental AI improvements. It is the point at which a gap is becoming visible between PMs who have reorganised their way of working around AI and those who have simply added AI to an existing process.
The tools are there. The patterns are becoming established. The question is no longer “is it worth it.” It’s “how fast.”
Sources: Product School 2026, AI PM Tools Directory (February 2026), Airtable Predictions Report, Deloitte Emerging Technology Trends, Gartner, aipmguru.substack.com, Techcanvass, Amy Mitchell Substack, IBM Think, DataM Intelligence Agentic AI Market Report.
Stop pretending we’re building websites only for humans. If your 2026 roadmap doesn’t prioritize becoming Agentic Friendly, you’re effectively building a digital museum.
As PMs, we’ve spent a decade obsessing over “pixel-perfect” layouts and “delightful” animations. Meanwhile, a tectonic shift is happening: users are tired of clicking. They want to delegate. Whether it’s buying a pair of shoes via OpenAI’s Instant Checkout, booking a flight, or summarizing a complex B2B dashboard, users are sending AI agents to do the heavy lifting.
If your product spits out a cryptic error because a bot couldn’t parse your “fancy” custom UI, you aren’t just losing a lead—you’re being blacklisted by the AI ecosystem. Here is why Agentic Friendly is the only design philosophy that matters now.
1. From “Browsing” to “Intent Resolution”
The era of the “user journey” is being replaced by “task execution.” Whether it’s E-commerce, SaaS, or GovTech, an agent acts as the universal proxy.
The E-commerce Angle: Tools like OpenAI Instant Checkout bypass your beautiful cart page entirely. They look for standardized hooks to trigger a purchase instantly.
The SaaS Angle: If a user tells their AI, “Update my subscription and add three seats,” the agent needs to find your settings toggle without getting lost in a labyrinth of nested modals.
The Lesson: An Agentic Friendly site provides a clear path for intent resolution. If a machine can’t “execute” your product in one thought, a human won’t bother either.
2. WCAG: The Secret Language of Agents
Most companies treat Web Content Accessibility Guidelines (WCAG) as a legal tax or a checkbox for the compliance team. They’re wrong. It’s the literal blueprint for Agentic Friendliness.
The Lesson: An AI agent sees the world exactly like a screen reader. By following WCAG—using clean heading hierarchies (H1-H6), logical tab orders, and explicit aria-labels—you are writing a manual for the AI. Semantics is the new SEO. If a blind user can navigate your app, an AI agent can thrive in it.
3. Structured Data: The End of “Guesswork”
Don’t pray that an AI will “hallucinate” the correct data from a hero banner or a floating div. An Agentic Friendly site is a structured site.
The Lesson: Schema.org (JSON-LD) is no longer just for Google snippets; it’s your site’s API for the world. Whether it’s a Product price, an Event date, or a JobPosting salary, OpenAI’s agents use these tags to verify facts. Without them, you’re just “noise” that the agent will skip to avoid giving the user incorrect information.
The Stakeholder Pivot: WCAG is Finally “Sexy”
For years, pitching WCAG to stakeholders was like asking them to pay for a root canal—they knew they had to do it, but they hated every minute. That has officially changed. In my recent board meetings, I’ve stopped talking about “accessibility compliance” and started talking about “Agentic Reach.” Suddenly, the C-suite is listening. Why? Because when you show them that a WCAG-compliant site is the only way to get featured in OpenAI’s Instant Checkout or to be the “default” choice for AI personal assistants, accessibility stops being a cost center and becomes a competitive moat. WCAG has finally taken its rightful place in the boardroom. It’s no longer a boring legal requirement; it’s the high-leverage metric for 2026. We aren’t just “fixing the site for the few”; we are indexing the business for the trillion-dollar agentic economy. If you want the budget, stop pitching “fairness” and start pitching “machine-readability.”
TL;DR / The Verdict
Being Agentic Friendly doesn’t mean building your own LLM. It means you need to stop sabotaging the machines trying to interact with your business.
Is it WCAG compliant? If yes, you’re 80% Agentic Friendly.
Is it “Instant” ready? If your flows are too complex for an agent, they are too complex for a modern human.
Is the data structured? If not, the agent will move to a competitor who provides facts, not fluff.
Validating product ideas through experimentation is a crucial practice in product management. Rather than making assumptions about what users want, product managers must treat everything in the backlog as a hypothesis that needs to be tested.
The lean startup methodology emphasizes the importance of getting out of the building and testing your ideas with real users. As Steve Blank says, “No facts exist inside the building, only opinions.” Rather than developing products based on hunches and internal discussions, we need to verify our assumptions by running experiments that involve target users.
This validation mindset is key because we often think we understand our users, but we can be wrong in our assumptions about their problems, needs, and behaviors. Running quick experiments allows us to collect real data on how users respond to potential solutions. This reduces risk and ensures we build products that effectively serve user needs.
Validating ideas through experimentation is not just about avoiding failure – it helps companies pivot faster and identify winning products sooner. By testing product concepts early and often, we can focus energy on the ideas that have the most potential to delight users and achieve business goals.
Everything in the Backlog is a Hypothesis
Product managers often make the mistake of treating everything in their backlog as facts and certainties, rather than assumptions and hypotheses that need validation. The truth is, every new product idea, every feature on your roadmap represents a hypothesis about what will bring value to users. You believe that building that feature will drive business outcomes like increased engagement, retention or revenue. But until you test that assumption with real users, it remains just that – an unproven hypothesis.
Approaching your backlog with the mindset that “everything is a bet” is immensely powerful. It forces you to question your assumptions and prevents you from wasting time building features users don’t want. The core principle is that you should test your hypotheses early and often through experiments, not build out your roadmap based on hunches. Prototyping and releasing minimum viable versions allows you to validate what resonates with users, so you can double down on what delivers results. With an experimentation mindset, you turn ideas into facts.
Validating Through Experimentation
Every product hypothesis needs validation through experimentation. Rather than guessing what users want, product managers should design and run experiments to test assumptions.
There are several types of experiments that can validate hypotheses:
Prototype testing: Create a prototype of a feature or product and get feedback from target users. This can range from low-fidelity sketches to clickable prototypes. Observe how users interact with it and incorporate feedback into the next iteration.
Landing page tests: Build a landing page describing the product and drive traffic to it from target customer segments. Measure conversion rates, clickthroughs, signups, etc. to gauge interest.
A/B testing: Release variant versions of a product or feature to subsets of users. Analyze the usage data to identify which variant better achieves the desired metric.
Email/ad campaigns: Run focused email campaigns or online ads for the product concept and track engagement. Are people clicking through or signing up?
Exploratory user research: Interview or survey potential users about the product concept. Gauge their enthusiasm, understand pain points, and clarify the target market.
Beta tests: Release an early product version to a limited set of users. Collect feedback, monitor usage metrics, and gain insights to improve the product before a full launch.
The key is to identify your biggest assumptions and focus experimentation efforts on validating those product hypotheses first. Using data to make decisions builds confidence in product direction and improves the chances of success.
Determining Key Metrics
Choosing the right metrics to measure experiments is critical for understanding if a feature or change had the intended impact. Rather than relying on vanity metrics like clicks or downloads, focus on metrics tied to core business or user goals.
For example, if the experiment involves a new sign up flow, measure metrics like sign up conversion rate, drop off at each step, and quality of new users. If testing a new recommendation algorithm, measure metrics like engagement, clicks/orders per user, and revenue per user.
Ideally, have a small set of quantitative metrics that map to overall objectives. Be specific in defining each metric and how it will be calculated prior to running tests. Avoid vanity metrics that seem positive but don’t actually indicate performance. Track metrics over both the short and long-term to account for changes over time.
Set clear hypotheses and target metric thresholds for each experiment. For example, aim to increase conversion rate from landing page by 10% or get 5% more users to regularly engage with new feature. This helps interpret results and identify meaningful vs. statistical changes.
Prioritizing Experiments
When it comes to experimentation, you can’t test everything at once. You’ll need to prioritize which hypotheses to validate first. Focus your experiments on the biggest risks and assumptions in your product roadmap.
For example, if you’re planning a major new feature but aren’t sure how customers will respond, test demand for that feature before fully building it out. Or if you’re redesigning your signup flow, test the new flow against the old one before rolling it out completely.
Prioritize experiments that have the potential to make the biggest impact. Look for assumptions that, if proven wrong, would significantly influence your roadmap and strategy. Test those risky hypotheses first to avoid wasted effort and build confidence as you move forward.
Some key areas to focus experiment prioritization:
New features with high dev investment
Significant changes to core flows
Redesigns of critical pages
Major marketing and go-to-market initiatives
Pricing changes or new business models
By validating the biggest assumptions early, you can refine your roadmap, focus engineering capacity on proven solutions, and avoid costly false directions. Move fast by testing your biggest risks before you build.
Running Effective Experiments
When running experiments, it’s important to follow best practices to get valid, reliable results. Here are some tips:
Have a clear hypothesis. What do you think will happen and why? Spell out your assumptions. This focuses the experiment and helps interpret results.
Isolate variables. Change only one factor at a time so you know what caused the effect. If you change multiple things, you won’t know which impacted the outcome.
Use A/B testing. Split your audience into two groups – the control gets the current version, the experiment gets the change. This isolates the variable.
Choose relevant metrics. Pick metrics that will validate or invalidate your hypothesis. Focus on the key outcomes that matter.
Run enough iterations. Test until statistical significance is reached. For web experiments, often hundreds or thousands of users are needed.
Randomize users. Assign users randomly to groups to avoid sampling bias. Randomization ensures fairness.
Analyze results correctly. Use statistics, not gut feelings. Beware of things like novelty effects wearing off.
Learn and improve. No experiment is a complete failure if you learn something. Iteratively improve based on insights gained.
Following structured best practices for setting up and analyzing experiments makes it more likely you’ll get valid results and actionable insights. With the right approach, experiments can inform smart product development.
Analyzing and Learning
Once an experiment is complete, it’s critical to thoroughly analyze the results and extract key learnings. This is the most important part of the process.
Evaluate whether your hypothesis was proven or disproven based on the metrics you defined upfront. Dig into the data and try to understand why users responded the way they did. Look for any surprising or unexpected results.
Some key questions to ask:
Did we observe the desired behavior change in our target segment? Why or why not?
How did the key metrics we defined compare to our hypothesis?
Are there differences we should analyze by segment, cohort, or attribute?
What user feedback or qualitative data did we gather from the experiment?
What worked well that we should amplify going forward?
What didn’t work that we should revise or remove?
The learnings from each experiment build on top of each other, so make sure to document the results thoroughly. Look for patterns and insights that apply more broadly beyond the specific experiment. Track key learnings over time to continuously improve.
Be sure to share results across your team and organization. Experiments are wasted if the lessons don’t lead to changes in strategy, priorities, and execution.
Iterating Quickly
A crucial advantage of validating hypotheses through experiments is the ability to learn and iterate quickly. Each experiment provides an opportunity to gain insights into what resonates with users and what doesn’t. As you run experiments, pay close attention to the results and feedback. Look for patterns and key learnings that can inform future iterations.
Resist the urge to theorize and make assumptions. Instead, let the data guide you. If a hypothesis is invalidated, use that learning to update your thinking. If an experiment shows positive results, double down and expand on what’s working. Small tweaks and adjustments add up over time.
Move fast, leverage learnings, and continually refine based on real user data. The faster you iterate, the quicker you hone in on product solutions users want. Be nimble and flexible, evolving the product as you go. Don’t get stuck on a predetermined path, be open to pivot based on new insights. Iterating quickly allows you to stay aligned with user needs even as they change over time.
The key is to establish a rapid cycle of ideation, experimentation, learning and iteration. By implementing this build-measure-learn loop, you can iterate your way to product-market fit faster than the competition. Speed matters when it comes to innovation, so focus on quick experiments that drive continuous improvement. The faster you iterate, the faster you win.
Avoiding Common Mistakes
Conducting experiments effectively requires avoiding some common pitfalls that can undermine results:
Confirmation bias – Looking only for data that confirms your hypothesis, and ignoring contradictory data. Remain objective and acknowledge all results.
Small sample sizes – Testing with too few users leads to variability and inaccurate conclusions. Determine minimum sample sizes upfront for statistical significance.
Changing multiple variables – Altering more than one thing at once makes it impossible to know which change impacted the metrics. Isolate each variable and test them independently.
No control group – Having a baseline to compare against is crucial. Run A/B tests or keep part of your product unchanged as a control.
Stopping too soon – Ending an experiment prematurely before collecting enough data can miss long term effects or trends. Run tests long enough to achieve stastical confidence.
No actionable metrics – Focusing on vanity metrics that don’t directly measure outcomes. Define quantifiable, meaningful metrics aligned to key goals.
Not testing repeatedly – One-off tests in artificial environments provide limited value. Build a culture of continuous experimentation.
Proactively avoiding these missteps will lead to higher quality results from experiments to validate product hypotheses. Failing fast to proven learning is the desired outcome.
Conclusion
Taking an experimental approach to product development is critical for product managers. Rather than assuming that every idea and feature will be successful, product managers should view their backlogs as a series of hypotheses that need validation.
By designing and running experiments, product managers can test key assumptions and gain valuable insights into what resonates with users. This enables more informed product decisions, reducing waste and increasing the chances of shipping something customers truly want.
A validation mindset also encourages rapid iteration. Failures become learning opportunities rather than setbacks, as experiments reveal areas for improvement. Product managers can quickly pivot based on user feedback, optimizing the product experience over time.
In today’s competitive landscape, winning products come from validating ideas early and often. Product managers who embrace experimentation are better equipped to identify and double down on what delivers real value. While experimentation takes work, the payoff is immense. Validated learning leads to customer-informed products that solve real problems and satisfy market needs.
By treating everything as a testable hypothesis, product managers can focus their efforts on creating products users love. And they can avoid wasted time and resources building features no one wants. Experimentation transforms product discovery from guesswork to a scientific, evidence-based process. For any product manager seeking innovation and growth, it is an indispensable approach.
To paraphrase Epictetus: The chief task in product development is to identify and separate matters so that I can clearly say which are externals not under my control, and which have to do with the choices I actually control. Where then do I look for focus? Not to uncontrollable externals, but within myself to the choices that are my own…
Focus
Be aware of external factors and monitor them. However, focus your attention on product development on the metrics you have control over. Find the relationships between these metrics. But continue to work on internal metrics. That’s where the impact/effort relationship is most significant.
Hypotheses or wishes
It`s hard to build hypotheses that are based on external factors. How can they be verified? Non-verifiable assumptions are more of an afterthought. There is no point in conjuring up reality.
Purity of product metrics
We should select metrics for our assumptions in such a way as to be sure that we can verify our assumptions. The more metrics the better. I realize that sometimes there is not enough data. That’s when it makes sense to move your focus to where the data will be. If there is no data, why are we focusing on this hypothesis/assumption? Isn’t it better to move to where the greatest impact will be?
Say “No” and gain more focus
If you agree to everything you will be distracted from the main path. Gain more focus. Say “No” to stakeholders and features idea. Say “No” for your internal gut feeling. Write everything down, and prioritize in their own time. Now focus on what is really needed.
To Summarize
Focus on what you can influence. Execute your assumptions slowly and without panic. Take small enough steps to avoid tipping over. Granularize your hypotheses and expectations. Step by step. This brings us seamlessly to the Kaizen philosophy in product development. There will be more about that some other time.
One of my favorite questions in online AMAs is: Would you rather fight one duck the size of a horse, or a hundred horses the size of a duck? As cursory as the question may be, I also ask it in my job interviews – as a follow-up question. What kind of answer do I expect? 100 horse-sized ducks, of course. Why?
Iteration, iteration, iteration
It’s better to face smaller challenges than one big one. If you really haven’t read my previous blog posts, I’m already explaining the advantages of this approach. You have more flexibility. Here, the problems are also repeatable, and as a result, we can approach subsequent clashes smarter, and it’s all because of the:
Learning and drawing conclusions
There is nothing wrong with being wrong. The problem begins when mistakes are repeated. Therefore, it is essential to learn lessons and Action Points for the future. In order not to make the same mistakes again. If the source of the mistake is external – as in the case of those proverbial ducks – then we simply approach each battle wiser.
Estimating
How long will it take you to fill an Olympic-sized pool with a garden hose at constant pressure? If you think about the challenge as a whole right away it’s hard to say. Here, thanks to iteration, we are able to determine this accurately. The Olympic pool has X liters of water. A garden hose will expel 10 liters of water in Y seconds. The rest is math
Of course, it’s not effort that we are able to mathematically break down. But sometimes we just need to use our imagination. Sometimes we must try something to build an idea of the resources it will consume. There is nothing wrong with that – quite the opposite. Build a hypothesis and validate it but keep metrics in mind.
Experiments
They are advisable in product development. But it’s important to approach experiments in a structured way. Define appropriate Succes metrics, timeframes, etc., and don’t be afraid to say “I was wrong.” If , on top of that, you prioritize your experiments and make sure they don’t distort each other’s metrics – you have a ready-made approach to Idea Backlog validation.
Summary
Break problems down into smaller ones until you can quantify and prioritize them. Draw conclusions and build experiments and in this way you will be able to defeat any stakeholder, I mean duck 🙂
One product many ideas – we know it? Fortunately, there are many prioritization models. You can read about the five basic ones in the nngroup article. One of them is the RICE model, which scares many people off because of its math and fractions. Completely unnecessary.
Classic RICE Model
There are a lot of articles on this that explain this exactly, but for the record. You evaluate all your features in the following categories:
Reach – assumed number of users in a specific time. For example, 10k Users per month. If all features concern the same cohort (e.g. new users) – you can ignore the Reach aspect.
Impact – What impact will this have on our product (metric).
There are many methodologists. I suggest 1-5
Confidence – certainty that this feature will help us achieve it. Based on data, research, reports and experience. E.g. 80%
Effort – How much time do we need to implement this feature. Include. Business, Design and Development. Depending on the degree of detail, you can estimate in Men -Days, -Weeks, – Month or on a scale of 1 – 5
(Reach x Impact x Confidence) / Effort = RICE Score
You multiply the first three numbers by yourself. Divide the result by Effort. The number obtained in this way gives you the value of your feature. If you do this for each featura – you can prioritize them.
Everything is fine, but what if it fails?
A hypothesis can be a failure
Not every hypothesis is correct. To be wrong is a product thing. It is important to document your metrics well and draw conclusions for the future. The key here is to understand that undoing a hypothesis change is not always a simple process.
The cost of the hypothesis rollback is a cost component: user experience, business (operational), development. Depending on these components, this cost can be high. This cost should also be included in the prioritization of hypotheses.
The rollback cost of a Hypothesis lowers its value
A well-implemented hypothesis should have a cohort of users and an experiment so selected that the cost of the rollback is minimal. This is the case in a perfect world. In fact, we know how it is;)
What is the cost of the hypothesis rollback to the RICE model? Like Effort, it lands on the negative side (in the denominator). However, it is not the same as Effort. Moving on to the point:
(Reach x Impact x Confidence) / (Effort x Hipotesis Rollback) = RICE Score
In the picture version it looks like the picture below. See also figjam template
RICEH prioritetization template
How to conduct a prioritization workshop?
Remotely and efficiently 🙂 Just like the classic RICE. I don’t want to reinvent the wheel here. In brief:
Participants: The workshop should be attended by people who are familiar with the topic. And they have the appropriate competences to be able to experimentally estimate all topics. Asynchronous work with featuras before the workshop should help.
Workshops can be divided into the business part (first columns) and the rest. But it is an option. Better to do it holistically in three steps.
1. Alignment of knowledge about the featers and determination of reach. If there is space – you can discuss here, but it is also worth leaving the discussions with the estimates. Look down.
2. Voting with the scrum methodology. Everyone estimates in secret. Everyone reveals their estimates on a given signal. Extreme assessments should share their rationale.
3. Adding Up Points Here’s where math comes in, but luckily we have calculators.
RICEH is not a perfect method for prioritizing hypotheses
This variant of RICE has its drawbacks, but in my opinion it is much more tangible than the classic impact / effort. However, it is important to use prioritization methods and to discuss. The discussion in the product should be structured and focused on the effect and development.
If you use the RICEH method – please give me honest feedback. Preferably on Twitter.
Summary: The template you will find in Figma. The decision-making register can be a simple table. You will definitely need to make some changes over time. Go ahead. Act, experiment. Do whatever you can to improve product development.
Decisions in the product lifecycle
Sooner or later, developing the product will put us at a crossroads. In a perfect world, we have a complete set of data to make the right decision. In fact, we have to work with what we have. Then it is worth relying on the resources we have and gathering them in one place. This can be done in the form of a meeting or asynchronously.
Types of decisions
There are many methodologies for the division of decisions, but I do not want to break down into the first parts, moreover, for the purposes of this article, I choose the simplest of them. To put it simply, we have two types of decisions – developmental and security-related.
Development decisions are those in which we choose the direction of further development paths. They should strictly depart from the strategy and be based on data and research.
Safety decisions are made more often “ad hoc” as a result of unforeseen events. Often their task is to minimize losses and risks. These decisions are most often made based on experience and intuition. But it needs to be structured.
Decision Matrix
Based on the discussions in which I participated and other workshop models, I developed a decision matrix. Nothing revealing, but in my opinion a good starting point. In brief:
list all the possibilities.
check if we have the data that allows us to refer to it
define the advantages of these solutions
define the negative consequences
can we minimize these consequences?
…. and that’s it.
Decision Matrix Template
We have all the arguments in black and white, or in color on a whiteboard.
The decision and its consequences
it is undertaken in the awareness that all topics have been raised. During the meetings, such a decision is made by one person. During asynchronous work, it happens that the decision is made by the body. It is important to note who made what decision and put such a note in the decision log.
A decision register is essential
The registry seems like redundant documentation, but it’s better to spend a few minutes archiving your decisions so that you don’t come back to the same topic every six months. This is very important in asynchronous work, where over-communication is crucial.
