Want this content delivered right to your inbox?

Subscribe to the Newsletter

A conversation with Joe McLean, Group Product Manager for the AI Stream at Miro

There’s a fundamental difference in the psychology between asking it questions to get answers or using it instrumentally to create something. – Joe McLean

In this episode of the Facilitation Lab podcast, host Douglas Ferguson interviews Joe McLean, Group Product Manager for the AI Stream at Miro, who led the overhaul of Miro’s Sidekicks and Flows AI surfaces launched at Canvas 25. Joe traces how his hobbyist love of Eurorack modular synthesizers shaped Flows, arguing that visible, patchable connections reveal what a chat box hides, and that a good tool’s structure can enable rather than constrain creativity. He and Douglas dig into what he calls the “visual trace” – treating an AI agent like a new hire who needs onboarding, check-ins, and a replayable record so a whole team, not just one operator, can trust and build on its work. The conversation covers how cheap execution is reshaping product development, from teams showing up to meetings with working prototypes instead of slide decks, to Miro’s internal VibeLab tool solving the “Git problem” of AI-generated design branches, to the rise of throwaway personal software built for an audience of one. They close on a candid discussion of the switching costs of chat-interface lock-in and Joe’s conviction that the healthiest relationship with AI comes from building things with it, not just asking it questions.

Listen on Apple Podcasts
Listen on Spotify
Watch on Youtube

This episode is part of the Facilitation Lab Podcast. See all episodes

Show Highlights

[00:00:00] Welcoming Joe McLean To The Show
[00:02:30] Synthesizers As Inspiration For Miro Flows
[00:04:30] Why Chat Interfaces Limit AI Thinking
[00:14:17] Agents As New Hires Needing Onboarding
[00:19:30] Showing Up With Working Prototypes Now
[00:36:00] Personal Software Built For One User
[00:42:15] VibeLab And Git Problems For Design
[00:48:49] The Switching Friction Of Chat AI

Joe McLean — LinkedIn
Joe McLean — How modular synthesizers and music software inspired Miro’s Flows (Medium)
Joe McLean — Overfitting and the problem with use cases (Medium / Bootcamp)
Joe McLean — Medium author page
Miro AI Workflows product page
AI Teaming Comes Alive on the Miro Canvas (Voltage Control)
Teaming with AI: Voltage Control and Miro AI (Miro Blog)
Miro AI + Voltage Control

About the Guest

Joe McLean is Group Product Manager for the AI Stream at Miro, based in Berlin, where he led the cross-org launch of Miro’s AI Workflows at Canvas 25, including an overhaul of Miro’s Sidekicks and Flows surfaces. Before that he ran Miro’s Canvas Experience and Sync Collaboration groups, and prior to Miro he spent seven years at Splice, the music creation platform, finishing as Director of Product Management for Creator Tools and Mobile. He started his career as a product designer and front-end engineer at Spongecell and ThoughtWorks, where he facilitated project quickstarts, inceptions, and product visioning exercises. A self-described Eurorack synthesizer enthusiast, he writes occasionally on Medium about design philosophy, including how modular synthesis inspired Miro’s Flows and why designing around narrow use cases produces brittle products.

Transcript

Douglas Ferguson: Welcome to New Friction. I’m Douglas Ferguson. AI just made execution almost free. So why are organizations still stuck? Because the friction didn’t disappear. It moved and it multiplied. It’s no longer in building. It’s in deciding what to build, how to align, and how to move forward when the path isn’t clear. That friction, the human side of change, is what this series is about. Each episode, I sit down with leaders who are living it, navigating the real challenges of AI transformation, not the tools, the people. The task that took two weeks now takes two minutes. The work isn’t the bottleneck anymore. The conversation before the work is. That’s the work this show is about. I’d like to introduce you to my conversation partner today, Joe McLean, group product manager for AI stream at Miro. Welcome to the show, Joe.

Joe McLean: Hey, great to be here.

Douglas Ferguson: Amazing. Really looking forward to this conversation. I have been thinking about this since our chat in Vegas where-

Joe McLean: In Vegas. Yeah.

Douglas Ferguson: … realized our… Well, this is one thing that happened in Vegas that can kind of come out of Vegas, I guess, but we realized we have a mutual love of synthesizers.

Joe McLean: Yes, we did. Not something I actually expected to find wherever we were, that weird restaurant in Vegas. I wasn’t expecting to talk about Eurorack for half an hour.

Douglas Ferguson: I think it was Cabo Wabo, right?

Joe McLean: That’s right. Yeah, that’s right.

Douglas Ferguson: Is that a Van Halen kind of… I don’t know. I didn’t look into it, but I think it might be a Van Halen reference, or I don’t know if he owns it maybe. I don’t know.

Joe McLean: I’m of no help to you in that regard, I’m afraid. Yeah.

Douglas Ferguson: But yeah, a revenue kickoff partner event with a business casual turned into conversations about synthesizers and Bitwig and all sorts of stuff.

Joe McLean: Yeah.

Douglas Ferguson: And I was delighted to hear that Reason and this kind of patchable analog modeling system was inspiration for the flows in Miro.

