2026-07-14 · 14 min read · Raw Drafts / Product Management / AI
The Infinite Canvas Is No Longer the Hard Part
AI can now generate a convincing real-time board quickly. The product-management challenge is preserving meaning as ideas become designs, tasks, and commitments across systems.
I remember when the impressive thing about Miro was that it worked at all. A browser could hold an apparently endless visual space, let several people move objects around at the same time, and keep the whole thing responsive while everyone zoomed between the overview and individual details. At the time, browser-based software still felt like a lighter category of software. Serious creative tools were installed on a computer. They had native graphics engines, direct access to local files and years of specialist engineering behind them. A shared infinite canvas therefore felt like a technical achievement before anyone had even asked what kind of organisation might eventually be built on top of it.
WebAssembly was often part of that conversation. Figma became the obvious example of a browser application doing work that previously seemed to require native software, and WebAssembly helped explain how that could be possible. It allowed performance-critical code to run efficiently in the browser, while WebGL and later WebGPU handled the graphics. The story was compelling because it made the browser itself look like the main obstacle. Once the rendering engine became fast enough, it seemed, the rest of the product could follow.
That is no longer how I see the problem. These days, an AI coding agent can generate a convincing real-time board surprisingly quickly. It can connect an infinite-canvas library to a multiplayer service, add shapes, connectors, selection tools, remote cursors, rooms, persistence and authentication. The result may not be polished, but it can already resemble the early version of a product that once looked technically intimidating. The canvas has not become trivial. It has become infrastructure.
What remains difficult is deciding what the canvas is for once people start using it for real work.
A whiteboard is useful because it allows uncertainty
This is where the evolution of Miro becomes more interesting than the technology behind it. Miro began as a place where uncertainty could remain visible. A team could place research findings next to half-formed ideas, draw connections between them, disagree about what they meant and rearrange the whole board without committing to a formal structure. That looseness was not a weakness. It was the reason the product worked so well for workshops, retrospectives, design research and early product planning. The board allowed people to think before they had decided what kind of information they were dealing with.
Product management begins in exactly this kind of ambiguity. A team may have several customer complaints, some usage data, a strategic goal and a vague feeling that the current product is not working. None of those things is a task yet. They may not even describe the same problem. The whiteboard gives them somewhere to coexist while the team works out what matters. It supports a stage of product development where contradictions are useful and premature structure can be harmful.
The problem starts when the same board is expected to carry the work beyond that stage. A sticky note becomes an action point. The action point gets an owner. The owner needs a deadline. The deadline belongs on a roadmap. The roadmap needs to reflect engineering capacity. The engineering work needs status updates, and those updates need to be summarised for stakeholders. Each step seems like a reasonable extension of the previous one, but together they turn a thinking surface into an operating system.
This is what has happened to Miro. It has gradually expanded from collaborative whiteboarding into documents, tables, diagrams, planning, prototyping and AI-assisted workflows. The company is no longer selling only a place to brainstorm. It is trying to own the movement from an unclear idea to a coordinated outcome. From a product-management perspective, that ambition makes perfect sense. The place where a team reaches a decision is an attractive place to offer the next action. The difficulty is that every step toward execution introduces rules that the original canvas was designed to avoid.
A sticky note is easy to manage while it remains a thought. It can be moved, copied, rewritten or deleted without much consequence. Once it becomes linked to a roadmap item or an engineering task, those same interactions become more serious. Deleting the note might remove only the visual object, or it might delete a commitment that someone is already working on. Copying it might create a harmless duplicate, or it might create a second task with the same owner and deadline. Editing the text might change the description on the board while leaving the delivery system untouched. The interface still shows a coloured rectangle with words inside it, but the object now carries organisational meaning.
Different products meet at the same transition
This is where Miro and Atlassian begin to meet from opposite directions. Miro started with ambiguity and has been moving toward structured work. Atlassian started with structured work and added a visual space in which ideas could exist before becoming issues. One product wants to turn the whiteboard into a place where work continues. The other wants to bring the whiteboard closer to the system where work is already managed. Both eventually arrive at the same moment: a sticky note becomes a task.
The user experiences that transition as a button. The product team experiences it as a data-model problem. Is the note converted into a new task, leaving the original object behind? Are the note and the task two views of the same record? Which system owns the title, the status, the owner and the deadline? What happens if the note is deleted but the task remains open? What happens if the integration stops working for a week and both sides continue changing? The interaction can appear effortless only because the underlying product has made a series of decisions that the user never sees.
Figma approaches the same challenge through the artefact rather than the task. FigJam gives teams a space to explore ideas, but the centre of the Figma ecosystem is still the product being designed. A discussion can become a screen, the screen can become a flow, and the flow can become a prototype. AI makes that progression even faster by turning rough descriptions into interfaces and interactive concepts. Instead of asking the team to convert an idea into a formal task, Figma makes the idea tangible.
That can reduce ambiguity more effectively than a written requirement. A ticket saying “improve onboarding” leaves almost everything unresolved. A prototype can show the sequence, hierarchy, content and interaction. It gives the team something concrete to react to. But the prototype does not contain the whole product decision. It may not explain which research supported the change, who approved it, whether engineering has the capacity to build it or whether the generated interaction is technically realistic. The artefact makes the proposal visible, but it does not automatically preserve the reasoning around it.
As Figma moves closer to product creation, more product-management responsibility enters the design file. A frame starts behaving like a specification. A comment becomes a decision. A component becomes a contract with engineering. A generated prototype may be interpreted as a commitment even when it was intended only as an experiment. The file begins carrying information that was once distributed across meetings, documents, tickets and code. This makes the product workflow feel more continuous, but it also raises the question of which part of the file is authoritative and which part is only exploratory.
Notion encounters the same problem from another angle. Its strength is not spatial thinking but persistent context. A research note can link to an opportunity, the opportunity can link to a project, and the project can contain tasks, owners, dates and status updates. This is closer to how organisations try to preserve memory over time. A workshop board can capture one moment brilliantly, but six months later it may be difficult to know which notes mattered, what was decided and what happened afterward. A connected workspace can maintain that chain more explicitly.
The trade-off is that structure has to be created and maintained. Someone needs to decide whether a piece of information is a task, an insight, a decision, a risk or an opportunity. Someone has to choose which database it belongs in and which properties it requires. The canvas allows people to postpone these decisions. The database demands them. This is why AI is becoming so important across all of these products. It promises to let people think and communicate naturally while the system handles the translation into structure.
Miro wants AI to interpret the canvas. Figma wants it to interpret and generate the artefact. Notion wants it to interpret the workspace. Atlassian wants it to interpret the delivery system. Their AI features may look similar on the surface, but they are built around different ideas of where product knowledge lives. The real competition is not over who can generate the best summary or the most attractive diagram. It is over which representation becomes the main context from which the organisation operates.
This matters because product development does not have a single source of truth, despite how often teams claim that it does. The research may be stored in one place, the decision in another, the latest design in Figma, the task in Jira and the implementation in the codebase. A sales conversation or client email may contain a promise that none of those systems knows about. The truth is distributed across representations that serve different purposes. Collaboration products keep expanding because each company wants its own representation to become the place where those fragments reconnect.
The infinite canvas is particularly attractive because it can display almost anything. A screenshot, task, diagram, document, prototype and chart can all be placed next to each other. The board gives the impression that the work has been brought together. Yet visual proximity is not the same thing as a shared model. Placing a Jira issue next to a Figma frame does not tell the system whether the task reflects the current design. Drawing an arrow from a research note to a roadmap item does not define whether the relationship must be maintained when either object changes.
AI makes the first version deceptively easy
This is also why generating a real-time board with AI can be misleading. The first version looks much closer to a finished product than it really is. The objects move correctly. Multiple people can edit them. Changes save. The interface may even feel polished. What the demo does not reveal is how the system will behave after several years of use, thousands of integrations and millions of decisions.
A new product has no past. It has no boards created under old schemas, no abandoned object types, no former employees who still own important documents and no customers depending on accidental behaviour from three versions ago. Nobody has yet created a board with 100,000 shapes and embedded files from six external systems. Nobody is asking why an export made in 2024 can no longer be opened. Nobody has built an internal process around a feature that the product team now wants to redesign.
The first 70 percent of the product can increasingly be generated. The remaining 30 percent contains most of the long-term difficulty.
Real-time synchronisation illustrates the difference. Modern collaboration libraries can merge concurrent edits, reconnect clients after network failures and keep shared state consistent. This solves an extremely difficult technical problem. It does not solve the product question of what should happen when two valid actions conflict semantically. One person may be moving a note while another converts it into a task. An AI agent may be reorganising a research cluster while a researcher is editing the same material. A user may delete an object that is still referenced by a roadmap, prototype and delivery ticket. Every operation can synchronise correctly while the resulting product behaviour is still wrong.
Undo becomes surprisingly revealing here. In a single-user application, undo usually means reversing the previous action. In a collaborative environment, the previous action may belong to somebody else. The product needs a concept of local intention, shared history and object ownership. When AI is added, the problem becomes even less obvious. If an agent changes 300 objects, is that one action or 300? Can the user preview the changes before they happen? Can another person continue editing the same area? Can part of the operation be accepted while another part is rejected? How should the system explain what the AI changed and why?
These may sound like edge cases, but mature products are largely made of edge cases that became permanent. The main interaction usually works early. The product becomes difficult when every interaction needs to remain consistent with permissions, history, integrations, offline behaviour and previous versions. This is why I increasingly see product management as the work of maintaining coherence across time, rather than simply deciding which features to build.
AI lowers the cost of implementation faster than it lowers the cost of consequences. An agent can add a custom object, toolbar action, database table and external integration in one working session. That feature may then require years of migration logic, export support, permissions rules, accessibility work and backwards compatibility. The danger is not only that AI generates bad code. It is that it makes it easy to create product concepts before the team has decided what those concepts mean.
When implementation was expensive, the cost itself created some resistance. Teams had to justify a feature before committing engineers to it. Now the feature may exist before the discussion has finished. This makes restraint and conceptual clarity more important. A product team needs to know which objects are central, which systems are authoritative, which transformations are reversible and which relationships must survive over time. Otherwise, AI helps the platform accumulate overlapping ways of representing the same work.
This is already visible in mature collaboration tools. A task can be created from a sticky note, a document, a table row or an AI-generated workflow. A roadmap can exist as a timeline, a database view, a board object or an external integration. A document can live on the canvas, beside the canvas or be generated from it. Each option may be useful on its own. Together, they can make the product difficult to explain because the system no longer has a clear centre.
The product reveals itself later
The real competition between Miro, Figma, Notion and Atlassian is therefore not a feature competition. It is a competition over where product work becomes real. Miro is betting that the canvas can become the main context. Figma is betting that the artefact can become the main context. Notion is betting that the connected workspace can become the main context. Atlassian is betting that the delivery system can remain the main context.
Each representation is good at a different part of the process. The canvas is good at ambiguity and relationships that are still being discovered. The workspace is good at preserving knowledge and structure. The design artefact is good at showing the intended experience. The delivery system is good at coordinating commitments. Product development moves through all of them, and the most difficult work happens during the transitions.
An observation becomes an idea. The idea becomes a decision. The decision becomes a design. The design becomes a task. The task becomes code. The code becomes a product that generates new observations. AI can accelerate every transition in that sequence, but acceleration is not the same as continuity. The output can become separated from the reasoning that produced it, and the organisation may lose track of what an object represents or why it exists.
The useful product-management question is therefore not whether the team can build one more surface or automate one more conversion. It is whether the conversion preserves the chain of evidence and responsibility. When an observation becomes a task, can someone still find the observation? When a prototype becomes a commitment, can someone tell which parts were tested and which parts were generated? When an AI agent rearranges a board, can the team understand the change well enough to take responsibility for it? These are not cleanup questions to answer after the interface is finished. They are the behaviour the organisation will eventually depend on.
This changes how I would judge a mature collaboration product. The most impressive board is no longer the one that feels limitless. It is the one that can become narrower at the right moment. It can give uncertainty room to exist without allowing that uncertainty to leak silently into execution. It can let the canvas, the database, the design file and the backlog remain different representations, while still preserving the reasoning that connects them.
A board generated in an afternoon can already look like the future. The product reveals itself much later, when the team returns after six months and can still tell what happened, why it happened, which system is authoritative and what they are now allowed to change. That is the part AI has not made cheap.
AI authorship note
This essay grew from Kris Haamer's questions about how Miro and similar products have changed, whether AI can now generate a real-time board, and why WebAssembly used to appear central to this kind of browser software. AI supported research, drafting, editing, and implementation. Kris directed the argument toward product management, asked for the products' challenges to be intertwined rather than listed, pushed the writing toward sustained paragraphs, and requested a stronger ending before publication.