On Wednesday 11 March 2026 I spent the evening at The Future of Product #3 in Amsterdam, a meetup hosted by Linear, miyagami, Miro and Orq.ai (all four logos were on the “Hosted by” line of the slides). The room had whitewashed brick walls, a projector on a low table and an audience split between sofas, chairs and standing room at the back. The theme across the talks was how AI changes the way products get built, from discovery all the way to evaluation.
Miro: “Everybody is a builder”
The first slides of the evening were a “More AI Playbooks” slide with a QR code for the audience to scan, followed by a Miro-branded slide reading “Everybody is a builder.” over a photo of a busy hackathon room.
“Everybody is a builder.”, to a room with people standing at the back.
miyagami: rebuilding the product development lifecycle
The miyagami talk, filed under “Future of PDLC”, was the most structured of the evening. It started with “The evolution of the Product Development Lifecycle”: three rows labelled Waterfall, Agile and AI (APD™), plotted as value over time, with a “Leap-of-faith” marker on the chart.
Waterfall, Agile and the AI-enabled APD, plotted as value over time.
It then went back to basics with “Three lenses of innovation”: Viability (Discovery), Desirability (Design) and Feasibility (Delivery), with innovation’s sweet spot where the three overlap. The next slide, “The Product Triad”, matched each lens to a role: Product Manager for viability, Strategic Designer for desirability and Software Architect for feasibility.
Viability, desirability and feasibility: the sweet spot is where they overlap.
Under the heading “Revamping our Product Development Lifecycle”, the core idea was “The AI enabled APD Cycle”. Sprint 1 is Discovery, Sprint 2 is Design and Sprints 3 to 6 are Delivery, all around a central hub labelled “Agents & MCPs”, with Miro, Figma and Linear logos on the cycle. The text on the slide explained the reasoning: most PDLC cycles suffer from context decay during handovers between Discovery, Design and Delivery. Their model uses a central Agent & MCP hub to keep a persistent state across the stack. Instead of experts syncing documentation by hand, MCP servers give the agents real-time access to the project’s evolving canvas, so design decisions stay grounded in discovery data and delivery stays aligned with the original intent, even when that intent changes.
The AI-enabled APD cycle: Discovery, Design and Delivery around a shared Agents & MCPs hub.
The talk closed with “We are a global technology partner, ready to help you scale faster.”
My take: “context decay during handovers” is the most accurate description I’ve heard of why product teams lose time. Using MCP as the shared memory between the discovery board, the design file and the issue tracker is a sensible use of the protocol. The hard part will be deciding who owns that shared state when the agents and the humans disagree.
Intake, Plan, Build, Review
Another talk was built around a simple four-step flow: 01. Intake, 02. Plan, 03. Build, 04. Review. One of its slides, “01. Intake [Before]”, showed a screenshot of the intake step before the change.
Intake, Plan, Build, Review: one workflow, step by step.
Orq.ai: an iterative SDLC for AI features
The last talk I photographed was “Iterative SDLC for AI Features” by Sohrab Hosseini, Co-founder at Orq.ai, with “The Future of Product #3” in the corner of the title slide.
Sohrab Hosseini’s title slide, with the four hosts listed at the bottom left.
A “Key insight” slide described Orq as three core pillars in a loop: Build → Evaluate → Observe. Then came “Single Agent vs Multi Agent…”. The slide after it gave the result in one sentence: “Both tested on gpt 5.2 and multi agent is 2.5x more expensive and worse given our evaluator.” A later slide added: “Do not forget to test your evals too.”
Single agent against multi-agent, measured with the same evaluator.
My take: I’m not surprised. A multi-agent design looks good in a diagram, but every handoff costs tokens and adds a new way to fail. Start with one agent and a good eval, and only split it up when the eval shows you need to. The “test your evals too” point matters as much: if the evaluator is wrong, every comparison built on it is wrong too.