Joe McLean: Yeah. Yeah. I mean, I think for people who make music that way, I’m a big Eurorack nerd, it kind of changed the way I think about music. And I think part of how I fell in love with it so hard is that it just feels like it has some deep affinity with how my brain works. It’s like you see the connections, you can visualize the flow of information, you hold that in your hands. And when we were thinking about how we could make AI accessible in Miro, how we could bring it into the Canvas, it was just such a natural way for those ideas to come together. I think for people who are still kind of wrapping their head around AI and what it does, it’s such a powerful way to visualize what’s happening when you’re hooking up context and transforming it into something else. And there’s something, again, just in my brain, seeing the wires, connecting it up, it has a physicality to it that I think can be missing when you’re just typing into an empty prompt box.

Douglas Ferguson: Yeah. The other thing that struck me too is how linear a conversation is. And you’ve got this conversation history that’s just stacking and stacking, and it’s just getting all jammed into this giant corpus of context where with the flows you can kind of pick and choose, and even after midway through a conversation, if you will, remove a wire and now you’re kind of constraining that context in a new way.

Joe McLean: Yeah. Yeah, absolutely. This is really interesting to me. I think a lot about how UIs make people think about the technology. And I think that there are pros and cons to the fact that so much of modern AI experiences feel like texting someone. That’s been really powerful to make it accessible to people because anyone has context texting someone. But it also sets a very particular expectation about the type of interaction you’re going to have, the types of things that are going to be possible. There’s not a great way for that interface to reveal what it’s capable of. You see people, a lot of companies and tools are playing around with things like skills and skill discovery. But I still think that at the end of the day, the fundamental idea is that you’re sending someone a message. And that’s only one way to think about what the technology can do. And I think we’re all walking around with this constraint that we’re not really thinking about anymore because it’s just the one that we’ve connected to as the first breakthrough UI. But there’s going to be many, many more. This is just the first generation. I think of the people carrying those giant cell phones in cars in the ’80s or whatever. The iPhone will come. There will be a different way of interacting with the underlying raw power of the technology. And I’m not sure that it’ll always be a text box for every job.

Douglas Ferguson: That also has a way of influencing how people innovate, right? Because if they’ve been painted a certain picture, and that’s their worldview of how the technology works, they’re living at that abstraction layer. They don’t necessarily understand that there’s more that could happen underneath. And that can be very stifling on the innovation side.

Joe McLean: Absolutely. And I think that’s where I feel another fun connection to our shared passion for synthesizers. I think one of the things that I really love about the Eurorack world is that by creating some structure and framework around the way that the pieces connect to each other, you create a space for all these tiny manufacturers to be very creative, but within an established paradigm. And when I compare the explosive creativity of all the hobbyist creators in that space to the world of mass-produced commercial synthesizers, there’s a time and a place for that. And the streamlining of that experience for people who don’t want to get in and tinker onto the hood is great for certain applications and certain situations. But I think there’s something so powerful about showing the wires and letting people get in there and engage with it in a new way. And I think that’s really inspiring from the perspective of thinking about how you build UIs for good tools. This is something that I felt going way back to my days at Splice building music production tools, is that when you’re building tools for expert creators or technical people, I think there’s a lot of freedom to build more complex and sophisticated interfaces because there’s a different expectation for things like information density or workflow complexity, or even how much training someone has in the software to be able to use it. We’re always really interested in bringing that barrier down and making it more accessible. But I don’t necessarily assume that the right answer is always for things to be simple, especially if the task is complex.

Douglas Ferguson: Yeah. And coming back to the Eurorack stuff, I mean, it’s like you get the gamut. You got modules that couldn’t be any more simple, like one knob on them even. And then you’ve got modules that are computer menus. It’s like a bank of 100 algorithms that have their own idiosyncratic settings and stuff. And it’s such a wild world. And to your point, I love the fact that it’s a bit of an ecosystem. You’ve got folks that are building modules that do nothing, maybe shape the control voltage, and they’re not there to make a sound. They’re not doing something in the conventional synthesizer sense. But they’re like, oh, I see what’s going on in this universe of how people are using these tools. This would be a really handy thing to give people just to create a slightly different experience.

Joe McLean: Yeah. And one of the first pieces of advice I ever got when I started playing around with synthesis and building electronics for synthesis is you got to get an oscilloscope. You got to get something that visualizes what’s going on because otherwise it’s just too abstract. You can’t wrap your head around it. That was good advice. And I think it is advice that is applicable these days to AI. So much of debugging an AI system comes from going in and reading the trace, seeing exactly what happened, being able to follow the path, so to speak. I think we’re visual people, and it’s really helpful to have something that you can understand and process in that way. And so yeah, an interesting way of thinking about a lot of these tools we’re building is how do you build an oscilloscope for the AI trace? How do you visualize the 4,000 line pull requests so you can understand what it’s actually doing to your server? That’s obviously something that’s very interesting to us in Miro, creating visualizations of all different kinds of information. And I think a lot about the information throughput of those different formats. Very challenging actually to read lots and lots of text to understand a plan or to understand a deep technical change. And it’s really powerful to have these visualization tools on hand to understand how information is flowing, or how things are changing or transforming. I think that’s quite important.

Douglas Ferguson: Yeah, I feel that. I’ve been using Miro in some ways that have driven me to want even more power in that regard. A great recent example is I built a very complex board for a client, and it involved 100 boards for 100 different locations, and then a synthesis board that rolled them up and doing some analysis, roll-ups per regions and areas. And then so the synthesis board ended up with so many flow connectors that I really wanted some visualization on the connections themselves, or even just having MCP tell me what’s connected and applying some rule sets and saying, hey, are the right regions connected to the right roll-ups? And based on what you announced at Canvas, and how you’re working on these things and thinking about these things, I have a hunch that I’ll be able to do that fairly soon.

