Miro × Lovable: What Changes When a Workshop Starts with the Problem

A blank prompt looks like freedom. In a room with a deadline, it often behaves like fog.

People open an AI builder with a real idea and immediately start asking for screens. Ten minutes later they have a dashboard, a gradient and no clearer answer to who the product is for.

The Miro × Lovable Buildathon was designed to interrupt that reflex.

The work started before the room

On 15 April, product managers, designers, founders and consultants came to Miro’s Amsterdam office for a four-hour buildathon. Elena Avramenko and I organised it with the Miro Community Team, with support from Xolo.

The event had one unusual constraint: participants received a Miro board before they arrived. They were asked to spend thirty minutes describing the problem, the person experiencing it, the competitive context and the shape of a first useful product.

It was not homework for its own sake. It protected the expensive part of the evening—the time when builders and mentors were together—from being consumed by naming ideas.

People arrived with something we could question.

Problem framing is a building material

Product work often treats discovery and delivery as separate phases. First there is a workshop. Later somebody turns the workshop into a specification. Eventually a third person builds something that resembles the specification.

AI collapses that distance, but it can also carry a weak assumption all the way into a working interface before anyone notices.

Starting in Miro made the assumption visible. Moving into Lovable made it testable.

The value was not that two products had been connected. The value was that the reasoning could travel with the build.

A board is useful only when it produces a decision

We asked people to arrive with more than sticky notes. The board needed to help them decide:

• Who is experiencing the problem, in what situation?

• What are they doing today instead?

• What is the smallest change in behaviour the product needs to create?

• Which part of the proposed solution is essential to test?

• What can be removed from the first build?

This is where many idea workshops become comfortable and useless. They create a complete map but never force a choice.

The handoff to Lovable changed the standard. If the board could not tell a builder what to make first, it was not ready.

Then the product argued back

Once people began building, gaps in the board surfaced immediately.

A user journey that looked obvious became awkward when it had to fit on a screen. A feature described as intelligent needed data nobody had. A broad audience became three incompatible workflows. The product was not merely the output of the thinking; it became a way to challenge it.

That is the loop we wanted: frame, build, inspect, return to the frame.

The procedure did not remove uncertainty. It gave uncertainty somewhere to appear.

The tool boundary should disappear

MCP made it possible to move context from the Miro board into the building environment. That is technically interesting, but the design principle is more important than the integration.

A useful AI workflow should reduce the number of times a person has to translate the same intention between documents, tickets, prompts and meetings.

Every translation loses something. The product manager shortens the research. The designer interprets the requirement. The builder fills in an unstated rule. By the time the product appears, the team is arguing about an assumption nobody remembers making.

Keeping the problem structure close to the build does not eliminate interpretation. It makes the interpretation easier to trace.

What worked

Four parts of the format earned their place.

Preparation created better pressure

Thirty minutes before the event meant the four hours together could be used for hard questions, building and recovery.

The audience brought its own problems

A generic challenge can be useful for beginners. For experienced product people, an idea they have postponed creates more commitment. It also exposes real organisational and domain constraints.

The output had two forms

Participants left with a clickable prototype and a structured product board. The first made the idea tangible. The second preserved the reasoning needed to continue.

The pitch was short

Two minutes forced each finalist to connect the problem, the product and the decision. There was no room for an innovation monologue.

What I would sharpen

The danger of a tool-led event is that participants optimise for using every feature. Next time, I would make three guardrails even clearer:

• No screen before the problem and user can be stated in one sentence.

• No feature unless it supports the behaviour the team wants to test.

• No final demo without one unanswered question and one next experiment.

I would also add a midpoint review where teams show only the core flow. Early feedback is cheaper than a beautiful detour.

Why this matters inside companies

Most organisations do not lack ideas. They lack a reliable way to move from scattered knowledge to a decision, and from that decision to evidence.

The workshop should not create another artefact that waits for a delivery team. It should create a working argument while the people who understand the problem are still in the room.

The best result is not that everybody becomes a software engineer in one evening. It is that more people understand the cost of their assumptions because they have tried to make them work.

The original buildathon listing describes the pre-work, the Miro-to-Lovable flow and the judging format. The event began with a simple promise: bring the idea that has been sitting in a document, a Slack thread or your head—and make the first version real.

If your team has ideas trapped between workshops and delivery queues, see how we run AI workshops and buildathons. We start with the problem, then build only what the problem earns.