If agents write the evals, draft the specs, and run the loops, what work is left for a product manager? One answer I keep seeing online is that product writes the evals, approves the agents, orchestrates the loops, and picks one at the end. At ProductCon San Francisco, I made the case that product’s role is much bigger: deciding what’s worth building and bringing a team along, which is especially important as agents accelerate building.
Over the past year I’ve spoken with more than 200 customers, and what they describe shows why. Most have found ways to build faster, but amid all the building “noise” they can’t always tell whether the extra output is leading to impact. Miro’s recent survey of 550 product leaders shows where it stalls: 74% said AI has increased how quickly they produce work, yet over half don’t see a proportional improvement in decision-making. More output hasn’t translated into better decisions.
Aligning and deciding on the right thing to build has always been the hardest part of product’s job, and building faster makes it that much more critical. So, here’s how I think about that craft, and how we practice it at Miro.
Product’s craft, now at a faster pace
The best product leaders I’ve worked with share a mastery of craft. They break big problems into pieces their teams can take on, communicate transparently to ensure those teams are aligned, and set an ambitious pace. Each of those elements depends on decisions: how to slice a problem, what to tell the team and what to tell leadership, how high to set a bar.
As teams can build faster, that craft stays the same but three things change:
- Decisions arise more often, so you need to make them sooner;
- Because decisions arrive so frequently, alignment becomes something you work on continuously, rather than once a quarter;
- And ambition should rise with your team’s capacity, which makes bigger bets worth taking.
Loops are a handy way to picture the work (a signal loop, a backlog loop, a build loop, a ship loop). A loop with only a PM and some agents in it leaves out the people who have the best ideas, the right context, the relevant expertise. Luckily, putting a multidisciplinary team in the loop actually has a name already: collaboration.
We try to practice this at Miro, with mixed results on any given day. I’ll admit: We’re AI-pilled. Designers check in code, agents handle a large share of our development through a software factory, and PMs prototype and pull their own analytics. We certainly struggle with the same noise our customers describe.
To keep the loops flowing and quiet the noise, we’ve settled on a few habits. Everyone on the team owns the why. We use the time AI frees up for more thinking. We keep it fun. And we expect good ideas from anywhere. Here are three specific ways those habits show up at Miro (the company) and on Miro (the canvas).
Kicking off a big project with the whole team
Imagine your closest competitor just launched a product, and your team has to respond. In the age of AI, you might see 20 members of the team running to their agents and entering more or less the same prompt; cue: the well-meaning chaos ensues.That’s why, at Miro, we choose to still start how we always have: with a brainstorm in Miro.
The ritual hasn’t changed, but the outcome can. While your team ideates, a Sidekick scaffolds the full scope of the project on the same board: a product brief, user stories, a sequence diagram, a mobile prototype, and a stakeholder deck. Teammates drop in shared knowledge to round out the context, like a dashboard built in Claude and the current OKR scorecards, so company objectives sit right next to the ideas. Then people push on the drafts. Why is that story a P0? Shouldn’t it be a P1? The prototype and deck are intentionally low-fidelity. They exist to start conversations.
We run kickoffs so everyone owns the why. Scaffolding takes that further. The session doesn’t end with a messy brainstorm that one person has to translate into next steps. It ends with a cross-functional team aligned on the why, and the what already scaffolded. Nobody spent the meeting building artifacts for a stakeholder review. They spent it asking whether the goal was high enough and how to solve the problem more creatively.
And the scaffold isn’t only for people. Agents can read the board, so when it’s time to execute, they own the why too, with the same context the team has.
That’s the shift I want AI to make: less doing, more thinking. In my experience, the critical unlock here is deeply human — the best thinking happens when people are enjoying themselves. That’s why we’ve built moments of delight into Miro, like personalized stickers, cursor chat and fun widgets like the spinner wheel. These micro moments aren’t just fun; they create micro moments of engagement that activate the entire team to solve hard problems.
Turning a prototype into a decision
If you’re prototyping with tools like Claude Design or Replit, you’ve probably had this experience: your agent calls it a great prototype, you feel confident, and then a designer looks at it with a polite, slightly pained smile.
That reaction isn’t about taste. Designers come in with context a prototype can’t hold: how the system works, which other initiatives every UX decision has to hang together with, and how to keep the product from feeling like Frankenstein. As a PM, your prototype isn’t the answer. It’s how you communicate and articulate a direction so design can build on it and make the solution better and sharper.
That only works if the conversation is ideation, not a design crit. Bring the prototype you built in your chat window or terminal onto a Miro board and let the team mark it up screen by screen. Notes on a canvas don’t read like critiques. They read like people building on each other’s ideas toward a shared outcome.
When the session ends, the team can pick up the board and the notes and run the next iteration. They can also ask a Sidekick to synthesize the decisions into a UX decision doc. It reads the comments, the changes, and who made them, then writes up what the team decided and why. That rationale gives context to the teams who weren’t in the room, and to the agents that will work from it.
Staying aligned while agents build
That alignment doesn’t end at handoff. During build, a product leader still makes hundreds of small decisions, but with dozens of agents running, it gets harder to see what’s going on.
At Miro, we point an internal Claude skill at the repo as the source of truth, and it visualizes what’s happening in Miro: the technical architecture, the decisions, the risks, and a kanban of what agents are working on and what tasks they have next. The board builds on the one from the kickoff, so the team can see how the work has evolved from idea into a fully animated working app. That gives us a complete view of the context we’d otherwise piece together from various threads in Slack, and it makes deeper decisions possible.
Alignment runs from early discovery through delivery, with product leaders still setting the direction, the decisions, and the pace.
Getting back to the craft and the collaboration
To close the loop on the question I started with: what work is left for today’s product leaders anyway?
The same craft as before, and even more depends on it. With teams building faster, that means deciding sooner, betting bigger, and staying in step with your team as you go. And that’s the work we’ve built Miro to support.
When you do that work well, individual gains become shared ones: the team aligns on shared context, decisions hold, and agents build from the same picture as the people. That’s why I like to say product is the x-factor that turns 10x productivity into 10x company impact. Or, in other words: product is so back.