Joe McLean: Yeah, for sure. I mean, I’m really interested in that, and also in the ways that you can interchange between the conversational ways of thinking about it and the visual ways of thinking about it. I’ll give you a couple examples. It’s interesting to think about something like a flow or really just any diagram as a representation of agent behavior. One of the things that we’ve been doing as we’ve been trying to describe how some of Miro’s more advanced agentic behavior should operate is we wind up drawing a lot of flow charts. And it’s not deterministic. We’re not building systems that say if this, then that. In many ways, the magic of agents is that they don’t have to operate that way. But you still need to be able to visualize the journey that you hope someone will go on as they accomplish a certain job and think about the prompts that will lead to them going on that sort of journey. You could even think about that visualization as a sort of eval on your expectations of the conversations unfold in a certain way. And so even just being able to visualize a conversation as a flow, or vice versa, to be able to understand a flow as a conversation, is an interesting way to think about what we’re trying to do when we’re designing systems with agentic behavior. But then there’s also other ways of thinking about this. We are very quickly seeing that code-based visualization or mapping out user journeys from behaviors defined in code is a great way of understanding code. Or you create a system entity diagram that maps relationships between the different objects in your system. It’s another thing, same idea from a different perspective. It’s like that information is out there, but it hasn’t been compressed in a visually parsable way. And when you can do that, you can build understanding a lot faster than going through the raw line level information.

Douglas Ferguson: A couple of things that it’s making me think about is how important plan mode is and getting to a understanding with your agent on what they’re going to build before just letting… Because if you get to a solid plan, you can one shot a lot of things these days. And a visual plan’s very powerful. Or even if the plan’s getting really, really complex, being able to visualize it on Miro or anywhere is a huge step up. And then the other thing that came to mind is, you mentioned evals, and I hadn’t thought of this before, but this idea of creating space and room for the team to participate in ongoing eval, to remove drift. Because we can build the best agents and the best systems, but they will drift over time. And so can the agent leave telemetry behind or exhaust behind, it’s visual in nature, so that we can just peek in as a team, or in our ongoing check-ins and work in alignment sessions, just look and see, does this exhaust looked right? Is this staying on track?

Joe McLean: 100%. Yeah. We call this the visual trace in our internal discussions of this. And it’s so important. I think you really just hit the nail on the head. I think this really connects back in a core way to the idea of multiplayer AI. I think if I think about all these interactions we’re having every day, there’s one category of things you touched on that’s so important, like preventing drift and creating a clear plan. This is important even just in one-on-one interactions with agents. I think it’s helpful to think of it as almost from a manager framework. It’s like you’ve got this new, very eager, very smart hire, doesn’t have a ton of context on your organization, or how you want to work, or even what the job is yet because you’ve only given it pretty limited amount of information. What kinds of governance, what kind of one-on-ones, what kind of systems, reviews, would you want to have with that report to make sure that they’re doing a good job? You’re not going to just hire them and check in 90 days later. You’re going to talk to them, you’re going to make sure that they can demonstrate understanding of the task, and they’re doing a good job as they go along. You also understand that they might need a little bit more guidance early on before they know how you do things to be able to stay focused. You’re not tracked in that way. And so I think a lot of those intuitions [inaudible 00:14:17]. But where it gets even more interesting is what you’re talking about when more people get into the mix, it becomes so much more important to have that visual trace so that other people can follow the conversation. It’s one thing to build that understanding one-on-one together with the agent. But if then you can’t replay it at all, you’re going to have problems when you try to go and work with other people. And I’ll say as a practitioner, this is a pain that we’re feeling firsthand every day now. Because people are showing up with ideas, prototypes, in some cases, entire systems that they’ve built with their agents as the agents become more capable. And then it falls over when they need to actually explain even what this thing is, or how it could be incorporated into other people’s understanding. And there’s this interesting challenge where if you run for, let’s say, several days, you build out this concept, it feels fully realized to you. There can be a bucket of cold water when you have to bring that to someone else and explain what it actually is. Because maybe before you would’ve gone through reviews, you would’ve built a shared understanding, maybe you would’ve whiteboarded it together and come up with a picture, and you build that collaborative understanding as you go. But when it’s just done, obviously there’s a magic to that. There’s also a totally new challenge, which is this thing just popped out of the fabric of the universe. And now it’s actually quite complicated and it’s hard to explain to other people. That can be a tremendously frustrating collaborative experience. And when you go that journey alone, it’s hard to come back.

Douglas Ferguson: You’re hitting on one of the core new frictions. I think it’s always been there to a certain degree. AI is just amplifying it in a big way. Because I mean, this is the reason user stories got invented. We want to get alignment, we want to tell a story, and let people really get inside of it and understand something that can be nuanced and complex. And certainly if people haven’t had time to sit with it, walk around with it, have that shower epiphany moment, like you mentioned, it just erupted out of the fabric of the universe. I think this is the type of thing that’s so important to focus our training around versus AI fluency. Because this AI fluency stuff, how to prompt, all these more tactical things, they’re changing so rapidly, it doesn’t matter. By the time they learn it, it’s irrelevant anymore. But if you can teach solid storytelling skills, group synthesis, these types of things that are going to be more and more critical as more and more things just erupt out of the fabric of the universe.

Joe McLean: Yeah. No, I think that’s totally spot on. And you’re right also that keeping up with the bleeding edge of prompting strategies is basically impossible. It’s out of date as soon as you learn it. The best way to build intuition for that is just by doing it anyway. And also, I believe that we’re probably in the waning days of that even being a thing that you need to do. The level of agent understanding has already gotten to the point where you’re probably messing it up more than you’re helping by saying you are an expert product marketer, make no mistakes type stuff. I think of that stuff as being very 2024, 2025 now.

Douglas Ferguson: So the rituals that you’re using to solve for some of this stuff, you talked about people bringing these pretty much finished concepts that are getting created so rapidly. What are some of the ways you’re leaning in to solve for that and help people navigate that moment, either on the sharing side or even the receiving side?

Joe McLean: Yeah. So I mean, for one thing, I’m not going to present this like we have this all figured out. I think we’re very actively in the process of reworking a lot of this to fit the agentic era. Something you touched on, which I really like, is that in some ways a lot of these kind of connection points are more relevant than they’ve ever been. So I don’t think it’s like throw it all out the window or something. I think it’s more about reworking and understanding where the new bottlenecks are located. For one, I think that it’s very rapidly becoming an expectation that you show up with a working something to virtually any meeting where you’re going to talk about something. The value of talking about it before any work happens has gone down dramatically. And I think there’s two big versions of this. One is design prototyping. So show up with an interactive prototype. Something that I’ve felt for a long time, especially when you’re talking about creator tools, is that looking at something at Figma is just not a good way to understand what an experience is going to feel like. It’s all in the fabric between the screens. And there’s no substitute for being able to actually experience it or try it. And you can get so close now to something that feels like what it will feel like. Gives you so much more information. Some cases, we even have designers now building on top of the actual live working product and trying to figure out infrastructure for that. The quality of the conversation you can have earlier on in pipeline is going way up. And so that’s becoming a new expectation. I think that’s also creating a bit of a culture shift on, I think there’s been this belief for a long time that you separate the problem definition and the solution definition stage. I’ll say personally as a practitioner, I’ve never loved that. Because we’re technologists, we’re building software. We have baked in a lot of assumptions about our solution to begin with. And sometimes I feel like we’re doing this deeply artificial thing where we’re all pretending like we’re not going to try to solve it with a software feature or something like that. I think the most interesting thing is the match between a problem and a solution. Have you chosen a solution that is well calibrated to the problem? That’s not to say that they’re the same thing. People can definitely jump to solutions that don’t have a problem to find at all and get into a lot of trouble that way by getting attached. But the interesting thing is always about a problem and a solution match. And if you’re missing one half, it makes it harder to have a high quality conversation. So problem definition, more important than ever. But I think that you can show up now with a solution that matches your problem and have a much higher quality conversation. That’s been one big culture shift.

Douglas Ferguson: That’s really cool. I love that. I mean, for years we’ve been preaching the importance of prototyping and bringing visual representations of what we’re trying to build, whether that’s a product feature or even a slide deck, or anything we’re trying to do as a team. If we can visualize it and get on the same page conceptually, it beats just having meeting after meeting after meeting. In fact, I think Dude’s Law is a prototype is worth 1,000 meetings. Back to your point about the product problem fit or the solution problem fit, I think of it like a lock and a key. And I love your framing on that, because I’ve had a bit of an aversion to the folks that are so religiously just like, we got to stay in the zone for a fixed amount of time or whatever. Because I’ve always naturally vacillated between the two because I had to go tinker and then come back to the problem. Do I understand the problem enough? And kind of swinging back and forth. And so I love this kind of version you’re presenting. I think it’s even more important that people lean in in that way now that it’s so easy to explore different solutions. It’s not costly to do so.

Joe McLean: Yeah. And I think that also gets to another topic that’s quite interesting to me in this space, which is I think we’re biased to think human scale as to what exploring the solution space could actually look like. You have this agent, you talk to it like it’s a person, so you think about it like a designer and you collaborate it with it the way that you would collaborate with a designer. So maybe you have Opus or maybe now even Fable and Claude Design make you a beautiful UI or something like that, or a slide deck or something like that. But there’s also this very interesting possibility where maybe you have a lightweight model make you 20, and then you choose the one you like the most. And I think that there’s this kind of old guard double diamond kind of thinking where it’s like a lot of those ways of thinking are actually still super relevant. There’s value in exploring a lot of bad ideas and making things very cheap and throwaway. So I don’t assume that the answer is always going to be that you’re going to use the most powerful model to do the most amazing thing. There are other strategies to explore the possibility space. And this is another way where I think the tool has really biased us. You mentioned before that flows can branch out in different directions. That’s one of the things I love about flows. And I think there will be more tools that emerge to start to take advantage of lighter weight exploration across a broader space. On the nerdier end of this spectrum, I’ve been super interested with Karpathy’s AutoResearch and the idea that LLMs can supervise the training of future LLMs. Obviously a very hot topic these days. But the general architecture of just setting up a bunch of parameters that could be optimized, and then making the runs and the experiments really inexpensive, something that can run in five minutes, not over a multi-day billion core GPU mega optimization run, but just like a lightweight experiment. I think a lot of exciting things are going to come from applying that type of thinking to other things.

Douglas Ferguson: Yeah. I keep pointing back to the early 2000s when e-commerce and the web was first showing up in a real significant way. In the late ’90s, I had an email address, but it’s like, okay, yeah, there’s some bulletin boards, blah, blah, blah. But once eBay and Amazon, some of these various juggernauts started to really figure it out and how it works, and Google replaced Yahoo, there was a seismic shift in how people came online and how they behaved. And so I think there’s still a lot of models that have yet to be developed. And to your point, whether that’s rapidly training small models that are fit for purpose, or even moving beyond this chat biased approach, what doors start to open in the next five, 10 years that are even hard to predict right now?

Joe McLean: Yeah. That’s one of my favorite topics to think about. And I think I would sum a lot of that up is how does your mode of interfacing with technology and the implications of that shape the ideas that you’re even capable of having? Bringing it back around to Eurorack, one of the things that I love most about that mode of creativity from the beginning is I made music that I never would’ve made sitting behind a computer or a traditional synthesizer. There’s no difference to the underlying capabilities of the technology. From the minute that we had a DAW, you can create any sound that could ever exist ever, hypothetically. There’s something about the texture and the choices that are made about where the knobs are and what’s connected and what’s easy and what’s hard that kind of creates a grain that makes some ideas more available than others. It’s a kind of compression of the possibility space. And so I think that the same phenomenon is going on right now. The choices that you make, the things that are surface level, even the things that the models are trained on and fine-tuned on, they all point you in a specific direction on top of a technology that is much more general purpose. And so yeah, I love your question. It’s like what new things are going to be possible as we explore that space? I think that’s really the question for software practitioners in the next five years.

Douglas Ferguson: How have you noticed the PDLC changing over time? You mentioned, I don’t know if it’s an official requirement or not, but almost this soft imperative at least to bring finished prototypes and visualizations of your concept to meetings and planning sessions. So that’s definitely a shift. Are there other very mechanical or specific shifts to the PDLC, whether it’s like I’ve seen things like automatic pull request reviews, these sorts of things. What sorts of stuff have y’all adopted in this new era?

Joe McLean: Well, another shift on the design side is that I think, across the industry, the expectation for polish is going up a lot. I was at a Shopify event in New York, and it was really interesting. It was a design event and it was really interesting to hear a lot of their designers talk about how the inexpensiveness of writing code has made it possible to invest a lot more in types of design polish that they never would’ve dreamed of investing in before. I mean, there’s some obvious things, like just all the design tweaks and paper cuts that tend to accumulate. I think every PM is guilty of pushing that stuff down the roadmap in exchange for business critical stuff. And there’s often a lot of really good reasons for doing that. But a lot of that stuff was premised on the idea that it was going to be really expensive actually to get all those things through the pipeline. And when you’re dealing in a very scarcity-minded environment where it’s tough to get those pull requests across the line, makes sense. Doesn’t make sense anymore really. I’ve seen a huge change in the last six months in the number of small tweaks that really up-level the experience that we’ve been able to get across the line. Shopify designers were talking about even investing in 3D animations and motions, things that they wouldn’t have even known how to do in the old world. And so I think that’s going to be a really interesting one to watch. It reminds me a little bit, I’m old enough to remember how the iPhone swept through the design world, and really up-leveled the expectation for design in consumer applications. And I think we’re about to go through a similar thing where all of a sudden teams that were always deprioritizing that work actually find the time for it. And so then that creates a new expectation for what a product experience feels like. People have less tolerance for that kind of jankiness that pervades a lot of applications.

Douglas Ferguson: Yeah. Not only jankiness, but also I would imagine accessibility requirements. Because that almost becomes no effort required to scan and make sure these-

Joe McLean: No excuse.

Douglas Ferguson: Yeah, exactly. It can point out the issues-

Joe McLean: No excuse now.

Douglas Ferguson: … and correct them for you. The other thing, and this is something I was thinking about earlier, was I love using the inference and probabilistic capabilities of the LLM to generate deterministic things. And so this is one of those traps that the bias around the chat interface traps a lot of people. Because if you’re in that mode, it’s hard to step back and go, wait a second, I don’t have to always ask it to do the thing. I could have it build a tool or a script or a command or a system that does the thing. And it’s not that I’m going to Lovable and saying, “Build me this whole product.” It’s like like I just have this one thing that I need done and I want it to be very consistent every time. And so please do that for me in a way that doesn’t consume tokens. And I think that’s going to be a pattern that hopefully more and more people start to employ because, A, we’ll be less dependent on tokens and data centers, and B, it’ll be less likely to create errors, right?

Joe McLean: Yeah. I mean, this kind of skips across several topics that are super interesting to me right now. One is the topic of personal software, basically building for a user of one. I’ve had a lot of fun experimenting around with that. I read, I think it was a blog post that really influenced me in this direction. And the author’s point was, essentially, think about all the overhead in every product that comes from essentially two things. That that piece of software needed to be designed to scale to tens or hundreds of thousands of users, which created complexity around infrastructure, complexity around how the product itself operates. But then also the fact that, because of that, it also had to be designed as a compromise between those 10,000 people. And so much of the software that we interact with on a daily basis is a product of deep, deep compromises that have been made to serve the deployment scale that was honestly needed to justify the VC money that went into that product. And so you kind of create this perpetual flywheel of a certain expectation of the scope and scale of software and how it’s supposed to be distributed. Some of the most interesting things I’ve seen built at Miro were internal tools only, things for our design team to use. And immediately people start thinking like, oh, well maybe we could monetize this. Maybe we could scale this up. But then you absorb all the complexity that comes along with that. You have to make it accessible to an external environment. You have to think about multi-tenancy, you have to think about security, you have to think about monetization. All these layers that start to come in once you start thinking about deploying software at that scale. And so when you don’t have to think about all that, something changes in your mind. Just to give you a little example, I’ve been having a lot of fun as a weekend project, I’ve just been building myself a little tiny personal streaming service just for me. I have a lot of music from my friend’s bands, MP3 collection that I built up in college. And I just built a little app. It was my weekend project with Fable back in the previous weekend where we had it for 48 hours. And I’ve been getting a kick of just having my own little streaming service, my own Apple Music, Spotify that I’ve been carrying around for the last couple of weeks. It works great. It’s really fun. Hardly has anything in it, but it’s mine. And it doesn’t have the complexity of serving hundreds of thousands or millions of albums. It has one user. Doesn’t even need to have a login system because it’s just me. And there was something really profound about building a software that way, thinking that way. Because it makes you account in a new way for all those compromises and frictions that come from the necessary scale. Obviously, not all of these lessons are applicable if you’re working at a B2B SaaS company, but I still think it’s valuable to build a little bit of intuition for where that line is and where that fabric is. And there’s also a connection here, and this is maybe where it does get more relevant to the world of scaled enterprise software, is thinking about what we really mean when we talk about forward deployed engineers. If we’re talking about people going into a company and building an extremely complex custom solution that sits on top of a larger platform, really interesting to think about what that actually represents in terms of the product that’s being offered to that company. It’s software for a user of one in a sense. I mean, maybe they’re a 10,000 person organization, but you don’t need to think about the complexity of taking that one enterprise feature request, and figuring out how to feature flag it and fold it and deploy it at scale. Maybe you can just build a very custom version that never leaves their premises. And so I’m oversimplifying a little bit, but I think that there’s something quite interesting about challenging the boundary of the assumed deployment scale for software.

Douglas Ferguson: But you’re making me think about how the age-old advice for SaaS companies were configurable maybe, but customizable, no. It’s like we don’t want to be in the business of creating unique installs for each client because it’s so hard to provide customer service and documentation varies. But in this age of AI, it would be possible to manage all divergent help documentation and support requests. And also it’s so quick to build. So maybe it opens a door for that as a possibility nowadays that was not even a path, or a path that all the elders advised against, right?

Joe McLean: Yeah. Yeah, yeah, absolutely. Well, and I think it’s interesting just how linearly, I don’t even know if linearly is the right word, it’s interesting to think how directly, let’s say, interesting to think how directly that stems from the shift in economics of the cost of producing software. The idea was always that you would make this very expensive thing, and then you get all your money back on the infinite scalability of building and deploying and distributing multiple copies of that thing. And it really flips the entire equation all of a sudden if it becomes very cheap and inexpensive to create that thing. Because now the level of customization you can achieve is a lot higher. And it only works if it gets a lot easier to build it. And I think we’re only feeling the very early ripple effects of that shift. At the extreme, you can even think of software that’s created on demand, just-in-time software, voidware, some really out there ideas.

Douglas Ferguson: Well, I wrote down emergent UI, because this is the concept I’ve been thinking about for a bit as you were talking about some of the concepts earlier around personal software. I actually experienced this in some of the stuff I was working on with my agents that I built in Claude Code. And one of my agents is a marketing agent, and the marketing agent has access to all of our marketing tools. And one of the things I was able to do is stitch together the data in ways that I’ve never seen it visualized. Sure, maybe I could have done it with Looker or something, but it was too expensive to go do all that stuff based on the value that I might get from my size company. But my agent was able to do it. And I didn’t even ask for this little UI or interface. It just decided that was the best way for Douglas to consume this information. And now I had this light bulb moment that that’s the future, where products and also chats and other AI interface and experiences are going to be delivering these interfaces that were never predetermined. And it won’t be a full-blown app. It’ll just be a little moment or a little widget that says, hey, this will be an easy way for Douglas to communicate with me right now.

Joe McLean: Yeah. This is one of the most fascinating topics in the world of software development to me right now, what the future of this particular thing is going to be. Going back to the previous topic of behavior shifts, we had a very similar shift that happened with our data team. So I feel like there’s certain groups within the organization that are always trying to get people to read their reports. Our user researchers, the data folks, they get all these amazing insights. And then I think sometimes in just the organizational information environment, it takes more time and attention. You have to give it a lot of focus to be able to understand some of those insights. And so a lot of folks on the data team started distributing these interactive data experiences, where it wasn’t just a report, you could see it and filter it different ways. It was almost like a mini dashboard that had been created for a very specific data set. Again, to your point, not configured on top of Looker, not super heavy, but just one-off for this one data pull that they did. And that was a light bulb moment for me too. I’m like, oh, this HTML embed that’s going in the Miro board now or whatever, that’s a different kind of thing. I don’t even really know what to call that. It’s like a page, it’s a document, it’s a piece of software, it’s an app, it’s a tool. It’s somewhere in the middle of all those. It’s an interactive artifact. And I think this goes all the way back to things we were talking about earlier in this conversation about visualization and communication of information. Now more important than ever, I would argue, and now also very inexpensive. So a data scientist or an analyst on your team who you never would’ve invested a week of a front-end engineer’s time to build an interactive data representation for a report, they can spin that up in a minute, and it makes the information that much easier to understand. And so I think we’re feeling the acceleration in building right now. I don’t think we’re totally feeling the acceleration yet in the ability to communicate information. And it goes back to something you said earlier, which I love, about thinking about storytelling, communication, the new skills that we need to be building. I think that has a deep relationship with the velocity. So as things start to move faster and faster, you need to be able to communicate more and more faster and faster, and that’s going to require new types of artifacts. And so all those kind of merged together for me. I’m thinking about the future of information sharing, especially in large organizations, how that’s going to work.

Douglas Ferguson: Yeah. And when I heard that I can now embed HTML files on the Miro board, that was exciting for me for this very purpose because of my agents building these little HTML applets or whatever we call them. And Miro can be a place where I can share those with the team. That’s amazing. Because emailing these things around is like an ice pick to the brain. And so I actually built a little thing into my agentic harness dashboard where the team can go view them. Much nicer to have a shared Miro board that can be updated on the fly and not have to build your own agentic dashboard. But coming back to the internal tools, I want to get your thoughts on this because this is something that came up as we were chatting. It was like a light bulb for me, that the impacts that this is going to have on design ops and product ops and probably even DevOps, right? Because those teams are very limited by the tools that they had time to build or the tools that are available in the market. And if they can now build more internal tools faster that help the teams do their jobs, I think that’s going to be an interesting space to see explode across organizations.

Joe McLean: Yeah, absolutely. To give some specific examples of tooling that we’ve been building, we have something internally at Miro called VibeLab that a few designers on the team built. It’s super cool. Basically what happened is they were all vibe coding interactive prototypes, and two problems emerged really quickly. First of all, you start to have Git problems with your design. So you’re like, okay, what does it mean to be on the branch that has the new stuff that the team is thinking about? How real is that yet? Has that been merged to main, and how we’re thinking about the future of the design? That has now diverged from the core product experience. So you’ve got your core product experience, you’ve got Mauricio’s thing, you’ve got Tilo’s thing. They kind of go in different directions. How do we merge our designs back together? That was the first problem. Second problem is we’re building all these prototypes. And like you said, I’m trying to email people things. I’m deploying it to Vercel, and I don’t know how to give you a link to it. That’s also insecure. So stuff is just floating around on people’s personal Vercel accounts. All this to say we built VibeLab, the designers internally, we worked on this to solve a lot of those problems. You could think of it as a highly specialized internal only version of some of the same things that Replit and Lovable are doing, but much more focused on allowing people to very easily play in their own sandboxes with Claude Code and just push something up to [inaudible 00:42:15]. So automating away the deployment problems basically, but still staying very flexible in the local environment, which also makes it a lot easier to bring ideas back together. Because then that problem becomes as simple as just pointing Claude to a different branch or a different repo and saying like… them together. So the combination of solving the deployment problem and keeping the working version very light has allowed our design team to move way faster. But then new bottlenecks emerge. So just to give a couple examples, hard to gather feedback on those prototypes. And so we built tools that take the prototypes and print screenshots back into Miro boards so you can annotate them with comments. And I’ve heard of a lot of designers building systems for that sort of thing. Another funny issue, we’re getting ready for the marketing event in May, and at some point folks from the brand and product marketing teams reach across, and they’re like, “We need all the Figma files for the landing page.” And we’re like, “We’re very sorry, but there are none.” We built all of the designs for everything we launched in code. It was built in some cases on top of the live product. And so going back to what you were saying about design ops and tooling, all of that stuff is getting rewired in real time across our organization. New tools are being built. And I think what’s really interesting about a lot of that, going back to personal software, is that I don’t think we would buy an off-the-shelf solution for a lot of these problems. So much of it is tailored to our internal process, our internal stack. I think that’s going to be a common story for internal tools where teams are more and more interested in building their own things. It’s also the maintenance costs are not as big of a problem there. If you’re going to build and ship a feature to your customers, you have a different maintenance obligation than something that you can deprecate internally. It still creates friction, but it’s not quite as severe.

Douglas Ferguson: Easy to go from version two to version three with crazy idiosyncratic changes when it’s an internal tool versus when it’s global. I’m curious, in working in this way, custom tooling, it’s not in Figma anymore. It sounded like Miro was playing a role in some of that with the commenting and stuff. And so these tools are interoperating with Miro. I’m curious how much innovation has that driven to the Canvas because you needed to have access to a certain thing or a new feature or a new doorway for connectivity or what have you. Has it driven much innovation on that side?

Joe McLean: Yeah, I would say on several different fronts. I mean, we use Miro for everything at Miro, maybe unsurprising, but I don’t know if folks realize totally how deep it goes. We use it for an everything. We use it for docs, tables. So much of our organization’s information is there. And as a consequence, the connectivity to external systems is extremely important for us because there’s a lot of valuable information that lives there. We also use it as a system of record for many things. And so as we were building some of the new stuff that we launched at Canvas 26 this year, we all felt a step change internally in our own utility for the tool when we started getting connectors hooked up. So it’s like, okay, well now I can take this big long Slack thread, and I can turn it into a collaborative workspace for the team. Or I can automatically take all those tickets from the team’s Jira board and drop them into Miro and start working with them and reprioritizing. And so because we’re so reliant on it as a tool, the connectivity to the outside pieces helped us a lot in terms of getting our work done. That’d be the first thing I would say. We were pushed to create more interoperability simply because of our own needs for the tool [inaudible 00:46:05] would be obviously quite useful for other people. One of the pieces that I’m paying the most attention to right now, even just in my own work, the initiatives I’m trying to drive at Miro right now, is a lot about our ability to read and write fluidly from Canvas. I think we had to jump through a lot more hoops to be able to do that. We’ve created complex layers of business logic to translate LLM output into board objects. As the models are advancing, we’re finding that the models can work more and more directly [inaudible 00:46:38] Canvas, but there’s still a translation layer needed to be able to get LLM information into board information and vice versa. And so I think one of the key innovation areas we’re pushing forward on now is trying to make that interchange as seamless as possible. Because we’re seeing that as the AI can see more of the board and manipulate the board almost as if it’s a file, we’re able to build much more powerful experiences than we could even a year ago. So that’s one of the main places we’re pushing right now.

Douglas Ferguson: I’m excited about that because I’ve been just blown away by what I’ve been able to do just with the API and my agents. And the API is limited. There’s certain format that it doesn’t have access to. It can’t unlock and lock things and can’t connect flows and stuff. But the amount of stuff that I was able to do saves so much time just getting in there and doing tedious stuff. So I’m excited to see where that goes. But one last question before we go to wrap. One of the things I hear from folks often as we’re working with them on their AI strategy and helping them think about multiplayer AI and starting to have conversations around how they set up their tooling and what makes sense for them long-term. One point of pushback I get is that, yes, I see that it’s more powerful if we can use AI as a team, but it’s almost like they’re addicted to their chat interface that they’ve been on for three years now and has learned so much about them. There’s memory there. They’re worried about losing, it’s almost like breaking up with a girlfriend or boyfriend. It’s like, hey, they know so much about me. This might be better over here, but I don’t know if I want to start all over again. This kind of switching friction. I’m curious your thoughts on that.

Joe McLean: Yeah. I mean, this is a really key topic I think. And it’ll be interesting to see to what extent companies are able to use that as leverage for retention on their products. I think you could argue on one hand that it’s an extremely powerful tool for that. On the other hand, [inaudible 00:48:49] will be huge pressure to start building export tools for that context for exactly that reason. I think there also may be a difference in how personal software, consumer software versus enterprise software, works in this regard. I would be extremely nervous if I were a CTO, was thinking about a vendor, an LLM vendor, Anthropic or OpenAI, capturing my entire organization’s memory with no way to get that information out in a way that would be allowed in platform switching order. And I think you’ll start hearing more and more conversation about this for exactly this reason. I felt this pain myself. One interesting way I felt it is I’m starting to really feel the friction of the segmentation between my personal AI world and my professional AI world. And before Miro paid for subscriptions for the various services, very early on when I was playing, I spent a ton of time at these tools. I have significant history built up in both Claude and ChatGPT. I’ve built strategies to cross-share context between the two of them. There’s a lot of that stuff that I don’t want in my professional LLM world for a variety of reasons, like personal stuff. But then I have the problem of all that context being missing doing my work. And so I am really starting to feel the contours of what my work AI knows versus my personal AI knows. And I think where it really gets wild is I get different results with that. I get a different kind of collaboration from my personal Claude versus my Miro Claude. And I think it’ll be really interesting to watch that trajectory forward, see what happens. Will there be eventually strategies, I’m sure that they’re aware of this problem, will they build strategies to have data security within the AI’s context from what it knows about you so that it has manners in a way to know the right things at the right time? Or are there reasons to keep those hard segmented for data security reasons? Imagine, again, like a CTO or a CIO being very nervous about their employees’ personal AI usage getting anywhere near company information. I am much more liberal in the connectors of data sources I hook up to my personal AI if I [inaudible 00:51:18] AI. And so a lot of really interesting questions ahead of something that we do as humans really naturally where we know how to keep those bullets separate most of the time, hasn’t really translated into the AI realm.

Douglas Ferguson: Yeah, compartmentalization.

Joe McLean: So not a direct answer, but yeah. Yeah. Yeah, exactly. Yeah.

Douglas Ferguson: When I switched to Claude, my ChatGPT became personal at that point. My strategy previously was to use ChatGPT projects if I was cooking or something. So then my cooking stuff didn’t pollute any of my other stuff. But now ChatGPT, I just kind of use that as my lightweight personal stuff. But yeah, I mean, I think that’s the big takeaway. Right now you have to develop your own personal strategies, and hopefully the large frontier models will start thinking about strategies for export and how to solve for that long term. But as we wrap here, I want to give you an opportunity to leave our listeners with a final thought.

Joe McLean: Oh man, put me up on a soapbox here.

Douglas Ferguson: I know. I didn’t warn you ahead of time. I usually warn folks. But I think we were talking too much about the Bouldering Project.

Joe McLean: Yeah, yeah. I think something I’d like to say, I’ve had the good fortune in my career to build tools that people use to be creative. I think that AI is the most amazing creative tool that we’ve ever been handed as humanity. I think incredible things will be created with this technology. I think there’s a dark path too, and I really encourage anyone who hears this, anyone who’s interested in this to build something. I think there’s a fundamental difference in the psychology between asking it questions to get answers or using it instrumentally to create something. And I think the healthy version of our relationship with this technology lies down the second path. And so I think I assume that many people in your audience are product builders and are already of this mindset, but I’ve seen over and over again people’s aha moment with this technology coming from building something that they weren’t able to build before. And I think that that represents a happier future for our relationship with AI.

Douglas Ferguson: Amazing. Thank you so much, Joe. It was a pleasure chatting as always, and look forward to our next one.

Joe McLean: Yeah, it was great to see you. Take care.

Douglas Ferguson: Thanks for listening to New Friction. If you enjoyed this episode, share it with a leader who’s in the middle of this right now. They’ll thank you for it. And if you want to go deeper, we bring leaders together through executive dinners and virtual masterminds. To learn more about our work or to inquire about exclusive executive events, visit voltagecontrol.com. I’m Douglas Ferguson. See you next time.