POPULARITY
Hosted by adam wiggins
3 episodes with adam wiggins
3 episodes with adam wiggins
3 episodes with adam wiggins
3 episodes with adam wiggins
2 episodes with adam wiggins
2 episodes with adam wiggins
3 episodes with adam wiggins
2 episodes with adam wiggins
Today's guest is Adam Wiggins! Adam is the General Manager of Platform at The Browser Company and co-founder of Heroku. With Adam, we talked about innovating user experience in software and AI, we discussed what Local-first software means and we explored the future of developer tools. (02:49) Introduction (04:01) Adam's journey in tech (06:15) The rise of developer experience (10:03) The constant drive of improving UX (12:07) Dia & The Browser Company (14:49) Using AI to improve UX (20:38) Unlocking potentials through UX (25:18) Local-first software (32:34) Data ownership (34:31) Web development and complexity (38:03) AI and the future of development (40:25) The iteration loop — This episode is brought to you by https://workos.com — You can also find this at: -
Editor's note: One of the top reasons we have hundreds of companies and thousands of AI Engineers joining the World's Fair next week is, apart from discussing technology and being present for the big launches planned, to hire and be hired! Listeners loved our previous Elicit episode and were so glad to welcome 2 more members of Elicit back for a guest post (and bonus podcast) on how they think through hiring. Don't miss their AI engineer job description, and template which you can use to create your own hiring plan! How to Hire AI EngineersJames Brady, Head of Engineering @ Elicit (ex Spring, Square, Trigger.io, IBM)Adam Wiggins, Internal Journalist @ Elicit (Cofounder Ink & Switch and Heroku)If you're leading a team that uses AI in your product in some way, you probably need to hire AI engineers. As defined in this article, that's someone with conventional engineering skills in addition to knowledge of language models and prompt engineering, without being a full-fledged Machine Learning expert.But how do you hire someone with this skillset? At Elicit we've been applying machine learning to reasoning tools since 2018, and our technical team is a mix of ML experts and what we can now call AI engineers. This article will cover our process from job description through interviewing. (You can also flip the perspectives here and use it just as easily for how to get hired as an AI engineer!)My own journeyBefore getting into the brass tacks, I want to share my journey to becoming an AI engineer.Up until a few years ago, I was happily working my job as an engineering manager of a big team at a late-stage startup. Like many, I was tracking the rapid increase in AI capabilities stemming from the deep learning revolution, but it was the release of GPT-3 in 2020 which was the watershed moment. At the time, we were all blown away by how the model could string together coherent sentences on demand. (Oh how far we've come since then!)I'd been a professional software engineer for nearly 15 years—enough to have experienced one or two technology cycles—but I could see this was something categorically new. I found this simultaneously exciting and somewhat disconcerting. I knew I wanted to dive into this world, but it seemed like the only path was going back to school for a master's degree in Machine Learning. I started talking with my boss about options for taking a sabbatical or doing a part-time distance learning degree.In 2021, I instead decided to launch a startup focused on productizing new research ideas on ML interpretability. It was through that process that I reached out to Andreas—a leading ML researcher and founder of Elicit—to see if he would be an advisor. Over the next few months, I learned more about Elicit: that they were trying to apply these fascinating technologies to the real-world problems of science, and with a business model that aligned it with safety goals. I realized that I was way more excited about Elicit than I was about my own startup ideas, and wrote about my motivations at the time.Three years later, it's clear this was a seismic shift in my career on the scale of when I chose to leave my comfy engineering job at IBM to go through the Y Combinator program back in 2008. Working with this new breed of technology has been more intellectually stimulating, challenging, and rewarding than I could have imagined.Deep ML expertise not requiredIt's important to note that AI engineers are not ML experts, nor is that their best contribution to a tech team.In our article Living documents as an AI UX pattern, we wrote:It's easy to think that AI advancements are all about training and applying new models, and certainly this is a huge part of our work in the ML team at Elicit. But those of us working in the UX part of the team believe that we have a big contribution to make in how AI is applied to end-user problems.We think of LLMs as a new medium to work with, one that we've barely begun to grasp the contours of. New computing mediums like GUIs in the 1980s, web/cloud in the 90s and 2000s, and multitouch smartphones in the 2000s/2010s opened a whole new era of engineering and design practices. So too will LLMs open new frontiers for our work in the coming decade.To compare to the early era of mobile development: great iOS developers didn't require a detailed understanding of the physics of capacitive touchscreens. But they did need to know the capabilities and limitations of a multi-touch screen, the constrained CPU and storage available, the context in which the user is using it (very different from a webpage or desktop computer), etc.In the same way, an AI engineer needs to work with LLMs as a medium that is fundamentally different from other compute mediums. That means an interest in the ML side of things, whether through their own self-study, tinkering with prompts and model fine-tuning, or following along in #llm-paper-club. But this understanding is so that they can work with the medium effectively versus, say, spending their days training new models.Language models as a chaotic mediumSo if we're not expecting deep ML expertise from AI engineers, what are we expecting? This brings us to what makes LLMs different.We'll assume already that our ideal candidate is already inspired by, and full of ideas about, all the new capabilities AI can bring to software products. But the flip side is all the things that make this new medium difficult to work with. LLM calls are annoying due to high latency (measured in tens of seconds sometimes, rather than milliseconds), extreme variance on latency, high error rates even under normal operation. Not to mention getting extremely different answers to the same prompt provided to the same model on two subsequent calls!The net effect is that an AI engineer, even working at the application development level, needs to have a skillset comparable to distributed systems engineering. Handling errors, retries, asynchronous calls, streaming responses, parallelizing and recombining model calls, the halting problem, and fallbacks are just some of the day-in-the-life of an AI engineer. Chaos engineering gets new life in the era of AI.Skills and qualities in candidatesLet's put together what we don't need (deep ML expertise) with what we do (work with capabilities and limitations of the medium). Thus we start to see what Elicit looks for in AI engineers:* Conventional software engineering skills. Especially back-end engineering on complex, data-intensive applications.* Professional, real-world experience with applications at scale.* Deep, hands-on experience across a few back-end web frameworks.* Light devops and an understanding of infrastructure best practices.* Queues, message buses, event-driven and serverless architectures, … there's no single “correct” approach, but having a deep toolbox to draw from is very important.* A genuine curiosity and enthusiasm for the capabilities of language models.* One or more serious projects (side projects are fine) of using them in interesting ways on a unique domain.* …ideally with some level of factored cognition, e.g. breaking the problem down into chunks, making thoughtful decisions about which things to push to the language model and which stay within the realm of conventional heuristics and compute capabilities.* Personal studying with resources like Elicit's ML reading list. Part of the role is collaborating with the ML engineers and researchers on our team. To do so, the candidate needs to “speak their language” somewhat, just as a mobile engineer needs some familiarity with backends in order to collaborate effectively on API creation with backend engineers.* An understanding of the challenges that come along with working with large models (high latency, variance, etc.) leading to a defensive, fault-first mindset.* Careful and principled handling of error cases, asynchronous code (and ability to reason about and debug it), streaming data, caching, logging and analytics for understanding behavior in production.* This is a similar mindset that one can develop working on conventional apps which are complex, data-intensive, or large-scale apps. The difference is that an AI engineer will need this mindset even when working on relatively small scales!On net, a great AI engineer will combine two seemingly contrasting perspectives: knowledge of, and a sense of wonder for, the capabilities of modern ML models; but also the understanding that this is a difficult and imperfect foundation, and the willingness to build resilient and performant systems on top of it.Here's the resulting AI engineer job description for Elicit. And here's a template that you can borrow from for writing your own JD.Hiring processOnce you know what you're looking for in an AI engineer, the process is not too different from other technical roles. Here's how we do it, broken down into two stages: sourcing and interviewing.SourcingWe're primarily looking for people with (1) a familiarity with and interest in ML, and (2) proven experience building complex systems using web technologies. The former is important for culture fit and as an indication that the candidate will be able to do some light prompt engineering as part of their role. The latter is important because language model APIs are built on top of web standards and—as noted above—aren't always the easiest tools to work with.Only a handful of people have built complex ML-first apps, but fortunately the two qualities listed above are relatively independent. Perhaps they've proven (2) through their professional experience and have some side projects which demonstrate (1).Talking of side projects, evidence of creative and original prototypes is a huge plus as we're evaluating candidates. We've barely scratched the surface of what's possible to build with LLMs—even the current generation of models—so candidates who have been willing to dive into crazy “I wonder if it's possible to…” ideas have a huge advantage.InterviewingThe hard skills we spend most of our time evaluating during our interview process are in the “building complex systems using web technologies” side of things. We will be checking that the candidate is familiar with asynchronous programming, defensive coding, distributed systems concepts and tools, and display an ability to think about scaling and performance. They needn't have 10+ years of experience doing this stuff: even junior candidates can display an aptitude and thirst for learning which gives us confidence they'll be successful tackling the difficult technical challenges we'll put in front of them.One anti-pattern—something which makes my heart sink when I hear it from candidates—is that they have no familiarity with ML, but claim that they're excited to learn about it. The amount of free and easily-accessible resources available is incredible, so a motivated candidate should have already dived into self-study.Putting all that together, here's the interview process that we follow for AI engineer candidates:* 30-minute introductory conversation. Non-technical, explaining the interview process, answering questions, understanding the candidate's career path and goals.* 60-minute technical interview. This is a coding exercise, where we play product manager and the candidate is making changes to a little web app. Here are some examples of topics we might hit upon through that exercise:* Update API endpoints to include extra metadata. Think about appropriate data types. Stub out frontend code to accept the new data.* Convert a synchronous REST API to an asynchronous streaming endpoint.* Cancellation of asynchronous work when a user closes their tab.* Choose an appropriate data structure to represent the pending, active, and completed ML work which is required to service a user request.* 60–90 minute non-technical interview. Walk through the candidate's professional experience, identifying high and low points, getting a grasp of what kinds of challenges and environments they thrive in.* On-site interviews. Half a day in our office in Oakland, meeting as much of the team as possible: more technical and non-technical conversations.The frontier is wide openAlthough Elicit is perhaps further along than other companies on AI engineering, we also acknowledge that this is a brand-new field whose shape and qualities are only just now starting to form. We're looking forward to hearing how other companies do this and being part of the conversation as the role evolves.We're excited for the AI Engineer World's Fair as another next step for this emerging subfield. And of course, check out the Elicit careers page if you're interested in joining our team.Podcast versionTimestamps* [00:00:24] Intros* [00:05:25] Defining the Hiring Process* [00:08:42] Defensive AI Engineering as a chaotic medium* [00:10:26] Tech Choices for Defensive AI Engineering* [00:14:04] How do you Interview for Defensive AI Engineering* [00:19:25] Does Model Shadowing Work?* [00:22:29] Is it too early to standardize Tech stacks?* [00:32:02] Capabilities: Offensive AI Engineering* [00:37:24] AI Engineering Required Knowledge* [00:40:13] ML First Mindset* [00:45:13] AI Engineers and Creativity* [00:47:51] Inside of Me There Are Two Wolves* [00:49:58] Sourcing AI Engineers* [00:58:45] Parting ThoughtsTranscript[00:00:00] swyx: Okay, so welcome to the Latent Space Podcast. This is another remote episode that we're recording. This is the first one that we're doing around a guest post. And I'm very honored to have two of the authors of the post with me, James and Adam from Elicit. Welcome, James. Welcome, Adam.[00:00:22] James Brady: Thank you. Great to be here.[00:00:23] Hey there.[00:00:24] Intros[00:00:24] swyx: Okay, so I think I will do this kind of in order. I think James, you're, you're sort of the primary author. So James, you are head of engineering at Elicit. You also, We're VP Eng at Teespring and Spring as well. And you also , you have a long history in sort of engineering. How did you, , find your way into something like Elicit where, , it's, you, you are basically traditional sort of VP Eng, VP technology type person moving into a more of an AI role.[00:00:53] James Brady: Yeah, that's right. It definitely was something of a Sideways move if not a left turn. So the story there was I'd been doing, as you said, VP technology, CTO type stuff for around about 15 years or so, and Notice that there was this crazy explosion of capability and interesting stuff happening within AI and ML and language models, that kind of thing.[00:01:16] I guess this was in 2019 or so, and decided that I needed to get involved. , this is a kind of generational shift. And Spent maybe a year or so trying to get up to speed on the state of the art, reading papers, reading books, practicing things, that kind of stuff. Was going to found a startup actually in in the space of interpretability and transparency, and through that met Andreas, who has obviously been on the, on the podcast before asked him to be an advisor for my startup, and he countered with, maybe you'd like to come and run the engineering team at Elicit, which it turns out was a much better idea.[00:01:48] And yeah, I kind of quickly changed in that direction. So I think some of the stuff that we're going to be talking about today is how actually a lot of the work when you're building applications with AI and ML looks and smells and feels much more like conventional software engineering with a few key differences rather than really deep ML stuff.[00:02:07] And I think that's one of the reasons why I was able to transfer skills over from one place to the other.[00:02:12] swyx: Yeah, I[00:02:12] James Brady: definitely[00:02:12] swyx: agree with that. I, I do often say that I think AI engineering is about 90 percent software engineering with like the, the 10 percent of like really strong really differentiated AI engineering.[00:02:22] And that might, that obviously that number might change over time. I want to also welcome Adam onto my podcast because you welcomed me onto your podcast two years ago.[00:02:31] Adam Wiggins: Yeah, that was a wonderful episode.[00:02:32] swyx: That was, that was a fun episode. You famously founded Heroku. You just wrapped up a few years working on Muse.[00:02:38] And now you've described yourself as a journalist, internal journalist working on Elicit.[00:02:43] Adam Wiggins: Yeah, well I'm kind of a little bit in a wandering phase here and trying to take this time in between ventures to see what's out there in the world and some of my wandering took me to the Elicit team. And found that they were some of the folks who were doing the most interesting, really deep work in terms of taking the capabilities of language models and applying them to what I feel like are really important problems.[00:03:08] So in this case, science and literature search and, and, and that sort of thing. It fits into my general interest in tools and productivity software. I, I think of it as a tool for thought in many ways, but a tool for science, obviously, if we can accelerate that discovery of new medicines and things like that, that's, that's just so powerful.[00:03:24] But to me, it's a. It's kind of also an opportunity to learn at the feet of some real masters in this space, people who have been working on it since it was, before it was cool, if you want to put it that way. So for me, the last couple of months have been this crash course, and why I sometimes describe myself as an internal journalist is I'm helping to write some, some posts, including Supporting James in this article here we're doing for latent space where I'm just bringing my writing skill and that sort of thing to bear on their very deep domain expertise around language models and applying them to the real world and kind of surface that in a way that's I don't know, accessible, legible, that, that sort of thing.[00:04:03] And so, and the great benefit to me is I get to learn this stuff in a way that I don't think I would, or I haven't, just kind of tinkering with my own side projects.[00:04:12] swyx: I forgot to mention that you also run Ink and Switch, which is one of the leading research labs, in my mind, of the tools for thought productivity space, , whatever people mentioned there, or maybe future of programming even, a little bit of that.[00:04:24] As well. I think you guys definitely started the local first wave. I think there was just the first conference that you guys held. I don't know if you were personally involved.[00:04:31] Adam Wiggins: Yeah, I was one of the co organizers along with a few other folks for, yeah, called Local First Conf here in Berlin.[00:04:36] Huge success from my, my point of view. Local first, obviously, a whole other topic we can talk about on another day. I think there actually is a lot more what would you call it , handshake emoji between kind of language models and the local first data model. And that was part of the topic of the conference here, but yeah, topic for another day.[00:04:55] swyx: Not necessarily. I mean , I, I selected as one of my keynotes, Justine Tunney, working at LlamaFall in Mozilla, because I think there's a lot of people interested in that stuff. But we can, we can focus on the headline topic. And just to not bury the lead, which is we're talking about hire, how to hire AI engineers, this is something that I've been looking for a credible source on for months.[00:05:14] People keep asking me for my opinions. I don't feel qualified to give an opinion and it's not like I have. So that's kind of defined hiring process that I'm super happy with, even though I've worked with a number of AI engineers.[00:05:25] Defining the Hiring Process[00:05:25] swyx: I'll just leave it open to you, James. How was your process of defining your hiring, hiring roles?[00:05:31] James Brady: Yeah. So I think the first thing to say is that we've effectively been hiring for this kind of a role since before you, before you coined the term and tried to kind of build this understanding of what it was.[00:05:42] So, which is not a bad thing. Like it's, it was a, it was a good thing. A concept, a concept that was coming to the fore and effectively needed a name, which is which is what you did. So the reason I mentioned that is I think it was something that we kind of backed into, if you will. We didn't sit down and come up with a brand new role from, from scratch of this is a completely novel set of responsibilities and skills that this person would need.[00:06:06] However, it is a A kind of particular blend of different skills and attitudes and and curiosities interests, which I think makes sense to kind of bundle together. So in the, in the post, the three things that we say are most important for a highly effective AI engineer are first of all, conventional software engineering skills, which is Kind of a given, but definitely worth mentioning.[00:06:30] The second thing is a curiosity and enthusiasm for machine learning and maybe in particular language models. That's certainly true in our case. And then the third thing is to do with basically a fault first mindset, being able to build systems that can handle things going wrong in, in, in some sense.[00:06:49] And yeah, the I think the kind of middle point, the curiosity about ML and language models is probably fairly self evident. They're going to be working with, and prompting, and dealing with the responses from these models, so that's clearly relevant. The last point, though, maybe takes the most explaining.[00:07:07] To do with this fault first mindset and the ability to, to build resilient systems. The reason that is, is so important is because compared to normal APIs, where normal, think of something like a Stripe API or a search API or something like this. The latency when you're working with language models is, is wild, like you can get 10x variation.[00:07:32] I mean, I was looking at the stats before, actually, before, before the podcast. We do often, normally, in fact, see a 10x variation in the P90 latency over the course of, Half an hour, an hour when we're prompting these models, which is way higher than if you're working with a, more kind of conventional conventionally backed API.[00:07:49] And the responses that you get, the actual content and the responses are naturally unpredictable as well. They come back with different formats. Maybe you're expecting JSON. It's not quite JSON. You have to handle this stuff. And also the, the semantics of the messages are unpredictable too, which is, which is a good thing.[00:08:08] Like this is one of the things that you're looking for from these language models, but it all adds up to needing to. Build a resilient, reliable, solid feeling system on top of this fundamentally, well, certainly currently fundamentally shaky foundation. The models do not behave in the way that you would like them to.[00:08:28] And yeah, the ability to structure the code around them such that it does give the user this warm, reassuring, Snappy, solid feeling is is really what we're driving for there.[00:08:42] Defensive AI Engineering as a chaotic medium[00:08:42] Adam Wiggins: What really struck me as we, we dug in on the content for this article was that third point there. The, the language models is this kind of chaotic medium, this, this dragon, this wild horse you're, you're, you're riding and trying to guide in the direction that is going to be useful and reliable to users, because I think.[00:08:58] So much of software engineering is about making things not only high performance and snappy, but really just making it stable, reliable, predictable, which is literally the opposite of what you get from from the language models. And yet, yeah, the output is so useful, and indeed, some of their Creativity, if you want to call it that, which is, is precisely their value.[00:09:19] And so you need to work with this medium. And I guess the nuanced or the thing that came out of Elissa's experience that I thought was so interesting is quite a lot of working with that is things that come from distributed systems engineering. But you have really the AI engineers as we're defining them or, or labeling them on the illicit team is people who are really application developers.[00:09:39] You're building things for end users. You're thinking about, okay, I need to populate this interface with some response to user input. That's useful to the tasks they're trying to do, but you have this. This is the thing, this medium that you're working with that in some ways you need to apply some of this chaos engineering, distributed systems engineering, which typically those people with those engineering skills are not kind of the application level developers with the product mindset or whatever, they're more deep in the guts of a, of a system.[00:10:07] And so it's, those, those skills and, and knowledge do exist throughout the engineering discipline, but sort of putting them together into one person that is That feels like sort of a unique thing and working with the folks on the Elicit team who have that skills I'm quite struck by that unique that unique blend.[00:10:23] I haven't really seen that before in my 30 year career in technology.[00:10:26] Tech Choices for Defensive AI Engineering[00:10:26] swyx: Yeah, that's a Fascinating I like the reference to chaos engineering. I have some appreciation, I think when you had me on your podcast, I was still working at Temporal and that was like a nice Framework, if you live within Temporal's boundaries, you can pretend that all those faults don't exist, and you can, you can code in a sort of very fault tolerant way.[00:10:47] What is, what is you guys solutions around this, actually? Like, I think you're, you're emphasizing having the mindset, but maybe naming some technologies would help? Not saying that you have to adopt these technologies, but they're just, they're just quick vectors into what you're talking about when you're, when you're talking about distributed systems.[00:11:03] Like, that's such a big, chunky word, , like are we talking, are Kubernetes or, and I suspect we're not, , like we're, we're talking something else now.[00:11:10] James Brady: Yeah, that's right. It's more at the application level rather than at the infrastructure level, at least, at least the way that it works for us.[00:11:17] So there's nothing kind of radically novel here. It is more a careful application of existing concepts. So the kinds of tools that we reach for to handle these kind of slightly chaotic objects that Adam was just talking about, are retries and fallbacks and timeouts and careful error handling. And, yeah, the standard stuff, really.[00:11:39] There's also a great degree of dependence. We rely heavily on parallelization because, , these language models are not innately very snappy, and , there's just a lot of I. O. going back and forth. So All these things I'm talking about when I was in my earlier stages of a career, these are kind of the things that are the difficult parts that most senior software engineers will be better at.[00:12:01] It is careful error handling, and concurrency, and fallbacks, and distributed systems, and, , eventual consistency, and all this kind of stuff and As Adam was saying, the kind of person that is deep in the guts of some kind of distributed systems, a really high, high scale backend kind of a problem would probably naturally have these kinds of skills.[00:12:21] But you'll find them on, on day one, if you're building a, , an ML powered app, even if it's not got massive scale. I think one one thing that I would mention that we do do yeah, maybe, maybe two related things, actually. The first is we're big fans of strong typing. We share the types all the way from the Backend Python code all the way to the to the front end in TypeScript and find that is I mean We'd probably do this anyway But it really helps one reason around the shapes of the data which can going to be going back and forth and that's really important When you can't rely upon You you're going to have to coerce the data that you get back from the ML if you want if you want for it to be structured basically speaking and The second thing which is related is we use checked exceptions inside our Python code base, which means that we can use the type system to make sure we are handling, properly handling, all of the, the various things that could be going wrong, all the different exceptions that could be getting raised.[00:13:16] So, checked exceptions are not, not really particularly popular. Actually there's not many people that are big fans of them. For our particular use case, to really make sure that we've not just forgotten to handle, , This particular type of error we have found them useful to to, to force us to think about all the different edge cases that can come up.[00:13:32] swyx: Fascinating. How just a quick note of technology. How do you share types from Python to TypeScript? Do you, do you use GraphQL? Do you use something[00:13:39] James Brady: else? We don't, we don't use GraphQL. Yeah. So we've got the We've got the types defined in Python, that's the source of truth. And we go from the OpenAPI spec, and there's a, there's a tool that you work and use to generate types dynamically, like TypeScript types from those OpenAPI definitions.[00:13:57] swyx: Okay, excellent. Okay, cool. Sorry, sorry for diving into that rabbit hole a little bit. I always like to spell out technologies for people to dig their teeth into.[00:14:04] How do you Interview for Defensive AI Engineering[00:14:04] swyx: One thing I'll, one thing I'll mention quickly is that a lot of the stuff that you mentioned is typically not part of the normal interview loop.[00:14:10] It's actually really hard to interview for because this is the stuff that you polish out in, as you go into production, the coding interviews are typically about the happy path. How do we do that? How do we, how do we design, how do you look for a defensive fault first mindset?[00:14:24] Because you can defensive code all day long and not add functionality. to your to your application.[00:14:29] James Brady: Yeah, it's a great question and I think that's exactly true. Normally the interview is about the happy path and then there's maybe a box checking exercise at the end of the candidate says of course in reality I would handle the edge cases or something like this and that unfortunately isn't isn't quite good enough when when the happy path is is very very narrow and yeah there's lots of weirdness on either side so basically speaking, it's just a case of, of foregrounding those kind of concerns through the interview process.[00:14:58] It's, there's, there's no magic to it. We, we talk about this in the, in the po in the post that we're gonna be putting up on, on Laton space. The, there's two main technical exercises that we do through our interview process for this role. The first is more coding focus, and the second is more system designy.[00:15:16] Yeah. White whiteboarding a potential solution. And in, without giving too much away in the coding exercise. You do need to think about edge cases. You do need to think about errors. The exercise consists of adding features and fixing bugs inside the code base. And in both of those two cases, it does demand, because of the way that we set the application up and the interview up, it does demand that you think about something other than the happy path.[00:15:41] But your thinking is the right prompt of how do we get the candidate thinking outside of the, the kind of normal Sweet spot, smooth smooth, smoothly paved path. In terms of the system design interview, that's a little easier to prompt this kind of fault first mindset because it's very easy in that situation just to say, let's imagine that, , this node dies, how does the app still work?[00:16:03] Let's imagine that this network is, is going super slow. Let's imagine that, I don't know, like you, you run out of, you run out of capacity in, in, in this database that you've sketched out here, how do you handle that, that, that sort of stuff. So. It's, in both cases, they're not firmly anchored to and built specifically around language models and ways language models can go wrong, but we do exercise the same muscles of thinking defensively and yeah, foregrounding the edge cases, basically.[00:16:32] Adam Wiggins: James, earlier there you mentioned retries. And this is something that I think I've seen some interesting debates internally about things regarding, first of all, retries are, can be costly, right? In general, this medium, in addition to having this incredibly high variance and response rate, and, , being non deterministic, is actually quite expensive.[00:16:50] And so, in many cases, doing a retry when you get a fail does make sense, but actually that has an impact on cost. And so there is Some sense to which, at least I've seen the AI engineers on our team, worry about that. They worry about, okay, how do we give the best user experience, but balance that against what the infrastructure is going to, , is going to cost our company, which I think is again, an interesting mix of, yeah, again, it's a little bit the distributed system mindset, but it's also a product perspective and you're thinking about the end user experience, but also the.[00:17:22] The bottom line for the business, you're bringing together a lot of a lot of qualities there. And there's also the fallback case, which is kind of, kind of a related or adjacent one. I think there was also a discussion on that internally where, I think it maybe was search, there was something recently where there was one of the frontline search providers was having some, yeah, slowness and outages, and essentially then we had a fallback, but essentially that gave people for a while, especially new users that come in that don't the difference, they're getting a They're getting worse results for their search.[00:17:52] And so then you have this debate about, okay, there's sort of what is correct to do from an engineering perspective, but then there's also what actually is the best result for the user. Is giving them a kind of a worse answer to their search result better, or is it better to kind of give them an error and be like, yeah, sorry, it's not working right at the moment, try again.[00:18:12] Later, both are obviously non optimal, but but this is the kind of thing I think that that you run into or, or the kind of thing we need to grapple with a lot more than you would other kinds of, of mediums.[00:18:24] James Brady: Yeah, that's a really good example. I think it brings to the fore the two different things that you could be optimizing for of uptime and response at all costs on one end of the spectrum and then effectively fragility, but kind of, if you get a response, it's the best response we can come up with at the other end of the spectrum.[00:18:43] And where you want to land there kind of depends on, well, it certainly depends on the app, obviously depends on the user. I think it depends on the, feature within the app as well. So in the search case that you, that you mentioned there, in retrospect, we probably didn't want to have the fallback. And we've actually just recently on Monday, changed that to Show an error message rather than giving people a kind of degraded experience in other situations We could use for example a large language model from a large language model from provider B rather than provider A and Get something which is within the A few percentage points performance, and that's just a really different situation.[00:19:21] So yeah, like any interesting question, the answer is, it depends.[00:19:25] Does Model Shadowing Work?[00:19:25] swyx: I do hear a lot of people suggesting I, let's call this model shadowing as a defensive technique, which is, if OpenAI happens to be down, which, , happens more often than people think then you fall back to anthropic or something.[00:19:38] How realistic is that, right? Like you, don't you have to develop completely different prompts for different models and won't the, won't the performance of your application suffer from whatever reason, right? Like it may be caused differently or it's not maintained in the same way. I, I think that people raise this idea of fallbacks to models, but I don't think it's, I don't, I don't see it practiced very much.[00:20:02] James Brady: Yeah, it is, you, you definitely need to have a different prompt if you want to stay within a few percentage points degradation Like I, like I said before, and that certainly comes at a cost, like fallbacks and backups and things like this It's really easy for them to go stale and kind of flake out on you because they're off the beaten track And In our particular case inside of Elicit, we do have fallbacks for a number of kind of crucial functions where it's going to be very obvious if something has gone wrong, but we don't have fallbacks in all cases.[00:20:40] It really depends on a task to task basis throughout the app. So I can't give you a kind of a, a single kind of simple rule of thumb for, in this case, do this. And in the other, do that. But yeah, we've it's a little bit easier now that the APIs between the anthropic models and opening are more similar than they used to be.[00:20:59] So we don't have two totally separate code paths with different protocols, like wire protocols to, to speak, which makes things easier, but you're right. You do need to have different prompts if you want to, have similar performance across the providers.[00:21:12] Adam Wiggins: I'll also note, just observing again as a relative newcomer here, I was surprised, impressed, not sure what the word is for it, at the blend of different backends that the team is using.[00:21:24] And so there's many The product presents as kind of one single interface, but there's actually several dozen kind of main paths. There's like, for example, the search versus a data extraction of a certain type, versus chat with papers, versus And each one of these, , the team has worked very hard to pick the right Model for the job and craft the prompt there, but also is constantly testing new ones.[00:21:48] So a new one comes out from either, from the big providers or in some cases, Our own models that are , running on, on essentially our own infrastructure. And sometimes that's more about cost or performance, but the point is kind of switching very fluidly between them and, and very quickly because this field is moving so fast and there's new ones to choose from all the time is like part of the day to day, I would say.[00:22:11] So it isn't more of a like, there's a main one, it's been kind of the same for a year, there's a fallback, but it's got cobwebs on it. It's more like which model and which prompt is changing weekly. And so I think it's quite, quite reasonable to to, to, to have a fallback that you can expect might work.[00:22:29] Is it too early to standardize Tech stacks?[00:22:29] swyx: I'm curious because you guys have had experience working at both, , Elicit, which is a smaller operation and, and larger companies. A lot of companies are looking at this with a certain amount of trepidation as, as, , it's very chaotic. When you have, when you have , one engineering team that, that, knows everyone else's names and like, , they, they, they, they meet constantly in Slack and knows what's going on.[00:22:50] It's easier to, to sync on technology choices. When you have a hundred teams, all shipping AI products and all making their own independent tech choices. It can be, it can be very hard to control. One solution I'm hearing from like the sales forces of the worlds and Walmarts of the world is that they are creating their own AI gateway, right?[00:23:05] Internal AI gateway. This is the one model hub that controls all the things and has our standards. Is that a feasible thing? Is that something that you would want? Is that something you have and you're working towards? What are your thoughts on this stuff? Like, Centralization of control or like an AI platform internally.[00:23:22] James Brady: Certainly for larger organizations and organizations that are doing things which maybe are running into HIPAA compliance or other, um, legislative tools like that. It could make a lot of sense. Yeah. I think for the TLDR for something like Elicit is we are small enough, as you indicated, and need to have full control over all the levers available and switch between different models and different prompts and whatnot, as Adam was just saying, that that kind of thing wouldn't work for us.[00:23:52] But yeah, I've spoken with and, um, advised a couple of companies that are trying to sell into that kind of a space or at a larger stage, and it does seem to make a lot of sense for them. So, for example, if you're trying to sell If you're looking to sell to a large enterprise and they cannot have any data leaving the EU, then you need to be really careful about someone just accidentally putting in, , the sort of US East 1 GPT 4 endpoints or something like this.[00:24:22] I'd be interested in understanding better what the specific problem is that they're looking to solve with that, whether it is to do with data security or centralization of billing, or if they have a kind of Suite of prompts or something like this that people can choose from so they don't need to reinvent the wheel again and again I wouldn't be able to say without understanding the problems and their proposed solutions , which kind of situations that be better or worse fit for but yeah for illicit where really the The secret sauce, if there is a secret sauce, is which models we're using, how we're using them, how we're combining them, how we're thinking about the user problem, how we're thinking about all these pieces coming together.[00:25:02] You really need to have all of the affordances available to you to be able to experiment with things and iterate rapidly. And generally speaking, whenever you put these kind of layers of abstraction and control and generalization in there, that, that gets in the way. So, so for us, it would not work.[00:25:19] Adam Wiggins: Do you feel like there's always a tendency to want to reach for standardization and abstractions pretty early in a new technology cycle?[00:25:26] There's something comforting there, or you feel like you can see them, or whatever. I feel like there's some of that discussion around lang chain right now. But yeah, this is not only so early, but also moving so fast. , I think it's . I think it's tough to, to ask for that. That's, that's not the, that's not the space we're in, but the, yeah, the larger an organization, the more that's your, your default is to, to, to want to reach for that.[00:25:48] It, it, it's a sort of comfort.[00:25:51] swyx: Yeah, I find it interesting that you would say that , being a founder of Heroku where , you were one of the first platforms as a service that more or less standardized what, , that sort of early developer experience should have looked like.[00:26:04] And I think basically people are feeling the differences between calling various model lab APIs and having an actual AI platform where. , all, all their development needs are thought of for them. , it's, it's very much, and, and I, I defined this in my AI engineer post as well.[00:26:19] Like the model labs just see their job ending at serving models and that's about it. But actually the responsibility of the AI engineer has to fill in a lot of the gaps beyond that. So.[00:26:31] Adam Wiggins: Yeah, that's true. I think, , a huge part of the exercise with Heroku, which It was largely inspired by Rails, which itself was one of the first frameworks to standardize the SQL database.[00:26:42] And people had been building apps like that for many, many years. I had built many apps. I had made my own templates based on that. I think others had done it. And Rails came along at the right moment. We had been doing it long enough that you see the patterns and then you can say look let's let's extract those into a framework that's going to make it not only easier to build for the experts but for people who are relatively new the best practices are encoded into you.[00:27:07] That framework, , Model View Controller, to take one example. But then, yeah, once you see that, and once you experience the power of a framework, and again, it's so comforting, and you can develop faster, and it's easier to onboard new people to it because you have these standards. And this consistency, then folks want that for something new that's evolving.[00:27:29] Now here I'm thinking maybe if you fast forward a little to, for example, when React came on the on the scene, , a decade ago or whatever. And then, okay, we need to do state management. What's that? And then there's, , there's a new library every six months. Okay, this is the one, this is the gold standard.[00:27:42] And then, , six months later, that's deprecated. Because of course, it's evolving, you need to figure it out, like the tacit knowledge and the experience of putting it in practice and seeing what those real What those real needs are are, are critical, and so it's, it is really about finding the right time to say yes, we can generalize, we can make standards and abstractions, whether it's for a company, whether it's for, , a library, an open source library, for a whole class of apps and it, it's very much a, much more of a A judgment call slash just a sense of taste or , experience to be able to say, Yeah, we're at the right point.[00:28:16] We can standardize this. But it's at least my, my very, again, and I'm so new to that, this world compared to you both, but my, my sense is, yeah, still the wild west. That's what makes it so exciting and feels kind of too early for too much. too much in the way of standardized abstractions. Not that it's not interesting to try, but , you can't necessarily get there in the same way Rails did until you've got that decade of experience of whatever building different classes of apps in that, with that technology.[00:28:45] James Brady: Yeah, it's, it's interesting to think about what is going to stay more static and what is expected to change over the coming five years, let's say. Which seems like when I think about it through an ML lens, it's an incredibly long time. And if you just said five years, it doesn't seem, doesn't seem that long.[00:29:01] I think that, that kind of talks to part of the problem here is that things that are moving are moving incredibly quickly. I would expect, this is my, my hot take rather than some kind of official carefully thought out position, but my hot take would be something like the You can, you'll be able to get to good quality apps without doing really careful prompt engineering.[00:29:21] I don't think that prompt engineering is going to be a kind of durable differential skill that people will, will hold. I do think that, The way that you set up the ML problem to kind of ask the right questions, if you see what I mean, rather than the specific phrasing of exactly how you're doing chain of thought or few shot or something in the prompt I think the way that you set it up is, is probably going to be remain to be trickier for longer.[00:29:47] And I think some of the operational challenges that we've been talking about of wild variations in, in, in latency, And handling the, I mean, one way to think about these models is the first lesson that you learn when, when you're an engineer, software engineer, is that you need to sanitize user input, right?[00:30:05] It was, I think it was the top OWASP security threat for a while. Like you, you have to sanitize and validate user input. And we got used to that. And it kind of feels like this is the, The shell around the app and then everything else inside you're kind of in control of and you can grasp and you can debug, etc.[00:30:22] And what we've effectively done is, through some kind of weird rearguard action, we've now got these slightly chaotic things. I think of them more as complex adaptive systems, which , related but a bit different. Definitely have some of the same dynamics. We've, we've injected these into the foundations of the, of the app and you kind of now need to think with this defined defensive mindset downwards as well as upwards if you, if you see what I mean.[00:30:46] So I think it would gonna, it's, I think it will take a while for us to truly wrap our heads around that. And also these kinds of problems where you have to handle things being unreliable and slow sometimes and whatever else, even if it doesn't happen very often, there isn't some kind of industry wide accepted way of handling that at massive scale.[00:31:10] There are definitely patterns and anti patterns and tools and whatnot, but it's not like this is a solved problem. So I would expect that it's not going to go down easily as a, as a solvable problem at the ML scale either.[00:31:23] swyx: Yeah, excellent. I would describe in, in the terminology of the stuff that I've written in the past, I describe this inversion of architecture as sort of LLM at the core versus LLM or code at the core.[00:31:34] We're very used to code at the core. Actually, we can scale that very well. When we build LLM core apps, we have to realize that the, the central part of our app that's orchestrating things is actually prompt, prone to, , prompt injections and non determinism and all that, all that good stuff.[00:31:48] I, I did want to move the conversation a little bit from the sort of defensive side of things to the more offensive or, , the fun side of things, capabilities side of things, because that is the other part. of the job description that we kind of skimmed over. So I'll, I'll repeat what you said earlier.[00:32:02] Capabilities: Offensive AI Engineering[00:32:02] swyx: It's, you want people to have a genuine curiosity and enthusiasm for the capabilities of language models. We just, we're recording this the day after Anthropic just dropped Cloud 3. 5. And I was wondering, , maybe this is a good, good exercise is how do people have Curiosity and enthusiasm for capabilities language models when for example the research paper for cloud 3.[00:32:22] 5 is four pages[00:32:23] James Brady: Maybe that's not a bad thing actually in this particular case So yeah If you really want to know exactly how the sausage was made That hasn't been possible for a few years now in fact for for these new models but from our perspective as when we're building illicit What we primarily care about is what can these models do?[00:32:41] How do they perform on the tasks that we already have set up and the evaluations we have in mind? And then on a slightly more expansive note, what kinds of new capabilities do they seem to have? Can we elicit, no pun intended, from the models? For example, well, there's, there's very obvious ones like multimodality , there wasn't that and then there was that, or it could be something a bit more subtle, like it seems to be getting better at reasoning, or it seems to be getting better at metacognition, or Or it seems to be getting better at marking its own work and giving calibrated confidence estimates, things like this.[00:33:19] So yeah, there's, there's plenty to be excited about there. It's just that yeah, there's rightly or wrongly been this, this, this shift over the last few years to not give all the details. So no, but from application development perspective we, every time there's a new model release, there's a flow of activity in our Slack, and we try to figure out what's going on.[00:33:38] What it can do, what it can't do, run our evaluation frameworks, and yeah, it's always an exciting, happy day.[00:33:44] Adam Wiggins: Yeah, from my perspective, what I'm seeing from the folks on the team is, first of all, just awareness of the new stuff that's coming out, so that's, , an enthusiasm for the space and following along, and then being able to very quickly, partially that's having Slack to do this, but be able to quickly map that to, okay, What does this do for our specific case?[00:34:07] And that, the simple version of that is, let's run the evaluation framework, which Lissa has quite a comprehensive one. I'm actually working on an article on that right now, which I'm very excited about, because it's a very interesting world of things. But basically, you can just try, not just, but try the new model in the evaluations framework.[00:34:27] Run it. It has a whole slew of benchmarks, which includes not just Accuracy and confidence, but also things like performance, cost, and so on. And all of these things may trade off against each other. Maybe it's actually, it's very slightly worse, but it's way faster and way cheaper, so actually this might be a net win, for example.[00:34:46] Or, it's way more accurate. But that comes at its slower and higher cost, and so now you need to think about those trade offs. And so to me, coming back to the qualities of an AI engineer, especially when you're trying to hire for them, It's this, it's, it is very much an application developer in the sense of a product mindset of What are our users or our customers trying to do?[00:35:08] What problem do they need solved? Or what what does our product solve for them? And how does the capabilities of a particular model potentially solve that better for them than what exists today? And by the way, what exists today is becoming an increasingly gigantic cornucopia of things, right? And so, You say, okay, this new model has these capabilities, therefore, , the simple version of that is plug it into our existing evaluations and just look at that and see if it, it seems like it's better for a straight out swap out, but when you talk about, for example, you have multimodal capabilities, and then you say, okay, wait a minute, actually, maybe there's a new feature or a whole new There's a whole bunch of ways we could be using it, not just a simple model swap out, but actually a different thing we could do that we couldn't do before that would have been too slow, or too inaccurate, or something like that, that now we do have the capability to do.[00:35:58] I think of that as being a great thing. I don't even know if I want to call it a skill, maybe it's even like an attitude or a perspective, which is a desire to both be excited about the new technology, , the new models and things as they come along, but also holding in the mind, what does our product do?[00:36:16] Who is our user? And how can we connect the capabilities of this technology to how we're helping people in whatever it is our product does?[00:36:25] James Brady: Yeah, I'm just looking at one of our internal Slack channels where we talk about things like new new model releases and that kind of thing And it is notable looking through these the kind of things that people are excited about and not It's, I don't know the context, the context window is much larger, or it's, look at how many parameters it has, or something like this.[00:36:44] It's always framed in terms of maybe this could be applied to that kind of part of Elicit, or maybe this would open up this new possibility for Elicit. And, as Adam was saying, yeah, I don't think it's really a I don't think it's a novel or separate skill, it's the kind of attitude I would like to have all engineers to have at a company our stage, actually.[00:37:05] And maybe more generally, even, which is not just kind of getting nerd sniped by some kind of technology number, fancy metric or something, but how is this actually going to be applicable to the thing Which matters in the end. How is this going to help users? How is this going to help move things forward strategically?[00:37:23] That kind of, that kind of thing.[00:37:24] AI Engineering Required Knowledge[00:37:24] swyx: Yeah, applying what , I think, is, is, is the key here. Getting hands on as well. I would, I would recommend a few resources for people listening along. The first is Elicit's ML reading list, which I, I found so delightful after talking with Andreas about it.[00:37:38] It looks like that's part of your onboarding. We've actually set up an asynchronous paper club instead of my discord for people following on that reading list. I love that you separate things out into tier one and two and three, and that gives people a factored cognition way of Looking into the, the, the corpus, right?[00:37:55] Like yes, the, the corpus of things to know is growing and the water is slowly rising as far as what a bar for a competent AI engineer is. But I think, , having some structured thought as to what are the big ones that everyone must know I think is, is, is key. It's something I, I haven't really defined for people and I'm, I'm glad that this is actually has something out there that people can refer to.[00:38:15] Yeah, I wouldn't necessarily like make it required for like the job. Interview maybe, but , it'd be interesting to see like, what would be a red flag. If some AI engineer would not know, I don't know what, , I don't know where we would stoop to, to call something required knowledge, , or you're not part of the cool kids club.[00:38:33] But there increasingly is something like that, right? Like, not knowing what context is, is a black mark, in my opinion, right?[00:38:40] I think it, I think it does connect back to what we were saying before of this genuine Curiosity about and that. Well, maybe it's, maybe it's actually that combined with something else, which is really important, which is a self starting bias towards action, kind of a mindset, which again, everybody needs.[00:38:56] Exactly. Yeah. Everyone needs that. So if you put those two together, or if I'm truly curious about this and I'm going to kind of figure out how to make things happen, then you end up with people. Reading, reading lists, reading papers, doing side projects, this kind of, this kind of thing. So it isn't something that we explicitly included.[00:39:14] We don't have a, we don't have an ML focused interview for the AI engineer role at all, actually. It doesn't really seem helpful. The skills which we are checking for, as I mentioned before, this kind of fault first mindset. And conventional software engineering kind of thing. It's, it's 0. 1 and 0.[00:39:32] 3 on the list that, that we talked about. In terms of checking for ML curiosity and there are, how familiar they are with these concepts. That's more through talking interviews and culture fit types of things. We want for them to have a take on what Elisa is doing. doing, certainly as they progress through the interview process.[00:39:50] They don't need to be completely up to date on everything we've ever done on day zero. Although, , that's always nice when it happens. But for them to really engage with it, ask interesting questions, and be kind of bought into our view on how we want ML to proceed. I think that is really important, and that would reveal that they have this kind of this interest, this ML curiosity.[00:40:13] ML First Mindset[00:40:13] swyx: There's a second aspect to that. I don't know if now's the right time to talk about it, which is, I do think that an ML first approach to building software is something of a different mindset. I could, I could describe that a bit now if that, if that seems good, but yeah, I'm a team. Okay. So yeah, I think when I joined Elicit, this was the biggest adjustment that I had to make personally.[00:40:37] So as I said before, I'd been, Effectively building conventional software stuff for 15 years or so, something like this, well, for longer actually, but professionally for like 15 years. And had a lot of pattern matching built into my brain and kind of muscle memory for if you see this kind of problem, then you do that kind of a thing.[00:40:56] And I had to unlearn quite a lot of that when joining Elicit because we truly are ML first and try to use ML to the fullest. And some of the things that that means is, This relinquishing of control almost, at some point you are calling into this fairly opaque black box thing and hoping it does the right thing and dealing with the stuff that it sends back to you.[00:41:17] And that's very different if you're interacting with, again, APIs and databases, that kind of a, that kind of a thing. You can't just keep on debugging. At some point you hit this, this obscure wall. And I think the second, the second part to this is the pattern I was used to is that. The external parts of the app are where most of the messiness is, not necessarily in terms of code, but in terms of degrees of freedom, almost.[00:41:44] If the user can and will do anything at any point, and they'll put all sorts of wonky stuff inside of text inputs, and they'll click buttons you didn't expect them to click, and all this kind of thing. But then by the time you're down into your SQL queries, for example, as long as you've done your input validation, things are pretty pretty well defined.[00:42:01] And that, as we said before, is not really the case. When you're working with language models, there is this kind of intrinsic uncertainty when you get down to the, to the kernel, down to the core. Even, even beyond that, there's all that stuff is somewhat defensive and these are things to be wary of to some degree.[00:42:18] Though the flip side of that, the really kind of positive part of taking an ML first mindset when you're building applications is that you, If you, once you get comfortable taking your hands off the wheel at a certain point and relinquishing control, letting go then really kind of unexpected powerful things can happen if you lean on the, if you lean on the capabilities of the model without trying to overly constrain and slice and dice problems with to the point where you're not really wringing out the most capability from the model that you, that you might.[00:42:47] So, I was trying to think of examples of this earlier, and one that came to mind was we were working really early when just after I joined Elicit, we were working on something where we wanted to generate text and include citations embedded within it. So it'd have a claim, and then a, , square brackets, one, in superscript, something, something like this.[00:43:07] And. Every fiber in my, in my, in my being was screaming that we should have some way of kind of forcing this to happen or Structured output such that we could guarantee that this citation was always going to be present later on that the kind of the indication of a footnote would actually match up with the footnote itself and Kind of went into this symbolic.[00:43:28] I need full control kind of kind of mindset and it was notable that Andreas Who's our CEO, again, has been on the podcast, was was the opposite. He was just kind of, give it a couple of examples and it'll probably be fine. And then we can kind of figure out with a regular expression at the end. And it really did not sit well with me, to be honest.[00:43:46] I was like, but it could say anything. I could say, it could literally say anything. And I don't know about just using a regex to sort of handle this. This is a potent feature of the app. But , this is that was my first kind of, , The starkest introduction to this ML first mindset, I suppose, which Andreas has been cultivating for much longer than me, much longer than most, of yeah, there might be some surprises of stuff you get back from the model, but you can also It's about finding the sweet spot, I suppose, where you don't want to give a completely open ended prompt to the model and expect it to do exactly the right thing.[00:44:25] You can ask it too much and it gets confused and starts repeating itself or goes around in loops or just goes off in a random direction or something like this. But you can also over constrain the model. And not really make the most of the, of the capabilities. And I think that is a mindset adjustment that most people who are coming into AI engineering afresh would need to make of yeah, giving up control and expecting that there's going to be a little bit of kind of extra pain and defensive stuff on the tail end, but the benefits that you get as a, as a result are really striking.[00:44:58] The ML first mindset, I think, is something that I struggle with as well, because the errors, when they do happen, are bad. , they will hallucinate, and your systems will not catch it sometimes if you don't have large enough of a sample set.[00:45:13] AI Engineers and Creativity[00:45:13] swyx: I'll leave it open to you, Adam. What else do you think about when you think about curiosity and exploring capabilities?[00:45:22] Do people are there reliable ways to get people to push themselves? for joining us on Capabilities, because I think a lot of times we have this implicit overconfidence, maybe, of we think we know what it is, what a thing is, when actually we don't, and we need to keep a more open mind, and I think you do a particularly good job of Always having an open mind, and I want to get that out of more engineers that I talk to, but I, I, I, I struggle sometimes.[00:45:45] Adam Wiggins: I suppose being an engineer is, at its heart, this sort of contradiction of, on one hand, yeah,
GPTScript is a new scripting language to automate your interactions with LLMs, Adam Wiggins conducts a retrospective on Muse, Nikita Prokopov surveyed a bunch of popular websites to see how much JS they loaded on their pages, Pages CMS is a no-hassle CMS for GitHub pages & Jim Nielsen writes about the subversive hyperlink.
GPTScript is a new scripting language to automate your interactions with LLMs, Adam Wiggins conducts a retrospective on Muse, Nikita Prokopov surveyed a bunch of popular websites to see how much JS they loaded on their pages, Pages CMS is a no-hassle CMS for GitHub pages & Jim Nielsen writes about the subversive hyperlink.
GPTScript is a new scripting language to automate your interactions with LLMs, Adam Wiggins conducts a retrospective on Muse, Nikita Prokopov surveyed a bunch of popular websites to see how much JS they loaded on their pages, Pages CMS is a no-hassle CMS for GitHub pages & Jim Nielsen writes about the subversive hyperlink.
Peter van Hardenberg talks about Industrialists vs. Academics, Ink&Switch's evolution over time, the Hollywood Model, internal lab infrastructure, and more! Peter is the lab director and CEO of Ink&Switch, a private, creator oriented, computing research lab. References Ink&Switch (and their many publications) The Hollywood Model in R&D Idea Machines Episode with Adam Wiggins Paul Erdós Transcript Peter Van Hardenberg [00:01:21] Ben: Today I have the pleasure of speaking with Peter van Hardenbergh. Peter is the lab director and CEO of Inkin switch. Private creator oriented, competing research lab. I talked to Adam Wiggins, one of inkind switches founders, [00:01:35] way back in episode number four. It's amazing to see the progress they've made as an organization. They've built up an incredible community of fellow travelers and consistently released research reports that gesture at possibilities for competing that are orthogonal to the current hype cycles. Peter frequently destroys my complacency with his ability to step outside the way that research has normally done and ask, how should we be operating, given our constraints and goals. I hope you enjoy my conversation with Peter. Would you break down your distinction between academics and industrialists [00:02:08] Peter: Okay. Academics are people whose incentive structure is connected to the institutional rewards of the publishing industry, right? You, you publish papers. And you get tenure and like, it's a, it's, it's not so cynical or reductive, but like fundamentally the time cycles are long, right? Like you have to finish work according to when, you know, submission deadlines for a conference are, you know, you're [00:02:35] working on something now. You might come back to it next quarter or next year or in five years, right? Whereas when you're in industry, you're connected to users, you're connected to people at the end of the day who need to touch and hold and use the thing. And you know, you have to get money from them to keep going. And so you have a very different perspective on like time and money and space and what's possible. And the real challenge in terms of connecting these two, you know, I didn't invent the idea of pace layers, right? They, they operate at different pace layers. Academia is often intergenerational, right? Whereas industry is like, you have to make enough money every quarter. To keep the bank account from going below zero or everybody goes home, [00:03:17] Ben: Right. Did. Was it Stuart Brand who invented pace [00:03:22] Peter: believe it was Stewart Brand. Pace layers. Yeah. [00:03:25] Ben: That actually I, I'd never put these two them together, but the, the idea I, I, I think about impedance mismatches between [00:03:35] organizations a lot. And that really sort of like clicks with pace layers Exactly. Right. Where it's like [00:03:39] Peter: Yeah, absolutely. And, and I think in a big way what we're doing at, Ink& Switch on some level is trying to provide like synchro mesh between academia and industry, right? Because they, the academics are moving on a time scale and with an ambition that's hard for industry to match, right? But also, Academics. Often I think in computer science are like, have a shortage of good understanding about what the real problems people are facing in the world today are. They're not disinterested. [00:04:07] Ben: just computer [00:04:08] Peter: Those communication channels don't exist cuz they don't speak the same language, they don't use the same terminology, they don't go to the same conferences, they don't read the same publications. Right. [00:04:18] Ben: Yeah. [00:04:18] Peter: so vice versa, you know, we find things in industry that are problems and then it's like you go read the papers and talk to some scientists. I was like, oh dang. Like. We know how to solve this. It's just nobody's built it. [00:04:31] Ben: Yeah. [00:04:32] Peter: Or more accurately it would be to say [00:04:35] there's a pretty good hunch here about something that might work, and maybe we can connect the two ends of this together. [00:04:42] Ben: Yeah. Often, I, I think of it as someone, someone has, it is a quote unquote solved problem, but there are a lot of quote unquote, implementation details and those implementation details require a year of work. [00:04:56] Peter: yeah, a year or many years? Or an entire startup, or a whole career or two? Yeah. And, and speaking of, Ink&Switch, I don't know if we've ever talked about, so a switch has been around for more than half a decade, right? [00:05:14] Peter: Yeah, seven or eight years now, I think I could probably get the exact number, but yeah, about that. [00:05:19] Ben: And. I think I don't have a good idea in my head over that time. What, what has changed about in, can switches, conception of itself and like how you do things. Like what is, what are some of the biggest things that have have changed over that time?[00:05:35] [00:05:35] Peter: So I think a lot of it could be summarized as professionalization. But I, I'll give a little brief history and can switch began because the. You know, original members of the lab wanted to do a startup that was Adam James and Orion, but they recognized that they didn't, they weren't happy with computing and where computers were, and they knew that they wanted to make something that would be a tool that would help people who were solving the world's problems work better. That's kinda a vague one, but You know, they were like, well, we're not physicists, we're not social scientists. You know, we can't solve climate change or radicalization directly, or you know, the journalism crisis or whatever, but maybe we can build tools, right? We know how to make software tools. Let's build tools for the people who are solving the problems. Because right now a lot of those systems they rely on are getting like steadily worse every day. And I think they still are like the move to the cloud disempowerment of the individual, like, you [00:06:35] know, surveillance technology, distraction technology. And Tristan Harris is out there now. Like hammering on some of these points. But there's just a lot of things that are like slow and fragile and bad and not fun to work with and lose your, you know, lose your work product. You know, [00:06:51] Ben: Yeah, software as a service more generally. [00:06:54] Peter: Yeah. And like, there's definitely advantages. It's not like, you know, people are rational actors, but something was lost. And so the idea was well go do a bit of research, figure out what the shape of the company is, and then just start a company and, you know, get it all solved and move on. And I think the biggest difference, at least, you know, aside from scale and like actual knowledge is just kind of the dawning realization at some point that like there won't really be an end state to this problem. Like this isn't a thing that's transitional where you kind of come in and you do some research for a bit, and then we figure out the answer and like fold up the card table and move on to the next thing. It's like, oh no, this, this thing's gotta stick around because these problems aren't gonna [00:07:35] go away. And when we get through this round of problems, we already see what the next round are. And that's probably gonna go on for longer than any of us will be working. And so the vision now, at least from my perspective as the current lab director, is much more like, how can I get this thing to a place where it can sustain for 10 years, for 50 years, however long it takes, and you know, to become a place that. Has a culture that can sustain, you know, grow and change as new people come in. But that can sustain operations indefinitely. [00:08:07] Ben: Yeah. And, and so to circle back to the. The, the jumping off point for this, which is sort of since, since it began, what have been some of the biggest changes of how you operate? How you, or just like the, the model more generally or, or things that you were [00:08:30] Peter: Yeah, so the beginning was very informal, but, so maybe I'll skip over the first like [00:08:35] little period where it was just sort of like, Finding our footing. But around the time when I joined, we were just four or five people. And we did one project, all of us together at a time, and we just sort of like, someone would write a proposal for what we should do next, and then we would argue about like whether it was the right next thing. And, you know, eventually we would pick a thing and then we would go and do that project and we would bring in some contractors and we called it the Hollywood model. We still call it the Hollywood model. Because it was sort of structured like a movie production. We would bring in, you know, to our little core team, we'd bring in a couple specialists, you know, the equivalent of a director of photography or like a, you know, a casting director or whatever, and you bring in the people that you need to accomplish the task. Oh, we don't know how to do Bluetooth on the web. Okay. Find a Bluetooth person. Oh, there's a bunch of crypto stuff, cryptography stuff. Just be clear on this upcoming project, we better find somebody who knows, you know, the ins and outs of like, which cryptography algorithms to use or [00:09:35] what, how to build stuff in C Sharp for Windows platform or Surface, whatever the, the project was over time. You know, we got pretty good at that and I think one of the biggest changes, sort of after we kind of figured out how to actually do work was the realization that. Writing about the work not only gave us a lot of leverage in terms of our sort of visibility in the community and our ability to attract talent, but also the more we put into the writing, the more we learned about the research and that the process of, you know, we would do something and then write a little internal report and then move on. But the process of taking the work that we do, And making it legible to the outside world and explaining why we did it and what it means and how it fits into the bigger picture. That actually like being very diligent and thorough in documenting all of that greatly increases our own understanding of what we did.[00:10:35] And that was like a really pleasant and interesting surprise. I think one of my sort of concerns as lab director is that we got really good at that and we write all these like, Obscenely long essays that people claim to read. You know, hacker News comments on extensively without reading. But I think a lot about, you know, I always worry about the orthodoxy of doing the same thing too much and whether we're sort of falling into patterns, so we're always tinkering with new kind of project systems or new ways of working or new kinds of collaborations. And so yeah, that's ongoing. But this, this. The key elements of our system are we bring together a team that has both longer term people with domain contexts about the research, any required specialists who understand like interesting or important technical aspects of the work. And then we have a specific set of goals to accomplish [00:11:35] with a very strict time box. And then when it's done, we write and we put it down. And I think this avoids number of the real pitfalls in more open-ended research. It has its own shortcomings, right? But one of the big pitfalls that avoids is the kind of like meandering off and losing sight of what you're doing. And you can get great results from that in kind of a general research context. But we're very much an industrial research context. We're trying to connect real problems to specific directions to solve them. And so the time box kind of creates the fear of death. You're like, well, I don't wanna run outta time and not have anything to show for it. So you really get focused on trying to deliver things. Now sometimes that's at the cost, like the breadth or ambition of a solution to a particular thing, but I think it helps us really keep moving forward. [00:12:21] Ben: Yeah, and, and you no longer have everybody in the lab working on the same projects, right. [00:12:28] Peter: Yeah. So today, at any given time, The sort of population of the lab fluctuates between sort of [00:12:35] like eight and 15 people, depending on, you know, whether we have a bunch of projects in full swing or you know, how you count contractors. But we usually, at the moment we have sort of three tracks of research that we're doing. And those are local first software Programmable Inc. And Malleable software. [00:12:54] Ben: Nice. And so I, I actually have questions both about the, the write-ups that you do and the Hollywood model and so on, on the Hollywood model. Do you think that I, I, and this is like, do you think that the, the Hollywood model working in, in a. Industrial Research lab is particular to software in the sense that I feel like the software industry, people change jobs fairly frequently. Contracting is really common. Contractors are fairly fluid and. [00:13:32] Peter: You mean in terms of being able to staff and source people?[00:13:35] [00:13:35] Ben: Yeah, and people take, like, take these long sabbaticals, right? Where it's like, it's not uncommon in the software industry for someone to, to take six months between jobs. [00:13:45] Peter: I think it's very hard for me to generalize about the properties of other fields, so I want to try and be cautious in my evaluation here. What I would say is that, I think the general principle of having a smaller core of longer term people who think and gain a lot of context about a problem and pairing them up with people who have fresh ideas and relevant expertise, does not require you to have any particular industry structure. Right. There are lots of ways of solving this problem. Go to a research, another research organization and write a paper with someone from [00:14:35] an adjacent field. If you're in academia, right? If you're in a company, you can do a partnership you know, hire, you know, I think a lot of fields of science have much longer cycles, right? If you're doing material science, you know, takes a long time to build test apparatus and to formulate chemistries. Like [00:14:52] Ben: Yeah. [00:14:52] Peter: someone for several years, right? Like, That's fine. Get a detach detachment from another part of the company and bring someone as a secondment. Like I think that the general principle though, of putting together a mixture of longer and shorter term people with the right set of skills, yes, we solve it a particular way in our domain. But I don't think that that's software u unique to software. [00:15:17] Ben: Would, would it be overreaching to map that onto professors and postdocs and grad students where you have the professor who is the, the person who's been working on the, the program for a long time has all the context and then you have postdocs and grad students [00:15:35] coming through the lab. [00:15:38] Peter: Again, I need to be thoughtful about. How I evaluate fields that I'm less experienced with, but both my parents went through grad school and I've certainly gotten to know a number of academics. My sense of the relationship between professors and or sort of PhD, yeah, I guess professors and their PhD students, is that it's much more likely that the PhD students are given sort of a piece of the professor's vision to execute. [00:16:08] Ben: Yeah. [00:16:09] Peter: And that that is more about scaling the research interests of the professor. And I don't mean this in like a negative way but I think it's quite different [00:16:21] Ben: different. [00:16:22] Peter: than like how DARPA works or how I can switch works with our research tracks in that it's, I it's a bit more prescriptive and it's a bit more of like a mentor-mentee kind of relationship as [00:16:33] Ben: Yeah. More training.[00:16:35] [00:16:35] Peter: Yeah. And you know, that's, that's great. I mean, postdocs are a little different again, but I think, I think that's different than say how DARPA works or like other institutional research groups. [00:16:49] Ben: Yeah. Okay. I, I wanted to see how, how far I could stretch the, stretch [00:16:55] Peter: in academia there's famous stories about Adosh who would. Turn up on your doorstep you know, with a suitcase and a bottle of amphetamines and say, my, my brain is open, or something to that effect. And then you'd co-author a paper and pay his room and board until you found someone else to send him to. I think that's closer in the sense that, right, like, here's this like, great problem solver with a lot of like domain skills and he would parachute into a place where someone was working on something interesting and help them make a breakthrough with it. [00:17:25] Ben: Yeah. I think the, the thing that I want to figure out, just, you know, long, longer term is how to. Make those [00:17:35] short term collaborations happen when with, with like, I, I I think it's like, like there's some, there's some coy intention like in, in the sense of like Robert Kos around like organizational boundaries when you have people coming in and doing things in a temporary sense. [00:17:55] Peter: Yeah, academia is actually pretty good at this, right? With like paper co-authors. I mean, again, this is like the, the pace layers thing. When you have a whole bunch of people organized in an industry and a company around a particular outcome, You tend to have like very specific goals and commitments and you're, you're trying to execute against those and it's much harder to get that kind of like more fluid movement between domains. [00:18:18] Ben: Yeah, and [00:18:21] Peter: That's why I left working in companies, right? Cause like I have run engineering processes and built products and teams and it's like someone comes to me with a really good idea and I'm like, oh, it's potentially very interesting, but like, [00:18:33] Ben: but We [00:18:34] Peter: We got [00:18:35] customers who have outages who are gonna leave if we don't fix the thing, we've got users falling out of our funnel. Cause we don't do basic stuff like you just, you really have a lot of work to do to make the thing go [00:18:49] Ben: Yeah. [00:18:49] Peter: business. And you know, my experience of research labs within businesses is that they're almost universally unsuccessful. There are exceptions, but I think they're more coincidental than, than designed. [00:19:03] Ben: Yeah. And I, I think less and less successful over time is, is my observation that. [00:19:11] Peter: Interesting. [00:19:12] Ben: Yeah, there's a, there's a great paper that I will send you called like, what is the name? Oh, the the Changing Structure of American Innovation by She Aurora. I actually did a podcast with him because I like the paper so much. that that I, I think, yeah, exactly. And so going back to your, your amazing [00:19:35] write-ups, you all have clearly invested quite a chunk of, of time and resources into some amount of like internal infrastructure for making those really good. And I wanted to get a sense of like, how do you decide when it's worth investing in internal infrastructure for a lab? [00:19:58] Peter: Ooh. Ah, that's a fun question. Least at In and Switch. It's always been like sort of demand driven. I wish I could claim to be more strategic about it, but like we had all these essays, they were actually all hand coded HTML at one point. You know, real, real indie cred there. But it was a real pain when you needed to fix something or change something. Cause you had to go and, you know, edit all this H T M L. So at some point we were doing a smaller project and I built like a Hugo Templating thing [00:20:35] just to do some lab notes and I faked it. And I guess this is actually a, maybe a somewhat common thing, which is you do one in a one-off way. And then if it's promising, you invest more in it. [00:20:46] Ben: Yeah. [00:20:46] Peter: And it ended up being a bigger project to build a full-on. I mean, it's not really a cms, it's sort of a cms, it's a, it's a templating system that produces static HT m l. It's what all our essays come out of. But there's also a lot of work in a big investment in just like design and styling. And frankly, I think that one of the things that in can switch apart from other. People who do similar work in the space is that we really put a lot of work into the presentation of our work. You know, going beyond, like we write very carefully, but we also care a lot about like, picking good colors, making sure that text hyphenates well, that it, you know, that the the screencast has the right dimensions and, you know, all that little detail work and. It's expensive [00:21:35] in time and money to do, but I think it's, I think the results speak for themselves. I think it's worth it. [00:21:47] Ben: Yeah. I, and I mean, if, if the ultimate goal is to influence what people do and what they think, which I suspect is, is at least some amount of the goal then communicating it. [00:22:00] Peter: It's much easier to change somebody's mind than to build an entire company. [00:22:05] Ben: Yes. Well, [00:22:06] Peter: you wanna, if you wanna max, it depends. Well, you don't have to change everybody's mind, right? Like changing an individual person's mind might be impossible. But if you can put the right ideas out there in the right way to make them legible, then you'll change the right. Hopefully you'll change somebody's mind and it will be the right somebody. [00:22:23] Ben: yeah. No, that is, that is definitely true. And another thing that I am. Always obscenely obsessed, exceedingly impressed by that. In Switch. [00:22:35] Does is your sort of thoughtfulness around how you structure your community and sort of tap into it. Would you be willing to sort of like, walk me through how you think about that and like how you have sort of the, the different layers of, of kind of involvement? [00:22:53] Peter: Okay. I mean, sort of the, maybe I'll work from, from the inside out cuz that's sort of the history of it. So in the beginning there was just sort of the people who started the lab. And over time they recruited me and, and Mark Mcg again and you know, some of our other folk to come and, and sign on for this crazy thing. And we started working with these wonderful, like contractors off and on and and so the initial sort of group was quite small and quite insular and we didn't publish anything. And what we found was that. Once we started, you know, just that alone, the act of bringing people in and working with them started to create the beginning of a [00:23:35] community because people would come into a project with us, they'd infect us with some of their ideas, we'd infect them with some of ours. And so you started to have this little bit of shared context with your past collaborators. And because we have this mix of like longer term people who stick with the lab and other people who come and go, You start to start to build up this, this pool of people who you share ideas and language with. And over time we started publishing our work and we began having what we call workshops where we just invite people to come and talk about their work at Ink and Switch. And by at, I mean like now it's on a discord. Back in the day it was a Skype or a Zoom call or whatever. And the rule back then in the early days was like, if you want to come to the talk. You have to have given a talk or have worked at the lab. And so it was like very good signal to noise ratio in attendance cuz the only people who would be on the zoom call would be [00:24:35] people who you knew were grappling with those problems. For real, no looky lose, no, no audience, right? And over time it just, there were too many really good, interesting people who are doing the work. To fit in all those workshops and actually scheduling workshops is quite tiring and takes a lot of energy. And so over time we sort of started to expand this community a little further. And sort of now our principle is you know, if you're doing the work, you're welcome to come to the workshops. And we invite some people to do workshops sometimes, but that's now we have this sort of like small private chat group of like really interesting folk. And it's not open to the public generally because again, we, I don't want to have an audience, right? I want it to practitioner's space. And so over time, those people have been really influential on us as well. And having that little inner [00:25:35] circle, and it's a few hundred people now of people who, you know, like if you have a question to ask about something tricky. There's probably somebody in there who has tried it, but more significantly, like the answer will come from somebody who has tried it, not from somebody who will call you an idiot for trying or who will, right, like you, you avoid all the, don't read the comments problems because the sort of like, if anybody was like that, I would probably ask them to leave, but we've been fortunate that we haven't had any of that kind of stuff in the community. I will say though, I think I struggle a lot because I think. It's hard to be both exclusive and inclusive. Right, but exclusive community deliberately in the sense that I want it to be a practitioner's space and one where people can be wrong and it's not too performative, like there's not investors watching or your, your user base or whatever. [00:26:32] Ben: Yeah. [00:26:32] Peter: at the same time, [00:26:33] Ben: strangers. [00:26:34] Peter: [00:26:35] inclusive space where we have people who are earlier in their career or. From non-traditional backgrounds, you know, either academically or culturally or so on and so forth. And it takes constant work to be like networking out and meeting new people and like inviting them into this space. So it's always an area to, to keep working on. At some point, I think we will want to open the aperture further, but yeah, it's, it's, it's a delicate thing to build a community. [00:27:07] Ben: Yeah, I mean the, the, frankly, the reason I'm asking is because I'm trying to figure out the same things and you have done it better than basically anybody else that I've seen. This is, this is maybe getting too down into the weeds. But why did you decide that discourse or discord was the right tool for it? And the, the reason that I ask is that I personally hate sort of [00:27:35] streaming walls of texts, and I find it very hard to, to seriously discuss ideas in, in that format. [00:27:43] Peter: Yeah, I think async, I mean, I'm an old school like mailing list guy. On some level I think it's just a pragmatic thing. We use Discord for our internal like day-to-day operations like. Hey, did you see the pr? You know, oh, we gotta call in an hour with so-and-so, whatever. And then we had a bunch of people in that community and then, you know, we started having the workshops and inviting more people. So we created a space in that same discord where. You know, people didn't have to get pinged when we had a lab call and we didn't want 'em turning up on the zoom anyway. And so it wasn't so much like a deliberate decision to be that space. I think there's a huge opportunity to do better and you know, frankly, what's there is [00:28:35] not as designed or as deliberate as I would like. It's more consequence of Organic growth over time and just like continuing to do a little bit here and there than like sort of an optimum outcome. And it could, there, there's a lot of opportunity to do better. Like we should have newsletters, there should be more, you know, artifacts of past conversations with better organizations. But like all of that stuff takes time and energy. And we are about a small little research lab. So many people you know, [00:29:06] Ben: I, I absolutely hear you on that. I think the, the, the tension that I, I see is that people, I think like texting, like sort of stream of texts. Slack and, and discord type things. And, and so there's, there's the question of like, what can you get people to do versus like, what creates the, the right conversation environment?[00:29:35] And, and maybe that's just like a matter of curation and like standard setting. [00:29:42] Peter: Yeah, I don't know. We've had our, our rabbit trails and like derailed conversations over the years, but I think, you know, if you had a forum, nobody would go there. [00:29:51] Ben: Yeah. [00:29:52] Peter: like, and you could do a mailing list, but I don't know, maybe we could do a mailing list. That would be a nice a nice form, I think. But people have to get something out of a community to put things into it and you know, you have to make, if you want to have a forum or, or an asynchronous posting place, you know, the thing is people are already in Discord or slack. [00:30:12] Ben: exactly. [00:30:13] Peter: something else, you have to push against the stream. Now, actually, maybe one interesting anecdote is I did experiment for a while with, like, discord has sort of a forum post feature. They added a while back [00:30:25] Ben: Oh [00:30:25] Peter: added it. Nobody used it. So eventually I, I turned it off again. Maybe, maybe it just needs revisiting, but it surprised me that it wasn't adopted, I guess is what [00:30:35] I would say. [00:30:36] Ben: Yeah. I mean, I think it, I think the problem is it takes more work. It's very easy to just dash off a thought. [00:30:45] Peter: Yeah, but I think if you have the right community, then. Those thoughts are likely to have been considered and the people who reply will speak from knowledge [00:30:55] Ben: Yeah. [00:30:56] Peter: and then it's not so bad, right? [00:30:59] Ben: it's [00:30:59] Peter: The problem is with Hacker News or whatever where like, or Reddit or any of these open communities like you, you know, the person who's most likely to reply is not the person who's most helpful to apply. [00:31:11] Ben: Yeah, exactly. Yeah, that makes, that makes a lot of sense. And sort of switching tracks yet again, how so one, remind me how long your, your projects are, like how long, how big are the, is the time box. [00:31:28] Peter: the implementation phase for a standard income switch Hollywood project, which I can now call them standard, I think, cuz we've done like, [00:31:35] Ooh, let me look. 25 or so over the years. Let's see, what's my project count number at? I have a little. Tracker. Yeah, I think it's 25 today. So we've done about 20 some non-trivial number of these 10 to 12 weeks of implementation is sort of the core of the project, and the idea is that when you hit that start date, at the beginning of that, you should have the team assembled. You should know what you're building, you should know why you're building it, and you should know what done looks like. Now it's research, so inevitably. You know, you get two weeks in and then you take a hard left and like, you know, but that, that we write what's called the brief upfront, which is like, what is the research question we are trying to answer by funding this work and how do we think this project will answer it? Now, your actual implementation might change, or you might discover targets of opportunity along the way. But the idea is that by like having a, a narrow time box, like a, a team [00:32:35] that has a clear understanding of what you're trying to accomplish. And like the right set of people on board who already have all the like necessary skills. You can execute really hard for like that 10 to 12 weeks and get quite far in that time. Now, that's not the whole project though. There's usually a month or two upfront of what we call pre-infusion, kind of coming from the espresso idea that like you make better espresso if you take a little time at low pressure first to get ready with the shot, and so we'll do. You know, and duration varies here, but there's a period before that where we're making technical choices. Are we building this for the web or is this going on iPad? Are we gonna do this with rust and web assembly, or is this type script is this, are we buying Microsoft Surface tablets for this as we're like the ink behavior, right? So all those decisions we try and make up front. So when you hit the execution phase, you're ready to go. Do we need, what kind of designer do we want to include in this project? And who's available, you know? All of that stuff. We [00:33:35] try and square away before we get to the execution phase. [00:33:38] Ben: right. [00:33:38] Peter: when the end of the execution phase, it's like we try to be very strict with like last day pencils down and try to also reserve like the last week or two for like polish and cleanup and sort of getting things. So it's really two to two and a half, sometimes three months is like actually the time you have to do the work. And then after that, essays can take between like two months and a year or two. To produce finally. But we try to have a dr. We try to have a good first draft within a month after the end of the project. And again, this isn't a process that's like probably not optimal, but basically someone on the team winds up being the lead writer and we should be more deliberate about that. But usually the project lead for a given project ends up being the essay writer. And they write a first draft with input and collaboration from the rest of the group. And then people around [00:34:35] the lab read it and go, this doesn't make any sense at all. Like, what? What do you do? And you know, to, to varying degrees. And then it's sort of okay, right? Once you've got that kind of feedback, then you go back and you restructured and go, oh, I need to explain this part more. You know, oh, these findings don't actually cover the stuff that other people at the lab thought was interesting from the work or whatever. And then that goes through, you know, an increasing sort of, you know, standard of writing stuff, right? You send it out to some more people and then you send it to a bigger group. And you know, we send it to people who are in the field that whose input we respect. And then we take their edits and we debate which ones to take. And then eventually it goes in the HTML template. And then there's a long process of like hiring an external copy editor and building nice quality figures and re-recording all your crappy screencasts to be like, Really crisp with nice lighting and good, you know, pacing and, you know, then finally at the end of all of that, we publish. [00:35:33] Ben: Nice. And [00:35:35] how did you settle on the, the 10 to 12 weeks as the right size, time box? [00:35:42] Peter: Oh, it's it's it's, it's clearly rationally optimal. [00:35:46] Ben: Ah, of course, [00:35:47] Peter: No, I'm kidding. It's totally just, it became a habit. I mean, I think. Like I, I can give an intuitive argument and we've, we've experimented a bit. You know, two weeks is not long enough to really get into anything, [00:36:02] Ben: right. [00:36:02] Peter: and the year is too long. There's too much, too much opportunity to get lost along the way. There's no, you go too long with no real deadline pressure. It's very easy to kind of wander off into the woods. And bear in mind that like the total project duration is really more like six months, right? And so where we kind of landed is also that we often have like grad students or you know, people who are between other contracts or things. It's much easier to get people for three months than for eight months. And if I feel like [00:36:35] just intuitively, if I, if someone came to you with an eight month project, I'd be, I'm almost positive that I would be able to split it into two, three month projects and we'd be able to like find a good break point somewhere in the middle. And then write about that and do another one. And it's like, this is sort of a like bigger or smaller than a bread box argument, but like, you know, a month is too little and six months feels too long. So two to four months feels about right. In terms of letting you really get into, yeah, you can really get into the meat of a problem. You can try a few different approaches. You can pick your favorite and then spend a bit of time like analyzing it and like working out the kinks. And then you can like write it up. [00:37:17] Ben: Thanks. [00:37:18] Peter: But you know, there have been things that are not, that haven't fit in that, and we're doing some stuff right now that has, you know, we've had a, like six month long pre-infusion going this year already on some ink stuff. So it's not a universal rule, but like that's the, that's the [00:37:33] Ben: Yeah. No, I [00:37:35] appreciate that intuition [00:37:36] Peter: and I think it also, it ties into being software again, right? Like again, if you have to go and weld things and like [00:37:43] Ben: yeah, exactly. [00:37:44] Peter: You know, [00:37:44] Ben: let let some bacteria grow. [00:37:46] Peter: or like, you know, the, it's very much a domain specific answer. [00:37:51] Ben: Yeah. Something that I wish people talked about more was like, like characteristic time scales of different domains. And I, I think that's software, I mean, software is obviously shorter, but it'd be interesting to, to sort of dig down and be like, okay, like what, what actually is it? So the, the, the last question I'd love to ask is, To what extent does everybody in the lab know what's, what everybody else is working on? Like. [00:38:23] Peter: So we use two tools for that. We could do a better job of this. Every Monday the whole lab gets together for half an hour only. [00:38:35] And basically says what they're doing. Like, what are you up to this week? Oh, we're trying to like, you know, figure out what's going on with that you know, stylist shaped problem we were talking about at the last demo, or, oh, we're, you know, we're in essay writing mode. We've got a, we're hoping to get the first draft done this week, or, you know, just whatever high level kind of objectives the team has. And then I was asked the question like, well, Do you expect to have anything for show and tell on Friday and every week on Friday we have show and tell or every other week. Talk a bit more about that and at show and tell. It's like whatever you've got that you want input on or just a deadline for you can share. Made some benchmark showing that this code is now a hundred times faster. Great. Like bring it to show and tell. Got that like tricky you know, user interaction, running real smooth. Bring it to show and tell, built a whole new prototype of a new kind of [00:39:35] like notetaking app. Awesome. Like come and see. And different folks and different projects have taken different approaches to this. What has been most effective, I'm told by a bunch of people in their opinion now is like, kind of approaching it. Like a little mini conference talk. I personally actually air more on the side of like a more casual and informal thing. And, and those can be good too. Just from like a personal alignment like getting things done. Perspective. What I've heard from people doing research who want to get useful feedback is that when they go in having sort of like rehearsed how to explain what they're doing, then how to show what they've done and then what kind of feedback they want. That not only do they get really good feedback, but also that process of making sure that the demo you're gonna do will actually run smoothly and be legible to the rest of the group [00:40:35] forces you. Again, just like the writing, it forces you to think about what you're doing and why you made certain choices and think about which ones people are gonna find dubious and tell them to either ignore that cuz it was a stand-in or let's talk about that cuz it's interesting. And like that, that that little cycle is really good. And that tends to be, people often come every two weeks for that [00:40:59] Ben: Yeah. [00:41:01] Peter: within when they're in active sort of mode. And so not always, but like two weeks feels about like the right cadence to, to have something. And sometimes people will come and say like, I got nothing this week. Like, let's do it next week. It's fine. And the other thing we do with that time is we alternate what we call zoom outs because they're on Zoom and I have no, no sense of humor I guess. But they're based on, they're based on the old you and your research hamming paper with where the idea is that like, at least for a little while, every week [00:41:35] we all get together and talk about something. Bigger picture that's not tied to any of our individual projects. Sometimes we read a paper together, sometimes we talk about like an interesting project somebody saw, you know, in the world. Sometimes it's skills sharing. Sometimes it's you know, just like, here's how I make coffee or something, right? Like, You know, just anything that is bigger picture or out of the day-to-day philosophical stuff. We've read Illich and, and Ursula Franklin. People love. [00:42:10] Ben: I like that a lot. And I, I think one thing that, that didn't, that, that I'm still wondering about is like, On, on sort of a technical level are, are there things that some peop some parts of the lab that are working on that other parts of the lab don't get, like they, they know, oh, like this person's working on [00:42:35] inks, but they kind of have no idea how inks actually work? Or is it something where like everybody in the lab can have a fairly detailed technical discussion with, with anybody else [00:42:45] Peter: Oh no. I mean, okay, so there are interesting interdependencies. So some projects will consume the output of past projects or build on past projects. And that's interesting cuz it can create almost like a. Industry style production dependencies where like one team wants to go be doing some research. The local first people are trying to work on a project. Somebody else is using auto merge and they have bugs and it's like, oh but again, this is why we have those Monday sort of like conversations. Right? But I think the teams are all quite independent. Like they have their own GitHub repositories. They make their own technology decisions. They use different programming languages. They, they build on different stacks, right? Like the Ink team is often building for iPad because that's the only place we can compile like [00:43:35] ink rendering code to get low enough latency to get the experiences we want. We've given up on the browser, we can't do it, but like, The local first group for various reasons has abandoned electron and all of these like run times and mostly just build stuff for the web now because it actually works and you spend all, spend way less calories trying to make the damn thing go if you don't have to fight xcode and all that kind of stuff. And again, so it really varies, but, and people choose different things at different times, but no, it's not like we are doing code review for each other or like. Getting into the guts. It's much more high level. Like, you know, why did you make that, you know, what is your programming model for this canvas you're working on? How does you know, how does this thing relate to that thing? Why is, you know, why does that layout horizontally? It feels hard to, to parse the way you've shown that to, you know, whatever. [00:44:30] Ben: Okay, cool. That, that makes sense. I just, I, the, the, the reason I ask [00:44:35] is I am just always thinking about how how related do projects inside of a single organization need to be for, like, is, is there sort of like an optimum amount of relatedness? [00:44:50] Peter: I view them all as the aspects of the same thing, and I think that that's, that's an important. Thing we didn't talk about. The goal of income switch is to give rise to a new kind of computing that is more user-centric, that's more productive, that's more creative in like a very raw sense that we want people to be able to think better thoughts, to produce better ideas, to make better art, and that computers can help them with that in ways that they aren't and in fact are [00:45:21] Ben: Yeah. [00:45:25] Peter: whether you're working on ink, Or local first software or malleable software media canvases or whatever domain you are working in. It [00:45:35] is the same thing. It is an ingredient. It is an aspect, it is a dimension of one problem. And so some, in some sense, all of this adds together to make something, whether it's one thing or a hundred things, whether it takes five years or 50 years, you know, that's, we're all going to the same place together. But on many different paths and at different speeds and with different confidence, right? And so in the small, the these things can be totally unrelated, but in the large, they all are part of one mission. And so when you say, how do you bring these things under one roof, when should they be under different roofs? It's like, well, when someone comes to me with a project idea, I ask, do we need this to get to where we're going? [00:46:23] Ben: Yeah, [00:46:24] Peter: And if we don't need it, then we probably don't have time to work on it because there's so much to do. And you know, there's a certain openness to experimentation and, [00:46:35] and uncertainty there. But that, that's the rubric that I use as the lab director is this, is this on the critical path of the revolution?
Welcome back for S3E27 of Inside Cyclones Hockey.It was a rough weekend for your Clones, despite coming up just short in an instant classic Saturday night.As they say, we're on to St. Louis!Weekend Recap & Highlights w/ PxP Voice Jake Sennholz:25 - 16:17Wiener Dog Race Recap, New Playoff Merch, Bobble Head Night, Deal of the Week & More w/ Zach Serwe 17:43 - 30:15Players Only w/ F #22 Adam Wiggins31:03 - 44:54See Adam's career profile here: https://www.wausaucyclones.com/player-profile/?player_id=11715&league_id=5&season_id=136Don't forget we have a one stop shop for Cyclones playoff tickets and merch all right here: https://www.wausaucyclones.com/playoffs/Make sure you follow the Cyclones across your favorite social media @WausauCyclonesYou can find Jake on Twitter @SennholzOnSportGo Clones!!
Bittersweet news is the topic of this episode. Adam Wulf and Adam Wiggins discuss the end of an era for Muse, leadership transitions, and what the future holds for Muse 3.0 and beyond. Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes An end, and a beginning Ink & Switch Adam Wulf Loose Leaf Here, File File prosumer Industrial research with Peter van Hardenberg Netlify proxy, Webflow, Hugo Managing Transitions: Making the Most of Change
It's been a year since Muse 2.0 launched. To help commemorate this anniversary, Adam Wulf once again joins Mark and Adam Wiggins to do a technical deep-dive intothe Muse's sync architecture. They discuss the benefits such as less ops burden and good developer experience; and challenges such as event vs state based data, handling different app schema versions, and the tradeoffs of a content-aware server. Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes Developer Duck The Pragmatic Programmer Metamuse episode 56: Sync Muse 2.0 Muse for Teams Local-first software Pingdom Local-first software with Martin Kleppmann Text blocks innovation tokens Replicache, LiveBlocks, PartyKit Automerge 2.0
Co-Founder and former CTO of Heroku, Adam Wiggins, joins us to talk about product design, research, remote work, and productivity. Listen now. Links https://twitter.com/adamwiggins https://mas.to/@adamwiggins https://adamwiggins.com https://adamwiggins.com/making-computers-better https://www.inkandswitch.com https://www.heroku.com https://museapp.com Tell us what you think of PodRocket We want to hear from you! We want to know what you love and hate about the podcast. What do you want to hear more about? Who do you want to see on the show? Our producers want to know, and if you talk with us, we'll send you a $25 gift card! If you're interested, schedule a call with us (https://podrocket.logrocket.com/contact-us) or you can email producer Kate Trahan at kate@logrocket.com (mailto:kate@logrocket.com) Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket combines frontend monitoring, product analytics, and session replay to help software teams deliver the ideal product experience. Try LogRocket for free today. (https://logrocket.com/signup/?pdr) Special Guest: Adam Wiggins.
This past Sunday, Adam Wiggins encouraged us to respond to what we believe. Because we believe the gospel is true, Romans 13 tells us to love others, live with urgency, and pursue the good life that is in Christ.
Adam Wiggins walked us through Philippians 2. As we reflect on starting a new year, we look to Jesus. This hope for all mankind affects how we look back and look ahead.
Welcome back for S2E20 of Inside Cyclones HockeyToday Jake and Zach preview the upcoming NA3HL Super Showcase including opponent stats and numbersCyclones Christmas Gifts w/ Zach Serwe:23 - 10:14Showcase Preview w/ Jake Sennholz11:10 - 19:03Players Only w/ Adam Wiggins 19:36 - 34:01Thank you to our friends/partners - Fleet Farm, APEX Learning, Four Seasons Screen Printing, Bug Tussle Wireless & HockeyTVTake advantage of the Busch Light CLONE ZONE! Watch a Cyclones game from the best seat in town while enjoying complementary snacks and beer from your very own 22 oz Cyclones Memorabilia Mug all for just $25 ($20 on Feb. 3) ---> https://www.wausaucyclones.com/buschlightclonezoneEnter your beloved K9 friend in our Corgi Races, happening Saturday, Jan. 21 ---> https://www.wausaucyclones.com/corgiracesJoin our newsletter to keep up on the latest and greatest with all things Cyclones, and always be the first to hear about new offers and promotions! ---> https://www.wausaucyclones.com/newsletterAll ticketing information including our Founders Club and Flex 4 options can be found here ---> https://www.wausaucyclones.com/ticketsFollow the Wausau Cyclones across your favorite social media by searching @WausauCyclones. Now including TikTok.Follow Jake Sennholz on Twitter @SennholzOnSportGo Clones!!
This week we're back for part 2 with Adam Wiggins — going beyond Heroku and the story of Muse (listen to part 1). After a six-year adrenaline high on Heroku, Adam needed time to recover and refill the creative well. So, he moved to Berlin, did some gig work with companies…dabbled in investing and advising. But he wasn't satisfied. Adam likes to build things. Ultimately, he was just waiting for the right time to reconnect with James Lindenbaum and Orion Henry — the same fellas he created Heroku with. Eventually they founded Ink & Switch, an independent research lab which led to innovations that made Muse possible. Muse is a tool for deep work and thinking on iPad and Mac. Today's show is all about that journey and the details in-between.
This week we're back for part 2 with Adam Wiggins — going beyond Heroku and the story of Muse (listen to part 1). After a six-year adrenaline high on Heroku, Adam needed time to recover and refill the creative well. So, he moved to Berlin, did some gig work with companies…dabbled in investing and advising. But he wasn't satisfied. Adam likes to build things. Ultimately, he was just waiting for the right time to reconnect with James Lindenbaum and Orion Henry — the same fellas he created Heroku with. Eventually they founded Ink & Switch, an independent research lab which led to innovations that made Muse possible. Muse is a tool for deep work and thinking on iPad and Mac. Today's show is all about that journey and the details in-between.
This week on The Changelog we're joined by Adam Wiggins, co-founder and former CTO of Heroku, for an exclusive trip down Heroku memory lane. Jerod and I are both tremendous fans of Heroku and we believe (to this day) they represent the apex in developer experience for delivering code to production. We talk through the beginnings of Heroku, the v1 most people have forgotten about, the era of web hosting back in 2008-2010, the serendipity of Silicon Vally in those days, pitching to Y Combinator, the makings of git push heroku, the Heroku style and name, the sale of Heroku to Salesforce, potential regrets — and we tee up part 2 coming next week with Adam going beyond Heroku and the story of Muse.
This week on The Changelog we're joined by Adam Wiggins, co-founder and former CTO of Heroku, for an exclusive trip down Heroku memory lane. Adam and Jerod are both tremendous fans of Heroku and believe (to this day) they represent the apex in developer experience for delivering code to production. We talk through the beginnings of Heroku, the v1 most people have forgotten about, the era of web hosting back in 2008-2010, the serendipity of Silicon Vally in those days, pitching to Y Combinator, the makings of git push heroku, the Heroku style and name, the sale of Heroku to Salesforce, potential regrets — and we tee up part 2 coming next week with Adam going beyond Heroku and the story of Muse.
Welcome back for S2E12 of Inside Cyclones Hockey.We've made it. The home opener is HERE! Join Jake and Zach as they preview all the excitement of the upcoming weekend and let you know how to save money on tickets.Coach Nathan Oystrick joins the podcast to share his thoughts on the team through six games and gives his scouting report on the St. Louis Jr. Blues.We appreciate you tuning in as always. Now, from the Eye of the Cyclone...Intro & First Home Goal Predictions w/ Jake Sennholz:39 - 4:39Weekend Promotions, Clone Zone, Pink the Rink Auction & More w/ Zach Serwe5:35 - 21:48Coach's Corner w/ Nathan Oystrick22:31 - 30:09Bid on your very own Pink the Rink Jersey HERE. Bids MUST be finalized by Oct. 18th ---> https://www.wausaucyclones.com/pinkJerseys Available#2 Carson Liebaert#3 Cael Bolton#5 Chase Heckerson#14#17 Brennan Valencia#23 Adam Napravnik#26#27 Adam Wiggins#39 (goalie cut)Join our newsletter to keep up on the latest and greatest with all things Cyclones! You will also be granted early access to single game tickets ---> https://www.wausaucyclones.com/newsletterAll ticketing information including our Founders Club and Flex 4 options can be found here ---> https://www.wausaucyclones.com/ticketsFollow the Wausau Cyclones across your favorite social media by searching @WausauCyclones. Now including TikTok.Follow Jake Sennholz on Twitter @SennholzOnSportGo Clones!!
I was super honored to join Adam Wiggins (cofounder of Heroku's) podcast to share thoughts on tools for thought, LIP, and Creating Luck.Full show notes on Metamuse: https://museapp.com/podcast/53-career/
The foundational technology for Muse 2 is local-first sync, which draws from over a decade of computer science research on CRDTs. Mark, Adam Wiggins, and Adam Wulf get technical to describe the Muse sync technology architecture in detail. Topics include the difference between transactional, blob, and ephemeral data; the “atoms” concept inspired by Datomic; Protocol Buffers; and the user's data as a bag of edits. Plus: why sync is a powerful substrate for end-user programming. @MuseAppHQ hello@museapp.com Show notes Adam Wulf @adamwulf Fantastical Loose Leaf Wulf's iOS ink libraries OpenGL Bézier curves Houston Muse 2.0 launches May 24 Metamuse episode on local-first software Core Data Pocket Clue, Wunderlist CouchDB, Firebase Adam's writeup on sync technologies from 2014 Evernote Pixelpusher Slow Software CRDTs, operational transform Automerge Actual Budget last write wins Actual open source hybrid logical clock, vector clock CloudKit lazy loading API versioning Protocol Buffers Wulf's article on atoms Datomic “put a UUID and a version number on everything” Swift property wrappers functional reactive programming Sourcery Sentry HDD indicator light Muse job post for a local-first engineer Local-first day at ECOOP 2022
This week, we sat down with Mark McGranaghan and Adam Wiggins to talk about building creative tools, designing across devices and platforms, creating career capital, starting design podcasts, and more.Golden Ratio Supporters:Zeplin lets designers spend more time on design, and less time prepping design files for the team. Effortlessly build user journeys with native connectors, flow groups, and text labels — no more maintaining extra layers in your design tool. Zeplin is so much more than just specs — get started for free to see why.The Sidebar:The Sidebar is an exclusive weekly segment for our Patreon supporters. You can subscribe starting at $1 per month for access to bonus content going forward! Sign up at patreon.com/designdetails.Latest VIP Patrons:Meredith GrubbsBrandon SchmittlingPablo González DayZach SheaPedroAlex KayaianJustin FarrugiaAustin SeeleyShrinkrayJeffrey DaneseMain Topic:This week, we sat down with Mark McGranaghan and Adam Wiggins to talk about building creative tools, designing across devices and platforms, creating career capital, starting design podcasts, and more.Mark McGranaghan on Twitter (website)Adam Wiggins on Twitter (website)MuseMetamuse PodcastInk & SwitchThe Twelve-Factor AppGo by ExampleThe future of iPadObsidianRoam ResearchAndy MatuschakCraftCool Things:Brian shared Vampire Survivors, a fun little indie roguelike that is easily worth the price for many hours of chilled-out vampire evasion.Hollow KnightDead CellsWarm SnowMarshall shared Agent to the Stars, a fun and different approach to the alien visitor genre.Design Details on the Web:
Today's guest Adam Wiggins, probably most well known for being co-founder of Heroku – a platform as a service that enables developers to build, run, and operate applications in the cloud.On his website, Adam describes himself as someone who is working to improve computers in service of human creativity and prosperity which I love and this is very much a theme that weaves its way throughout our conversation. Adam's current focus is on Muse - a tool for thought app that was spun out of his research lab – Ink And Switch. Currently for iPad, Adam tells me it will be launching on Mac soon and then mobile.Adam is also a startup investor and advisor and co-hosts the Metamuse podcast with Muse co-founder Mark McGranaghan.In our interview today, Adam and I discuss his childhood fascination with computers, how, as an introvert, he fell in love with designing software products and how we should all be asking ourselves how can we put more effort into making computers and the internet somewhere that really improves humanity's most important noble pursuits such as art and science, as well as our mental and physical health?Adam was humble and generous with his time for which I am grateful and I think there are lots of lessons we can all learn from this conversation.I hope you enjoy the conversation as much as I did.----------Adam Twitter / website / Ink & Switch / Muse / Metamuse Podcast / HerokuDanielle Twitter / Instagram / Newsletter
Welcome to the Danielle Newnham Podcast where I interview tech founders and innovators to learn the inspiring, human, stories behind the game-changing tech we use every day. I am so excited to be back and I have another incredible lineup of guests this year which I can't wait to share with you so don't forget to subscribe wherever you listen to your podcasts so you don't miss out.Just so you know, I am changing things a little bit this year and trialling weekly episodes vs different series so let me know what you think.And as always, I will be talking to really inspiring founders, innovators and investors about a myriad of topics from reimagining education to NFTs, impact investing, accessible tech and the highs and lows of building game-changing products. There's also a big focus on the human side of these stories this year so do hit the subscribe button to be the first to hear each one.Finally, I hope you all had a wonderful break and are raring to go in 2022 – I cannot wait to share these really special episodes with you.
Adam Wiggins was from California originally, but has lived in Berlin for the last decade. Earlier in his life, he did burning man art installations and was a DJ. Now, he is a middle aged family man, so he focuses on his family, his daughter, his adorable dog and his career/software projects. His partner is also an immigrant, whom he met while in Berlin.Adam loves Berlin, and in fact, loves European cities in general, for their focus on quality of life. He mentions that in the states, there is a large amount of economic freedom but some inequality and more highs and lows to speak of. The culture in Berlin specifically is full of history, culture, and a bohemian element which is very attractive to music and art.Adam is most well known for starting Heroku, which completely simplified the way developers think, interact and use infrastructure. Post its acquisition by Salesforce, he found himself thinking about the future of computing, and started a research lab called Ink & Switch. The area they landed on was computing interfaces, and usage around screen touch. After a few prototypes, they landed on something that they though was a solid combination of desktop precision with touch screen mobility.This is the creation story of Muse.SponsorsCourierImg.lyRoutableCTO.aiCloudways offers peace of mind and flexibility so you can focus on growing your business instead of dealing with server management. With Cloudways, you get an optimized stack, managed servers, backups, staging environment, integrated Git, pre-configured, Composer, 24/7 support, and a choice of five cloud providers: AWS, DigitalOcean, Linode, Google Cloud, and Vultr. Get up to 2 Month Free Hosting by using code "CODE30" and get $30 free hosting credit.LinksWebsite: https://museapp.com/LinkedIn: https://www.linkedin.com/in/adam-wiggins-a7623845/https://adamwiggins.com/Support this podcast at — https://redcircle.com/code-story/donationsAdvertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.com/privacy
Expectant Praying | Adam Wiggins
Join us for episode 13 of The Torch of Progress with Adam Wiggins Key Discussion Points: Thomas Edison, Bell Labs, ARPA, and Xerox PARC: what do all of these people and groups have in common? They are all pioneers of the industrial research model. Basic science concerns itself with the search for truth, without any focus on how its findings may impact human existence. Business (even innovation ones like Silicon Valley startups) tend to put existing technology into practice, rather than inventing something new. Industrial research sits in the middle of this spectrum, seeking to find breakthrough ideas that have commercial applications on a five- to ten-year time horizon. Adam walks through this history, which was a big influence for his independent research lab, Ink & Switch (www.inkandswitch.com). Guest Speaker Adam Wiggins: Hi, I’m Adam, and my mission is to improve computers and the internet in the service of human prosperity. Right now I’m building Muse, which turns your iPad into a tool for thought. In the past, I founded the Ink & Switch research lab and Heroku. I design products, build teams, write, podcast, and occasionally invest. I’m from California but have settled in Berlin. Follow me on Twitter: @hirodusk
What does maturity look like? In this sermon, Adam Wiggins shows the importance of each person taking their next steps to grow. When we all take steps toward growth, the church begins to look more like Jesus.
Crafting the right tools for creatives in the digital age. A conversation with Adam Wiggins, entrepreneur and the director of a research lab. Visual index available as a YouTube clip.
The Twelve-Factor App methodology Drafted by developers at Heroku based upon their observations of what made good apps First presented by Adam Wiggins circa 2011 (then published in 2012) The Factors 1 - Codebase: one codebase tracked in revision control, many deploys 2 - Dependencies: explicitly declare and isolate dependencies 3 - Config: strict separation of config from code 4 - Backing services: foster loose coupling by treating backing services as attached resources 5 - Build, release, run: strictly separate build and run stages 6 - Processes: processes are stateless and share-nothing 7 - Port binding: export services via port binding 8 - Concurrency: scale out via the process model 9 - Disposability: processes are disposable, they can be started or stopped at a moment's notice 10 - Dev/prod parity: Keep development, staging, and production as similar as possible 11 - Logs: treat logs as event streams, don't manage log files 12 - Admin processes: admin and utility code ships with app code to avoid synchronization issues What's Missing? 7 years since first being published, what changes should be made to make it more relevant for today? Some have argued for adding 3 additional factors: Telemetry Security "API First"-philosophy For a full transcription of this episode, please visit the episode webpage.End song:Flowerchild (Roy England Remix) by Owen Ni - Make MistakesWe'd love to hear from you! You can reach us at: Web: https://mobycast.fm Voicemail: 844-818-0993 Email: ask@mobycast.fm Twitter: https://twitter.com/hashtag/mobycast Reddit: https://reddit.com/r/mobycast
I denne episode af Let's start @ Nine fortsætter vi vores minitema om cloud native applikationer, som er bygget efter 12 factor principperne. I den forrige udgave hørte vi Nikolaj Brinch Jørgensen fortælle om de første 5 factorer og i denne udgave gælder det så de næste 7 faktorer. De 12 faktorer er defineret af Adam Wiggins, som også er stifter af cloududbyderen Heruko og som derfor havde en naturlig interesse i at udbrede budskabet om hvordan løsninger skal skrues sammen for at fungere godt i et cloud miljø. Wiggins publicerede 12 factor november 2011. Så hvor microservices handler meget om organisering af funktionalitet i komponenter, så handler 12 factor om de kvaliteter de enkelte komponenter skal besidde. I Kents Corner skal vi høre hvordan de store tegneserieforlag håndterer legacy og hvordan der kan være penge i at lave jævnlige refactorings.
Dette er den første af to episoder af Let's start @ Nine hvor vi har besøg af Nikolaj Brinch Jørgensen, som vil guide os igennem de 12 faktorer, som er afgørende for moderne, såkaldte “Cloud Native” apps eller løsninger. De 12 faktorer er defineret af Adam Wiggins, som også er stifter af cloududbyderen Heruko og som derfor havde en naturlig interesse i at udbrede budskabet om hvordan løsninger skal skrues sammen for at fungere godt i et cloud miljø. Wiggins publicerede 12 factor november 2011. Så hvor microservices handler meget om organisering af funktionalitet i komponenter, så handler 12 factor om de kvaliteter de enkelte komponenter skal besidde. I dette afsnit gennemgår vi de første fem faktorer, mens de øvrige syv kommer i næste afsnit. I Kents corner bliver vi klogere på fiktive byer som Gotham og Arkham.
My Guest this week is Adam Wiggins, the cofounder of Ink & Switch — an independent industrial research lab working on digital tools for creativity and productivity. The topic of the conversation is the future of product-focused R&D, the Hollywood Model of work in tech, Ink & Switch’s unique organizational structure, and whether it can be extended to other areas of research. Links Adam Wiggins’ Home Page Adam on Twitter Ink & Switch's Home Page A presentation on Ink & Switch's Structure Sloan Review Article on Applying Hollywood Model to R&D (Paywalled) Transcript How the idea came about Ben: How did you come up with this idea? Like wait what what originated that I'm just really interested in the thought process behind there Adam: sure, you know, I think me and my partner's we come out of the sort of the startup kind of school of thought on Innovation, I think. There's a lot of way to think about there's the more academic research minded approach to Innovation. There's made which get a bigger companies. So yeah, we come out of very much from the yeah. I don't know what you want to call it ad Jolene startup y combinator or whatever that you know mix of elements is which is really about build a thing really quickly get it in front of customers minimal viable product innovate, but at least my thinking is that the startup model has been so successful in the last let's say decade. Particularly with the kind of mass production of the startup that you get through groups like y combinator such that I feel like the problems the space of problems that can be solved with that kind of, you know group of 25 25 year old Founders spending three months to build a thing not say it's let's say saturated. Yeah to some degree in that maybe the more interesting problems are like bigger or longer in scope. And so then we thought about okay. Well, what's a what's a model that is more possible for going after bigger things. And that's when I kind of fell down the rabbit hole of researching these Industrial Research Labs. I know that you spent a lot of time on as well, you know, these big famous examples like Bell labs and Xerox Parc and arpa and so forth. And of course many other examples when we thought okay, well, You know, we're not at the we're not in a position to you know, be setting up a multimillion-dollar research arm of a government or commercial institution. But what can we do on a smaller scale with a small Grant and it's kind of a scrappy band and people and that's kind of what led us to the Incan switch approach. The Thought Process Behind the Model Ben: can you go one step further where it's you have the constraint that you can't do a straight-up corporate research lab, but I think there are a lot of unique ideas in terms of a model that are sort of just unique and. In that like how did you cope that Lee idea that like, okay, we're going to like have our principles. We're going to pull in people temporarily. We're going to build this network that that seems sort of to come out of the blue. So what was what was the thought process behind that? Adam: Well, maybe it came out of the constraint of do it with very little money. And so part of that is we're trying to work on a big problem. Hopefully and I can talk about that if you want, but the in terms of the the model that we're using we came at it from do it with very little money and that in turn leads to okay. Your big costs are usually sort of like office space and then the people right, but if we can do these really short term projects, we called the Hollywood model and I can explain about that if you want the basically we have like a four or six or eight week project. You can bring in some experts on a freelance basis and you don't necessarily need to commit to paying salary is over the longer term and you couple that with no office. We have an all distributed team. We're not asking people they don't need to pick up. Move somewhere to even temporarily to work on a project. Right? And so we what we can offer them as a lot of flexibility. And so the I think there's certain there's benefits for the people to participate in these projects join, but from the lab point of view again, it was we were embracing this constraint of do it really really cheap. Yeah and that basically boiled down to very short projects people on a freelance basis only no office and that that's kind of what what led us there, but I think there actually is a lot. Benefits to doing things that way there's some big downsides as well but there's some benefits as well. So the constraint led us to the model you might say got a desire to work on a big problem in the same with a longer time Horizon like you would for a you know, a classic R&D lab, but trying to do that with a lot less money. Let us to this kind of short-term project model. The Hollywood Model in Tech Ben: There are three things that I want to take into from that the three things are going to be how the Hollywood model works and sort of the difference between the Hollywood model in Tech versus in Hollywood and then like those those pros and cons and then it feels like there's a tension between working on a really big long term projects via very short term sort of Sprint demos. So. So let's let's start with the Hollywood model because in Hollywood I like after after I learned about. You doing that I sort of dug into it and it's it seems like the Hollywood model Works partially because all of Hollywood is set up so that even the best people work on this temporary basis. Whereas in Tech, it feels like you sort of have to get people who are in very special life situations in order to get the best people. So like, how do you how do you juggle that? Adam: Yeah, yeah, that is those are really good point. Well just to I guess briefly explain. The Hollywood model is please the idea. There is I actually lived in Los Angeles for a time and have a lot of friends who are trying to break into that industry and got a little exposure to that. I don't pretend to be an expert but and you can read about this online as well, which is that most movies are made by forming a an entity usually an LLC for the duration of the movie Project. You know, I might be a year or two. Here's whatever the shooting time is and everyone from the director or the camera people the whole cast the entire crew are all hired as essentially short-term contractors for whatever the duration of time their services are needed. But even someone like director who's there throughout. It's essentially a one or two-year gig for him it yeah, and everyone's fired right things right expanded and it's and it's an interesting accounting model because it means the sort of earnings from the movie in the and how that connects to the studio. And then the way the studio is invest is almost more like maybe Venture Capital invest in startups to some degree. So that's that's my understanding of it. So we kind of borrowed this idea for saying okay part of what we like about this is you get a situation. Any given person and a cameraman a crew member a member of the cast doesn't isn't guaranteed some long-term employment. They don't sign on for an indefinite thing. They sign up for the duration of the project. Right and the end everyone leaves. But what you see is that the same directors tend to hire the same crew the same. You probably noticed this most dramatically in directors that bring the same actors on to the same onto their future films because if working with them before worked, why wouldn't you bring them back? Right and so it's but it's it inverts the model of instead of we're going to keep working together by default. It's more every time a project ends. We're all going to disperse but the things that work will kind of bring back together again and just inverting the model in a subtle way. I. Produces better teams over the long term. But yeah, you get this sort of loose network of people who work and collaborate together to have more of an independent contractor gig mindset and I think that was yeah it was inspired by that and like you said, can we bring that to kind of Technology Innovation? How do you incentivize the hollywood model? Ben: Most people in Tech don't do that. So, how do you sort of generate? How do you get the best people to come along for that model? Adam: That was definitely a big unknown going into it and certainly could have been a showstopper. I was surprised to discover how many great people we were able to get on board maybe because we have an interesting Mission maybe because me and some of the other. Core people in the team have you know just good networks good career Capital. Yeah, but actually it's that more people are in between spaces and you might guess so quite a lot to work with us on projects. Certainly. There's just people who are straight. You know, they made freelancing or some kind of independent Contracting be their business, right so that those folks are to work with a lot of folks that do open source things, you know, we work a lot of people from the DAT Community, for example, a lot of folks there. They actually do make a livelihood through some degree of freelancing in this space. So that's an easy one. But more common I think is you think of that. Yeah full-time salaried software engineer or product design or what have you and they. You know, maybe they do a new job every few years, but they're expecting a full employment salary HR benefits, you know the lunch on campus and the you know, the massages and you know yoga classes and so I was worried that trying to you know compete to get Talent like that when all we have to offer these very short term projects would be difficult. But as it turned out a lot of people are in some kind of in-between space. We're really interesting. Project with an interesting team good sort of in between things maybe a palate cleanser in a lot of cases turned out to be quite interesting. So we got a lot of people who are you know, they're basically looking for their next full-time gig but then they see what we have to offer and they go oh, you know, that's actually quite interesting and they can keep looking for the next job while they're working with us or whatever. Yeah their Habits Like do this thing is like an in-between thing onto the way that are to their next. Employment or we have situations like, you know one person we were able to get on the team with someone who is on Parental. Leave from their startup and so basically wanted to be like getting the mental stimulation of a project but couldn't really go into the office due to needing to take care of an infant, right? Um, and so by working with us was able to get some nice in that case part-time work and some mental stimulation and a chance to build some skills in the short term in a way that was compatible with. Needing to be home to for childcare. So the a lot of cases like that. I think so it granted, you know people that are looking for full-time gigs. We can't give them the best offer in the world. But there's a surprising number of people that are willing to take a weird interesting kind of cool learning oriented project in between there. May be more conventional jobs. Building from scratch with the Hollywood Model? Ben: Yeah. Because one of the things that I'm constantly thinking about what I'm asking these questions is how do we have more things using the same model in the world? Because I think it's a really cool model that not many people are using and so it's like what like could there be a world where there are people who just go from like one to the other and then would be an interesting shift in the industry to be a little more gig oriented or Independent. Contractor oriented versus the sort of the full-time job expectation that folks have now. Yeah and another sort of difference between I think Hollywood and Tech is that Hollywood you're always sort of Reinventing things from scratch. Whereas in tech there is code and and things that sort of get passed on and built on top of . Do you do you run into any problems with that or is it just because like every every experiment is sort of its own its own thing. You don't you don't have that problem. Adam: Yeah, the building on what came before is obviously really important for a lot of our projects. We were pretty all over the place in terms of platforms. And that was on purpose we built a bunch. Projects on the iOS platform we bought built from on the Microsoft Surface platform. We've done in various different web Technologies, including electron and classic web apps and so in many cases there is not a direct, you know, even if we had written a library to do the thing we needed in the other thing. We actually couldn't bring that over in that kind of build it all from scratch each time or or the the mic slate of it. I think is part of what makes it creative or forced to rethink things and not just rely on the. Previous assumptions that said. You know for certain tracks to research you might call it a big one for us is this world of like CR DTS and essentially like getting a lot of the value of getting a lot of capabilities that you expect from cloud Solutions real time collaboration Google Docs style of being able to do that and more peer-to-peer or less centralized oriented environment. And so we in an earlier project. We built a library called Auto merge just in JavaScript and it was being plugged into our electron app and. And in future projects, we wanted to build on top of that and we have done a number of subsequent projects some of which were but obviously they needed to like use the JavaScript runtime in some ways. So if we were doing another electron project, yes, you can do that but that and then another case, you know, we wanted to go with tablet thing. All right. Well that limits us because we can't use that library in other places. And in one case is we chose to build for example in the Chrome OS platform because we can get a tablet there and partially because we already had this investment in kind of. Script ecosystem through these libraries. But yeah again that comes with comes with trade-offs to some degree. So so we're always trying to balance build on what we made before. But also we're really willing to kind of start over or do the blank canvas because we really feel like at this. Level of early Innovation. What matters is the learning and what lessons you learn from past projects and you could often rebuild things in a fraction of the time in some cases we have actually done that is rebuilt an entire project sort of like feature complete from what on a completely different platform. But if you can skip past all the false turns and you know Discovery process and to build what you where you ended up it's often something that can be done in just a tiny fraction of the time or cost Knowledge Transfer in the Ink&Switch Model Ben: Got it. And do you have a way of transferring learning between different groups of temporary people that things like would be one tricky piece. Adam: Absolutely. Well an important thing here is we do have core lab members both. We have some principal investigators who are people that are around long-term and are the people that drive our projects and their, you know, carry a lot of those learnings both the Practical ones, but also like culture. Cultural elements and then a lot of the folks we work with they'll come back to work for a future project. But yeah, absolutely every given project is a new combination of people some existing people in the lab. They carry forward some of those learnings and then some people who are new and so we've had to do we tried a variety of approaches to kind of. Do a mental download or crash course and you know, none of it's perfect. Right because so much knowledge. Is that even though we take a lot of time to do a big retrospective at the end of our projects try to write out both raw notes, but also like a summarize here's what we learn from this project even with that and sharing that information with new people so much of what you learn is like tacit knowledge. It's somehow, you know more in your gut than in your head. And so to some degree we do count on the people that are more standing numbers that go project project in some cases. We do have to relearn small lessons each time. And again that that somewhat is a you know, if you start over from scratch and you kind of start from the same premises then you often discover some of the same same learnings. I think that's okay as long as we get a little faster each. Each time and then yeah combine that with learning documents and I don't know for example, we're actually the point now we have enough projects under our belt. We actually have a deck that is like here's all our past projects and kind of a really quick crash course summary, at least here's what they're called and least when people reference. Oh, yeah. That's the way we did things on Project number five right was called this and you can be like at least have some context for that. And so short answer is we haven't solved the problem but here's some things that at least have helped with that. Yeah, and how many projects have you done in total? Yeah. Well depends on exactly how you count. But when it comes to what we consider the sort of the full list called formal projects, which is we spend some time kind of wandering around in a in a period of time to call pre-infusion named after the the espresso machine for the sort of record time. You put in the water to kind of warm up the grounds. So the version of that and once we have basically a process where once principal investigator finds a project with egg, I think there's a really promising area and we should fund this. Okay. Now we're going to go actually hire experts that are specific to this area. We're going to commit to doing this for again six weeks or eight weeks something on that order. There's a project brief we present basically present that to our board to basically give like a thumbs up thumbs down. I'm so if you count stuff that has been through that whole process we've now done 10 projects cool. That's over the course of about three years. Ink&Switch Speed vs. Startup Speed Ben: Yeah, that's that's really good compared to. Like I start up where you do one project and takes three years. Adam: I need to maybe feels sometimes it feels slow to me. But honestly, we spend as much time trying to figure out what it is that we want to do as actually doing it and then suspend a really good bit of time again trying to retrospect pull out the learnings actually figure out. What did we learn? You know, we usually come out with strong feelings and strong Instinct for kind of this work. This didn't work. We'd like to continue this. There's more to research here. This is really promising. This was a dead end but actually takes quite a bit of time to really digest that and turn it into something and then kind of the context shift of okay. Now, let me reorient and switch gears to a new project is really a whole skill, too. To be doing such a rapid turnover, I think and I think we've gotten decent at it over the last few years, but I think you get a lot better if you wanted to keep at it. Ink&Switch's Mission and Reconciling Long Term Thinking with Short Term Projects Ben: Yeah. And I've actually like to step back real fast to the bookmark in terms of a the big picture long-term thinking like what is in your mind the real Mission here and B. How do you square these? Like, how do you. Generate a long-term result from a whole bunch of short term projects. Adam: right. Yeah, really cool problem. Absolutely. Yeah. Yeah and one again, I don't pretend to have answers to we're still in the middle of this experiment will see if it actually actually works. Yeah, let me start by just briefly summarizing our our mission or a theme. I like to think of it a little bit right like typically these and these great examples of successful Industrial Research Labs, you know for Bell Labs or theme was this Universal connectivity that has Bell had this growing Communications Network and they wanted to like solve all the problems that had to do with trying to tie together an entire nation with Communications technology or Xerox Parc. Of course, they had this office of the future idea. It's. How many papers and copier what is it going to be? I think you need a theme that is pretty broad. But still you're not just doing a bunch of random stuff that people there, you know think it's cool or interesting new technologies. It's tied together in some way. So for us our theme or a research area is Computing for productivity and creativity. Sort of what the digital tools that let us do things like write or paint or do science or make art are going to look like in future and we were particularly drawn to this and. And our investors were drawn to this because so much of the brain power and money and general Innovation horsepower in Silicon Valley certainly the tech industry broadly and even to some degree in Academia computer interaction research and so on it really pointed what I would call consumer technology. Right, it does social media It's Entertainment. It's games. It's shopping. Yeah, and and that's really a phenomenon just the last five or ten years, right the successful smartphones the fact that sort of computing has become so ubiquitous and mass-market its health and fitness trackers yet wearable, and you know, that's all great, but. I think that the more inspiring uses the more interesting uses of computers for me personally. I things that are about creativity there about self-improvement there about productivity and when you look at what the state of I'm going to look like a spreadsheet, right if you look at Excel in 1995 and you compare that to Google Sheets in 2018 the kind of looks the same. Yep, you know, it's at a Google Sheets as real-time collaboration, which is great. Don't get me wrong. But basically the same kind of program, right? Yeah. And I think you can say that same thing for many different categories Photoshop or presentation software note-taking software that sort of thing. There's some Innovation to give me to go get me wrong, but it just feels very out of balance how much again of that Innovation horsepower of our industry broad. They could go into Super Side. So for us the theme is around all right. We look forward five or ten years to what we're using to be productive or created with computers. What does it look like and you know, the reality is desktop operating systems or more and more kind of advanced mode because that's not where apple or Microsoft revenue is anywhere. But at the same time I don't think it's you know, touch platform particularly, you know are built around phones and consumer Technologies and sort of the pro uses of them tend to be kind of attack on afterthought. And so it sort of feels like we're in a weird dead end which is like what are we going to be doing 10 years from now to yeah do a science paper or write a book or make a master thesis or write a film script? It's hard to picture and but actually picturing it is that's that's sort of our the job of our research here. Ben: and that is a really long term project because you sort of need to go back down the mountain a little bit to figure out what the what the other mountain is. Adam: Absolutely. Yeah the local Maxima of some kind and so maybe you need to yeah be a little. Out of the out of the box and go away from basically make things worse before they get better. Aside on AI Enabled Creativity Tools Ben: Yeah, just aside on that. Have you been paying attention to any of the sort of like a I enabled creativity tools? This is just been on my mind because Neurosis is coming up and there's some people who have been doing some like pretty cool stuff in terms of like. Enhance creativity tools were like maybe you start typing and then it starts completing the sentence for you and and or like you sort of like draw like a green blob and it fills in a mountain and then you sort of like just adjust it. Have you been paying any attention to those tools at all? Adam: Yeah. Absolutely. Some of the follow sir pokes on Twitter that post really interesting things in that vein that hasn't been an area of research for us partially because maybe we're a little contrarian and we like to kind of look where. You are looking and I feel like Ai, and that kind of Realm of things is very well. Or I should say a lot of people are interested in that that said yeah, I think to me one of the most interesting cases with that is usually we talk about with like generative design or things like. Sot great Target Range Loop last year by an architect who basically uses various kind of solvers we plug in like here's the criteria we have for like a building face, you know, we need the window has to be under the, you know can't because of the material dimensions and the legal things and whatever it can't be here's the constraints on it. But here's what we want out of the design. You can plug that in and the computer will give you sort of every possible permutation. And so it's a pretty natural step to go from there to then having some kind of. Algorithm whether it be here a stick or something more learning oriented, which is then try to figure out from that superset of every possible design satisfies the constraint which of them are actually sort of the best in some sense or fit what we said that we like before where we use, you know, the client or the market or whatever it is you're looking for. So I think there's a lot of potential there as I think it was more of an assistive device. I get a little skeptical when it gets into the like let's get the computers to do our thinking for us. Yeah realm of things. I would say, you know, I think you see with the fit and of the sort of auto complete version of this, but but yeah, but then but then maybe I you know, I love that artisanal Craftsman, you know, some kind of unique vibe that humans bring to the table and so yeah tools as. Assisting us and helping us and working in tandem with us and I think yeah, there's one probably a lot of potential for a eye on that that said that's not an area where researching. Ben: Yeah. I just I wanted to make sure that was on your radar because like that's that's something that I pay a lot of attention to him very excited about. More Reconciling Long Term and Short Term Ben: Yeah, and so for the long-term Vision, the thing that I always worry about in the modern world is that we are so focused on what can you do in a couple months these little Sprint's that if there's a long-term thing you just wouldn't be able to get there with a bunch of little projects. So I'm really interested in like how you resolve that conflict. Adam: Yeah, well you could say it's one of the biggest Innovations in Innovation, which I know is the area your study medication to get into this iterative mindset this what he called agile whether you call it. Yeah, iterative that the idea of kind of breaking it down into small discrete steps rather than thinking in terms of like I don't know we're going to go to the moon and let's spend the decade doing that. But instead think of and I didn't even see that difference in something like the space program right the way that the modern. Space exploration stuff that's going on is much more in terms of these little ratcheting steps where one thing gets you the next rather than that one big Mega project. It's going to take a really long time the super high risk and super high beta so I in general. I think that's a really good sort of shift that's happened. But yes, it does come at the expense of sometimes there are jumps you can or need to make that are not necessarily smaller steps. And so I certainly don't propose to have the answer to that. But at least for what we're doing the way I think of it is, you know, starting with a pretty Grand Vision or a big Vision or a long time Horizon. If nothing else and trying to force yourself first and foremost into the bigger thinking right? But then going from there to okay, if that's you know, where we want to go. What is the first step in that direction? What is the thing that can give us learning that will help us get there and one of the metaphors I always love to use for I guess research in general or any kind of Discovery oriented process is the other Lewis and Clark expedition, you know, this was commissioned by the Thomas Jefferson was president at the time and it to me was really crazy to read about. Holly you know they hadn't explored the interior of the continent they believe there might still be willing - running around and actually one of the things Thomas Jefferson Wander from the he's like, I really loved a, you know get a while you're out there they just had no idea they knew that the Pacific Ocean was on the other side that had ships go around there. But other than that it was this dark interior to the continent, but they sat out you know that expedition set out with the goal of reaching the Pacific Ocean and find out. What's on the way right and they did they took their best guess of what they might encounter on the way and put together Provisions in the team to try to get there. But then the individual sort of you might wait, you might call the iterative decisions. They need to make along the way to be go up this mountain rage. And we divert this way to be cut across this River. Do we do we follow this for a while do we try to befriend these tribes people who run away etcetera. Those are the sort of the iterative steps for the important thing is keeping in mind that long-term strategic goal. Um and defining that goal in such a way that it doesn't say go west, you know, it's not a set of directions to get there because you can't know that you have to start with here's what our vision is. Let's connect the two coasts of this country and then we're going to take whatever whatever iterative steps seem to be most promising to lead us in that direction. Also realizing that sometimes the most iterative step leads us in a way even away from our goal. So hopefully that's what we're trying to do it in can switch is picking individual projects. We hope carve off a piece of the bigger thing that we think will increase our learning or build our Network or just somehow illuminate some part of the this problem that we want to we want to understand better again, what is the future of you know, productive and creative Computing and then hopefully over time those will add up in the trick is not to get lost for me. I think the trick is not to get too lost in. Detail of the project right? And that's where the Hollywood model is. So important because you got to end the project and step away to truly have perspective on it and to truly return to looking at the bigger thing and that's what you don't get in my experience working in a startup that has operations and customers and revenue that you know goals. He need to hit us according to those things which are absolutely you know, the right way to run a business but then. Keeping that that that bigger picture view and that longer term mindset is very difficult. If not impossible in that setting. So that's our approach. Anyways, see how about in longer term? Loops around Loops: The Explicitly Temporary Nature of the Whole Lab Ben: and in terms of of your approach and ending things is it true that you're actually going to at the end of a certain amount of time. You're going to step back and look reevaluate the whole. Is it like you're sort of doing like loops loops around Loops Adam: indeed? Yes. So individual projects have this sort of you know, we'll end it and and step back and evaluate thing. And then yeah, the whole thing is basically, you know, we have a fixed Grant when that's how it's out and right and it's up to us to deliver invest to investors the learning you might call the intellectual property. We're not patenting things or whatever, but the. See protect the things that offer commercial potential and could potentially be funded as startups. Basically. Yeah, that's you know, that's that's what we'll do. And actually that will happen next year. Wow. And when that does happen will hopefully do you know will do the same process? Like you said that the the bigger loop on the smaller Loop which that we've done on the smaller Loops which is retrospect at the end write down everything we've learned and then we do go ahead and let the team. Part of that may be when you've done put all this hard work and getting a team together, but my experience is that if there's really some great opportunity there. You'll recall us it in some new form. What Comes out of the Lab? Ben: I can see it's going multiple ways. Where you. You ended and then you could either say there's another five-year research thing in this or there's some number of sort of more traditional startups to come out of that to try to capture that value are those sort of the the two options. What what do you see as the possibilities that come out of this? Adam: Yeah, those are those are both pretty key outcomes and they're not mutually exclusive right so it could be that we say, all right, great, you know we generated sort of five interesting startup options one of them. You know an investor decided to pick that up and you know, maybe take a team that is based on some of the people in the lab that worked on that and those folks are going to go and essentially work on commercializing that or making a go to market around that but then some other set of people who were involved in things and want to come back to this. He's promising tracks research and we're going to take another grant that has another time duration, I think. The obviously money is your ultimately all of them in limiting factor it yeah in any organization, but but I like the time boxes. Well, I think we use again we use that for our short-term projects and and some degree. We used it for the lab overall. I think thinking that it's like that Star Trek, you know, what is it or three-year Mission our five-year Mission, whatever it is. It's something about the time box that kind of creates clarity. Yeah, maybe in some is and yeah, you might decide to do another time box another chunk of time. In other chapter actually investors do this as well. If you look at something like the way that Venture struck funds are structured they often have sort of multiple. Entities which are you know, it's fun one fun to fund three. Yeah, right and those different funds can have different kind of buy-ins by different partners. They have different companies in their portfolio, even though there is like a continuous. I don't know if you want to call a brand or culture or whatever the ties them all together and I think that approach of like having these natural chapter breaks time or money based chapter breaks in any work is like a really useful and valuable thing for. Productivity and I don't know making the most of the time. Human Timescales - 4-5 Years Ben: I completely by that. I have this theory that human lives are kind of divided up in like these roughly five year chunks. We're like that's that's the amount of time that you can do the sort of the exact same thing for the most time and if you if you like if you don't have. You can reevaluate every five years but it's like you look at like school. It's like you really like maybe it's like five years plus or minus like to but beyond that it's really hard to like sustained. Intense and tension on the same thing. So that makes that makes a lot of sense Adam: agree with that. I would actually throw out 4 years as a number which does I think Max match the school thing it also matches the vesting schedules are usually the original vesting schedule and most startups is a four-year window. And if I'm not mistaken, I think that is the median length of marriages think there's something around. Well, you know, maybe it's something around, you know, there's renewal in our work life is what we're talking about here. But there's also renewal in a personal life, right? And if you're yeah if your employee at a company. Maybe something around for years as a feels like the right Tour of Duty. No not say you can't take on another Tour of Duty and maybe with the new role or different responsibilities, but there's something about that that seems like a natural like you said sustained attention, and I think there's something to goes about as well as inventing. Or Reinventing yourself your own personal identity and maybe not connects to you. Marry. Someone for years goes by you're both new people. Maybe those two people aren't compatible anymore. Yeah. I don't know. Maybe that's figure that's reaching a little bit far. I mean the other yeah Investors, Grants, and Structuring Lab Financing to Align Incentives Ben: that makes a lot of sense and you mentioned investors a couple of times but then also that it's a grant so how did you something something that I'm always interested in is sort of like how to. He's up. So the incentives are all aligned between the people like putting in the money the people doing the work and people setting the direction and so like how did you structure that? How did you think about sort of coming up with that structure? Adam: Yeah, I've used maybe investors and Grant sort of a little Loosely there again, the model we have is a little different. So when I you know went to pitch the private investors on what we were going to do with this, I basically said look. Me and my partner's we had been successful in the past producing commercial Innovations. We want to look now at something that's a little bigger a little longer term and wouldn't necessarily fit as cleanly into some of the existing funding models including things like the way that the academic research is funded and certainly Venture funding and so take a little gamble on us. Give us a pics. Amount of money a very small amount of money by some perspectives to deliver not profits, but rather to deliver again this kind of concept of learning intellectual property in the loose sense not in the legal sense, but in the sense of intellectual Capital, maybe might be another way to put it and more explicitly. Yeah spin out potential right but the but but no no commitment to make any of these things. It's just we've evaluated all of these opportunities. Here's what we think the most promising ones are and that includes both. Let's call it the validated findings. We think there's a promising opportunity here at technology. That's right to you know, serve serve some marketing users well, but also some things that we got negative findings on we said well look we think there's a really interesting Market of users to serve right here the technology that would be needed kind of isn't ready yet and still five years out or maybe the market is actually tough for an early not very good for sort of early adopter type products and so in some way that would be valuable to. There's as well to have this information on why actually is it is not wise to invest in a particular Market a particular product opportunity. So that was that was what we asked for and promised to deliver and obviously we're still in the middle of this experiment so I can't speak to the whether they're happy with the results. But at least that's the that's the deal that we set up. Tension between Open Knowledge Sharing and Value Capture Ben: I just I love the idea of investment not. Necessarily with a monetary return and it's like I wish there were more people who would think that way and. In terms of incentives. There's also always the question about value capture. So you you do a really good job of putting out into the world just like all like the things that you're working on and so it's like you have all those the great articles and like the code. Do you hold anything back specifically for for investors? So that because I mean it would make sense, right because you need to capture value at some point. So it's like there's there's got to be some Advantage. So like how do you think about that? Adam: Yeah. I don't have a great answer for you on that, you know, certainly again, you know, there's conventional conventional ideas there around yet Trade Secrets or patents or that sort of thing, but I kind of. Personally, I'm a little bit more of a believer in the maybe comes back to that tacit knowledge we talked about earlier, which is you can in a way. I feel like it's almost misleading to think that if you have the entire project is open source that somehow you have everything there is to know I feel like the code is more of an artifact or an output. Yeah of what you learn and the team of people that made that and the knowledge they have in their minds and and again in. To some degree in there. There are sort of hearts and souls. Yeah is actually what you would need to make that thing successful. Right? And I think a lot of Open Source people who work on open source for a living rely on that some degree, which is you can make a project that is useful and works well on its own but the person who made that and has all the knowledge about it. They have a they have a well of. They have a lot of the resources that are really valuable to the project. And so it's worth your while to for example go hire them. And so that's that's the that's the way I think that we think about in The Way We pitched it to investors. If I were to do this again, I might try to look for something a little more concrete than that a little more tangible than that. The other part of it that I think is. Pretty key. Is that the networking? Yeah, and so you could say okay. There's the knowledge of the people who worked on in their heads. It may be that that kind of ties together. But there's the knowledge we transferred directly by like here's a here's a document that tells you everything we learned about this area where we think the opportunities are but then it's also by the way, we had a bunch of people to work on this some of whom are now in some cases where we were pushing the envelope on a particular Niche e sub technology. We end up with people on the team who are in many cases of the world's experts or we're in touch with the few experts in the world on a particular topic and we have act we have that network access. And so if someone wants to go and make a company they have a very easy way to get in touch with those people not the really impossible for someone else to take that. Bundle of information or take even a code based on GitHub and pick through the contributors list try to figure out who worked on it and go contact them. You know, I think that's possible Right, but I think it's quite different. You would be the pretty substantial disadvantage. There's someone that actually had the worm Network and the existing working collaboration. Extending the Ink&Switch Model to Different Domains Ben: Yes, the I like that and in terms of using the model in different places. Have you thought about how well this applies to other really big themes the things that you're working on our nice because it's primarily software like the capital costs are pretty low. You don't need like a lab or equipment. Do you think that there's a way to get it to work for maybe in biology or other places where there's higher friction. Adam: Yeah, I think the fact that we are in essentially purely in the realm of the virtual is part of what makes the sort of low cost. By all remote team and not asking people to relocate that's what as part of what makes that possible. We do have some cost. We've certainly purchased it quite a bit of computing Hardware over the course of the of the course of the lab and ship those to whoever needs it. But that said, you know, we can do that. I think this model would best apply to something that was more in the realm of knowledge development and not in the realm of you have to get your hands physically on something. Whether that's a DNA sequencer or a hardware development or something of that nature, but on the other hand as certainly as cameras get a more of the quickest and high-speed internet connections get better and certainly we've learned a lot of little tricks over the time. I think we were talking about the start of the call there about. Our use of document cameras is basically screen screen sharing for tablets doesn't work great because you can't see what the users hands are doing. So we learned pretty quickly that you got to invest in document cameras or something like that in order to be able to kind of effectively demo to your teammates. One of the quick or as a kind of a sidebar but related to that is one of the learnings we had in making the distributed team thing work is you do have to get together in person periodically so we can to support early team Summits got it. Making Watercooler Talk and Serendipity Work with a Distributed Team Ben: I was actually literally just thinking about that because one of the things that I always hear about. Great research places like whether it's like Bell Labs or DARPA is sort of like the the water cooler talk or the fact that you can just sort of like walk down the hall and like really casually hop into someone's office. And that's the problem with distributed teams that I haven't seen anybody saw well, so so you just do that by bringing everybody together every once in a while. Do you think that generates enough? Adam: Yeah. I mean the to your right like. That problem is very big for us. And there's there's a number of benefits we get from the distributed team, but there's also a number of problems. We haven't solved and so I'm not sure how this would balance against the sort of the spending the same amount of money on a much shorter term thing where people could be more in person because that water cooler talk you get some of with a slack or whatever but. It's just not the same as being co-located. So yeah, the the one of the mitigating things we have that I think is works pretty well as about about quarterly or so. We got everyone together and it's actually kind of fun because because we don't have to go any place in particular. There's no central office. We try to pick a different city each time someplace that's creative and inspiring we tend to like interesting Bohemian Vibe, you know in some cases urban city Center's been in some cases more historic places or more in nature. Ideally someplace close to International Airport that it wouldn't fly into and for really a fraction. I mean offices are so expensive. Yeah, and so our fraction of the price of maintaining an office. Actually fly everyone to some pretty interesting place once a once a quarter and so for a week, we have like a really intense period where we're all together in the same physical space and we're working together. We're also getting the human bonds more that casual conversation and we tend to use that time for like a lot of design sketching and kind of informal hackathons are also some bigger picture. Let's talk about the some of the longer term things lift our gaze a little bit and that helps a lot. Again, it is not as is demonstrably not as good as being co-located all the time, but it gets you I don't know 30 to 40 percent of the way there for, you know a fraction of the cost. So yeah over the over the longer term again, I don't know how that would Stack Up Against. Collocated team, but that's one good thing to getting product review so far. Where to find out more Ben: I see that we're coming up on time and I want to be very respectful of your time. I'm going to make sure people know about the website and your Twitter. Is there anything else any other places online that people should learn more about and can switch to learn more about you and what you're working on. Adam: Ya know the the website and the Twitter is basically what we got right now. We've been really quiet in the beginning here not because you know, I'm a big believer in that, you know that science approach of Open Access and you know, it's about sharing what you've learned so that humanity and can build on each other's learnings that said it, you know, it's a lot of work to to package up your ideas, especially when they're weird and fringy like ours are in a way that's consumable to the outside world. So we're trying to do a lot more of that. All right now and I think you're starting to see that little bit to our to our Twitter account where in including publishing some of our back catalogue of internal memos and sketches and things which again very itchy things you got to be really into whatever the particular thing is to find find interest in our internal memo on something as well as taking more time to put together demo videos and longer articles that try to try to capture some of the things we've learned some of the philosophies that we have some of the technologies that were. So yeah, there's she spots a great Thinking About Extending The Model Ben: So freaking cool. the. That I'm doing is just putting together the ideas and trying to almost make a more generic description of what you're doing so say like, oh, what would this look like if it goes into biology or it goes into something? What would this look like for nanotech? could you do the distributed team using University resources? Right? Like could you partner with a whole bunch of universities and have someone in different places and they just like go in and use the lab when you need to I don't know like that's one Bay action item based on learning about this is like oh, yeah. I think I think it could work. Adam: That sounds great. Well, if you figure something out, I'd love to hear about it. I will absolutely keep you in the loop. Ben: awesome. Cool. Well, I really appreciate this. I'm just super excited because these new models and I think that you're really onto something. so I really appreciate you bringing me in and going into the nitty gritties. Adam: Well, thanks very much. Like I said, it's still an experiment will we get to see? But I feel like I feel like they're more Innovation models than just kind of start up. Corporate R&D lab and Academia. Yeah, and if you believe like I do that technology has the potential to be an enhancement for Humanity then you know Finding finding new ways to innovate and a new types of problems and you new shapes of problems potentially has a pretty high high leverage impact the world.
Ben talks with John Norman about his process and modified approach to the delivery, payment, and tech of modern managed health care. They also touch on age bias in the programming world, living a purpose-driven life, and dealing with startup growth. Iora Health "The Hot Spotters"- Atul Gawande The Healing of America- T.R. Reid WellnessFX Agile Manifesto HIPAA Being Mortal- Atul Gawande "How to Scale a Development Team"- Adam Wiggins "The Double Diamond Model of Product Definition and Design"- Peter Merholz John on Twitter
Chad talks with thoughtbot CMO Dan Croak about our content marketing strategy, managing the flow of new media, and the origin of our growth team. Bourbon Paperclip thoughtbot Playbook How To Scale a Development Team- Adam Wiggins Semantic Linefeeds- Brandon Rhodes Coelevate Hound North Star Metric Words to Avoid Dan on Twitter
On this weeks Giant Robots Ben welcomes Adam Wiggins, Heroku co-founder and former CTO, to join as more of a guest host than guest. They discuss team size/structure, project scalability, the benefits of working abroad & self-maintenance best practices. Adam Wiggins Heroku "2 Dudes Talking" podcast genre discussion How to Scale a Development Team Good Software Takes Ten Years. Get Used To It. The E-Myth Revisited Down and Out in the Magic Kingdom
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: On the academic side, you’re very limited by your work has to fit in the box of like a peer reviewed quantifiable research paper and in the commercial world, it needs to be commercializable in the next, you know, probably a year or two, maybe, maybe 3, but all the good ideas don’t fit in one of those two boxes. 00:00:27 - Speaker 2: Hello and welcome to Meta Muse. We use the software for your iPad that helps you with ideation and problem solving. But this podcast isn’t about Muse the product, it’s about Muse the company, the small team behind it. I’m Adam Wiggins. I’m here today with my colleague, Mark McGranaghan. Mark, you reading anything good lately? 00:00:43 - Speaker 1: Yeah, just last night, I actually reread an ultra classic, you and your Research by Hamming, who’s a famous scientist, and it’s about how you build a really impactful research program over the course of your career, and I was inspired to reread it because it’s one of the chapters in the classic book, The Art and Science of Doing Engineering, which is about to be republished by Stripe Press. 00:01:05 - Speaker 2: Stripe Press is really on a tear these days. 00:01:09 - Speaker 1: Yeah, for sure, highly recommended. 00:01:10 - Speaker 2: And also perhaps relevant to our topic today, and I’m happy to say that our topic today was requested by a listener. So Fetta Sanchez wrote in to ask us, how do you get into the HCI slash interaction slash new gestures research field. So probably we need to start at the top there. Maybe you want to tell us what HCI is. 00:01:32 - Speaker 1: Sure, so HCI stands for human-computer interaction, and this is things like the way humans interface with computers, and also the way they use computers as a tool in their lives, how they get things done, how they learn. To use them, how they accomplish their goals, things like that. 00:01:48 - Speaker 2: And I did a couple of years of a computer science undergraduate degree that I did not finish. And during that time, I really remember everything in the curriculum was algorithms, databases, compilers, maybe some network type of things. And I only learned about HCI as a field a couple of years ago. And to me it was a bit of a revelation because this concept of How the user interacts with the computer and that being a whole field of study. Well, I was very excited about, but stood for me in very stark contrast to the System the algorithms oriented computer science that I sort of knew from my brief time in academia. 00:02:29 - Speaker 1: Yeah, likewise, it was pretty new to me, and it’s a whole huge world, you know, there’s conferences and papers and many professors who’ve dedicated their entire careers to it. 00:02:37 - Speaker 2: It was fun for me to dive in and learn about that world a little bit, and you and I were both part of this independent research lab called Inot Switch. Uh, and through that process, we began publishing and then made some connections with folks in this field, and then you and I went to a conference called Kai last year that I think really kind of opened the door for us there. Maybe one thing that would be worth doing is um categorizing here a little bit. There’s Human-computer interaction as a branch of computer science in the academic tradition, that is say mostly done in universities, sort of the the pure sciences. Then there’s corporate R&D which is more associated with for profit businesses, but actually it’s where a lot of the HCI innovations that are maybe the most famous, uh, we think of places like Bell Labs or Xerox PARC, maybe today, Microsoft Research. And then there’s a small but growing space of called them independent computer science labs, independent HCI researchers, of which I think we we had some contact with. How would you define the difference between those three categories? 00:03:39 - Speaker 1: Yeah, well, like you said, the academic side is grounded in these research universities, and this is often directed by a professor or graduate students, and there the values are really around evidence, rigor, review, publication and communication, and creating knowledge over time, which is a whole thing we should talk about. And then on the industrial side, it’s often more integrative because you need to consider. Not only the the pure HTI elements, but the business elements and the hardware constraints and the how easy the thing is to learn for the user and practice and things like that. And then on the indie side, this is a smaller domain, but that’s tends to be more experimental, free form. People can bring their own wild ideas to it and just try stuff. So it’s a nice injector of new ideas. 00:04:22 - Speaker 2: One way we can maybe make this concrete is to describe the path from let’s say the lab to commercial product. And I’ve I’ve struggled to find full stories on this in many cases, I think this is something that happens behind closed doors a little bit, even though science does have open publishing, the exact story of how something went from basic research or early um HCI research to a product that’s in the hands of end users is not well understood or well or written down anywhere. Um, I think the Xerox PARC case is one that has a lot of um, Fame and certainly in the tech circles that we run in, there’s there’s some books about it. There, they invented things like the modern GUI, uh, as well as what you see is what you get word processing, and was really a pretty special place. And notably there was a branch of Xerox, the copier company, and they were looking for innovations. I think their theme was the Office of the Future. And they were looking for innovations around that and, and clearly, you know, this is the 1970s, they knew that would have to do with computers, personal computing was, didn’t really exist yet or was, you know, still just an emerging idea. So that’s one famous example. Uh, maybe more recently, you have something like Microsoft Research, and I think, you know, I don’t 100% know what the path is for some, you know, for example, interesting innovations that emerged from Microsoft, to what degree were those laboratory projects versus some other path. Uh, one that I find quite interesting is what we now on the Apple platform, we talk about face ID on the Apple platform we use face ID rather. And that uses stereoscopic cameras and infrared, and infrared camera, which gives you depth sensing, right? So this is why you can’t fool your iPad into unlocking by holding up a picture of your face, because it can actually sense the the shape of it. And that idea was first in Windows Hello, which sort of was the Microsoft implementation of facial recognition. And that in turn, the technology there, I think came from the Microsoft Kinect, which is actually a gaming. Device, um, and I’ve tried to like dig into the history on this. I don’t know if it came out of a Microsoft lab. I think it may have come out of some other independent place. So you often have these very winding paths where a promising technology like stereoscopic cameras emerges, but you’re still trying to figure out the application of it. And it’s actually quite a long distance between when these early researchers are doing the work, and it’s in the hands of consumers as a usable product. 00:07:00 - Speaker 1: Yeah, and I think honestly, that’s the best case that you have this long winding path, but it does eventually find its way into commercialization. I think one of the ideas we had originally behind the lab was these two domains are kind of spinning in circles. So it’s a lot of good ideas from the academic world that are getting stuck or don’t have the appropriate context from the commercial world, so they’re not transferring over. And on the flip side, the commercial world isn’t tapping into the academic tradition and the way that it should be. So you have a lot of like the, the Microsoft research and the, the Googles and so on, they do a lot of internal research. 00:07:36 - Speaker 1: Google X maybe is their, their internal lab, or they have a bunch of computer science just doing research on, you know, search and stuff like that, uh, some of which gets thrown out as papers and some of which doesn’t, but the kind of the classic path from uh academic labs through commercialization I hypothesize is actually weaker than it, it should be or could be and perhaps was in the, in the past. And one of our ideas with the lab was to help bridge that gap with something that was kind of in between with the with the so-called industrial research lab. 00:08:01 - Speaker 2: Actually, Google search is another case. It’s not an HCI thing, it’s more of an algorithms thing, but the founders of Google, they were doing academic research work at Stanford, if I’m not mistaken, came up with this page rank algorithm, which was a science paper published like any other. At some point, I’m not super knowledgeable about the story, but at some point they decided to turn that into a working prototype. They set up this search engine, they found it worked way better than anything else out there, and they realized they could spin that out into a commercial. Entity. And so those two individuals took it from that early lab work all the way through to a commercially viable product, but it takes pretty extraordinary individuals and probably extraordinary circumstances or at least serendipitous circumstances for that to happen. And so what you’re alluding to there with the the gap between The academic researchers who are exploring wild new ways we can interact with computers and commercial companies that can bring these to people in their everyday lives. Um, that’s, you know, in the Google case, these, these extraordinary individuals took it across that threshold, but what can we do to create more movement there? 00:09:12 - Speaker 1: Yeah, exactly. I think We’ll see as we get more into HCI specifically here, that the HCI domain isn’t as obviously susceptible to the academic tactics as other domains, so things like algorithms are very quantifiable, they’re very repeatable, they’re very discreet, and those are things that work well in the the traditional academic model of of measurement and confidence intervals and so on, whereas HCI is often much more multi-dimensional, maybe case based, maybe hard to quantify. 00:09:39 - Speaker 2: Yeah, for sure, I think how it feels is like a huge dimension of making interfaces, but that is something that is very hard for science to evaluate. Uh, it’s something that is more of a taste or judgment call, but then science is and should be about rigor and the academic tradition and fitting into these and and sometimes I think that does mean from what I’ve seen of the HCI field. Sometimes I read these papers where, I don’t know, one example was, um, I think it was also a Microsoft research project. They did an interesting thing where they rigged up some projectors where you could essentially put windows from your computer, uh, individual windows, whether it’s like a document app or something else up on the wall and they had projectors, so basically all the walls. We were 100% turned into these screens, but it was collaborative. So I could put up one window, and it’s not like, while I’m, you know, screen sharing, no one else can, someone else could put up their window and you had this shared space that was very spatial and that sort of thing. This sort of stuff was, was, you know, part of what was inspiring us and we were thinking about the new opportunity. But notably there. It’s a really interesting prototype, you can look at their video and look at what they’ve done and read the paper and think about how this might be applied in the real world, but they have to, it’s not enough to just build the thing and say, hey, we liked it or we didn’t like it, then you need to go and do some kind of quantifiable test. And they did a usability test or user test, which is as near as I could tell was just grabbing 7 random people that happened to be walking by in the office and having them use it for 2 minutes and then, you know, giving them a little survey and writing it down. And it seems like, OK, well, I guess that makes it science because you’re measuring a thing. But that’s not where we make great breakthrough new interfaces, but it’s very difficult because you just leave it to, well, did you like the thing you built? People always are attached to the things they built. They always like the thing they built. How do we, how do we measure that? That’s probably an unsolved problem a little bit for the academic side. 00:11:34 - Speaker 1: Yeah, I think so. Thinking about things that do work well in this space, reflecting on my own journey. I started not so much with the HCI as like proposing a certain windowing system or a specific gesture model. I started more on the fundamental side. So we think about human computer interaction, you need to understand the human body, like biomechanics and things like that. You need to understand the human mind, like cognition, and then you need to understand the computer science fundamentals, things like the graphics pipeline. So I found it very useful to go and study those fundamentals, both within. And outside the HCI literature, and there again, that area is much more susceptible to traditional scientific methods, so it’s very good information. um, and then you really understand that the fundamentals, the ground truth. 00:12:21 - Speaker 2: You know, the point about humans and computers are equal participants in this. And I think there is a tendency for computer people to focus on the computer. Maybe one thing that HCI tries to do, or at least um some of the HCI teams that I’ve had chance to interact with, including this team out of UCSD that we met at this conference we went to, they try to have maybe a cognitive science person or behavioral sciences person on the team, and they are concerned more with that, how does the human mind work, how does our attention work? How does our how do our bodies work, and then, but you also have to connect that. Together with what’s possible with the technology, both in the moment and of course, also in the future where we think technology might go. And I think, you know, for example, VR AR stuff is maybe in some ways a hot or buzzy space or maybe was, maybe that’s died down a little bit. But if you go read a lot of research about that, you see that for example, one of the biggest problems with that is just a simple case of, OK, if you got these controllers, you’re waving around in the air as the main way you interact with it, your arms just get tired. And it’s, it’s like they, they’ve measured this, right? They, they put people in situations where they’re using these kinds of controllers for long lasting tasks and they see that after an hour, you got to take a rest and they’re they’re, they’ve tried lots of different things to try to make that to be able to let you do a full work day the way you would at a standard desktop computer or whatever, and they haven’t found a solution. And so if you’re coming in, if you’re a commercial company that’s coming in and wants to do something with this space, you probably want to read that literature and keep those, uh, keep that challenge, that unsolved problem in mind. Yeah, one place to fill in more of the picture on the academic side, for me, the big eye opener was going to, uh, the biggest conference in the space, which is Kai last year, you and I kind of spontaneously both decided to go. This is when we were still within the lab, but thinking about the use. Idea and that was a really great experience because we both got to meet a lot of the professors and researchers that were working in this space, got to see how many people were there. I, I don’t know, it was 2000, 3000 people, there’s hundreds of papers submitted, many, many tracks of talks, and then we saw all of these people who are working really hard at thinking big and thinking future facing about what, what computers can do for us and how we can interact with them. Some examples of just for fun, I pulled up my old notes, uh, had a very early version of Muse. Uh, back then, a prototype that I was working with, and I was able to dig that out of my, my archives, or dig the the Muse board exports out of my archives. Um, we had, for example, there was a talk on peripheral notifications, and this is where they’re basically testing, OK, so if you have a slack notification or an email notification or something pop up, and it’s on screen somewhere. What can we do to put it in your peripheral vision so that it won’t break your state of flow, or a better way to put it is just trying to understand what what kinds of sizes and colors and motions and shapes for a particular notification in a particular place in your field of view, how likely that is to get your attention. And then as a person who’s implementing something that wants to give a notification, you can go read this literature and they have this very extensive data set. And if you say, hey, I want something that’s absolutely certain to grab your attention, you should do it like this. If I want something that’s more a little bit of a note to the side, but I don’t want to distract you if you’re in the middle of something, maybe you should use this shape and this color and be in this space in your in your field of view. And there’s things there about keyboards and different ways to improve typing on mobile, there was lots of things about wall mounted displays. Uh, there was, um, Ken Hinckley’s group, uh, which has been a source of inspiration for us at use. They do a lot of stuff with tablets, particularly around the surface platform. They had one that was, I don’t know, they attached a bunch of extra sensors, they basically strapped a bunch of extra sensors onto a standard consumer tablet and they use that to detect, I think what they called like postures, so they could tell better the grip, like how you were holding the tablet at the time and then they can make the software behave differently. And clearly this is not something you can use in production. They, this is the equivalent of a raspberry pi taped onto the back and a bunch of sensors, you know, kind of hot glued on around the edges. This would never work in commercial environment, but it suggested some things you could do if such a capability. Existed and I think that that is a good example of what um what I think this field of this best does is it it it gives you possibilities to draw from and then it’s the applied people, what we would normally call just people building products that can potentially go and draw from that pool of ideas and that pool of things, finding things that have been learned and use them to make potentially new products that solve uh new problems or old problems in new ways. 00:17:07 - Speaker 1: Yeah, this experimental slash prototype approach is probably the thing that we um most think of when we think of HCI. Another type of work that I found very helpful is the ethnography, where you go and you understand how people actually work day to day and what’s worked for them and what hasn’t. Couple of examples there. One is a book called, I think it’s a small matter of programming or the simple matter of programming. This is a study of uh end user programming in the wild, things like Excel spreadsheets, CADS, and what actually works there, and because they talk to these people who are actually doing work every day and and having success or not in these environments, they’re able to pretty deeply understand what is useful in the way, in a way that you probably couldn’t get with either theorizing or experiments. 00:17:50 - Speaker 2: And I’ll just interject to say that one was a big inspiration for uh Hiroku. And it’s also a good indicator of how much the academic world is ahead of in a, in a strange way. We think of maybe in the startup world or the tech world or whatever, oh, we’re so on the cutting edge of things, but a small amount of programming was written in 1993, if I’m not mistaken. And this was 2006 or 2007 when I was reading this and and applying some of what it, um, some of the ideas that were in it went into Hiroku. And so at that point, the book was already 15 years old, but a lot of the research and understanding in it and ideas that suggested were still really bold, innovative, or just thought provoking, in a way that current technology and software products and certainly programming tools um had not taken advantage of or um learned from. 00:18:45 - Speaker 1: Yeah, a lot of the ideas that one tends to think of in HCI perhaps as as a supposedly novel interaction or approach has actually been tried before. I think it’s very important to understand that prior art, especially if it basically didn’t make it into the commercial world and like, why is that? Or else you’re liable to make the same mistakes again. Um, another example that I’m thinking of was the study. Of so-called folk practices with computer programs. This is like little habits or techniques that people have picked up to make themselves more productive with programs, and they found two examples. One is lightweight version control by making copies. So if you’re in, if you’re editing a photo and you want to, you know, have some quick version control. Uh, you might, uh, duplicate the item in your canvas, like in Figma, you know, make another copy of it, and then fiddle with the new version, and then you can kind of compare it to the old version, even if you don’t have like a, you know, get for Figma or whatever. Um, another one was this idea of everyone likes to have a little scratch space where you can like put, you know, your little clippings and bits and things you’re working on, and that was one of the inspirations for. the shelf in the original Muse prototype. 00:19:47 - Speaker 2: Another book we both read around that time was The Science of managing our digital stuff, and they had a lot of insights, again, things that I think we borrowed from a little bit from Muse, but because they come into it from this ethnographic or academic perspective, they just want to learn, they want to collect the data, they want to understand users. They’re not coming in with the point of view of like, we have a product we want to sell you or or just a uh A product we believe in and we’ve already bought into the mindset of, they just want to learn. And so one insight there was people who have been designing file systems, that is the way we store documents on our computers for decades have talked about the hierarchical file system, that is to say, folders that nest inside each other, uh, is no one thinks that way and hard drives get messy and no one wants that, maybe we want a tagging system, I think BOS had a version of that, um, maybe we want fast search or whatever. And these folks just did a bunch of studies of people including how they use Dropbox or Google Drive or their own hard drives or just the way they manage their files, and pretty reliably, people like putting files in folders. And they like pretty shallow hierarchies and they can remember where it is and it’s best for them if it’s only in one place. And you can sit there and talk about how that’s not the best solution or whatever, but they, they did a pretty broad survey and just saw this is what people want to do despite the existence of other ways of doing it and the other kinds of solutions, including search and tagging and so forth. At some point you have to acknowledge the reality of this is how humans behave, and even if we don’t like that behavior, we need to think about that when we build tools for them. 00:21:27 - Speaker 1: Yes, if you’re contemplating doing a search-based or tag-based information management system, please read this book. It’s, it’s super critical. 00:21:35 - Speaker 2: There’s an interesting tension there between, I think the academic world. is not only good at, but is science is essentially built on prior art and you’re building on what came before, right? Any paper that doesn’t start with a survey of other research that this is built on or related to or other people have tried similar things, and you’re you’re extending the tip of human knowledge, hopefully, by building on everything we already know. Um, and so for that reason, the academic world is very good at the the prior art thing. And maybe the startup world is all about, hey, I’m a 24 year old that doesn’t know anything and I’m totally naive, but I have this wild idea for a thing I want to build, and 99% of that at the time, that turns out to be an idea that a bunch of other people tried, it doesn’t work and fail for all the same reasons as everyone else does, but 1% of the time it turns out that some assumptions about the world have changed, and it is that naivety, it is that. Not looking at why people failed before that it allows you maybe to find an opportunity. So there is, there is a bit of attention there, but sometimes the um I’m very appreciative of the what people have thought about this, they studied it in depth, there’s a lot of prior art here, like look that up before you start building things, um, and I think that that would be advice I would give to my younger self, I think at a minimum. Alright, so that gives us a little bit of the landscape of of HCI. Now the next part of the question was, how do you actually get into this field? I think that’s kind of a tough one, so I’m gonna actually say that for the end. Uh, but in the meantime, there was a follow on question here and Fetta says, how do you forget or ignore current patterns and come up with new ones? You have some thoughts on that, Mark? 00:23:14 - Speaker 1: Yeah, I come back to this first principles idea of really understanding the basis for all of this, the biomechanics, the cognitive science, the computer science, and then understanding the Um, assumptions or lemmas, uh, of the current design paradigms. So, you know, for example, Uh, one thing we see with with phones is most apps are designed for only one finger to be used at a time, and it would be a mistake to translate that design constraint or design decisions over to a tablet, we think, but a lot of apps just kind of blindly do that do that because they’re both iOS and they’re both touch apps. Um, another example even more relevant to use is the pencil. A lot of the gesture space of tablet apps can’t assume that the user has a pencil because Apple and the various app developers just aren’t willing to make that assumption. Uh, with, with muse, we realized that was, uh, assumption that people were making and one that you could take the other side of. So we’ve basically said you really need a pencil to use muse and therefore we’re gonna have some of the functionality behind that, you know, that, that, that physical gesture. 00:24:15 - Speaker 2: Yeah, the status quo is a powerful force for all of us, and we, we tend to act on not quite habit, but this stack of assumptions about the world and what the right way to do something is. And here’s where I like to think in terms of maybe a spectrum between on one far extreme is the research thinking, the out of the box, wild ideas, weird ideas, when you go to one of these HCI conferences, this is what you see a lot of just Sometimes frankly pretty wacky mad scientist kind of stuff. Now, um, but actually there’s only certain times where that is appropriate and in fact, doing research is a place where that is appropriate. Typically, if you’re making a product that you expect people to use in the real world, it’s actually a bad thing to have weird out of the box ideas, particularly about basic interactions. You want the status quo, you want the known path, they usually called the best practice. And I’ve certainly run into this on. Teams where I don’t know, you’re building a basic e-commerce site or something like that, and there’s someone there that wants to do something fun and exciting and so they’re like, and so they say, why not, let’s try this wild idea, you know, instead of checking out like this, you you do this crazy thing and 99% of the time that’s just a bad idea. Please do it the way that other people do it. And this is one of the things that I think tends to make software so high quality in the Apple ecosystems, both Mac and then even more so on iOS is you have this pretty stringent set of, you know, they call it guidelines, but in many cases are just outright rules to get your app approved. They have this very extensive culture and set of principles and so forth in the human interface guidelines and in all the precedent with Apple apps and the wider ecosystem there. It’s all really good and it all hangs together and it works well and people know how to use it. And so most of the time you actually should do the boring, expected common known path thing. And it required, but it’s a shift in mindset, a fun one, but, but also takes some stretching of the brain, you challenge yourself a little bit to go into the research thinking mindset as both of us did, we went to to Ink & Switch. 00:26:29 - Speaker 1: Yeah, I think that’s an important point and a balance to strike. Another big source of inspiration for me has been the world of analog tools. We’ve been thinking about how to build good digital tools for maybe 50 years or so. We have a couple of 1000 years of explicit and implicit study of how to create analog work environments, so things like personal libraries, uh, studies, uh, workshops, artist studios, in some cases, there’s explicit treatises about how you organize one’s library, but there’s also just a huge amount of implicit and embedded knowledge in the patterns that we use every day and that people have kind of habitually used to organize, you know, say the library. So I like to look at the, the physical world and see, how can we just like, as a baseline, make it as good as that. So a simple example would be, if you use ink on a pen, it has zero latency. If you use ink on a really good tablet app, it might have 15 to 20 milliseconds, which is a lot. And if you use it on a bad tablet app, it might have 50 milliseconds. Um, so that’s a really basic example of how there’s a, there’s a simple bar to set. Uh, another one that I think about a lot is multitasking. So if you have a desk, and you have your main piece of work in front of you, and you have some notes to the side or uh up on the top of the table. It’s super fast and easy to multitask your attention, just like you kind of move your eyes or you move your neck and your eyes re refocus, maybe you lean into one side or the other, um, but it’s it’s super fast and lightweight. What you think about a typical iOS app, it’s like, you know, press next page, transition animation, spinner, loads, fonts come in, right? And so it’s it’s very discouraging to actually do this kind of multitasking work. 00:28:06 - Speaker 2: And maybe the flip side of that of taking physical world information practices, things from artist studios and offices, file folders. Scissors, rulers, pencils, desks, you do tend to get, especially the first time an analog process comes on to is digitized. So you think it’s something like desktop publishing going on to computers in the 1980s or yeah, word processors was taking what was a typewriter or a typesetter and moving that onto the screen, spreadsheets that were that way, um maybe PowerPoint, uh taking overhead transparencies, bringing onto the computer in the late 80s, early 90s. In all of these cases, they tend to be very literal. Like the first version of PowerPoint was a way to print out overhead print transparencies, and it wasn’t until much later that the idea of a slide deck that would be all digital and you would never need to print out and put on a projector, uh, showed up. And then often you when you look back at these first transliterations from the analog world to the screen, you see this thing where it’s, oh, isn’t this funny? You know, there’s the little, the little picture of the trash can and a little picture of the Um, you know, often very literal and kind of heavy handed and not taking advantage necessarily of what can be done in the new medium. Do you have a, I don’t know, a sense for the how we take the best parts and the things that work about the physical world, knowledge tools that we’ve been working with for so long and are so adapted to human needs, but not also get stuck in a weird rut of translating them directly so that we don’t get the benefits of the computer. 00:29:39 - Speaker 1: Yeah, I don’t think there’s a simple rule for that, but again, I come back to the fundamentals. A lot of the stuff is driven by the like the biomechanics or the cognitive structures of our mind, which isn’t going to change. So for example, we have a very realistic, deeply embedded expectation that when we like touch something and move our hands that it moves, and that I think is basically not going away, and it would be a mistake to think it’s going to go away. Uh, likewise, I think we have quite embedded cognitive arch. texts around both spatial memory and associative memory. I think those are basically baked in and they’re not going to go anywhere. 00:30:10 - Speaker 2: I guess that comes to mind because I feel like that tension or it’s not even the right word for the interleaving of try to draw the best parts of the physical world workspaces, but also really embrace this digital space and it’s part of the pitch, I guess, or the the value hypothesis for use as a product is that. We are going to take taking something you previously did with Post-it notes and your whiteboard and your notebook and some printouts of some screenshots that you scribble on that are on your desk, and moving them into this expensive and fragile computing device. That it will have new capabilities and new powers that you couldn’t get. And so getting bringing those best parts across, which is, for example, that yeah, you touch something and it moves right away and there’s this instantaneousness to it, and then you’re not like looking at spinners and loading screens and whatever, um, but also taking advantage of all the Um, incredible capabilities and the great depth of possibility that exists within once you move to the digital virtual workspace. 00:31:18 - Speaker 1: Yeah, one idea for an exercise here and this kind of gets into our next question would be just to try to understand and catalog the properties of these physical workspaces that are interesting. So for example, I have a desk here that I think is 6 ft by 3 ft. 00:31:32 - Speaker 2: For our non-American listeners, that’s probably about 2 m by 1.5. 00:31:38 - Speaker 1: Yes, thanks, Adam. So you have this desk and imagine it’s covered with like textbooks and notes and photo printouts at, you know, say 200 DPI. What’s the resolution of that? And if you do that exercise, you’ll see that it’s like massively bigger than even our most advanced displays, it’s not even close, and just being kind of aware of those basic fundamental properties of the physical world and how they might or might not be reflected in your app, I think is a good baseline. 00:32:02 - Speaker 2: So we mentioned academic HCI work, which tends to happen in universities and funded by grant money and the output is published papers, and then there’s corporate R&D which is divisions, separated divisions, but still departments within some large company that has a lot of cash, like a bell, or a Xerox or a Google to throw at potential new innovations, but there’s a third category that Or at least I hope it’s a category now, uh, that it’s much more rare, but I can switch falls into this, and that would be the independent research lab. And the hypothesis behind I and Switch was what if we take the corporate R&D lab, but we cut off the corporation. And this quickly leads you into how does this stuff get funded and our um. Our mutual friend, Ben Reinhard has a whole series of excellent articles about how innovation happens and particularly the different kinds of funding models that can happen and how it gets funded in turn leads into the incentives of the people doing it and there’s quite a, quite a rabbit hole there for those who are interested in it. But the concept behind it and switch was that we could get some grant money to do independent research. With the idea that it would generate called intellectual property. I don’t love that term, but basically, ideas that could potentially be commercialized and ideas with enough depth to them and research, and where we falsified ideas that were no go, and we had some really compelling ones. One of those turned out to be Muse, which we we went ahead and spun out to begin the commercialization project process. But there There are a few others that I know of that are independent labs. One is um Dynamicland, which is sort of Brett Victor’s effort to bring computing and programming in particular into a more spatial, a physical spatial environment, not just on a screen. And then another one that I know of is um maybe more in its nascent stages, but Andy Maze has done amazing work on mnemonic devices. And he’s, I think funding and stuff maybe started with Patreon and maybe led up to institutional funding kind of more of a kind of a, what’s the word for it, a nonprofit, more of a philanthropy type approach. But I think there’s no great answer for how independent research can get done, but I at least I hope that I could switch is an interesting example, if not role model for others that might want to see how they can push the frontiers forward in a particular space. 00:34:24 - Speaker 1: Yeah, that’s both the challenge and the promise of this third type of institution on the academic side, you’re very limited by your work has to fit in the box of like a peer reviewed quantifiable research paper and in the commercial world, it needs to be commercializable in the next, you know, probably a year or 2, maybe, maybe 3, but all the good ideas don’t fit in one of those two boxes. As hard as it is to collect them with this third organizational type, I think it’s worth trying. 00:34:47 - Speaker 2: It’s a great point. I think the time horizon is one of the key. Variables, let’s say that defines what I would call research for for anything, but certainly for human computer interaction, which is, um, I believe Xerox Park actually had an explicit time horizon of 10 years. Which is definitely way beyond what a commercial entity would normally do. Um, and I think, you know, basic science even has a longer time horizon than that sometimes. But yeah, when you look at maybe university labs, they’re thinking forward really, really far, um, maybe corporate R&D labs are thinking further than their commercial counterparts. And then if you talk about a startup, particularly something. combinator, you’ve got to build that MVP, get it to market, validate it, get customers. You can’t be building it on some shaky technology that one, you don’t know if it’ll work, and two might take many years of development yet to come to come to enough maturity that you can base something that people really want to build a product that people will depend on. 00:35:44 - Speaker 1: Yeah, and I also think you get a bit more wildcard energy in these independent orgs, you know, the, the academic institutions and the, the big commercial labs are just necessarily more constrained and structured, and you can have just more eccentric people doing stuff on the independent side, which sometimes leads you down weird dead ends, but sometimes you get really interesting results and it kind of injects a new idea into the mix. I’m actually we talked mostly about like independent research labs or research efforts. I also consider like indie creators, artists, tinkerers in this bucket too. One example that comes to mind is that the video game Braid, which is this amazing like time traveling based game where the time traveling is like very smooth and scrubbed frame by frame. Um, that’s actually been something of an inspiration for me thinking about like version control and time travel for productivity tools. 00:36:33 - Speaker 2: Yeah, I think that’s Jonathan Blow, and he also went on to make. Other like category breaking games, uh, trying to remember the name of it, there was a puzzle game that was actually really nice on the the iPad that I played with my girlfriend at the time. And then if I’m not mistaken now, he’s working on inventing a new programming language. So yeah, so that the, uh, maybe it just takes a certain mindset, a desire to perhaps even a um a drive to think outside the box and do weird stuff. And yeah, I certainly agree that Labs depend on weird, wild, I think I saw the word maverick used quite a bit when describing um there’s this book called Dealers of Lightning, which I think covers, covers Xerox Park and and kind of those glory days pretty well, and it talks about, yeah, there are these, I don’t know, kind of long hair types and, you know, don’t wear shoes in the office and of course those aren’t the qualities that make them good researchers, but it’s connected to this. Maybe desire to do a weird thing to not conform to try stuff at the fringes, to be actually fascinated by things that are at the fringes, as opposed to, this is weird, who cares? I want to work on something more mainstream, let’s say, um, and not to say that that’s a better or worse approach to bring to your work, uh, just that it, it fits in a different space in the innovation cycle. Well, maybe that brings us around to the core of the original question, how do you get into this field? 00:38:04 - Speaker 1: Yeah, and I, I feel like there might be two different questions embedded there. One is maybe how do you participate or contribute or even just kind of find, find out what’s going on, uh, and the other is how do you make a living doing it. And, uh, I, I think making a living doing it is, is harder, but it’s maybe simpler to answer. There, there are two main paths right now. There’s the academic path and there’s the corporate path. Um, the academic path you you basically you go to graduate school and you get a PhD. Uh, but even after that, it’s, it’s quite challenging just because it’s so competitive in the corporate path, you become a practitioner and you, you do good, you know, engineering or product work and eventually you can enter this more researching ladder. But I’m not sure we have that much to contribute on that front because neither you or I have gone down those paths, maybe more of the how do you engage with the community where we should focus here. 00:38:43 - Speaker 2: Yeah, absolutely. Well then, you teed up really nicely. How should we engage with the community? 00:38:49 - Speaker 1: Well, step here I would say is start digging into the literature, you know, it sounds obvious, but I think a lot of people haven’t done this either they don’t realize it’s there or they’re intimidated by it. Um, but this reminds me of Rich Hickey’s classic talk, hammock driven development. He’s like, if you’re working on something like you. I think you need a hash function that does X going to Google Scholar type hash function that does X enter and see what comes up. Like there’s almost certainly going to be something there. 00:39:12 - Speaker 2: Well, maybe there’s a great chance to talk about something again. I coming purely from the what what academics would call the industrial side, uh, yeah, working in companies that build products that they sell to people. That’s what I did my whole career. And so things like the fact that all this academic work tends to be published as PDFs in a particular format, there’s a lot tech to formatted to column PDFs, they have a particular style of writing, they have this particular style of citations, you typically, they’re not always open access, but when they are, they’re PDF on a web page, and the search engine for them is something like Google Scholar. I I actually didn’t know that. I didn’t know how to go find those things. And so as a Let’s say as a product developer, designer or engineer, I knew how to Google for stuff. I know how to find stack overflow. I read medium pieces, I read people’s blogs, I follow other folks in my field on Twitter, but the academic world of things was sort of a dark, yeah, was dark to me, except for on occasion, I would stumble across a book like the one you mentioned earlier, a small matter of programming. And I feel like I discovered this incredible trove of knowledge from someone that came at the the problem space from a very different perspective. And I think it also goes the other way, not as much, but I think academics are less likely to read the medium think piece posted by the product designer, the engineer, and basically the two, I think the two communities, if that’s the right way to put it. Uh, have different communications conventions and different ways that they share knowledge with each other and different systems for evaluating. Uh, importance and so on. So it’s very hard to, um, if you’re, if you’re steeped in one, it’s hard to cross the world into the other. So maybe that comes to all right, you find some hooks into this, you can follow some people, whether it’s on Twitter, whether it’s through their personal blogs, you can start to find some papers and Google Scholar on the topic, you can find some slack communities maybe that talk about this stuff and you can try to get hooked into it and and. Again, if you’re someone that comes from more the practitioner side, we might say, engineering products, design, uh and you haven’t been exposed to the academic side, going and and exposing yourself to that is a very good idea and maybe vice versa. 00:41:30 - Speaker 1: Yeah, and one other thing I would emphasize there is that you can do this citation crawling practice where you find a paper that you’re interested in, you can go look at the, the references, and this will refer to a bunch of other papers and sometimes books and in HCI it’s mostly papers, there are a few books, and then you can type those titles into Google Scholar and follow them that way. And a good way to kind of know if you’re getting your hand around the literature is if. When you read a new paper and like you basically recognize most of the citations or they’re kind of off the edge of your um your map in terms of your area of interest. So you’ve kind of identified the full graph of relevant papers and then you’re, you have a good handle on the literature. 00:42:05 - Speaker 2: And I think this is something that’s very much you learn this in the academic tradition, which is if you want to advance the state of the art in a field, first you need to know all the things that humans already know. And you do that by consuming all the literature, and you know when you’ve consumed all the literature exactly the way you described, kind of a crawling process, which is you start with a few seminal papers or you start with a few that are your starting point and you follow all the citations until you get to the edges of it and you feel like, OK, I’ve filled in this space now I know. in some kind of um general sense, what humanity knows about the subject. And now if I am, if I have novel ideas or I want to do new research or I see open questions that stand on top of this, now I can go do that in order to potentially contribute to this. 00:42:52 - Speaker 1: Yeah, and then speaking of taking that next step, it can be intimidating, certainly if you want to jump all the way to publishing in a peer reviewed journal, but I think you can take more incremental steps. One example that comes to mind is Dan Lew’s work on latency in computer systems. Uh, he did a series of measurements and experiments to assess uh the different latencies like from your keyboard. Your monitor for when you move your mouse to something happening, and uh but he was able to publish this on his personal website, and it’s not an academic peer reviewed paper, but it’s, that work has been quite influential, and you can indeed reach the kind of the caliber of academic work, even if you’re not participating in that full pipeline. 00:43:29 - Speaker 2: I’ll note that um work, and if I recall correctly, it’s published on kind of a really basic HTML page with very limited formatting and and whatever feels very um homegrown and authentic. But one of the things he does that’s so compelling is he says, he starts with this hunch, which is computer seems slower than I remember when I was younger, but then he goes to, you know, maybe the way if you don’t come at it from that scientific rigor position, you might go, you know, computers seems slower. I’m gonna like make some snap judgments. And then I’m going to go write a blog post and complain about it. But what he did was say, well, are they actually slower? And he got a, I don’t know, some kind of high speed camera set up and set that up and pointed it at the keyboard and the screen, and he recorded himself pushing a key, and then you can see on the camera when it appears on the screen, and then he, he wrote down exactly to the millisecond and he did that with a whole bunch of different devices, including some computers dating back to the 80s and then he put them all on the table and sorted them in order. And that’s a simple. Application of the scientific method to in this case, a very literal human computer interaction. How long does it take when I press a key when it appears on the screen? And that doesn’t say how long it should take or what would feel right, but you can put now real numbers to this intuition that maybe computers are more sluggish than they were at a different time. 00:44:55 - Speaker 1: Yep, exactly. And then if you are looking to take that step towards uh participating in these peer reviewed journals, a possibility that we’ve had some success with is collaborating with an established academic in the space. Um, Adam, you’ve kind of spearheaded our collaboration with Martin, maybe you want to describe that. 00:45:12 - Speaker 2: Right, well, we were lucky enough to get to work with Martin Klepman, who’s a one of the world’s experts on, say data and data synchronization, particularly around another track of research we had in the the lab around um what we eventually called local first. And he is someone who was in the indust, let’s say the industry world, he was doing startups and at some point felt that he can contribute more to the industry or the world by jumping over to the academic world to do more basic research around algorithms having to do with um synch data synchronization. And so we were lucky enough to get the chance to work with him within the context of the you can switch lab on a kind of a light part-time basis. And that led pretty naturally to, OK, well, we want to write a piece and publish it. And he wanted to publish some of his findings and he said, hey, you know, I think this could go into the academic format. And I said, well, Well, how does that work? He’s like, well, basically we take this web page we wrote, we put it into a lot of tech, we change some of the wording to remove, make it less emotional, uh, we changed the links into the citations where that makes sense, and we, we had a whole process to make it into something fits this format that’s expected by the academic world, and then we submitted it to a conference, uh, where it was accepted and eventually I actually ended up going to present it for. Um, various travel logistics reasons. Um, but yeah, that was a very interesting experience because the four authors on the page, uh, the paper, I think you and Peter maybe both have a good bit of academic experience, although I don’t know if you’ve published that way before. Martin is extremely good at that stuff, and then I knew very little about that world, but working with someone that knows all the ins and outs of it was a very um rewarding way to to learn about it. 00:46:58 - Speaker 1: Yeah, exactly. And to be clear, we didn’t just jump right to that, you know, a collaboration with one of the world’s leaders in synchronization technologies. There’s a little bit of a. 00:47:09 - Speaker 2: Yeah, don’t email Martin and ask him whether he’ll write a paper with you, he doesn’t know who you are. That’s not what I’m advocating for. 00:47:15 - Speaker 1: There’s there’s a bit of a proof of work function here where if you do some of your independent research in the space, and especially if you publish something that’s coherent and compelling, it becomes much more. You know, reasonable to establish a collaboration. Actually, when we did some of our publications around Muse and our latency measurement work, we had a few academics reach out to us and you know, say that’s interesting, maybe we should, you know, do some work together. I don’t think we’ve brought any of those yet to the point of writing a paper together, but it just shows that once you have some, some work out in the world that shows that you’re serious, that you’re engaging somewhat in the academic tradition that you’re aware of the literature, that you have contributions, um, it becomes a more feasible to have those collaborations. 00:47:54 - Speaker 2: Yeah, perhaps like any other intellectual or maker or tradition, this is a world or a community or a society that thrives on seeing what else you’ve done, and if you see that someone has done great work that overlaps with work you’re interested in, and that creates opportunity to connect, to learn from each other and then maybe lead to, can lead to collaborations. And yeah, maybe it’s not such a huge leap from do a weekend hack project and write up your learnings about it to eventually doing something a little more deeper and a little more serious that brings you in the direction of um the academic recognized academic world. Well, it’s interesting to note then that In doing the research lab, we came to it not from the perspective of how do we become a part of HCI, but rather we just wanted to see computers and computing interfaces get better uh in in some particular ways that led us to doing maybe some interesting experiments that led to some novel research that we we published about, and that in many ways opened the door to us to be more connected to this larger academic field. Is that something that a path you would recommend for others? 00:49:05 - Speaker 1: Yeah, there are certainly interesting paths there, you know, there’s this independent research lab path, and of course, there’s the academic and commercial path, and I think those are all interesting. I would also say though that being a scientist or being an innovator isn’t a hat that you’re granted by some external institution. It’s a way of thinking, it’s a way of navigating the world. You know, a scientific method is something anyone can use. Publishing is something anyone can do. Everyone can read the literature. So if you’re interested in this, I don’t feel like you’re, you’re stuck because you don’t have some credential like a PhD. Anyone can step into this world, go on to Google Scholar and read literature, and then maybe you have something to contribute on top of that. 00:49:40 - Speaker 2: It’s hard to think of a better place to leave it there. If any of our listeners out there have feedback, feel free to reach out to us at @museapphq on Twitter or hello at museApp.com by email. We’d love to hear your comments and ideas for future episodes, and big thank you to Fetta for giving us this very uh intriguing and deep topic to explore. I’ll catch you next time, Mark. 00:50:04 - Speaker 1: Great, thanks, Adam.
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: It was important for us that people be able to reach this level of partnership, which again is a group of peers, even if they weren’t there at the founding of the company. 00:00:21 - Speaker 2: Hello and welcome to Meta Muse. Use a software for your iPad that helps you with ideation and problem solving. This podcast isn’t about Muse the product, it’s about Muse the company and the small team behind it. I’m Adam Wiggins. I’m here with my colleague Mark McGranahan, and Mark, I know that, uh, we have to get creative with our hobbies here in this time of staying home. Uh, what have you been doing in regards to your piano lessons? 00:00:46 - Speaker 1: Yeah, well, I usually take lessons at my teacher’s house here in Seattle, but now we’re going all remote. And we actually did this once, uh, last year during some snowstorms here, which shut Seattle down, and then I just like propped my iPhone up on my desk and we did our best, uh, but now that I have a little bit more experience with this podcast and with other AV stuff, trying to do a better setup, so. Um, used a, a real mic to record and we set up multiple camera angles with my laptop video and my iPhone camera, and that’s worked pretty well. And then I think the next experiment will be actually plugging the digital output for my, for my digital piano kind of directly into an audio interface. As well as getting a vocal mic and hopefully that will improve the kind of the piano sound quality that she hears on the other side. 00:01:35 - Speaker 2: Well, excuse to play with. 00:01:37 - Speaker 1: Yeah, I would be lying if I said that wasn’t a big factor. 00:01:40 - Speaker 2: We’ve got our summit next week as well, which we’re doing all virtual we meet in person for that, so we’re also going to Try to get a little creative. I guess the whole world is is doing that to some degree. 00:01:50 - Speaker 1: Yeah, I mean, on the flip side of this, as a company, we have a lot of experience with remote, so this hasn’t been too big of a change for us. I’m talking to, uh, for example, people who are elementary school teachers and I just, I can’t even imagine. 00:02:01 - Speaker 2: So the topic we wanted to talk about today was hiring an engineering partner and maybe the Muse partnership model more generally. So I’ll link in the show notes to the job description we’ve got on the web. Beautiful design there done by our colleague Leonard. But, um, I think you wrote most of this, Mark, and, and I wanted to quote from the, the opener a little bit and, and maybe you can expand on this or explain it, uh, further. So the the page says this role is on our partner track, meaning that it has a high level of freedom and responsibility while earning a significant stake in the business. So, can you, uh, can you tell us what does it mean to be an engineering partner as opposed to, say, a soft software engineer as a regular employee. 00:02:45 - Speaker 1: So, our partnership model is, we have a very small team, all of whom are intentionally peers, including the founders, and who are treated more like owners than employees. So, in practice, I would say a partner is In between a typical startup employee and the kind of sole founder of a bootstrapped in the startup, it’s kind of in between. 00:03:08 - Speaker 2: And by typical startup employee here we talk about in the early days when it’s a small team, people have a lot of impact, I guess, on the, on the company because there’s just not that many of them, and option grants are common, which is sort of an option to buy company stock in the future if it does become valuable, uh, but at the same time, they don’t really get a lot of visibility into, say, the financials of the business. 00:03:32 - Speaker 1: Yeah, the typical model is you have the founders who are there when the company is incorporated and they get the vast majority of the equity and they have very outsized responsibility and decision making ability and and freedom and flexibility, and then you hire employees and starting with employee 1 and definitely on from there, they’re kind of a second and lower tier of staff by design. And what we want with the partnership is more of a model where those Team members are all peers, uh, in terms of the day to day work, in terms of their freedom and responsibility, and also in terms of their equity ownership in the business. 00:04:08 - Speaker 2: And just to make it concrete here, we’ve got 4 partners right now. So there’s Yumi and Yulia, with sort of the 3, that got started last year. Leonard joined us not too long after. So we’re a partnership of 4 right now, and we have maybe some contractors and things we’ve worked with, but for the For the most part, it’s really those 4. We’re all owners in the business and therefore, essentially peers. Uh, now we’re looking to fill in this 5th person, uh, who will come from an engineering background, but we want them to have that same kind of stake in the business or level of ownership or level of responsibility. 00:04:42 - Speaker 1: Yeah, exactly, and it goes both ways like you have this higher level of ownership, you have more freedom, but because this is probably the last partner that will hire for some time. There’s a lot of responsibility. Like these 5 people, they need to make the business successful together. Um, so you really need to have a really high talent density to make that work. 00:05:01 - Speaker 2: So you’ve used this turn of phrase freedom and responsibility, and I don’t know if that’s a call back to the Netflix deck, sort of internal employee hiring and culture deck, but I read this, I’ll link to it in the show notes. I read this many, many years ago and it really had a big impact on me and how I think about teams and hiring and and management. 00:05:20 - Speaker 1: Oh yeah, very familiar, a classic. And interestingly, I think it’s been both very influential, yet it’s still quite contrarian. 00:05:28 - Speaker 2: Having a lot of latitude, having a lot of ability to make choices in your daily work, also comes with it, yeah, responsibility to do the best thing for the business, and you don’t have someone sitting there telling you what the right thing to do is. And maybe this comes to the conventional relationship you often happen have between employers and employees, which is one of the boss tells you what to do and the employee knows they’re successful in their job when the boss is happy, so it’s really largely about pleasing what whoever has the authority says they want. Uh, which produces some, some strange dynamics, uh, sometimes and some power. Obviously there’s a huge power asymmetry there as well. 00:06:10 - Speaker 1: Yeah, and that was a big motivation for me in designing our partnership model. I wanted individual success to be measured by the market as much as possible, so it’s not about pleasing your boss or getting some committee to give you a certain rating. Um, there’s one or two people who are working in each discipline, so it’s very clear if your work is having the right impact for the business. 00:06:30 - Speaker 2: And maybe we can talk about the terminology of calling it partners or partnership, and in particular, in contrast to the term that you often hear in Silicon Valley, which is founder. So what, what’s the difference there? Why do we use this term partner? 00:06:45 - Speaker 1: It was important for us that people be able to reach this level of partnership, which again is a group of peers, even if they weren’t there at the founding of the company. There’s certain things like you’ll always be able to call yourself, you know, a member of the founding team or a founding partner, but we think it’s important that people can come in, uh, demonstrate their skills, prove their value to the business and join this group of peers as a full partner. 00:07:11 - Speaker 2: Yeah, founder is a funny piece of terminology, right? It’s not a job title. It’s not like VP of engineering or something. Uh, it’s a statement of where you were at a particular time. And I’ve certainly used that title for myself quite a bit on, you know, CVs or whatever, just because, yeah, I do start companies, that’s sort of my, um, my career. And, and so when you’re doing a jack of all trades, just getting things off the ground, uh, type of a role, well, founder does seem like the right description for that. But it does rule out people coming in later and having a really big, or even a foundational, you might say, impact. Uh, and I think of some famous examples of this. For example, uh, Howard Schultz, I think it’s the fellow’s name from Starbucks. He wasn’t one of the founders of Starbucks, but he, in the sense of being this pivotal person that helped make it what it is today. He was, or that we just don’t have a word to talk about that, basically. 00:08:12 - Speaker 1: Yeah, and typically there’s a very narrow and rare path for people to say become a CEO externally, and that happens sometimes, of course, um, but the default path is you read the job description and it says like employee of X division, you know, doing this subset of that thing and even before you’ve talked to the first person at the company, it’s clear you’re going to have a very prescribed and small impact, whereas if you come in and say with the job description. You’re going to be a partner in this business, you’re going to own a big chunk of it, and we’re going to expect and hope that you step up to that with your contributions. Um, you’re setting a much higher ceiling for people to reach up to. 00:08:49 - Speaker 2: The one thing I was concerned about when we got this off the ground and 3 of us, the 3 initial partners had this idea to have this small talent dense team was that it would really restrict our, certainly our ability to grow quickly, although that wasn’t, uh, specifically a goal for us to grow the team quickly. But actually that we would rule out the ability to hire a potentially really great people, really great people in that particular craft who don’t have that other dimension of either their skill set or maybe just their interest. Being an owner of a business and feeling that responsibility for the whole thing being successful, versus kind of focusing on your craft and your specialty. It is not something everyone can or or wants to do. And so we rule out being able to hire some a really great software engineer who doesn’t want to be a business owner and be worrying about the fundamentals of the business. Um, and so I was, I saw that as a risk. I felt like when Leonard joined us, uh, that was a great validation of this model because he wanted that. He wanted to. You know, this is a very talented guy. He had the option to go lots of, uh, very prestigious big tech companies. And one of the reasons he told me that he, he wanted to work with us is that chance to have a high impact and be an owner in. Uh, in a business. And so he’s both really great at his craft, which is design, but he also has the mindset to care about, pay attention to, and contribute to all the other aspects of the business. 00:10:22 - Speaker 1: There’s only a subset of people who are interested in this model, and that’s fine because within that universe, they seem especially interested in what we’re doing and kind of more inclined to join our venture versus a typical startup where they’d be, you know, employee number 76 and earn 0.01% or whatever. Um, so I think it’s kind of concentrating and focusing our recruiting ability into uh the type of people who we most want to work with. 00:10:50 - Speaker 2: Now, this works for a 5 person team, maybe you could even imagine 67. I don’t necessarily imagine it would scale to, I don’t know, 1520, 25 people, um, but how do you, how do you think about that if we did at some later time feel like we did want to grow the, grow the team because the opportunity in front of us or the, the, um, money we’re earning from customers makes it possible to do that. 00:11:15 - Speaker 1: Yeah, I think maybe there’s separable axes there. So I think it would be harder to have partners as you go beyond 67 people, although there is precedent for that, of course, and professional services firms that have big partnerships, uh, but you, you might be able to separate kind of how many employees, how many staff total you have versus what percentage of them are are partners, even if there’s some coupling there. I would also say that we did. Design the partner model, kind of the current iteration of it, specifically for 4 to 7 people, because that’s the size of one team, or maybe 3 to 7. And when you go beyond 6, maybe 7 people, you don’t really have one team anymore. You have 2 teams that you like, you know, team divisions and like extra communication and coordination and decoupling and stuff like that. And it’s kind of a different way of operating. You can, you can’t do it totally as modically mind melting like we do now. So I think it would also change in that respect if we move beyond 7 people, but I’m hopeful that we can um get quite far with this small team again, because of the talent density and because of the leverage you can get these days with SAS. 00:12:20 - Speaker 2: And it’s interesting change for both of us maybe because we do come from that startup background where hiring and growing the team quickly is seen as an absolute requirement. And uh you were an engineering manager, ran a team at Stripe. How big was that or how many people were sort of under your um authority there? 00:12:41 - Speaker 1: Yeah, I managed teams from like 3 to about 50 at Stripe, so I saw a gamut and indeed a huge part of your time as an engineering manager at a company like Stripe, we are growing very quickly, is actually the mechanics of growing a team. So it’s like, you know, recruiting, interviewing, onboarding, training, team, cell division, off boarding. I probably spent like half my time doing that. And so part of the idea with a deliberately smaller partnership is you can spend more of your time focusing on the actual products in the business. Now there’s anything wrong with doing those other things. I quite enjoy them. Um, but if you, if you want to grow very fast, you have to invest a lot in it and it necessarily detracts from your work on the product. 00:13:24 - Speaker 2: Yeah, certainly for me, there was an appeal to being in more of a maker mode, be able to spend more of my time doing writing, product development, design, and so on. Uh, at Hiroku, I was my sort of my largest management experience and at one point had a, yeah, quite large, uh, team under me there and you can do a lot with a big team of expert people. It’s, it, it, it can be a really amazing thing and there are super, uh, opportunities very worth going after that that basically require that. Uh, but then on the other side of things, yeah, being able to make stuff and be really close to, I don’t know, I like a pretty close personal relationship with quite a lot of our, um, our early users and now customers, and that’s a lot harder to do if you also need to be, uh, making your team and all of the, the care and feeding of that, uh, your priority. 00:14:18 - Speaker 1: Yeah, and to circle back to something we mentioned earlier, I think you have that. That much more direct relationship with the customers and the product and and again the evaluation loop is much cleaner, with a large company, you have like, you know, various management chains that are quite deep, you have the different functional areas, you know, you have multiple phases of roadmap planning, the evaluation process is very complex, and so you end up spending a lot of your brain cycles like managing that social dynamic, uh, whereas here I think we have much more focus on our product and our customers. 00:14:51 - Speaker 2: The time that you need to put into getting everyone on the same page, even if it theoretically we all agree roughly where we’re going and what the pressing problems are, there’s these huge sophisticated systems that, um, larger companies use. Google’s, I think, known for the OKR system. Uh, when I was at Salesforce for a little while, I got exposed to this thing called V2O. Uh, and these terrible acronyms are very necessary systems that allow you to take a large group of people and get everyone on the same page about what you’re doing and focused around a particular business priority and have everyone understand how their work can fit into that. And by comparison, I think you mentioned this, uh, earlier. By comparison with a small team, we basically have a team summit once every 2 months. We spend a week going really deep on big picture questions and spending a lot of time with each other and having casual conversations, and that basically works great for getting everyone on the same page and aligned to use the manager speak there. Um, and that’s kind of all you need, plus uh like a weekly, uh, planning meeting and, and, you know, with a con on board, kind of, you, you’re all set. The, the meta elements there are much easier and much more, uh, much simpler. 00:16:09 - Speaker 1: Yeah, now I think the flip side of all of this, uh, freedom and responsibility and minimal management infrastructure is you really need the partners to take a lot of initiative and to have good judgment and to have good taste. And I think that’s reflected in the type of people who uh we tend to find applying for these partner roles. They tend to be people like perhaps former entrepreneurs, uh, serial independent contractors, um, people who have a lot of experience doing uh open source projects or running things like that. Um, people who have worked at very small startups, it’s people who kind of just tend to take initiative and take responsibility for their own career success that I think finds, um, the most traction with our model. 00:16:50 - Speaker 2: Good judgment and making good decisions, making wise decisions, I think it’s a huge part of this, and you want to be able to trust in everyone’s judgment. When you talk about the split a little bit between. Maybe founders, employees in the startup world or maybe more classic business. There’s, let’s let’s call it management and labor, uh, or boss and employee, that that sort of thing. Another really influential source of kind of business know-how for me was, uh, Peter Drucker’s book Management to this giant collection of business essays from I don’t know, the 1980s or something like that, which still are remarkably applicable to uh the modern world of tech companies. And in management, he talks about sort of the, what makes a manager, a manager is not. managing a team or the people side of it, it’s feeling responsibility for and having the suitable authority to make the business be successful, the whole business, whereas an individual contributor, a crafts person, what have you, their job is to make a particular thing. So if your job is to build a website for the company. You’re gonna build the website, make it as successful as possible by whatever uh criteria you’re given. But beyond that, you, you probably have a vague, certainly strong but vague interest in the overall health of the business and that you want to make something you’re proud of, and of course you want your job to continue to exist, and you want all your colleagues to continue to be employed there, but you don’t really have any levers for making the business be successful or not outside of your specific domain. 00:18:27 - Speaker 1: Yeah, and there are a lot of good reasons why um companies have this, this management and labor dynamic and it can work very well and indeed I had spent a lot of my career working in that model, but I, I wanted with Muse to not be spending so many brain cycles on like, you know, convincing people they should be doing stuff and like motivating them to do stuff that wasn’t necessarily stuff they were interested in and like judging their work constantly. I just want people to more like do the thing that was right for the business out of their own initiative, and I think we’ve been able to get that here. One other thing that this reminds me of is uh dealing with miscellaneous business stuff. So for example, expenses. This, this can become a huge mess in big corporations, kind of, uh, classically, you know, you have the programmer who can’t get a decent computer or they have to do like a multi-week uh procurement process to get a hotel, we have to use some terrible, you know, flight booking software. And here the model is much simpler. It’s you’re a partner in the business, you essentially own a piece of this bank account, and you need to make good decisions about how we use it, and we mostly trust you to do that. And so if, you know, you think you should buy, you know, I don’t know, a new mic for a podcast, you know, do that or if We’re deciding where to have the summit. It’s not like an us versus them dynamic on the expense. It’s, we can go somewhere more expensive and that’s less runway for for all of us in the business. 00:19:45 - Speaker 2: Yeah, and I think that element of looking at the money in the bank account and seeing, you know, what’s possible or what is wise to spend money on for equipment is one thing, but a, a very challenging topic in any model is individual compensation. That is how much money do you get paid. I remember talking to Yuli about this early in the The business, which is, you know, transitioning from the employee mindset, which is one of, OK, I’m going to negotiate with my employer. Not exactly in an adversarial way, but you could say you have different incentives, you have different interests. The employee wants to negotiate to get as much money as they can, and the employer wants to get the, uh, the employee to work for as cheaply as they can. And then they hopefully through that tension, negotiate to some fair middle ground. By contrast, when everyone’s a partner, you basically look at the Money in the bank account, you look at the spreadsheet of growth and customers, and you look at financing possibilities, and you go, OK, well, if we game this out, like what can we afford to pay ourselves? 00:20:50 - Speaker 1: Yeah, exactly. And related to that, I like that we have a relatively simple compensation model that also, I think mostly pays people for the responsibility that we’re asking them to take versus for their negotiation negotiating leverage. Um, so our model is essentially there’s some dollar amount that we want all the partners to be earning roughly and then depending on their situations, the cash versus equity balance might be a little bit different. 00:21:17 - Speaker 2: So when it comes to the stock compensation, Uh, you had a, a, a bunch of strong feelings about that, and in particular the way that maybe option grants for startup employees are a little bit of a raw deal. You got people get stuck with tax burdens and exercise windows and things like that. 00:21:33 - Speaker 1: Thought about a bunch of different things, but we ended up mostly on um options, mostly for legal and tax reasons, um, but we try to give way, way more than is standard for an employee again to reflect this, this kind of being in between an employee and a founder. Um, and also we have this no cliff and uh the exercise window is very long. So basically the idea is once you’ve Worked at the company for a quarter, you’ve contributed a lot of effort, you’ve earned this equity compensation and it’s yours to keep, uh, basically for as long as the US government will allow us to let you keep it. Um, and the, the terms are as simple and as favorable to the employee as the staff as possible. 00:22:13 - Speaker 2: And that that was something I was pretty passionate about as well, because having done a lot of businesses over the years and divvied up ownership in different ways and that sort of thing, you often see this thing where you have these typically 4 year grants, uh, for founders, it’s often even more dramatic where essentially in the beginning, you just divide the company three ways, uh, and then you get diluted over time. But the Sort of the ownership that you have reflects what you happen to negotiate for, what the circumstance of the company happened to be at the time when you came in the door. And what I really prefer is that there’s something that is based on both the contributions you’ve made to date, but also reflects the commitment that you have made in the, you know, in the near term in the next couple of years. I think 2 years is kind of a nice time window on that. And furthermore, that if your life circumstances change, or if you decide that you no longer have good contributions to make to this business, you’re not in the what they sometimes call the investing in peace um situation, which is you’re kind of sitting around keeping your chair warm because you have this great option grant or this great stock grant that you want to see out to the end, but you’re not really actually in a position. You have these weird cliffs and things, you’re motivated to, OK, I want to stick around till next February because that will make a big difference for me. Uh, but it’s something that is a little bit closer to, uh, your, your salary, which is, as long as you’re contributing, you’re earning, and then at some point, if your circumstances change and you want to be elsewhere. I guess I don’t like people being chained to a thing. It seems bad for both parties. It’s certainly bad for a person to not be moving on from a role that they’re no longer, no longer want to be in. But similarly, I think it’s bad for the company that becomes a person who’s not contributing with the same passion and the same vigor and maybe that is space in the cap table or space in the sort of the team seats, uh, that could be given to someone else that’s in a better position to contribute. 00:24:21 - Speaker 1: Yeah, and I think the typical 4 year stock grants plus 1 year cliff plus 30 day exercise windows can really contribute to that feeling of people feeling locked to the company or compelled to sit and wait it out and I think both of those are not healthy. And indeed we’ve tried to do other things to make it feel like People have their own independent free lives and they’re not like chaining themselves to this company for 4 to 6 years when they join. It’s more like you come in and you do this like rotation of this tour and after 2 years, you can choose to re up or you can choose to go in a different direction with your career and both of those are totally fine uh with the company and totally reasonable things to want to do with your own life. And you know, another example of this would be, um, we try not to have Which basically prefer cash compensation to benefits so that if you don’t have all these like weird tentacles into your personal life in the form of benefits like you’re earning this compensation and then if you want to um move in the future, you don’t have to like unwind all these benefit entanglements with the company that you just have more cash that you can use to spend on those things as you will. 00:25:28 - Speaker 2: You mentioned earlier the Agency partnership and this was uh was also something that I think you brought into our discussion when we were formulating this model that, um, I had never really thought about before. But there is the case of, yeah, maybe something like a designer brand agency, uh, maybe something like an attorney’s office, sometimes maybe medical practices are this way. Uh, maybe, probably my best exposure to it, although I don’t know how accurate it is, is, uh, the TV show Mad Men, where they have these basically ad agencies that that have this small set of people who are the partners, and then of course, there’s a larger group who are the, uh, let’s say the standard employees. What exposure did you have to the partnership model via Uh, this kind of, this kind of business and, and how did that play into the, the idea here? 00:26:16 - Speaker 1: Yeah, mostly via the professional services world, you know, accountants and lawyers and so on and Uh, we, we drew from that two of the key aspects for our current design. One is this idea that anyone can make partner over time. So, when you form like a law firm, the people who founded the company, they have their names on the sign, sure, but over time as other people make partners, they take on that sign and then make a new one with the new partner’s name on it, right? And I really like that dynamic. Again, I think it allows people to step in and and for the talent and the company to rotate um. The other was this idea that in these professional services firms that are structured as partnerships, the partners are not just for example, really good lawyers, they’re also responsible for the health of the business. So that’s things like bringing in business, doing recruiting for the firm, taking care of all the miscellaneous business things that one needs to do, making decisions about, you know, the office or whatever, and um again I isolate that model of these people who feel more responsibility than just their narrow functional expertise. 00:27:17 - Speaker 2: Yeah, that style of, I guess call it rotating partnership also fits in with the the tour of duty idea that you mentioned, which is Someone can be a partner and a prime driver at the business for 20 years, but then maybe they want to retire, maybe they want to move on to new things, maybe they want to focus on their family. And I feel like sometimes the cult of personality stuff that we get in the tech world a little bit produces something where key people moving on to their next thing or in some cases dying, right? Like that happened with um the Walt Disney Company. You know, the, the Disney Company basically lost its soul and was totally lost in the weeds for a pretty long time when Walt Disney passed, unfortunately quite young, relatively speaking, and it took a really long time to reform itself because it was so built around this one visionary genius individual. And while granted, Disney was a a a unique genius uh and um. I think it is the case sometimes that if we build companies in a way that kind of assumes these these founding people who were there at the beginning, the only people that can ever drive it forward, uh, that actually doesn’t create a long term healthy business. And if people can do their tour of duty and then rotate out and others can take it to the next, uh, take it to the next level and you have something where that’s a, a normal, um, Normal way that you do business as opposed to an exceptional event, it seems to me that actually makes a healthier business over the long term. 00:28:49 - Speaker 1: Yeah, I think so, and I hope so. Of course, we’ll have to see over the next 248 years, how that actually works out, you know, the mechanics of it, but I’m optimistic. Should we talk a little bit about how we bring these partners on, you kind of alluded to it with like the ramp or the process, uh, but there’s actually a quite deliberate thing that we do there. 00:29:07 - Speaker 2: As someone who’s done a ton of hiring in my life, uh, I’m pretty passionate about pilot projects. And so just putting aside the the partner topic for a moment, I think the way that hiring often happens, which is based on a series of intensive interviews and then going to a full-time offer that’s contractually or at least implied to be something that lasts for many years, seems like a very strange step function that you go from, let’s have some conversations to now we’re gonna like commit to this huge event. Often coupled, I think there’s some connection there to the um. Kind of the um the uh in-office type teams where someone maybe actually needs to move to a new city. But yeah, that, that huge commitment based on essentially just some conversations doesn’t produce great results from what I’ve seen, and I really love pilot projects, uh, where you basically hire someone on a contract basis for a week or 2 weeks or a day or whatever, whatever can fit into their. Their life effectively and you really try to work with them as if they were on the team, uh, for a real project and then at the end of that both sides, you know, the, the potential person being hired onto the team, they see inside what the team is really like maybe they see some of the, the dirty laundry that isn’t so visible just from the outside and they can get a real sense of what it’s like. And then of course on the employer side you, you see what this person can really contribute. Be it not just how they represent themselves in an interview. Uh, but the partner thing adds a whole other dimension. 00:30:39 - Speaker 1: Well, it’s basically extending the ramp. So, again, in a typical startup model, you basically have this, this terminal level which is employee, and once you’re hired, you take this step function and you’re an employee and that’s it. And our model has uh a couple more steps. So we do this initial. Um, do initial, you know, phone conversations or, you know, reviewing open source work on the basis of that, we’ll do a 1 to 2 week trial project and if that goes well, then we move into a longer contract where we’re evaluating the person for the partnership and that’s typically 2 months, maybe 10 weeks. And then at the end of that trial period, we will make a decision together about uh making them an offer for a partner, and that we found is enough time uh this this two month period is enough time for them to step into the level of partner. You can really understand the the code base and the product and the business and really, you know, get into this mind meld with the rest of the partnership. 00:31:40 - Speaker 2: Mind meld is a great way to put it. One thing I’ve found through this process that is really different. From the kind of hiring I’ve done elsewhere, is I need to basically emotionally open myself to this person as if they were. A partner in the business. And for me, that’s actually for me it’s very personal like my. My work life and and the things I’m trying to accomplish in my venture and the feeling of ownership, you know, it’s it’s sort of people jokingly say things like it’s my baby when they talk about a business that they own, uh, but that’s, that’s how I feel. It’s, it’s, um, it’s a very personal thing for me and so to talk about the most. Difficult challenges or the open questions, uh, within the business is a kind of vulnerability. Take that leap a little bit and present them with the unfinished thinking and the open problems that we’re grappling with and then you see if those conversations. Have a spark or or allow you to come up to come up with new ideas or better decisions, or go in new directions that are uh that are maybe better than what they would have been without this contribution of this this person and that’s a good sign that uh that they are someone that’s will add something new to the partnership. 00:33:02 - Speaker 1: Yeah, I think that process is really important and again, you need the time for that to unfold properly. If you just like surprise the person with their initial interview, like here’s this weird company, we’re building this wild product, we have this different organizational model, here’s all the challenges we’re facing. Do you want to sign up, you know, for the next two years of your life to do this? They’d be like, uh, I don’t know, how can I tell? Um, you really need some time for that to, uh, you know, get folded in with the partnership over the course of a couple of months. This relates to one other thing that I think is really important, which is this is a genuinely two-way process. I think companies often think of interviewing as like we’re assessing this candidate for a fit at the company, which is true, but I think if you’re doing it right, you’re also giving the candidate uh the opportunity and the chance to evaluate, you know, their fit for their life with what this company is up to. And uh again these conversations help with that and we encourage it. You know, we say we’re gonna come up with, with our, you know, opinion about this. We also want you to take an honest look at if this honestly somewhat unusual company is right for you and it’s not right for everyone, which is fine. And again, we have because we have some time, uh, they have a chance to decide before they make a bigger commitment. 00:34:13 - Speaker 2: Yeah, exactly so that it’s, it’s, it is really this intimate relationship you’re entering into. And you can like what a company does from the outside, you can like its product, that may or may not mean that you fit in with the team, uh, or that you have something to contribute or that your unique energy is going to take the team in new directions that are are net positive. I like to talk sometimes about working chemistry. It’s this really ineffable thing and it’s hard to guess from from interviews for sure because it it doesn’t specifically have to do with liking someone, but I like to measure working chemistry by when you sit down and collaborate on a thing together. What comes out? Does magic happen? Does something amazing that you could not have made individually, um, does the result of that collaboration have something really special to it? 00:35:05 - Speaker 1: Yeah, I’m really happy that we’ve been able to find great working chemistry with the partnership so far. It gives me, you know, so much energy and it’s very rewarding professionally to have that. 00:35:15 - Speaker 2: Well, Mark, would you recommend this model to other companies? We’re pretty early in the experiment here and maybe we’ll have to report back a couple of years in, uh, but is this something broadly applicable or is it just something pretty specific to Muse, this little indie software development firm doing a pretty nichey product? 00:35:34 - Speaker 1: So there are things that are specific to our unique company, but I think this underlying idea of uh trying to increase the talent density, trying to give your staff much more responsibility, basically, uh, giving them the freedom and responsibility to step up. I think you could find that a lot of people actually do. And conversely, if you treat people as like, uh, you know, employees with very narrowed roles and very little ability to make decisions on their own, indeed that’s what they’ll do. Um, so I would encourage people to see if they can set a higher, higher ceiling and higher expectations for their staff. 00:36:11 - Speaker 2: Yeah, well, speaking for myself, you know, the, the proof will be in the output in the product that we deliver and whether it’s something customers like and whether the business can be viable, but I’m really, really enjoying working on a small partnership with people I can really trust where I can. Be spending a lot of my time making things, but also, uh, we make decisions largely by consensus, uh, and that I can really trust in the judgment and decisions that we all make together and I think the decisions we make are are better than what we would make individually. That’s been really personally very satisfying for me and that that matters a lot uh to me is that I have a workplace that is, um, I’m excited to get up and be a part of every day. Absolutely. If any of our listeners out there have feedback, please feel free to reach out to us at @museapphq on Twitter or hello at museApp.com by email. I’d love to hear your comments or ideas for future episodes. Really enjoyed the chat, Mark. Likewise, Adam, see you next time.
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: And I feel like this idea of really changes the abstractions that operating systems should provide because maybe OSs should not just be providing this model of files as a sequence of bytes, but this higher level CRDT like model and how does that impact the entire way how software is developed. 00:00:23 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for thought on iPad. This podcast isn’t about Muse the product, it’s about Muse the company and the small team behind it. I’m Adam Wiggins here with my colleague Mark McGranaghan. Hey, Adam, and joined today by Martin Klutman from the University of Cambridge. Hello. And we talked before about Mark’s dabbling in playing the piano. I understand this is a hobby you’re starting to look into as well, Martin. 00:00:49 - Speaker 1: Oh yes, I’ve been playing the piano, like trying to do it a bit more consistently for the last year and a half or so. My lockdown projects. 00:00:57 - Speaker 2: And do you have a technique for not annoying your neighbors, or is this an electronic piano, or how do you do that? 00:01:03 - Speaker 1: It’s an electric piano, although I don’t think it’s too bad for the neighbors. Lately I’ve been trying to learn a WBC 400 piece that I can play together with my wife, so she’ll play two hands and I’ll play the other two. 00:01:15 - Speaker 2: Nice. I suspect a lot of our listeners know you already, Martin. I think you’re within your small, narrow niche, you’re a pretty high profile guy, but for those that don’t, it’d be great to hear a little bit about your background. What brought you on the journey to the topic we’re gonna talk about today? 00:01:31 - Speaker 1: Yeah, well, I’m a computer scientist, I guess. I started out as an entrepreneur and started two startups some years ago. I ended up at LinkedIn through the acquisition of the 2nd startup. And they worked on large scale stream processing with Apache Kafka and was part of that sort of stream processing world for a while. And then I wanted to share what I had learned about building large scale distributed data systems. And so I then took some time out to write a book which is called Designing Data Intensive Applications, which has turned out to be surprisingly popular. 00:02:10 - Speaker 2: Yeah, you wrote a nice kind of tell-all, you showed the numbers on it, which it’s been financially successful for you, but also one of the more popular O’Reilly books just by kind of copy sold in recent times. I like that post, like the candor there, but yeah, it makes you a pretty successful author, right? 00:02:28 - Speaker 1: Yeah, it’s sold over 100,000 copies, which is, wow, way more than what I was expecting for something that it’s a pretty technical, pretty niche book, really. But the goal of the book really is to help people figure out what sort of storage technologies and data processing technologies are appropriate for their particular use case. So it’s a lot about the trade-offs and the pros and cons of different types of systems. And there’s not a whole lot on that sort of thing out there, you know, there’s a lot of sort of vendor talk hyping the capabilities of their particular database or whatever it might be, but not so much on this comparison between different approaches. So that’s what my book tries to provide. Yeah, and then after writing that book, I sort of slipped into academia, sort of half by accident, half by design. So I then found a job at the University of Cambridge where I could do research full time. And since then I’ve been working on what we have come to call the first software, which we’re going to talk about today. The nice thing there is that now then academia compared to the startup world, I have the freedom to work on really long term ideas, big ideas which might take 5 or 10 years until they turn into like viable technologies that might be used in everyday software development. But if they do work, they’ll be really impactful and really important and so I’m enjoying that freedom to work on really long term things now as an academic. 00:03:53 - Speaker 2: And certainly it struck me when we got the chance to work together through these Ink & Switch projects that because you have both the commercial world, including startup founder, but obviously you’re very immersed in the academic kind of machinery now and again just that long-term mindset and thinking about creating public goods and all that sort of thing. And I found that I actually really like now working with people that have both of those. Another great example there would be another former podcast guest Jeffrey Litt. He was also in the startup world, now he’s doing academic work at MIT. 00:04:26 - Speaker 1: Yes, and I’m actually doing a project with him right now, right, I forgot about that. 00:04:29 - Speaker 2: There’s a current Ink & Switch project there. So I find that maybe if you live your whole life in one of those two kind of commercial slash industry or academia, you get like a fish doesn’t know what water is kind of thing, but if you have experienced both models, then it’s easier to know the pros and cons and understand the shape of the venue you’re doing your work in in the end. The point is to have some meaningful impact on humanity through your work, whatever small piece of the world you hope you’re making better. In our case, it’s computer things, but that the venue you’re in is not the point, that’s just a vehicle for getting to where you want to go, and each of these styles of venue have different trade-offs, and being aware of those maybe makes it easier to have your work have an impact. 00:05:19 - Speaker 1: Yes, I think it is really helpful to have seen both sides and I find it allows me to be a little bit more detached from the common mindset that you get like in every domain you get, you know, there are certain things that everyone believes, but you know, they’re kind of unspoken, maybe not really written down either. And so like in academia, that’s like the publishing culture and the competitiveness of publication venues and that sort of stuff, which seems ridiculous to outsiders. But if you’re in it, you kind of get accustomed to it. And likewise in startups, it’s like the hype to be constantly selling and marketing and promoting what you’re doing to the max crushing it, always crushing it, exactly, and to an outsider that seems really. it’s kind of a ridiculous show that people put on frankly. But to an insider, you know, you just get used to it and that’s just your everyday life. I find that having seen both makes me a bit more detached from both of them and I don’t know, maybe I see a little bit more through the bullshit. 00:06:21 - Speaker 2: So as you hinted, our topic today is local first software. So this is an essay that I’ll link to in the show notes. It’s about 2 years old, and notably there’s 4 authors on this paper, 3 of them are here, kind of almost a little reunion, and actually the 4th author, Peter van Hardenberg, we hope to have on as a future guest. But I thought it would be really fun to not only kind of summarize what that philosophy is, particularly because we’re actively pursuing that for the Muse sinking persistence model, but also to look at sort of what we’ve learned since we published that essay and revisiting a little bit. What do we wish we’d put in, how’s the movement, if that’s the right word for it, how’s that evolved, what have we learned in that time? But I guess before getting into all that, maybe Martin, you can give us the elevator pitch, if I’m to reference the startup terminology, the brief summary of what is local first software. 00:07:18 - Speaker 1: Yeah, local first software is a reaction to cloud software and so with cloud software, I mean things like Google Docs, where you have a browser window and you type into it and you can share it really easily. You can have several people contributing to a document really easily, you can send it for comments. Very easily and so on. So, it has made collaboration a ton easier, but it’s come at a great cost to our control and our ownership of the data, because whenever you’re using some cloud software, the data is stored on the cloud provider servers, like Google servers, for example. And you know, as users, we are given access to that data temporarily. Until that day where Google suddenly decides to lock your account and you are locked out of all of the documents that you ever created with Google Docs, or until the startup software as a service product you’re using, suddenly goes bust and decides to shut down their product with 2 weeks' notice and maybe allows you to download a zip file full of JSON files as your data export. And I find that tragic because as creative people, we put a ton of effort, time and our souls and really our personalities into the things that we create. And so much now the things that we create are computer-based things, you know, whether you’re writing the script for a play or whether you’re negotiating a contract or whether you’re doing any sort of endeavor, it’s probably a file on a computer somewhere. And if that file is in some cloud software, then there’s always this risk that it might disappear and that you might lose access to it. And so what we try to do with local first software is to articulate a vision for the future where that does not happen, where We have the same convenience that we have with cloud software that is we have the same ability to do real-time collaboration. It’s not back to the old world of sending files back and forth by email. We still want the same real-time collaboration that we get with Google Docs, but at the same time we also want the files stored. On our own computers. Because if there are files on our own computers, then nobody can take them away. They are there, we can back them up ourselves. We can optionally back them up to a cloud service if we want to. There’s nothing wrong with using a cloud service as long as the software still continues working without the cloud service. Moreover, we want the software to continue working offline so that if you’re working on a plane or working on a train that’s going through a tunnel or whatever, the software should just continue to work. And we want better security and privacy because we don’t want cloud services scanning through the content of all of our files. I think for creativity, it’s important to have that sense of privacy and ownership over your workspace. And so those are some of the ideas that we try to encapsulate in this idea of local first software. So how can we try to have the best of both worlds of the convenience of cloud software. But the data ownership of having the files locally on your own device. 00:10:15 - Speaker 2: Yeah, for me, the core of it is really agency and much of the value of cloud, and I think there’s a version of this also for mobile apps, let’s say and app stores and that sort of thing, which is not what we’re addressing in the paper, but maybe there’s a theme in computing that we’ve made computers vastly more accessible by In many cases, taking agency from people, and that’s actually a good thing in many cases, right? You don’t need to defrag your hard drive anymore. You lose your device, your email, and your photos and all those things are still in this cloud that’s managed by experiencedmins and product managers and so forth at companies like Google and So forth, and they can often do a better job of it in a lot of cases than an individual can. I mean, I think of managing my own email servers, SMTP servers, years back and needing to deal with data backup and spam filtering and all that kind of thing, and Gmail came along and I was just super happy to outsource the problem to them. Absolutely. They did a better job managing it. So I think that’s basically in many ways a good trend or as a net good in the world, and I don’t think we feel like we necessarily want to go back to everyone needs to do more of those data management tasks, but I think for the area of creative tools or more, I guess you call them power users, but it’s like you said, if you’re writing a play, that’s just a very different kind of interaction with a computer than the average person doing some calendar and email and messaging. Yeah, maybe they want different trade-offs. It’s worth doing a little bit more management and taking a little more ownership to get that greater agency over something like, yeah, my work product, the script of my play or my master thesis or whatever it is that I’m working on is something that really belongs to me and I want to put a little extra effort to have that ownership. 00:12:08 - Speaker 1: Right, exactly. And I feel like it’s not reasonable to expect everyone to be a sys admin and to set up their own services, you know, you get this self-hosted cloud software, but most of it is far too technical for the vast majority of users, and that’s not where we want to go with this. I think you still want exactly the same kind of convenience of clouds software that, you know, it just works out of the box and you don’t have to worry about the technicalities of how it’s set up. But one part of local first software is that because all of the interesting app specific work happens client side on your own device, it now means that the cloud services that you do use for syncing your data, for backing up your data, and so the cloud services become generic. And so you could imagine Dropbox or Google Drive or AWS or some other big cloud provider just giving you a syncing service for local first apps. And the way we’re thinking about this, you could have one generic service that could be used as the syncing infrastructure for many different pieces of software. So regardless of whether the software is a text editor or a spreadsheet or a CAD application for designing industrial products or music software or whatever it might be, all of those different apps. Could potentially use the same backup and syncing infrastructure in the cloud, and you can have multiple cloud providers that are compatible with each other and you could just switch from one to the other. So at that point, then it just becomes like, OK, who do you pay 6 cents a month to in order for them to store your data, it becomes just a very generic and fungible service. And so that’s what I see makes actually the cloud almost more powerful. Because it removes the lock-in that you have from, you have to use a single, the, the cloud service provided by the software offer. Instead, you could switch from one cloud provider to another very easily and you still retain the property that you’re using all of the cloud providers' expertise in providing a highly available service and you don’t have to do any admin yourself. It’s not like running your own SMTP server. So I feel like this is a really promising direction that local first software enables. 00:14:24 - Speaker 3: Yeah, for sure, indeed, and you could even describe local first software, I think, as sort of generalizing and distributing the capabilities of the different nodes. So in the classic cloud model, you have these thin clients, they can dial into the server and render whatever the server tells them. And then you have the servers and they can store data and process it and return to clients and when you have both of those at the same time, you know, it works great, but then if you’re a client like you said, who’s in a tunnel, well too bad you can’t do anything, and the local first model is more that any node in that system can do anything, it can. Process the data, I can validate it, it can store it, it can communicate it, it can sync it, and then you can choose what kind of typologies you want. So it might be that you just want to work alone in your tunnel, or it might be that you want to subscribe to a cloud backup service that does the synchronization storage part for you while you still maintain the ability to process and render data locally. This actually gets to how I first got into what we’re now calling local first software. I was in a coffee shop with Peter Ben Hartenberg, who’s one of the other authors that Adam mentioned. And we’re talking about working together at the lab when he was a principal there, he’s now the director, and he showed me the pixel pusher prototype. So Pixel Pusher was this Pixel art app where you color individual pictures to make a kind of retrographic thing, and it was real time collaborative, but the huge thing was that there was no server, so that you had this one code base and this one app, and you got real time collaboration. Across devices, and that was the moment that I realized, you know, I was a fish in the cloud infrastructure water and I didn’t realize it. Just assumed, oh, you need servers and AWS need a whole ops team, you’re gonna be running that for the rest of your life, it’s the whole thing. Well, actually, no, you could just write the app and point at the other laptop and there you go. And we eventually kind of realized all these other benefits that we would eventually articulate as the desiderao property to the local for software article, but that was the thing that really actually kicked it off for me. 00:16:19 - Speaker 1: Yeah, and that’s aspect that the apps become really self-contained and that you just don’t have a server anymore, or if you have a server, it’s like a really simple and generic thing. You don’t write a specific server just for your app anymore. That’s something that I’m not sure we really explored very well in the local first asset as it was published, but I’ve been continuing to think about that since, you know, this has really profound implications for the economics of software development. Because right now, as you said, like if you’re a startup and you want to provide some SAS product, you need your own ops team that is available 24/7 with one pager duty so that when the database starts running slow or a node falls over and you need to reboot something or whatever, you know, there’s just all this crap that you have to deal with, which makes it really. to provide cloud software because you need all of these people on call and you need all of these people to write these scalable cloud services and it’s really complicated, as evidenced by my book, a lot of which is basically like, oh crap, how do I build a scalable cloud service. And with local first software, potentially that problem simply goes away because you’ve just got each local client which just rights to storage on its own local hard disk. You know, there are no distributed systems problems to deal with, no network time outs and so on. You just write some data locally and then you have this syncing code which you just use an open source library like automerge, which will do the data syncing between your device and maybe a cloud service and maybe the other services. And the server side is just non-existent. And you’ve just like removed the entire backend team from the cost of developing a product and you don’t have the ops team problem anymore because you’re using some generic service provided by some other cloud provider. And you know, that has the potential to make the development of collaborative software so much cheaper. Which then in turn will mean that we get more software developed by smaller teams, faster, it’ll improve the competitiveness of software development in general, like it seems to have so many positive effects once you start thinking it through. 00:18:22 - Speaker 2: Yeah, absolutely. For me, yeah, maybe similar to both of you, my motivations were, well, both as a user and as a, let’s say a software creator or provider on the user side, we have these 7 different points we articulate and I think you can, in fact, we even set it. Up this way is you can give yourself a little scorecard and see which of the boxes you tick. It’ll be fun to do that for the muse syncing service when that’s up and running, but the offline capability is a huge one to me, and it’s not just the convenience. I mean, yeah, it’s. Every time I’m working on the train and my train goes through a tunnel, and suddenly I can’t type into my documents anymore, for example, or I don’t know, I like to go more remote places to work and have solitude, but then I can’t load up Figma or whatever else, and Yeah, that for me as a user is just this feeling of it comes back to the loss of agency, but also just practically it’s just annoying and you know we assume always on internet connections, but I wonder how much that is because the software engineers are people sitting in office. Or maybe now at home in San Francisco on fast internet connections with always connected devices versus kind of the more realities of life walking around in this well connected but not perfectly so world we all live in. That’s on the user side. 00:19:42 - Speaker 1: Yeah, I feel like there’s a huge bias there towards like, oh, it’s fine, we can assume everyone always has an internet connection because yes, we happen to be that small segment of the population that does have a reliable internet connection most of the time. There’s so many situations in which you simply can’t assume that and that might be anything from a farmer working on their fields using an app to manage what they’re doing to their crops and something like that and you know, they won’t necessarily have reliable cellular data coverage even in industrialized countries, let alone in other parts of the world where you just can’t assume that sort of level of network infrastructure at all. 00:20:17 - Speaker 3: Yeah. Yeah, it’s funny you mention this because we often run into this on the summits that we have for Muse. So we were recently in rural France and we had pretty slow internet, especially on upload. I think it was a satellite connection, and we always had this experience where there are 4 of us sitting around a table and you’re looking at each other, but you can’t, you know, send files around cause it needs to go to, you know, whatever, Virginia and come all the way back. 00:20:43 - Speaker 1: It’s crazy if you think about it, it’s ridiculous. 00:20:46 - Speaker 2: Yeah, and I don’t think you even need to reach as far as a farmer or a team summit at a remote location. I had a kitchen table in the house I lived in right before this one that was like a perfect place to sit and work with my laptop, but the location of the refrigerator, which it really couldn’t be any other place, just exactly blocked path to my router, and the router couldn’t really be any other place. I guess I could run a wire or something, but I really wanted to sit right there and work. But again, it’s this ridiculous thing where you can’t even put a character into a document and I could pick up the laptop and walk a meter to the left, and now suddenly I can type again and you can be that to something like. G, which does have more of a local is probably one of the closest thing the true local first software where you can work and yes, you need an internet connection to share that work with others, but you’re not stopped from that moment to moment typing things into your computer. 00:21:38 - Speaker 3: Yeah, and furthermore, from the implementation perspective, even when you have a very fast internet connection, you’re still dealing with this problem. So if I’m using an app and I type in a letter on my keyboard, between the time when I do that and when the round trip happens with the AWS server, which might be 50 or 100 milliseconds, the app needs to do something useful. I can’t wait for that full round trip. It needs to immediately show. Me what’s happening. So you inevitably have this little distributed system where you have your local process and app trying to display something immediately, and you have the remote server. And the great elegance, I think, of the local first approach is that that’s just like another instance of the general problem of synchronizing across nodes, whereas often in other apps, that’s sort of like an ad hoc kind of second special case thing, like, oh, It’s only going to be like this for 100 milliseconds. So just kind of do a hacky solution and make it so that most of the time the right letter shows up. And that’s why you have this behavior where apps will have like an offline mode, but it like never works, because I think we mentioned this on the podcast before, there’s systems that you use all the time and systems that don’t work. This is a maximum we can link to. But again, with local first, you’re kind of exercising that core synchronization approach all the time, including when it’s just you and another server on a good connection. 00:22:50 - Speaker 1: Yeah, and from a sort of fundamentals of distributed systems point of view, I find that very satisfying because I just see this as different amounts of network latency. Like if you’re online you have network latency of 50 or 100 milliseconds. If you’re offline, you have network latency of 3 hours or however long it’s going to be until you next come back online again. To me those are exactly the same, you know, I don’t care if it’s a few orders of magnitude apart. Both the network latency both need to be dealt with and if we can use the same techniques for dealing with both standard online latency and being offline, that just simplifies the software dramatically. 00:23:25 - Speaker 2: Going back to sort of the infrastructure, fewer moving parts thing and speaking to our personal motivations, for me, the experience of running Hiroku was a big part of my motivation or fed into my interest in this because Hiokku was an infrastructure business. I didn’t quite grasp what that meant when we went into it. I just wanted a better way to deploy apps, and in the end, I enjoy writing software, I enjoy creating products that solve problems for people, but infrastructure is a whole other game. And you know, it became the point where once you’re, I don’t know if mission critical is the right word, but just something people really care about working well and you’re in the critical path. So for example, our routing infrastructure, if it was down for 3 seconds, people would complain. So the slightest hiccup, and as they should, that was part of the service that that company is providing, and so that’s fair enough. But then when I go, OK, well, I’m building software, when I think of, for example, Muse, where I’m providing this productivity tool to help people think and that sort of thing. I don’t want to be paged because someone went to move a card 5 centimeters to the right and our server was down or overloaded or something, so then they can’t move the card and so then they’re writing into support angrily. I’m pretty comfortable with there’s some kind of cloud syncing problem and OK, I can’t easily like push my changes to someone else, and that is still a problem, but it feels like it’s on this slightly different timeline. You’re not just blocking the very most basic fundamental operation of the software. And so the idea that exactly as you said, it changes the economics, for me personally, I want to spend more of my time writing software and building products and less of my time setting up, maintaining and running infrastructure. So I guess looking back on the two years that have elapsed, I would say that this is probably, it’s hard to know for sure, but the Inkot switch essays, there’s a number of them that I think had a really good impact, but I think this one probably just my anecdotal feeling of seeing people cite it by. it in Twitter comments and things like that. It feels like one of the bigger impact pieces that we published, and I do really see quite a lot of people referencing that term, you know, we’ve sort of injected that term into discussion again, at least among a certain very niche narrow world of things. So, yeah, I’d be curious to hear from both of you, first, whether there’s things that looking back you wish we’d put in or you would add now, and then how that interacts with what you make of local first movement or other work that people are doing on that now. 00:25:59 - Speaker 1: I’m very happy that we gave the thing a name. There’s something we didn’t have initially when we started writing this and we’re just writing this like manifesto for software that works better basically. And then at some point we thought like it would be really good to have some way of referring to it and you know, people talk about offline first or mobile first, and these were all kind of established things and terms that people would throw around. And we also wanted some term X where we could say like I’m building an X type app. And so I’m very glad that we came up with this term they first because I’ve also seen people even outside of our direct community starting to use it. And just, you know, put it in an article casually without even necessarily explaining what it means and just assuming that people know what it is. And I think that’s a great form of impact if we can give people a term to articulate what it is they’re thinking about. 00:26:50 - Speaker 2: Yeah, language, a shared vocabulary to describe something as a very powerful way to, one, just sort of advance our ability to communicate clearly with each other, but also, yeah, there’s so many ideas. I mean, it’s a 20 something page paper and there’s so many ideas, but you wrap this up in this one term and for someone who has downloaded some or most of these ideas, that one term can carry all the weight and then you can build on that. You can take all that as a given and then build forward from there. 00:27:19 - Speaker 1: Yeah. One thing I wish we had done more on is I think trying to get a bit more into the economic implications of it. I guess that would have made the essay another 5 pages longer and so at some point we just have to stop. But I feel like it’s quite an important aspect like what we talked about earlier of not having to worry about back ends or even just like not having to worry generally about the distributed systems problem of like you make a request to a server, the request times out. You have no idea whether the server got the request or not. Like, do you retry it? If so, how do you make the retry? Is that potent so that it’s safe to retry and so on. Like all of those problems just go away if you’re using a general purpose syncing infrastructure that somebody else has written for you. And there are other implications as well that are less clear of what about the business model of software as a service. Because there a lot of companies' business model right now is basically pay us, otherwise you’re going to get locked out of your data. So it’s using this idea of holding data hostage almost as the reason why you should pay for a product. And you know, it’s like that with Slack. Like you put all of your messages in Slack those messages were written by you and your colleagues. There’s nothing really Slack did to own those, they just facilitated the exchange of those messages between you and your colleagues. But then once you go over the, whatever it is, 10,000 messages limit, then suddenly you have to pay slack to see the messages that you wrote yourself. And generally that’s the business model with a lot of software as a service. And with local first, it’s not clear that that business model will still work so clearly. But of course, software developers still have to be paid for their time somehow. So how do we find a way of building sustainable software businesses for collaboration software but without holding data hostage? I think that’s a really deep and interesting question. 00:29:07 - Speaker 3: Yeah, I think as an aside that uh you might call it the political economy of software is understudied and underconsidered, and I would put in here like the economics of software business, but also the interaction with things like regulation and governments and the huge amount of path dependence that’s involved. I think that’s just a huge deal. I think we’re starting to realize it, but yeah, there’s a ton of stuff we could do and think about just for local first. Like just one kind of branch that I hope we get to explore is we mentioned how local first enables you to do totally different topologies. So with cloud software almost by definition, you have this hub and spoke model where everything goes through. The central server and the central corporation. Well with local first, you can very easily, for example, have a federated system where you dial into one of many synchronization nodes and you could even have more like a mesh system where you request and incentivize packets to be forwarded through a mesh to their destination, sort of like TCPIP networking, but for like the application layer, and it may be, you know, it’s still kind of TBD but it may be that a mesh or a distributed approach has totally different political implications from a centralized node and that might become important, so. I just think there’s a lot to think about and do here. 00:30:15 - Speaker 1: Yeah, I think so too. And like, I would take email as an analogy maybe, which is a federated system just like what you described, like you send your email to your local SMTP server and it forwards it to the recipient’s SMTP server and the system works really well. Certainly as criticisms like spam filtering is difficult in a really decentralized way. Maybe spam is not a problem that local first software will have as much because it’s intended more like for collaboration between people who know each other rather than as a way of contacting people you don’t know yet. But certainly like I think taking some inspiration from that federation and seeing how that can be applied to other domains, I think would be very interesting. 00:30:55 - Speaker 3: Yeah, and this brings us to the topic of like industrialization and commercialization, and I feel like there’s more promise than ever around local First and more people are excited about it, but I still feel like we’re just in the beginning phases of getting the ball rolling on industrial and commercial applications. And if I’m being really honest, I feel like it might have been slower than I had initially hoped over the past few years, so I’m just curious if Adam and Martin, you would reflect on that. 00:31:21 - Speaker 2: It’s always hard to say, right? The thing with any technology, but certainly my career in computing, this has always proven to be the case, is that something seems right around the corner and it stays so for 20 years. I don’t know, maybe VRs in that category, but then there’ll be a moment, suddenly it’ll just be everywhere, broadband internet or something like that. So as a people who are both trying to advance the state of the art but also making Business decisions, you know, should I start a company? Should I invest in a company? Should I keep working on the company I’m working on based on what technologies exist or where you see things going? Yeah, you’re always trying to make accurate predictions. So yeah, I agree on one hand it felt very close to me on the basis of the prototypes we’d built, the automerged library, the reference, Martin I’ll link that in the notes here, but basically that’s a JavaScript implementation of something called CRDTs which Just I guess as a sidebar, it could be easy to think that CRDTs and local first software are kind of one and the same because they are often mentioned together and in fact our paper talks about them together, but CRDTs are a technology we find incredibly promising for helping to deliver local first software, but local first is a set of principles. It doesn’t require any particular technological solution. Yeah, based on the strength of those prototypes, many of which worked really well, there’s the networking side of it and whether you can have that be fully kind of decentralized versus needing more of a central coordination server. But once you get past that hump, it does work really, really well. But I think that comes back to the point you both made there about the economic model side of things, which is we have a whole software industry that’s built around people will pay for software when there’s a service connected to it. Right, so Sass, in particular B2BASS is just a fantastic business to be in, and as a result, we’ve seen a huge explosion of software around that, but connected to that is, for example, the Fremium model, exactly like what you mentioned with Slack, the docs is one of those. Notion is one of those. They do this kind of free for individuals, but then you pay when you’re a business and then you need to come up with the feature stuff, the kinds of features that seem to be selecting for you being a business with more serious needs and something like retaining your message history is there. I wrote a whole other shorter essay about paying for software. I’ll link that in the notes, but I think we got into a weird corner. The industry got itself into a weird painted itself into a corner because Things like Google giving you so much incredibly high quality software, Gmail, Google Docs, Google Maps, etc. for quote unquote free, but then how you’re really paying for it is your attention and your data, right? And that being kind of montizable through being able to essentially serve you ads. And I think that’s fine and I’m very glad for Google’s existence and they found that model, but it almost feels like then it taught people that good software should be free and that you shouldn’t pay for, maybe that’s a little bit connected to the concept that software R&D basically costs nothing to make additional copies of it. So therefore, if you make this big upfront investment and then the software exists and you can duplicate it endlessly, but I think there’s a lot of things flawed about all of that. But the end place that gets you to is, OK, if someone has my data and I’m paying them to maintain it and run the servers that it’s on, I can stomach that. OK, now I’ll pay $5 a month, $10 a month for my Dropbox account or something like that. But other than that, we’ve become accustomed to, oh, if it’s an app on the App Store, the App Store is a good example of these kind of consumer economics, we just expect it to be vastly lower cost or free and good software costs money to make, and as we kind of talked about earlier, I would rather be building the software, not maintaining the infrastructure, but when you set it up so that The only way you can make money is to build software that has infrastructure, you’re actually incentivized, build that back end as soon as you can and get the user’s data in there and not necessarily hold it hostage, but just take ownership of it, because that’s what people will pay for. They won’t pay for software where they own the data themselves. 00:35:34 - Speaker 1: Yes, one thing that a friend has suggested is that when talking about the business model of local first software, we should just call it SA, like label it as SAS, market it in exactly the same way as SAS. Don’t even tell people that it’s local first software and just use the fact that it’s a lot cheaper and easier to implement local first software and use that for your own benefit in order to build the software more cheaply. But don’t actually market the local first aspect. And I thought that’s quite an interesting idea because, you know, it is an idea that people are accustomed to and to be honest, I think the amount of piracy that you would get from people like ripping out the sinking infrastructure and putting it for something else and then continuing to use the app without paying for it, it’s probably pretty limited. So you probably only need to put in a very modest hurdle there of say, OK, like this is the point at which you pay. Regardless of whether that point for payment is, you know, necessarily enforced in the infrastructure, it might just be an if statement in your client side up and maybe that’s fine. 00:36:38 - Speaker 2: Muse is basically an example of that. We have this membership model that is, you know, subscription is your only option and there are a lot of folks that complain about that or take issue with it, and I think there are many valid complaints you can make, but I think in many cases it is just a matter of what. Folks are accustomed to and we want to be building and delivering great software that improves and changes over time and maps to the changing world around it, and that’s something where as long as you’re getting value, you pay for it and you’re not getting value anymore, you don’t have to pay anymore. And then a model like that basically works best for everyone, we think, again, not everyone agrees. But then again, you do get this pushback of we are running a small service, but it’s not super critical to the application, but maybe that would be a good moment to speak briefly about the explorations we’re doing on the local first sync side, Mark. 00:37:32 - Speaker 3: Yeah, so right now Muse is basically a local only app, like it’s a traditional desktop app where files are just saved to the local device and that’s about it, and you can manually move bundles across devices, but otherwise it just runs locally and the idea is to extend be used with first syncing across your devices and then eventually collaboration across users using a local first approach. Now we don’t plan to do, at least initially the kind of fully distributed mesh networking peer to peer thing. It will be a sync service provided by Muse and kind of baked in to the app, but it will have all those nice local first properties of it works offline, it’s very fast, all the different nodes are first class and so forth while eventually supporting syncing and and collaboration. So, yeah, we’re going through this journey of, we had a lot of experience with um basic prototypes in a lab, but there’s a big jump to have a commercialized and industrialized product, not just in terms of charging for the business model and stuff, but in terms of the performance and it’s like all the weird things that you deal with in the real world, like versioning and schemas and the idiosyncrasies of networking and All the things that go around the core functionality, like one thing we’re thinking a lot about is visibility into the sync status and how it’s different in a local first world. Yeah, so I’m excited that we are now investing a lot in bringing local first into the real world with MS. 00:38:57 - Speaker 1: Yeah, and I feel like more generally, if we want the local first ideas to be adopted, we need to make it easy in a way that people can just take an open source library off the shelf, not have to think too much about it, plug it into their app, have a server that’s ready to go, that’s either it’s already hosted for them or they can spin up their own server and make that path. Super easy and straightforward and that’s kind of where my research is focusing of trying to get the technologies to that point. So right now, we have some basic implementations of this stuff. So automerge is a library that does this kind of data synchronization. It includes a JSON like data model that you can use to store the state of your application. It has a sort of basic network protocol that can be used to sync up two nodes. But there’s so much more work to be done on making the performance really good, like at the moment it’s definitely not very good. We’re making progress with that, but it’s still a long way to go. Making the data sync protocol efficient over all sorts of different types of network link in different scenarios, making it work well if you have large numbers of files, for example, not just single file and so on. And so there’s a ton of work still to be done there on the technical side. I think before this is really in a state where people can just pick up the open source library and run with it. Part of it is also like just uh getting the APIs right, making sure it has support across all the platforms, just having a JavaScript implementation is fine for initial prototypes, but Obviously, iOS apps are written in SWIFT and Android apps will be written in coin or whatever people use and so you need to have support across all of the commonly used platforms and we’re gradually getting there, but it’s a ton of work. 00:40:43 - Speaker 2: And conceptually seeing how autoerge is evolving. And how people are trying to use it sometimes very successfully, sometimes less so, but I see this as a case of technology transfer, which is an area I’m incredibly interested in because I think it’s kind of a big unsolved problem in HCI research, computer science, honestly, maybe all research, but I’ll stick to my lane in terms of what I know, which is there is often this very excellent cutting edge research that does sit in the labs. So to speak, and never graduates or it’s very hard or there isn’t a good path often for it to jump over that hump into what’s needed in the production world and of course in the research world you’re trying to do something new and different and push the boundaries of what was possible before and in the production commercial side you want to choose boring technologies and do things that are really reliable and known and stable, and those two, there’s often a bridge that’s hard to divide there. Sitting in your seat as again someone who’s enmeshed in the academic world right now and you’re creating this library, you know, started as a called a proof of concept for lack of a better term, and then you have customers if that’s the right way to put it, but as an academic you would Shouldn’t have customers, but you sort of do because people want to use this library and in fact are for their startups and things like that. How do you see that transition happening or is there a good role model you’ve seen elsewhere or just kind of figure it out as you go? 00:42:16 - Speaker 1: Well, I think where we’re trying to go with this is it’s great for automerge to have users. I don’t think of them as customers. I don’t care about getting any money from them. But I do care about getting bug reports from them and experienced reports of how they’re getting on with the APIs and reports of performance problems and so on. And those things are all tremendously valuable because they actually feed back into the research process and so I’m essentially using the open source users and the contributors as a source of research problems. So with my research hat on, this is great because I have essentially here right in front of me a goldmine of interesting research problems to work on. I just take like the top issue that people are complaining about on GitHub, have a think about how we might solve that. And often there’s enough of a nugget of research problem in there that when we solve the problem, we can write a paper about it. It can be an academic contribution as well as moving the open source ecosystem gradually towards a point where we’ve ironed out all of those major technical problems and hopefully made something that is more usable in production. So, I actually feel those worlds are pretty compatible at the moment. There are some things which are a bit harder to make compatible like sort of the basic work of porting stuff to new languages on new platforms, that’s necessary for real life software engineering, but there’s no interesting research to be done there, to be honest. But so far I’ve found that quite a lot of the problems that we have run into actually do have interesting research that needs to be done in order to solve them. And as, as such, I think they’re quite well compatible at the moment. 00:43:56 - Speaker 2: And like imagining or the mental picture of someone submits a bug report and one year later you come back and say, here’s the fix and also the paper we published about it. 00:44:08 - Speaker 1: I’ve literally had cases where somebody turns up on Slack and says, I found this problem here. What about it? And I said, oh yeah, I wrote a paper about it. And the paper has a potential algorithm for fixing it, but I haven’t implemented it yet, sorry. And they go like, WTF what you put all of this thought into it. You’ve written the paper. And you haven’t implemented. And I go, well, actually sorry for me, that’s easier because if I want to implement it, I have to put in all of the thoughts and convince myself that it’s correct. And then I also have to implement it and then I also have to write all the tests for it and then I have to make sure that it doesn’t break other features and it doesn’t break the APIs and need to come up with good APIs for it and so on. So for me actually like implementing it is a lot more work than just doing the research in a sense, but actually, Doing the research and implementing it can be a really useful part of making sure that we’ve understood it properly from a research point of view. So that at the end what we write in the paper is ends up being correct. In this particular case, actually, it turned out that the algorithm I had written down in the paper was wrong because I just haven’t thought about it deeply enough and a student in India emailed me to say, hey, there’s a bug in your algorithm, and I said, yeah, you’re right, there’s a bug in our algorithm. We better fix it. And so probably through implementing that maybe I would have found the bug, maybe not, but I think this just shows that it is hard getting this stuff right, but the engagement with the open source community, I found a very valuable way of Both working towards a good product but also doing interesting research. 00:45:39 - Speaker 3: I think it’s also useful to think of this in terms of the research and development frame. So research is coming up with the core insights, the basic ideas, those universal truths to unlock new potential in the world, and it’s my opinion that with local first, there’s a huge amount of development that is needed, and that’s a lot of what we’re doing with Muse. So analogy I might use is Like a car and an internal combustion engine. If you came up with the idea of an internal combustion engine, that’s amazing. It’s pretty obvious that that should be world changing. You can spin this shaft at 5000 RPM with 300 horsepower, you know, it’s amazing, but you’re really not there yet. Like you need to invent suspension and transmission and cooling and It’s kind of not obvious how much work that’s gonna be until you go to actually build the car and run at 100 miles an hour. So I think there’s a lot of work that is still yet to be done on that front. And eventually, that kind of does boil down or emit research ideas and bug reports and things like that, but there’s also kind of its own whole thing, and there’s a lot to do there. There’s also a continuous analogy. I think once the research and the initial most obvious development examples get far enough along, you should have some. Unanticipated applications of the original technology. So this should be someone saying like, what if we made an airplane with an internal combustion engine, right? I don’t think we’ve quite seen that with local first, but I think we will once it’s more accessible, cause right now to use local first, you gotta be basically a world expert on local first stuff to even have a shot. But once it’s packaged enough and people see enough examples in real life, they should be able to more easily come up with their own new wild stuff. 00:47:11 - Speaker 1: Yeah, we have seen some interesting examples of people using our software in unexpected ways. One that I quite like is the Washington Post, as in the newspaper, everyone knows. They have an internal system for allowing several editors to update the layout of the home page. So the placement of which article goes where, with which headline, with which image, in which font size, in which column. All of that is set manually, of course, by editors. And they adopted automerge as a way of building the collaboration tool that helps them manage this homepage. Now, this is not really a case that needs local first, particularly because it’s not like one editor is going to spend a huge amount of time editing offline and then sharing their edits to the homepage. But what I did want is a process whereby multiple editors can each be responsible for a section of the homepage and they can propose changes to their section. And then hand those changes over to somebody else who’s going to review them and maybe approve them or maybe decline them. And so what they need essentially is this process of version control, Git style version control almost, but for the structure of representing the homepage. And they want the ability for several people to update that independently. And that’s not because people are working offline, but because people are using essentially branches using the Git metaphor. So different editors will be working on their own local branch until they’ve got it right and then they’ll hit a button where they say, OK, send this to another editor for approval. And that I found really interesting. It’s sort of using the same basic technologies that we’ve developed with CRTTs, tracking the changes to these data structures, being able to automatically merge changes made by different users, but applying it in sort of this interesting unexpected context. And I hope like as these tools mature, we will expand the set of applications for which they can be sensibly used and In that expansion, we will then also see more interesting unexpected applications where people start doing things that we haven’t anticipated. 00:49:19 - Speaker 2: Maybe this reflects my commercial world bias or maybe I’m just a simple man, but I like to see something working more than I like to read a proof that it works. And both are extremely important, right? So the engineering approach to seeing if something works is you write a script, you know, fuzz testing, right, you try a million different permutations and if it all seemed to work, kind of the Monte Carlo simulation test of something, and it seems to work in all the cases you can find, so it seems like it’s working. And then there’s, I think, the more proof style in the sense of mathematical proof of here is an airtight logical deductive reasoning case or mathematical case that shows that it works in all scenarios that it’s not a Monte Carlo calculation of the area under the curve, it’s calculus to determine precisely to infinite resolution area to the curve. And I think they both have their place kind of to Mark’s point, you need to both kind of conceptually come up with the combustion engine and then build one, and then all the things that are gonna go with that. And I think we all have our contributions to make. I think I probably, much as I like the research world at some point when there’s an idea that truly excites me enough, and local first broadly and CRDT. in this category, and I wanna see it, I want to try it, I want to see how it feels. In fact, that was our first project together. Martin was, we did this sort of trello clone essentially that was local first software and could basically merge together of two people worked offline, and they had a little bit of a version history. I did a little demo video, I’ll link that in the show notes. But for me it was really exciting to see that working, and I think maybe your reaction was a bit of a like, well, of course, you know, we have 5 years of research. Look at all these papers that prove that it would work, but I want to see it working and moreover feel what it will be like because I had this hunch that it would feel really great for the end user to have that agency. But seeing it slash experiencing it, for me that drives it home and creates internal motivation far more than the thought experiment is the right word, the conceptual realm work, even though I know that there’s no way we could have built that prototype without all that deep thinking and hard work that went into the science that led up to it. 00:51:42 - Speaker 1: Yeah, and it’s totally amazing to see something like working for the first time and it’s very hard to anticipate how something is going to feel, as you said, like you can sort of rationalize about its pros and cons and things like that, but that’s still not quite the same thing as the actual firsthand experience of really using the software. 00:52:01 - Speaker 2: All right, so local first, the paper and the concept, I think we are pretty happy with the impact that it made, how it’s changed a lot of industry discussion, and furthermore, that while the technology maybe is not as far along as we’d like, it has come a long way, and we’re starting to see it make its way into more real world applications, including news in the very near future. But I guess looking forward to the future for either that kind of general movement or the technology. What do you both hope to see in the coming, say, next 2 years, or even further out? 00:52:38 - Speaker 3: Well, the basic thing that I’d like to see is this development of the core idea and see it successfully applied in commercial and industrial settings. Like I said, I think there’s a lot of work to do there and some people have started, but I’d like to see that really land. And then assuming we’re able to get the basic development landed, a particular direction I’m really excited about is non-centralized topologies. I just think that’s going to become very important and it’s a unique potential of local first software. So things like federated syncing services, mesh topologies, end to end encryption, generalized sync services like we talked about, really excited to see those get developed and explored. 00:53:18 - Speaker 1: Yeah, those are all exciting topics. For me, one thing that I don’t really have a good answer to but which seems very interesting is what does the relationship between apps and the operating system look like in the future? Because like right now, we’re still essentially using the same 1970 Unix abstraction of we have a hierarchical file system. A file is a sequence of bytes. That’s it. A file has a name and the content has no further structure other than being a sequence of bytes. But if you want to allow several users to edit a file at the same time and then merge those things together again, you need more knowledge about the structure of what’s inside the file. You can’t just do that with an opaque sequence of bytes. And ICRDTs is essentially providing a sort of general purpose higher level file format that apps can use to express and represent the data that they want to have just like Jason and XML are general purpose data representations and CRDTs further refined this by not just capturing the current state, but also capturing all the changes that were made to the state and thereby they much better encapsulate the what was the intent of the user when they made a certain change and then capturing those intents of the user through the operations they perform that then allows different users changes to be merged in a sensible way. And I feel like this idea of really changes the abstractions that operating systems should provide because maybe OSs should not just be providing this model of files as a sequence of bytes, but this higher level CRDT like model and how does that impact the entire way how software is developed. I think there’s a potential for just rethinking a lot of the stack that has built up a huge amount of craft over the past decades. And potential to like really simplify and make things more powerful at the same time. 00:55:17 - Speaker 2: Yeah, local first file system to me is kind of the end state, and maybe that’s not quite a file system in the sense of how we think about it today, but a persistence layer that has certainly these concepts baked into it, but I think also just reflects the changing user expectations. People want Google Docs and notion and Figma. And they expect that their email and calendar will seamlessly sync across all their devices and then you have other collaborators in the mix, so your files go from being these pretty static things on the disk, you know, you press command S or ControlS and every once in a while it does a binary dump of your work that you can load later and instead it becomes a continuous stream of changes coming from a lot of different sources. They come from, I’ve got my phone and my computer and Mark’s got his tablet and his phone, and Martin, you’ve got your computer and we’re all contributing to a document and those changes are all streaming together and need to be coalesced and made sense of. And I think that’s the place where, for example, Dropbox, much as I love it, or iCloud, which I think in a lot of ways is a really good direction, but both of those are essentially dead ends, because they just take the classic static binary file and put it on the network, which is good, but it only takes you so far, cause again, people want Google Docs, that’s just the end of it. And that puts every single company that’s going to build an application of this sort. They have to build the kind of infrastructure necessary to do that. And we’ve seen where I think FIMA is the most dramatic example, they just took sketch and ported it to a kind of a real-time collaborative web first environment, and the word just there is carrying a lot of weight. Because in fact, it’s this huge engineering project and they need to raise a bunch of venture capital, but then once you had it, it was so incredibly valuable to have that collaboration, and then, of course, they built far beyond the initial, let’s just do sketch on the web. But any company that wants to do something like that, and increasingly that’s not table stakes from user expectation standpoint, they want to be able to do that, but you have to do that same thing. You’ve gotta drop, you know, tens of millions of dollars on big teams to do that. It seems strange when I think many and most at least productivity applications want something similar to that. So, if that were built into the operating system the same way that a file system is, or, you know, we proposed this idea of like a firebase style thing for local first and CRDTs which could be maybe more developer infrastructure, maybe that’s also what you guys were speaking about. Earlier with kind of like AWBS could run a generic sync service. I don’t know exactly what the interface looks like, it’s more of a developer thing or an end user thing, but basically every single application needs this, and the fact that it is a huge endeavor that costs so much money and requires really top talent to do at all, let alone continue running over time and scale up, just seems like a mismatch with what the world needs and wants right now. 00:58:25 - Speaker 3: Yeah, and now I want to riff on this, Adam, because the strongest version of that vision is
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: Building my own tools, when I type a character in or hit save, I know exactly where the bits are going, and I think that changes the relationship that you have with your software. There’s kind of a power dynamic where if you don’t know what the company that’s providing you some software products is doing with your data, they have the power, whereas if you build your own thing, you understand exactly what’s going on, you’re in control. 00:00:25 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for thought on iPad. This podcast isn’t about Muse product, it’s about Muse the company, the small team behind it. My name is Adam Wiggins. I’m here with Mark McGranaghan. Hey, Adam, joined today by Linus Lee. Hello, hello. And Linus, before the call you were showing me on video chat here, you have a fun new gadget in the audience would like to hear about that one. 00:00:50 - Speaker 1: Yeah, this is always good audio podcast materials when you have to show something off visually, but I semi recently got this thing called the Surface Duo, which is an Android phone from Microsoft, but the Android part’s not super interesting. What’s interesting is it folds out like a book. It’s about the size of a passport, and if you imagine. Passport, but it folds out and there’s screens on both sides of the book, and there’s like a stylus you can use on it and it’s meant to be sort of like a multitasking, multi-screen, note taking on the go productivity kind of phone, and the screen there is continuous, it’s using the folding screen technology is there a scene there. 00:01:24 - Speaker 1: There’s a solid theme there, it’s two separate screens, but it’s like if you imagine like a Nintendo DS from way back when, tilted on side. 00:01:33 - Speaker 2: Or yeah, maybe a shrunk down multi-monitor set up. 00:01:36 - Speaker 1: Yeah, exactly, and it’s great for reading, great for like general kind of content consumption, taking notes, things like that, not so. For like watching videos or like Instagram’s really struggles to fit on that screen because it’s basically square. But yeah, I’ve been enjoying using actually, one of the perks of living in New York, where I live is that all the tech stores are just lined up right down 5th Avenue so I can go visit them when I go running. Microsoft came up with a new one, I think just last week or something like that, and I went down yesterday to visit it and they didn’t quite have it on the shelf yet, but maybe soon, maybe I’ll upgrade. 00:02:08 - Speaker 2: Microsoft’s Surface line has continued to impress me. We did a quite a bit of prototyping on one of the Surface tablets from a few years back, and just in general, what they’ve done there, kind of going into hardware and doing such a good job at it, is really quite impressive for, especially such an established, you know, company which are not known for that kind of innovation or moving into brand new markets and doing a good job. 00:02:32 - Speaker 1: Yeah, definitely, it seems like they sort of see their responsibilities of doing things that are weird. They’re very reluctantly did like a classic laptop form factor. So yeah, I like it. 00:02:42 - Speaker 2: And could you tell the audience a little bit about your background and interests? 00:02:47 - Speaker 1: Yes, so my name is Linus. I say I grew up in Indiana, which is where I spent most of my childhood, before that, I spent the first half of my childhood in Korea, just where my family is from, but I grew up in Indiana, like normal kind of public high school towards the end of that high school experience, I kind of self taught myself how to code JavaScript backbone, react kind of stuff. And then got a little job over the summer at a software startup in the area called Spencer. We did agriculture, precision agricultural software, so basically using some hardware in the field. Indiana is a farming state, so hardware in the field plus some weather data and satellite imagery and other things like that to try to Improve efficiency and ease of producing food for humans or for cattle and and so forth. And so I was there for about that summer and then ended up taking a year off after high school to work there, learning Django and JavaScript and all that good stuff, and that was my first kind of real programming gig. I learned a lot there for about 2 years and then after that, the company itself ended up getting bought, then I had a few extra months to travel and things like that, and then went to UC Berkeley, where I studied computer science for a few years just in California, so went to Silicon Valley, did some other startup stuff, was briefly part of things like relate, which is online IDE. Oh yeah, they’re doing some pretty cool stuff, and a couple other projects, and then recently I moved to New York, just where I am now working at uh another software startup doing sort of tools for thought space things called idea flow, and then all through that time sort of off on the side I’ve also been doing random other. Experiments, building my own various side projects and writing a little bit and things like that, which I’m sure we’ll get more into. 00:04:32 - Speaker 2: Yeah, well, I would think looking over your homepage and your Twitter account and your blog posts that these what you call side projects appear to me like they could easily be a full-time worth of output. So doing that on the side from your regular work as opposed to, I don’t know, a retired gentleman who can spend his full day building interesting tools that certainly speaks impressively to your output or maybe passion for building these tools. 00:04:59 - Speaker 1: Yeah, that’s a misconception that I’ve gotten a couple other times. I think it’s actually interesting to think about, like, having to work a normal job, like not being completely free on your own to follow all your whimsical ideas and having a bit of constraint on not only your time but also like having to use normal note taking tools and having to like use notion and talk to people and slack and things like that I think is a good kind of way to ground yourself. 00:05:25 - Speaker 2: Yeah, we actually see this dichotomy in the we call it the research world, or even in like a classic software company that has maybe like an R&D arm with sort of mad scientists thinking big ivory tower thoughts versus the more kind of production like please our customers, keep our systems running thing and you typically have If you’re too much in the research, free floating, just have big ideas, you’re not constrained by the realities of the market, or customers or anything else, you’re just out of touch, and it’s hard to like, make things that are meaningful. But of course, on the other side of the equation, if you’re really deep in the trenches of doing an atlas holding up the world kind of thing with production systems, and you’re thinking about tomorrow and next week, and you just can’t have big open, out of the box thoughts or, like you said, explore weird whims or unusual directions. So it’s a difficult dichotomy, seems like you’re walking that line though. Yes, yes, definitely. So our topic today is self-made tools, and of course, Linus, your work is a stellar example that I’ll link to some posts here, maybe Moocle is an interesting one here. You have a post explaining your motivation for that, and there’s a few other posts we can reference here, or other folks I know who are really prolific self-made tool makers. But yeah, what does that mean for you? What are self-made tools? Why do you do it? And is it something you recommend others explore, or is it only for a certain kind of person, maybe? 00:06:51 - Speaker 1: Yeah, so the way that I look at my tools is a lot of the software that I rely on to function as a working human day to day are things that I built myself to varying degrees. I have notes apps that I built that I used to keep sort of my personal information in, in general, a little bit. I have obviously things like my website and other kinds of public presence things, but also like a contacts app, CRM. Your typical productivity suite kind of stuff, and then because these are just sort of like things that I imagine and then I go build, there’s also things that sort of don’t exist as general purpose things in the market that I’ve built out, like a personal search engine, which is the monocle that you referenced earlier, where I have all my data sort of shoveled into a search index and then I can search for anything across any of my sort of bank of data from people that I’ve met to conversations that I’ve had to websites that I’ve bookmarked and things like that. So some of them are sort of what you would normally imagine as side projects, so like off the shelf libraries and frameworks and things combined into things that I put on the cloud, and other ones are more involved. Monacle, I think is a good example where the search index that I use for that is one that I built myself. It was originally a project to learn how kind of full text search worked and then that is then written in a programming language that I wrote called Inc and this that kind of goes very deep into that. Yeah, things that I built myself to fix my own problems or solve my own solutions, or solve my own problems, I guess, and really for myself only, nobody else, I mean I guess if you wanted to, you could go to get up and clone those down and deploy yourself, but a vanishingly small number of people do that and so it’s mostly just for me to use. 00:08:29 - Speaker 2: As you sit there and describe, writing your own full text search engine, writing your own programming language, sort of not just the end application, but really going down the stack. I’m reminded of this, it’s basically a meme now, but I think it’s like an excerpt from a movie where there’s a guy that wants to change a light bulb, so then he goes to get the light bulb out of the cabinet, but then it turns out that the cabinet’s got a Loose things that he’s going to get the screwdriver, but then the screwdriver turns out that it’s in the squeaky drawer. And at the end, I think like his wife comes home, what are you doing? He’s like, I’m changing the light bulb, obviously. So it feels like with technology and software systems today, I mean, the stack goes very, very deep. How do you decide when to like stop diving down. I guess another way to put it was, how much is the decision to say, for example, write your own full text search is that a pragmatic decision versus following your curiosity. You want to learn how this works. 00:09:21 - Speaker 1: Yeah, I mean, to the question of when do I stop, it’s really when my curiosity stops being strong enough to get me through learning whatever I have to learn. Back months and months ago when I was more naive, I mean this is all endless yak shaving, right? Like I needed note taking app and then I realized I need a front end library and then I realized I need a language. And there was a point in time when I was sort of made to myself the argument that ultimately this is sort of a more productive way to work because in the end, the little time that I take to build my own tools is gonna kind of come back because it’s sort of so fit to the way that I think and things like that. And I think to some degree that’s still true in that. When I’m really in the flow, I’m more productive with the tools that I built, but I think really the argument that building your own kind of software ecosystem is more productive may be a little flawed, but I think the change of mindset that I’ve had is, I mean, I still do it and so there still has to be a good reason that I do it, and I think for me that reason is that it just changes the relationship that I have to the software that I use. And that if it’s my own tools that I built on top of my own stack, running on it runs on the cloud, I use digital lotion, so I don’t want to control everything, but to a large extent running on sort of things that I understand, I can trust it more. It feels more personal. I mean, I made it sort of handmade it obviously and so. I think it changes the relationship that I have with the software that I use, and the data that I get to keep on it and trust it a little more and makes it feel more little more personal and durable. And so I think that’s the benefit and along the side, I get to kind of learn a lot, right? A lot of my side projects are motivated by just encountering some new piece of technology that I don’t understand, and then I use. Building a kind of prototype clone of whatever I’m trying to learn how something works. I use that as the excuse to build another tool like the search engine or I have like a toy assembler that I made which I don’t need to assemble X86 code very often, so I don’t use that as much, but it was a cool learning project. 00:11:20 - Speaker 2: Yeah, I really like the personalization angle. I think there’s also this element of agency or self-actualization or something like that, that fits into the same theme. You know, we had Wei Wei Xu on the podcast, for example, we talked about the fact that you have this homogenizing effect of now that most technology is made by these absolutely massive companies that are practically nation states, and of course, they’re appealing to the widest possible audience, and that fits into the kind of software. Yeah, basically, the wider an audience you can reach with your software, you know, the more you can become one of these huge empires, but then very much lost in that is not just sort of niche software, but also just things that are weird, different, appealing to a smaller audience, and in a way, the personalization side is, you know, when you’re making something just for yourself or just for yourself in a small group, that’s about as personal as it gets. It’s a nice antithesis or palate cleanser or something from Let’s say the mass produced software that honestly is what rules our lives now. 00:12:23 - Speaker 1: Right, definitely the phenomenon of like every fast website looking like Stripe, but a little bit worse. We were talking about something related right before the show about how there’s sort of two bifurcating kind of classes of software, the one that you just referenced the kind of big company one. is things that are meant to be sort of lines of business, things that companies sell to other companies or other people, and they sort of have a tendency to grow indefinitely, like you build a prototype, you start selling it, people need more things and so kind of grows unboundedly both in terms of like feature setting complexity. Technical debt, but also in terms of just codeba complexity. It’s just easier to add things when you need the product to do newer things and more things, whereas the idea of situated software where you have a very finite group of people you’re building for and a very finite use case you’re building for, which is frequently what I think my tools are, I just needed to do these three things. Take my notes, save them, I want to be able to read them, I want to be able to send it to these places or receive some notes from these places. And I know exactly what I want, maybe I’ll want to add one or two things there, but it’s definitely not going to grow unboundedly. It’s definitely meant for only me or only the small group of people, and I don’t really care if that many people use it. It’s sort of an underrated group of software, but I think there’s places where it’s the right thing. 00:13:41 - Speaker 3: Yeah, and just to riff on this piece a little bit, so I agree with all of the sort of first order reasons we gave around, it can be more fun, you get to learn, you have the potential for it to be more fit for purpose for you personally, but there’s also interesting second order effects with this focusing. So you talked about how the general purpose tools they have all these. Layers that are built up over time, because they need to serve a lot of use cases, right? And with all those layers, even if you have a very focused use case for the software, you’re kind of stuck with those because the layers, they end up coupled with each other and you have all these weird linkages, so you can’t just boot out some piece of it. So for example, if you want to make a very basic static site, well, OK, now you need the static site generator, and now you need a library system, you need a package manager, you need a way to install the package manager. Need a way to check for security vulnerabilities and all the packages, need a web server, you need a place to run the app, it’s the whole thing, right? And even if you have a very basic site, you’re kind of stuck with all that. And so what I like about these very simple projects is you have a possibility to do what I call stack fusion, based on the similar idea from algorithms of stream fusion, which is kind of looking at the whole thing and what you’re actually trying to do and like compacting it down to the minimal possible stack. The example that I like to give is these web pages I’ve done. Where my stock is like, I open up index. HTML type, type, type, save, that’s the website, and that’s a very basic and almost contrived example, right? But it just shows how much stuff you could potentially get rid of if you are able to do this sort of stack fusion. 00:15:11 - Speaker 1: Yeah, I like that a lot. I think one of the questions that I get about, I guess at this point, my personal infrastructure is what you call it, is, for example, authentication, you’ll ask how I do authentication because there’s no kind of authentication related code in any of the open source code that I’ve released. And the reason is because at the app level I don’t do any authentication because all my stuff lives on a single Linux server and I just have one giant authentication layer at the top, um, at the kind of reverse proxy layer and then once any request goes through that layer for anything that needs to be authenticated, I can assume that it’s me and then I have all the permissions that I want and I like the idea of what you call fusion of just if you know. A lot about the environment that you’re deploying on who’s going to be using it and things like that. You can make a lot of assumptions that let you not need a bunch of those abstractions instead of when you kind of collect samples when you need to deploy a search engine, you don’t have to start with I’m going to start up a web crawler, I’m going to start up a database. I statically regenerate my search index every once in a while. It goes into a file, the file is loaded to the browser and then the browser does a search. I don’t need any kind of sophisticated database or ingestion algorithm or anything like that. 00:16:19 - Speaker 3: And this leads to further 3 order benefits because if you successfully do this stack fusion, you have much more ability to understand all the pieces work and you potentially have more durability, because a lot of the complexity is often to support like dynamism and change, which is a direct liability in terms of erosion of the stack. But if you have files on a Linux server, there’s fewer ways that can go wrong then a whole dynamic database is doing authentication and so on. Adam, you might be able to speak to this because I know this was a motivation for you with Broku. 00:16:50 - Speaker 2: Yeah, for sure, and the bit rot or software erosion, the idea that a piece of software that worked at one time doesn’t work anymore even though nothing changed with it, which always seems weird because a software is digital, why should it not work the same every time? And the answer is that the world changes around it. Sometimes in small ways, you have an operating system upgrade, some things were changed and I don’t know how paths are parsed or something like that, but often in big ways, for me, one of the biggest disruptions in my personal tooling was I used to write a lot of things with little Ruby scripts that ran at the command line, that worked great when the only kind of computer I used was what we call a desktop class computer. Once the phone became a huge part of my computing life, now that doesn’t fit in, or the world has changed in a way that those pieces of software don’t fit into it as well as they once did. But one of my motivations at Hiroku, yeah, for sure was I felt like hobby projects and interesting side projects, and even at a company, what you might call, yeah, we should talk more about the situated software label, but you often have this case where I did this at companies I worked for companies I consulted for, and you also see it often as spreadsheets or filemerro things, or whatever, but sometimes also web apps, would be something where one person would build a custom tool for just that team, whether it’s 5 people or 10 people or 20 people, and they would set it up and it would be running over time. As a web app, so often it would stop working database goes down, server needs a reboot, the file system is full, because the log rotation thing wasn’t set properly. And so one of the things we strive for with Roy was to make these more explicit contracts with the underlying system, so that you could more easily upgrade things and have the platform do a lot more of that maintenance kind of automatically, and then hopefully the app could keep running over the long term. I think there’s no perfect way to ever do that. I think we did make some good strides there in terms of reducing the likelihood of that software erosion. I’ll link out to the article we did about that. 00:18:51 - Speaker 1: Yeah, I want to also dig a little more into the kind of dynamism, ease of making changes thing because I think there’s actually two ways to look at the ease of making changes when you solve a problem with software. One way is to make the software sufficiently sophisticated, so that you can swap any arbitrary part out and you can keep making changes. The other is to make the software so simple that it’s easy to rewrite, and you can just rewrite it when the constraints change. Yeah. And the way you do that is you make your data layer more portable, use a lot of my data is stored in. New line to JSON, just lines of JSON packed into a single file or text files are marked on files or something like that where like basically any tool that I pull in is going to be able to talk to it or if I really need to structure something like SQL, you know, you can plug that into basically any language and it makes things like backup really easy because you just copy the file. And things like flat dependency trees. So if you don’t depend on a lot of things, it’s easy to rebuild things and you make sure that the earth doesn’t shift under you quite as much. If you write relatively small things that do one or two jobs only, then if the constraints change a little bit, maybe you can just modify the software a little bit, but if the world changes a lot, it’s not the end of the world and you can scrap it and rewrite it or something like that. I try not to rewrite things too much. I try to make most of my things last a while, but I’ve rewritten some of the older pieces of the things I’ve been using the note tap and things like that, which I wrote at this 0.56 years ago. I’ve rewritten those a couple times just because the world changed and some of the packages that I used to use aged out and so it didn’t take too long. 00:20:26 - Speaker 2: Yeah, some other stuff on the durability that I think we talked about a bit before. I know, Mark, you were maybe one of the ones who opened my eyes to the value of the go and static linking, so the sort of dynamically linked libraries, whether it’s DLLs on Windows or the dotSO files on Linux. You think of it as being sort of a necessity for modern software, but go just as screw all that, it’s too complicated, it’s likely to break, now you’re like tying things together, let’s just package it all together and, you know, computers are fast and we have storage, so it’s fine. 00:20:57 - Speaker 3: Yeah, exactly, I like that aesthetic. 00:21:00 - Speaker 1: Yeah, I like go and some kind of philosophies and the tools that I used for the same reason where it’s as someone who maintains a few dozen different things that are sort of concurrently running online, it’s very difficult to think about doing that while running on an ecosystem like node. I love node, JavaScript fee, it’s great, but one of the faults it has is like every project has a million dependencies and by the time you’re done with the next project, the old projects so about a date. And so it’s difficult to think about operating in the style of like many, many different small projects with an ecosystem like that, whereas with Go or, you know, one of the benefits of writing your own language is that the language only makes breaking changes when you decide to make breaking changes on your own terms and so using languages that prioritize long term durability of software I think helps a lot and things like static thinking, I think is a reflection of that value. 00:21:49 - Speaker 3: Yeah. And by the way, this Go discussion reminds me of a generalization of the personally built software question, which is, if you are a company or organization, should you use something off the shelf or should you build it yourself? I don’t think we want to go into that whole discussion, but I’ll just know that there are a lot of echoes in that analysis and that calculus between an individual and Corporate. And I was thinking about with Go because in the same way that people will often tell you, you should always just use a library off the shelf. I’m sure at one point everyone said, why would you ever write a programming language? Well, it turns out it was the correct thing to do. It does important things that no language had correctly brought altogether. And so I think there’s a similar dynamic playing out with personal software and with corporate choice to use libraries versus build. 00:22:34 - Speaker 1: Definitely one thing that you touched on there is the idea of like leverage and building your own tools, the various levels in the stack where at some level of like operational scale or software development scale, if in your own programming language makes sense because it gives a greater leverage over the things that make your shop easy or hard, yeah, and I think. That doesn’t just apply at the programming language level, it also applies to your life at the tool level. So, let’s say like a lot of your work is about remembering people and keeping relationships with people, maybe designing your own CRM or context app gives you that extra leverage, or maybe if your job is about taking a lot of notes and learning a lot, building notes app for yourself actually does give you that leverage and so. There’s a whole thing with not a hair syndrome which we don’t have to get into, but I think that’s one way to think about it is in the long term will it pay off for me to have this sort of deep understanding and control over what I use and depend on, yeah. 00:23:23 - Speaker 3: I do also think there’s another side to this, which is our now of the calculus has been very focused on the I, you know, the durability, the flexibility, the understandability, and that’s all important that goes into the calculus. But I also think there’s an artistic element of sometimes to make a statement about how you think the world should work, the only way to do it is you just Do it all yourself top to bottom. And I do think that comes through sometimes with these personal software projects and even some of these libraries and other software endeavors that initially seemed like a weird thing to try to go out and do. But ultimately, you see that not only are they providing ilities, but they end up making a statement about the world, which I think is cool. And I think people underestimate how important that is. 00:24:02 - Speaker 1: Yes, definitely, that reminds me of one of my favorite others sort of self-made software people is this couple of people called 100 Rabbits. I don’t know if you’ve come across them, but, oh yeah, yeah, they have a little boat, I think called the Pino, and they sail down from Vancouver down to Australia up to Japan, and they’re just open source hackers. On a boat and they also have their own sort of homebrew software stack basically from the like language virtual machine up for various things, a lot of C99 old school software things, things that don’t break things that don’t consume a lot of energy, certainly no electron apps. I think actually they’ve publicly said that running instances of Chrome is untenable for them because they only have a limited amount of energy from those solar powered things on their bone and they have to be really efficient with it. But I think that’s a great example of building your own tools or building your own software stack, not purely for the utility that it provides in your life, but as a demonstration of this is possible, or these are the values that I believe in, which I think is, as you said, also important. 00:25:04 - Speaker 2: Uh, the one that comes to mind for me on that, and these are publicly available, but a fellow named Jordan Singer has little apps. It’s just a calculator, a draw tool, browser, and these are all things that come by default on modern smartphones or whatever, but he has a particular aesthetic and a particular just kind of minimalist. Just does the littlest thing possible, hence little, and yeah, it just has a particular style to express. It’s not that those tools provide utility you can’t get elsewhere, it’s more like they express something about how their creator sees the world. 00:25:37 - Speaker 1: Speaking of little, one of the nice things about building your own thing is computers are very fast these days. I don’t think most people realize how fast computers are these days, and the reason that software is slow is because it turns out we write a lot of code and we make computers execute a lot of code. A modern desktop computer can run 2 to 4 billion instructions per second on a single core, and if you’re slack or if you’re whatever app takes up a second to start up, what is it doing with all those billing instructions? Like you just have to show a rectangle on the screen. It’s wild. And fortunately if you write your own thing, there’s only so many lines of code that I can pack into my little project as a single person hacking on it over a weekend, and so. By virtue of that and very little else, all my things are really fast, like my notes have loads faster than it takes for notion to start showing its spinner to load the rest of the page, and those things about building little things are also nice things like performance and sort of consistent design aesthetics and things like that you get for free. 00:26:39 - Speaker 2: Now, we’ve talked about these are sort of personal tools, personalization, you’re building for yourself, sort of your target audience of one, and that person is the same person making it. And that also makes me think of a fellow I’ve worked with closely named Simon Kalinsky, who does a lot of personal tracking tools and things like that. He’s also a musician, and he makes a lot of music tools. I’ll link out to his portfolio, so he’s maybe in the same category as you in terms of making for himself, and that’s it. Most of the time. But then you have something like, in a lot of my experiences with this more like situated software is often creating for a small group. It’s either a group of friends, or family, can also be obviously very much in the corporate, call it enterprise environments, you know, just a small team that has a need, and I’m thinking there of Robin Sloan’s concept of home cooked. An app can be like a home cooked meal. He’s got a little kind of messaging app for his family that he wrote about, I’ll like that in the show notes as well. So how often do you find either of you are writing when you’re doing this sort of work? Are you writing for just yourself versus a very small group? 00:27:45 - Speaker 1: Yeah, that’s an interesting question. I think in my experience, most of the things that I end up building are for just myself. Almost all my work is online just because, you know, there’s no reason to keep it to myself if other people want to look at it, yeah, and you can look at it and I like writing a little. and things like that. 00:28:02 - Speaker 2: Well, out of curiosity, what happens in that case when someone submits a bug report, a pull request, a feature request, you say, no, you got the wrong idea. This is for me, not you. 00:28:12 - Speaker 1: Or yeah, I mean, sometimes it depends. A good example is my programming language. A lot of the reasons that I have it is, well, it’s not at all because I have this grand vision of like, I think this is how programming should work and these are the features that it shouldn’t it’s just, I did a university project once where I built like a Lip interpreter, which I think is like a common college project and I was like, oh this is cool. Maybe I should be able to build a whole language like this, and I can decide what all The keywords are, and that will be the thing or instead of saying function, because I like to keep it short. And so it’s a reflection of just my tastes for those things, if other people want to come in and kind of speak their opinions, I say things for your opinions, but this is my language you can fork it and I’ll help you fork and understand the code base, but for my thing, I want to keep it to my tastes and it’s totally fine. But for some other things, for example, I have a little Twitter client that I use, like a Twitter reader that just talks to the Twitter API but gives me my own kind of chronological timeline and a few other kind of search niceties and for things like that, other people have come along and they’ve contributed things like a Docker file for people to more easily clone it and use it on their own setting and things like that. And sometimes, actually the. Twitter thing is really interesting because it’s designed to be sort of in one very specific way and user customizable, which is that you can add these tabs that correspond to searches instead of just having your own timeline, your home timeline is just one of the many tweet deck style, one of the many tabs that you can have open and you can have another tab that’s like people talking about tools for thought or you can have another tab that’s like Taylor Swift content or whatever because I’m a big fan. And maybe that means that other people don’t have to contribute patches or get put in pull requests because it’s like end user programmable, throwing a buzzword there, but it’s end user programmable and so in that way maybe people don’t have to modify the software itself for the thing to suit their needs. But yeah, pull requests come in if it doesn’t really change the way that I use it, I’m open to it a lot of times because it is an improvement, but if it impacts the way that I use it, then, you know. Yeah, I built it for myself, and so you can fork it, fork it, yeah. 00:30:20 - Speaker 1: Build your own version that matches your own taste, yeah, definitely, and I’m actually a huge fan of that. You can fork it and the winner will get the masses kind of approach to open source. 00:30:28 - Speaker 3: And I think by the way, that aligns well with having artistic goals because in that world, the actual code repository is not so much the output as the instigation that you’ve admitted into the world. This I think was a success of go by example, where I don’t think anyone has used the actual code base, but people have used the X by example idea and layout a lot and that’s propagated, which is great. 00:30:52 - Speaker 1: Certainly, I think this is true of Monaco as well the search engine thing where just building that, I think it’s one of those ideas where you tweet it out and then the thread is a bunch of people who are like I’ve been thinking about building a personal searching for and for the last 5 years and why haven’t you done it? It’s because there isn’t that instigator. To say this is doable and these are the ways that you could do it. And one of the pure joy moments of building my own tools and then putting it out in the world like this is seeing other people take those ideas and either take the codebase or just take the idea and go and build their own tools because it’s really lovely to see against the kind of tsunami of these like corporate mass market tools, these little small islands of personal tools that are reflections of the maker’s values and tastes kind of come into play. 00:31:38 - Speaker 3: Yeah, I think as an empirical observation, there’s a very big step function and like difficulty and effort when you go from one person to end users, especially in our classic SAS model of client server where the server is multi-tenanted. There’s all kinds of complications. You have two code base, you have multi-tenancy, you have security, you have upgrades, you have different versions across the client, the server. It’s a whole idea. So I think in practice that stops a lot of people and and equals one, they say, you know, just basically go fork it and do whatever you want. I do think there’s a world where this step function is decreased a lot, and this goes back to our discussion of local first software. If you can have something more like spreadsheets where you can just send someone one file, and that’s basically all they need to be able to participate in this home cooked meal, I think it could be much more successful. In fact, we see this with spreadsheets often there’s groups of friends or groups of colleagues at a company where they’re sort of sending around or linking around or forking a spreadsheet and it sort of spreads as a meme within a company. I could see the same thing with local for software if you didn’t need a server and if all the data was either stored directly on the clients or you could bring your own server and so the originator of the software didn’t need to worry about multi-tenant hosting your data. 00:32:49 - Speaker 2: Yeah, the authentication, the identity generally, of course, is just kind of this huge unsolved problem. Throw in the multi-tenancy, you throw in the Partitioning by users, even if you leave out the security thing, assume that all your users are, yeah, friends or family members are in the same company or something like that. It just quickly gets very, very complicated compared to the, maybe the world of software that I sort of grew up in, which is something where when you write a program, maybe it saves data persists data to disk by writing a file, which is incredibly simple, as you said earlier, there, like, you can copy it, you can delete it, you have a lot of agency over it without needing to build that into the tool, the app. And yeah, the concept of user just doesn’t really exist or it’s implicit in, for example, your local Unix user or something like that. The permissions are all handled by the operating system, the location and the file system is handled by the operating system. You just write the program, and all the rest can go around it. That’s kind of not where we’re at. In a way, modern operating systems, whether they be on the desktop or mobile, do way, way more, or even the web has way more APIs, way more capabilities, accessing hardware, all these different things you can do, but in a way, some of these simpler things like Just knowing who the user is, you could do that in a Unix program. There’s a who am I, you know, function, and you can kind of inherit that from the operating system or file permissions you can inherit from the operating system. Basically, every app is reimplementing all of that from scratch in the modern world. 00:34:21 - Speaker 3: Now that we’re talking about it, I have another example. So longtime listeners of the podcast will know that there’s often two examples we drawn. One is spreadsheets and one is games as areas that have in many ways at the frontier of computing. So now I’m thinking about sort of situated or home cooked software in a context of games. And there I do think you see it with the like scripting and modeling community. So you have these games where there’s an existing infrastructure for players and accounts and identities and server hosting and everything, and People can contribute their own programs in the form of different skins or different map scripts. And that is very successful. So again, you just need to basically put your code, if you will, out there. People can share it around and copy it around and link it around, and that’s all you need. You don’t need to run your own map hosting server or whatever. That’s been very successful. It makes me think even more that if you could have a similar substrate in the world of personal knowledge management or more traditional SAS apps, you could see the same success. 00:35:17 - Speaker 1: Yeah, definitely, I think, Mark, what you’ve been talking about sort of made me go on a train of thought about software packaging, because a lot of this is about how do you take something that works on my computer and make it so that other people can just take it and run it and it works the same on their computer and In a similar way to what we’re kind of talking about, I think the advent of GitHub as the de facto way that people share code, I think is kind of one of those step function changes right about, yeah, instead of sending me a zip archive or sending me patches, you can just send me a link and then I can download it and include and oftentimes there’s instructions in the repo of how to run it and presumably there’s more that we can go. Down that road about instead of having to copy a whole bunch of files down and then set all these things up and things like deploy AWBS with all the scripts and stuff, maybe you can just give me a file and I can run it and it’ll just work. And I think that, yeah, there’s a lot that we can still improve on on the packaging side, I think, for just being able to share sort of single user single instance piece of software. 00:36:11 - Speaker 2: Yeah. In a way I’m nostalgic for the Windows era of download an EXC. And run it, and I know why in the world of malware and so on, that maybe doesn’t work anymore, but there was something quite simple and elegant about it, and because Microsoft did work so hard at kind of keeping backwards compatibility in the operating system, you typically knew that, yeah, someone wrote compiled an EXC 10 years ago, and you could still run it on a Windows computer today. And the closest thing we have to that now, or the best thing I would say, is the web, where typing a URL into your URL bar is essentially downloading and running a program on the fly in a safe sandbox, which is frankly, a miracle when I start to think about how that works, but it has these limitations of things you can’t do, it’s not personal. If you want to do anything with, you know, it’s gonna have some kind of persistence that really needs to have a back end, and now you’re into this whole crazy world of different tools, and you need to know 5 different programming languages, just to make the most basic thing, you know, shared to do list or something work, and yeah, a world of local first apps or something where you could download a piece of software, expect to run, have it be in a security sandbox so it’s safe, but not necessarily to go through some kind of Gatekeeping review system, and then be able to do persistence and other things that you would do in the local environment, or even add in some of the collaboration side of things. I would be very disappointed if we don’t end up in a world there sometime in the coming years, but I also don’t know the path that gets us from there because the companies with the most resources and software engineers to throw at the problem, are pretty motivated to keep their walled gardens and keep you logging into their system and keep you on their servers rather than empower local, more powerful local apps. 00:38:04 - Speaker 1: Speaking of being able to download an EXC and run it through, I think there is momentum in that direction. I think one example that has been quite a big source of inspiration as I work on my own program language kind of tooling and ecosystem is Dano. Do you know? There’s no JS and then Dano is sort of the typescript run time, I think is the way they talk about it, but it’s all of the same underlying technology as node, but it runs. Sort of TypeScript natively has built in Tyscript compiler and some other nice things in the language and that’s all fine, but the really interesting thing is Dano inherits kind of big focus on developer experience and toling quality from other languages like go and rust and so I think in the kind of intervening 15 years, they’ve learned a lot about how to distribute andacket software, like, a lot of the big focus of Noja was just like, let’s get a synchronous eventsa. Yeah, it’s really good. Like they got that, but everything else is kind of a mess. And then you know, I think a lot of the right choices have been made for kind of software your ability. So you can do things like deno compile, which gets you an executable binary, so you can write things with typescript and build it with Deno and package it up so that I can give you an EXE and you can run it on any Linux thing, right? And I think things like that sort of being built into the language tool chain are pushing us. I think in the right direction. The other thing that Dano does that’s really interesting is instead of having a package registry, the packages that you can import are just kind of URLs and so you say import X from this URL string and it’ll download and cache that thing at that URL, but then there’s no intermediator that has to be up all the time or that has to be correct all the time, you’re just downloading things from the web, which I think is about as futureproof as you could get. 00:39:39 - Speaker 2: Yeah, another interesting thing about Teno, and that’s a smaller point, but I think it’s an important one, which is this sandboxing thing is so important for making it possible to, I can give my friend a piece of software that I’ve written, and they can just run it, and we don’t need to go through some onerous review process, but we obviously also need to protect from the now huge world of malware, and so sandboxing, and good sandboxing is a potential technical solution to at least some elements of that. And the browser obviously does an incredible job at that, but if you want to run a command line program, no, the demo actually does a lot of that, where by default, any demo program you run at the command line has no permissions essentially to the core operating system, but you can pass. It switches to say, I wanted to be able to, for example, make an outbound HTTP request to this host, or I want to give it full network access or something like that. So you have a lot of that kind of control that I associate with, for example, cueSOS. So that sandboxing gives you a lot of control over the individual programs, how they’re accessing the network or the file system, that sort of thing, while at the same time just giving you the incredible simplicity, which I still love that you had from Ruby and Python, and of course, Go and Rust nowadays, and leading back to the C days, which is, you just have the file and you type, run this file at the command line or you double click it, or whatever it is. The thing just runs, and you compare that to, you know, what it takes to sort of run a web app, particularly a database back web app, that’s just incredible simplicity that I think can do the job in a lot of cases, especially for these kind of self-made or situated apps. 00:41:15 - Speaker 1: Yeah, actually, one thing that people say around software packaging is that the modern analog of the EXC is like the Docker container, and I think sort of aspirationally that’s in the right direction where instead of having a single battery that you can run a Docker is sort of the representation of a thing that you can put in a machine and it’ll run and if you need an entire system set up then you can have. Whatever confirmation YAL or whatever, you can just throw it to a cloud provider and it’ll spin up the whole thing. And I think that’s aspirational in the right direction, like that’s where we want to get to and I think if the dreams are fulfilled, that’s that’s a really interesting world where you can, you know, give your friend a confirmation YAL and they’ll just spin up their own little thing. But in practice, just quality of experience wise, it’s much easier to execute an EC than to throw it up on a web service. Maybe there’s a gap that we can fill there. But yeah, it’s interesting to think about sort of in this world of having a backend service and databases and then users and things like that in a web app, what that equivalent to executing the binary experience looks like. 00:42:16 - Speaker 2: I think in my ideal world you would somehow put together, I guess the client side version of the Docker cubeSOS virtualization sandbox thing would be, imagine a launch an application launch screen that’s like the iPad home screen. Basically, I could drop a Docker file essentially on there and become an app icon, and when I tap the app icon, it fetches whatever it needs to fetch to run it, spins up a virtual machine and runs it, and gives it to the computer full screen until I exit. Something like that that just makes it very, very easy, in fact, standard, totally standardized to just spin it a virtual machine and run it. And maybe there’s a server side. version of that as well and certainly some I think platform services have attempted this, certainly some we have services have stats at this, something where you really do just have maybe Hiokku, the Hioku button was the equivalent of that drop a little link onto your GitHub read me and you click this button and it kind of spins you up a virtual instance of whatever this application is. So we’ve had some good stabs at it to try to at least package up the complexity, if not remove it or simplify it. We haven’t quite maybe got that perfect. There’s still no .exe equivalent basically. Yeah. 00:43:27 - Speaker 3: Yeah, and I think there’s a couple of things missing here. I think on the one hand, there’s additional platform primitives that are needed for things like identity and data if you’re really gonna do this without having your whole full blown client server thing, which is necessarily a lot of hassle. But also these things like Docker and virtualization and so forth, they are sort of the opposite of Stack fusion. It’s like we’re gonna run any stack you want, you know, any language, you know, 10,000 files in your node modules or whatever, you know, go for it. And that’s awesome because it gives you a way to better manage all its existing complexity that’s out in the world. A lot people needn’t want that, but it might be that if You want a really nice double click experience that you need to do a bunch of stack fusion and say, OK, these are the APIs. They’re much, much narrower than all our stuff. Maybe it’s only one programming language. Maybe you don’t have your full suite of wild just calls or whatever. Maybe you can’t contact any address in the network, you know, you figure out what’s a very narrow interface, but by accepting that narrowness, accepting that fusion, you can give a much more powerful experience to the Home Cook app developer. 00:44:26 - Speaker 1: Yeah, one thing that’s come to mind is we have this conversation is the metaphor of the app as a thing that you can hold and move around as opposed to a thing that you install on a system. I used to be a Windows user and then these days I kind of use Mac and Linux and one of the really interesting things with the Macs, like, not the underlying software model of applications installed the system, but just the end user model of how the Mac works with applications is that there’s like a dot app file. And there’s like the safari. app and that’s the safari app and if you want to get rid of it, you just take that file and you move it to the trash. And if you want to open it, you just open it, you can move it to a different part of the folder or something like that, compared to in Windows, for example, where you have an installer. 00:45:09 - Speaker 1: I mean you can have an EXC too, but and it’s just spraying files everywhere like messes with the registry and like put some weird stuff in weird places that can do a bunch of stuff to your computer and yeah, I’m just realizing how clean and that’s just so much more and user friendly the Mac model is of here’s a thing you can click on it to run it and it’ll do the thing that you expect and if you don’t like it, you can get rid of it as opposed to like, it’s now fused with the operating system, you can never remove it completely. 00:45:32 - Speaker 2: And I do think that, you know, mobile operating systems do that even better, and they even package the data with it, so it sort of all goes together. When I delete it, it’s deleted, that’s it, it’s gone. Now, of course, mobile restricts you and limits you in so many other ways. That basic idea of, first of all, the user’s mental model, I think of, OK, an application, I’ve installed it, or I have it now, and it’s a tile on my home screen until I decide I don’t want it anymore, and then I press it and tap delete and the tile goes away, and there’s this 1 to 1 association between the icon that lives in a particular place in this mildly spatial interface. The application code and data, and then I can basically manipulate it as one unit. And that’s where I certainly feel like there’s a very big lost opportunity for end user programming system customizability, whatever, particularly on the iPad, where I guess you can make shortcuts and stuff like that, but again, because of the review process, because of the heavyweight tooling doesn’t even run on that same platform. The idea of, yeah, you know, I’d love everyone to do a little apps style thing on their iPad, you know, they’re making it themselves in place, and they type up their little program and they turn it into a tile that’s on their home screen, and data gets stored there, and if they wanna send it to someone else, they can, if they wanna move it to another device, they can, if they want to delete it, they can. I think there’s something very powerful about the simplicity of that model, but then we haven’t quite connected that together with the more programmability side of the equation. 00:47:03 - Speaker 1: Right? I mean, it goes back to what Mark was saying about to have that quality of experience of stack fusion, you need some constraints, and I guess I’s platform is providing some of those constraints so that you can have that simplicity, just better API contracts for the era. Another example more on the website that comes to mind is Relate. Which I’m a little biased because I worked there for a little bit, but one of the things that you can do with a rep, a repel is a running environment, right? It’s like code plus an execution environment, and you can click a button and the software and it’s not perfect. There’s some bit rod for like old things won’t run because like some MPM package has gone out of date or something, but by and large, the promise of it is a repel is like that, that packaged up thing. With all the configuration, there’s a little database that you can talk to inside of Apple and things like that, and you hit run, and if you see someone else that has the thing that you want to run, you can fork it, put it into your own account, and then you can hit run and now you have your own running instance. And maybe the right solution kind of looks like that where you just abstract the whole thing, even at a higher level than like a docker container or a Docker file and you just say, here’s an environment plus some code, and you can look inside if you want, but really it’s just a click run and it runs kind of experience. 00:48:15 - Speaker 2: Yeah, definitely put Repole in the same continuum of, I don’t know if they think of themselves as a kind of platform of service or serverless kind of environment, but I think it is in the same continuum with Roku, for example, and the idea of, yeah, wrapping it all up and then putting it on the web, which there’s pros and cons to essentially running it on someone else’s computer, but certainly for the use case of learning and getting started, I think that’s sort of a no-brainer, and of course over time that is becoming more and more. Powerful. Yeah, that also makes me think of Code pen, which obviously is a much simpler use case because it’s just some CSS and JavaScript, it’s all client side, etc. but it has a lot of that vibe and it creates a lot of that sharing dynamic, which is you search on there for, you know, find me a pen for, I don’t know, doing parallax scrolling with a whatever, whatever, you find a couple of good examples, you find the one you want, you fork it, you make some changes. Maybe that has a little bit of some of the same vibe of the skinning modding gaming community you talked about earlier there, Mark. 00:49:13 - Speaker 1: Yeah, exactly. And then once you have something like replic containers or environments that you can spin up and sort of give to people, then it’s really interesting to think about, well, what does an app store that’s built on that model look like, where instead of downloading things to your machine and running it there, you have sort of web software. Where there’s like a ret store or whatever and instead of downloading a to do app you hit run and it clones that thing to your account and then it spins up a little bit of backing code and a little bit of client code and you have your own web app but it’s running just with your account and just with your data and you can look at your data and you own all of that. Stuff until you have the cloud provider, but that I think is also really interesting to think about where you have sort of single user web apps and a way to distribute them, and then you can get people to have their little cloud environment with their little web apps, instead of having your own computer, you just have your own little cloud garden of things. That sounds amazing. The last interesting thing that I wanted to touch on was the idea of transparency in the transparency down the stack and down your tool. One thing that I found that’s really kind of gratifying is my own tools, especially not just at the top but down to the language layer, is just being able to understand what’s happening. I think if you use a tool like notion, which I think is great, but it’s very opaque. I type something in and it shows up on screen and I load that same page up on a different computer and it shows up on screen, but I have no idea how they’re saving it, how they’re transforming it, where it’s going, who owns it, whether it’s in another continent, and that’s nice in one way that it’s packaged and kind of hidden away, but building my own tools, I think an interesting benefit has been when I type a character in or hit save, I know exactly where the bits are going. I know almost down to the CPU instruction, what’s happening with that data. And I think that going back to the first thing that I mentioned, it changes the relationship that you have with your software where it’s there’s kind of a power dynamic where if you don’t know what the company that’s providing you some software products is doing with your data, or what’s happening behind the scenes, they kind of have the power and you’re paying them so they let you use the thing, whereas if you build your own thing, you understand exactly what’s going on that you’re in control and you can understand. Even just the concept of like, the things that you use to run your day to day life, you have the power to understand fully, I think is kind of a radical idea. 00:51:29 - Speaker 2: It comes back to this agency and this sense of, yeah, as we live in a world where there’s more and more complexity to the technology and it becomes indistinguishable from magic, and that’s good in the sense that magic is great and powers more and more things in our lives, but then it’s bad in the sense that we lose that understanding of it that actually is important in the long run. I feel there may have been a, it’s a Star Trek The Next Generation episode where they encounter, and if there were some humans or an alien race, I can’t remember where, kind of they had forgotten how to service the technology or how it worked, you know, in generations past, because it works so well and it’s kind of self-maintaining and that sort of thing, but then the whole civilization was in a state of Not decay, but let’s call it stasis or mild decay as a result of this, I kind of explored philosophically that concept which that shows was very good at doing. 00:52:25 - Speaker 1: Yeah, maybe maybe we’re not so far away from that kind of thing where there’s another exec CD of like, you know, all of modern software depends on this one little piece that’s maintained by some lonesome developer in the middle of nowhere Arkansas or something. Yeah, these things are hugely complex and there’s a lot of parts that are sort of under service. My favorite variation of that joke is in the tools without space. One of the table stakes thing that you have to build when you build like a note taking or knowledge management app is you need a good rich text editing experience to be able to do things like bullet lists and things like that and basically. Everybody that I know uses this library called Prosemir, which is amazing and excellent and really well designed, and also quite complex just conceptually, and it’s just this one dude, Maran working on the library, and he’s like holding up an entire kind of burgeoning venture backed industry, which is sort of frightening and interesting to think about. 00:53:18 - Speaker 2: was a place to end. I thought it’d be interesting to talk about software as kind of an ever evolving thing versus something that you finish. We talked about this in the filmmaking podcast with Max Bacht where he basically said films, you finish it, it’s printed, that’s it, it’s done. You don’t get. iterate on it, any feedback you get and you think, oh man, I should have done that differently. Too bad, you know, if it’s a TV series, you could incorporated the next season or whatever. And I’ve also tweeted about kind of this is part of why the subscription model actually does make sense for software is that it’s sort of never done. The tweet that I quoted there was the curl maintainer speaking a little bit about the 23 years he spent working on that piece of software, and it’s still very active, new featu
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: One of the characters is a poet that evokes much emotion with his work, and one of his fans asks, how do you do it? How do you come up with these words that are so moving? And he says, well, the key is the poet has to speak the words that are already in the person’s heart. Hello and welcome to Meta Muse. Muse is a tool for thought on iPad. This podcast isn’t about Muse the product, it’s about Muse the company and the small team behind it. I’m Adam Wiggins here today with my colleague, Leonard Sursky. Hi. And Leonard, it’s one of my favorite times of year now that I live in a place with seasons. When the leaves turn orange and red and fall off the trees, kind of have that smell of the, I guess it’s the decaying leaves in the air, little bit of a chill, but it’s not too cold yet, Halloween and pumpkin carving. How are you enjoying your fall so far? 00:00:55 - Speaker 2: Yeah, I love it. It’s my favorite season, I think, especially since we both live in a city in Berlin which has a lot of parks and a lot of forest area. It’s just really great to be able to go into a forest and enjoy a long walk in that atmosphere. 00:01:09 - Speaker 1: My dog loves it as well. Basically, the leaves on the ground all over the place, I think, give like plenty of stuff to kind of sniff through, so it makes dog walks more interesting as well. 00:01:19 - Speaker 2: Even for humans, I feel like the smells in the autumn are more exciting than in the summer. 00:01:24 - Speaker 1: Absolutely, yeah. Well, I’ve got exciting news. The Muse team is growing. I’ll link to our jobs page here. We actually have two positions now. Longtime listeners of the podcast might remember we talked about our partnership model all the way back in episode 4. That’s when we were hiring the 5th member of our team who ended up being Adam Wulf. That was a good year and a half ago, I think. And it’s certainly nice, the stability, I think, team dynamic compared to the kind of fast hiring growth startup environment that I was previously used to where you just always have new people coming in, you’re constantly on boarding, group dynamics are constantly changing. We’ve had this really stable group for a while, which is nice in a lot of ways, but also it’s really exciting to think of new perspectives and just fresh faces coming in to to join us. And I guess growing from 5 to 6 or 5 to 7 isn’t such a huge jump, but also it’s a pretty big change for us, I think. 00:02:17 - Speaker 2: Yeah, it’s a really exciting moment for the company. So we’re hiring for two positions. One is a local first engineer and one is actually a design slash storytelling position, and that’s what we want to talk about today. 00:02:30 - Speaker 1: Yeah, that’s right. It felt like something really worth digging in on that we landed in this kind of maybe slightly unusual job description. Well, I suppose local first engineer is also unique in its own right, but The designer and storyteller versus other ways we could have titled this role led me to really reflect on like what is storytelling and why do we want to call it this for a marketing role or just a designer or brand designer or something like that, and how does Muse tell its story today? And what do we think of the unique qualities of a person like this that could join our team and That’s kind of the whole deal with this podcast, right, as we take a relatively straightforward thing like a job listing and then go very philosophical. So, maybe we start there. Our topic is storytelling, so, Leonard, for you, what does that word mean? 00:03:19 - Speaker 2: Yeah, I think it’s been an interesting process to figure that out internally for us as well. You and I have been kind of filling that role as the storyteller from MS and doing all the marketing and the design on the marketing side for that. And on one hand, we have had really great success. I think with telling our story, I think that’s kind of what we have to do for Muse, since we are a small company and we don’t have that much budget basically to spend on advertising and stuff like that. So we kind of have to tell our story and share our ideas. And the good thing is for us, for us, we have a lot to say. We have built the product based on research that you’ve done at I can Switch for many years. And so there’s actually a story to tell here and we just need to be able to really tell that story well. 00:04:04 - Speaker 1: Yeah, I think there’s a couple of different layers of it telling our story as a team, telling the story of the product, telling the story of how people think and how technology has helped or hindered that over time. There’s many different dimensions here, but I think it’s pretty important, the software by itself without the explanatory elements would be at a minimum hard to understand and possibly worse, just easy to dismiss if you don’t have that kind of backstory in context. And so I found myself just kind of researching this fundamental question, what actually is storytelling and of course, I think we all sort of know that stories are fundamental to how humans understand the world. That’s how we, for example, share culture or instill moral lessons, how we bond with each other, entertain, obviously, and everything from religious and mythological texts, the Bible or fast forward to Something like modern day superhero movies, those are sort of our modern myths and those stories are ways that we not just are entertained, but yeah, we kind of understand the world and what we as society value or don’t value. You can even look at something a little less that’s sort of like a fictional story and something more directly explanatory. I think like TED Talks, for example, you can make fun of the format and people do, and maybe they’re sort of annoying sometimes, but in a way, I think they have been so successful and so far reaching because they’ve found. a format that on one hand is addressing big meaty questions about how we improve the world, but they also have kind of a gather around the campfire vibe. Let me tell you a story that will enlighten and entertain, but also instill a lesson or at least some enlightenment. So I think once you start thinking about this, you sort of see it everywhere. 00:05:50 - Speaker 2: Yeah, I think TED Talks are a great example of a format that’s made for storytelling or like built around storytelling. Yeah, I think the most popular TED Talks are all just really, really great stories and it becomes less about the point that’s being made or that’s something you could also get elsewhere and less time if you want to, basically. But the reason they’re also so popular is because the story is so well told. And that to me points to the interesting thing about storytelling, which is that it’s really independent of the specific medium that we’re talking about. And I think that’s why it’s so difficult or so unusual to have an actual storytelling job, because most people see themselves more as craftspeople for one specific medium, right? Like maybe a, like a video person or you have a writer, or you have someone that makes music that is a great public speaker. But all of these sort of have the underlying element of storytelling and you kind of need to be great at at storytelling in order to be a great artist in your specific medium. 00:06:49 - Speaker 1: Or in some cases it may even just be a CEO or a leader or an entrepreneur or product person. So Steve Jobs comes to mind as probably one of the greatest storytellers, certainly in the tech industry, but also of our age. Now, folks like to point to that original introduction of the iPhone video, but also many others of his, even here now, more than a decade after his death, we’re still sharing. Videos and other clips that show him, in some cases really specific anecdotes, but in other cases, he’s introducing a product, he’s framing how to see the world, and how this product fits into that, and how it serves user needs. That is storytelling. 00:07:28 - Speaker 2: And I think that’s an often underrated aspect of that sort of role where we say usually, OK, Apple, you know, they have great designs, Steve shops had a great sense of taste. But yeah, I think a lot of it really comes down to storytelling where, OK, the iPhone can be really nicely crafted and it can be a great product, but the thing that will make it feel right and will make it feel like something that people want is actually the story that’s told around it and the story that the product tells. And I think that’s something that A lot of people don’t like consciously consider and often I think it’s sort of naturally like a story builds around it without the people making it really considering what that is, but I think it’s really valuable if you do actually sit down and figure out what kind of story you want to tell. 00:08:13 - Speaker 1: So then if we bring it to the realm of, yeah, business and yeah, especially tech products, you know, clearly Steve Jobs or anyone else getting up on stage to announce a product that is conventionally you would call that marketing, right? You’re marketing your product. And I think it’s interesting here to kind of compare a little bit how we see. I think actually originally we had had sort of two job descriptions here for this role and you’d call it a marketing designer and I think I’d called it a marketer and storyteller and so notably there we both were using this term marketing to capture part of what the role would do and I kind of think that marketing has a bad name or It’s sort of disrespected, I think compared to all the other disciplines that go into building a company. Certain product development, because people think of annoying or bad marketing, you know, invasive paid media advertisements getting in your way, whatever, shoving information in your face that you don’t want or demanding you to do something. But I do think marketing is a really important function. You can build a great product, but if no one knows that it exists, or how it fits in their lives or whether it’s for them. Then it kind of doesn’t matter, right? People need to be able to find out about it. And I also think marketing as a discipline has a lot of great tools, which includes, for example, this concept of the marketing funnel, which we do rely on. Especially in the early days, we looked at stuff like how many people convert from essentially downloading and logging into the app for the first time to kind of making it far enough that maybe they’ve sort of like figured out what the app is for and call that the onboarding stage. And we use that to figure out that our onboarding, we tried a bunch of different things, and basically it wasn’t working. So many people just didn’t even make it through it because they just couldn’t figure out what this weird app was about. It’s kind of how we landed on the onboarding, the you design that we have now that Still plenty of people get confused and don’t know what the hell this weird app is, but enough of them make it through to make it work. So those concepts like the marketing funnel, I think, are really valuable, and we do use those, and I do think that there’s a misunderstanding of what marketing really is, in the sense of a conversation with the market, understanding the market, figuring out how to explain the product to the right people, all that kind of thing. But at the same time, it does come with a lot of baggage that maybe it’s better to kind of leave off and certainly it implies a pretty transactional or you’d say pragmatic, but sometimes almost crassly pragmatic, just like try to get people in your funnel and get them all the way through. With whatever annoying tricks and dark patterns you can versus the longer term investment and we’re telling a story about the product, about us, about you and about the world and over time, if you like that story, you know, maybe that also means the products fit for you. How do you see marketing that terminology, does it have the same kind of negative implication for you, or how do you see that connecting to what we do at Muse with selling our product? 00:11:09 - Speaker 2: Yeah, I feel like we both had a similar realization during this process of writing the job description that we were sort of at opposite ends of the spectrum where I was thinking more from a marketing perspective and you were thinking more from a storytelling perspective. And as you said, I think like the realization is that These both kind of need to come together since they both touch so many different things and it would be wrong to just think of marketing as, OK, we are doing paid advertising, we’re doing a website and we’re doing like a few little banners of local design. And it will also be wrong to just think of storytelling as this purely artistic activity. Instead, we kind of need to bring them both together and really think about how we can use storytelling in our marketing and how we can sell our product in a way that also tells our story. 00:11:57 - Speaker 1: And maybe this question of selling, which is almost is more clarifying than talking about marketing, which is a pretty broad, maybe term or discipline, maybe that helps clarify, which is there’s the very artistic side, which I’d put this podcast in that category, you know, we’re basically here to explore philosophical topics that are of interest to us and our guests. Basically, Mark and I started it essentially for fun and then things got out of hand. Whereas maybe something like the memos we write where we describe the philosophies behind a particular product feature, maybe that’s in the middle, like, you know, we want to explore why and how we made this thing, but in the end, it’s partially to to that, hey, this feature might be useful if you’re a person that needs whatever it offers, and so in a way that’s sort of selling the product a little bit. Then you take something like our website or the app store listing page, and that is very explicitly when someone comes to your website, or at least when I go to a website for a product. Tell me, right? Tell me what’s good about your product. Tell me quickly, like, pitch me, impress me, help me figure out right away, is this for me, is this not for me? Do I want it? Can I afford it? Does it fit into my life? Does it solve the problem I have? Does the vibe of the product and the team like, fit with me well, and I want that, that’s appropriate for that setting. So yeah, there needs to be, or at least for us, what works is this balance between, we do have a product to sell, we have a business to run, and we need to be pragmatic about that, but at the same time, we’re all here because we want to express something artistic, we want to, as Mark would say, make a statement and, you know, our goal is to have an impact on the industry and how people see creative computing, and also we need to be viable as a business. Now, on the product side, how do you think storytelling does or doesn’t fit in there? 00:13:39 - Speaker 2: So we have already talked about all the different mediums that storytelling is really useful for. And I feel like Adam, you’ve been doing most of the exploration for us there and trying different mediums to tell our story and what’s been your experience so far. 00:13:53 - Speaker 1: Yeah, for sure. I think medium is incredibly important. The medium is the message, I think they sometimes say, but by here, by medium, you know, we talked about the TED Talk is one kind of format or like conference talks or lecture maybe is the medium there, but a different medium would be, for example, long form writing. So this is something I’ve done a ton of in my career, including at Hiroku and these long kind of academic essays that I can switch. And that’s actually quite different from the much shorter, punchier kind of copywriting you do for a website, for example, or an app store listing page, like here’s some bullet points of features, but also a huge one on the internet these days is video. Now that everyone’s got fast enough computers and connections and things and we have everything from YouTube to videos on Twitter to TikTok. Videos are really, really important format, certainly one we’ve used a bit for these like short product demo videos we do on Twitter, but also we embed them in our website. The moment there’s a big hero video on the front page of our website, and so on, and that was something you really couldn’t do on computers generally, but even on the internet up until relatively recently. But in working on this job description, I found myself really reflecting on the web as a medium, and I’ve been working in web for a long time, working with web technologies for a long time, and I feel like a lot of the discussion about technologies there and how the web is advanced is typically about web apps, the notions and Google Docs and so on in the world, but I feel like what gets less, I don’t know, airtime, let’s say, is the web as more of a content medium, and you’re a storytelling medium, so. That certainly includes something like, you’ve got a personal blog, and what do those pages look like, what’s the reading experience like on that, but that also includes something like a marketing website that is more of an exploring, you know, you tend to skim it, you maybe don’t read all the copy carefully, there’s a lot of embedded images, there may be a little animations with CSS transitions. And one of the things that we kind of built into this job description is we really want someone who uses the web as one of their primary mediums for telling stories. That doesn’t mean they’re necessarily the world’s greatest web designer, it means that they’re taking advantage of this new and frankly pretty unique medium to tell their stories, even if they’re, say, primarily a long form writer, that how you make that article page for your personal site. What the reading experience is like there, that that’s something you put a lot of craft and thought and design work into. And it occurred to me kind of again in thinking about this and thinking about our own needs and what you and I have done on the website as well as what I’ve done on my personal site for my articles and things like that, that the web is really a pretty unprecedented medium because it combines many together. Obviously there’s texts and typesetting is quite sophisticated, and you also have images, but now you have videos which are very easy to embed whether Using a hosting service or just kind of hosting your own HTML 5 video playback stuff, but then you bring in the dynamic medium element of it, and that is quite the next level, right? So you could say to begin with, it might be something like, OK, you know, a PDF and the web can both have pretty sophisticated rendering, but the web can be totally responsive or you resize the window or you’re on different sized devices and everything reflows. But then you can go a step further from that, right? You get into the CSS transitions, you get into something like changing behavior when you’re scrolling, and, yeah, sometimes scroll hijacking is sort of annoying, but you’ve also seen sites do some pretty interesting and sophisticated things with using your scroll as a way to kind of progress you through this understanding of a product or whatever it is they’re offering. And then, of course, that can ultimately go to totally interactive things you can click on and explorable explanations and things like that. And I feel like it’s really only in the last few years, let’s say the last 5 years, the web has really come in doing its own on that, that all this stuff is very universally supported on every browser, that you can view it on your phone, almost just as well as you can on a desktop device. That it’s fast, that you have these amazing transitions and animations, that you can do video and audio, and almost everything that you could possibly think of can all be put together and integrated and controlled in a way that’s potentially very sleek and very powerful, and there’s really been nothing like that to date. And what I’m most excited about for this position and just also broadly, is telling stories through the web, really taking advantage of All that’s come together with that in the last 5 or 10 years. 00:18:24 - Speaker 2: Yeah, totally. I feel like there’s a ton of untapped potential in the web for telling stories in new ways. And some of that kind of happens on like personal websites. So there’s still like some spark of the experimental web as it was like a few decades ago. But most of that has been sort of restrained into a Very small corner of the internet. And if you look at most companies or products or websites, like they are very much the same and don’t really try to tell any kind of special story or tell a story in a different way than the competition, basically. And I think that is a unique opportunity for companies like us and that our size to kind of have an outsized impact with this sort of goal in the company to, yeah, do something that basically other companies can’t do. 00:19:09 - Speaker 1: Yeah, part of that might actually be the reason you see more interesting experimental use of the medium on people’s personal sites with smaller teams is I think it does require a kind of person that puts together a lot of skills into one. I know one mind and so the same person that designs the site can also be implementing the HTML and the CSS. They’re maybe not a front end developer, I mean, you do this, certainly, I do a bit of this as well, they’re not necessarily an expert at that, but they know enough to really use the medium to its fullest. I think that’s pretty important and I think not to beat up on content management systems, the WordPresses and Squarespaces of the world, but I think they do tend to naturally take you into templates and sort of pretty restrictive, just sort of doing what’s been done. Before, which again is totally fine and appropriate for many people’s websites, that’s fine. But the interesting stuff tends to be when you have someone who can put all that together into one mind or one set of skills, and you don’t tend to have that, I think in bigger companies. You do have that with an individual’s personal site and with a small team site, and certainly that’s what we are striving for to some degree with our website and hope to really expand on this, especially if we get the right kind of person on the team here. 00:20:28 - Speaker 2: And as you said, the big factor here is that the web really works as a medium that a lot of other mediums can kind of build on top of. And so if you have a basic understanding of how the web works and are interested in getting into that, then you can combine that with another skill you have, whether it’s music or video production or just drawing or writing. And on top of that, you can kind of build a really unique experience on the web that you wouldn’t be able to do with just a single skill. 00:20:57 - Speaker 1: Yeah, well, that’s one of the things that’s great about the web is a multimedia medium is you can basically bring most other types of storytelling mediums into it. So, for example, photography is a really great format for storytelling. But you can use that potentially together with the web, taking the right photo that tells a story that then gets embedded in a website, whether it’s part of a post, or whether it’s something more of like a hero shot or background image or something like that, as just one really simple example. Now, I also think another medium worth talking about here is social media. I don’t know if it’s quite right to call that a medium, but at the same time I think it is. And one of the things that’s always struck me, obviously Twitter is our kind of main social media outlet for various reasons, but whenever I go to try to use some other social media platform, and I think, OK, well, maybe people would like to see new stuff on Instagram, or apparently notion blew up on TikTok for a while there. And the idea of a short video that shows productivity software, well, you know, guess what, that’s a lot of what we do on Twitter, right? We record these short demos that show a particular feature or a little vignette of how you use this product in the real world and show the hands and the stylus in action. It’s not just a screen recording. So clearly that works, but times when I have gone to look at these other social media platforms and think how we might fit in there, and I realized as soon as I’m there that there’s a whole universe of What format is it? What’s the aspect ratio, how long are these videos, you know, what goes in the text, you know, how’s that superimposed, and then on top of that, of course, it’s just the culture and the conventions that come with the platform and people have been using them a long time. So I think that being proficient in a particular social medium platform is sort of a medium in and of itself, and like the web, can incorporate other mediums, which is images and video and text and short form, long form, etc. but each one is almost its own language to speak. You have to be fluent in it to get good use out of it. 00:23:02 - Speaker 2: And social media seems interesting because there are so many different communities within that. Like it’s not a single thing that you post to and then it’s on social media, like you always post to a specific group of people. And ideally it’s full of people that are already telling a similar story and are really familiar already with the context that you’re sort of setting. 00:23:24 - Speaker 1: Yeah, that’s a great point. The stories resonate with our own experience or they match to something that we understand or believe to be true about the world. And actually there’s a quote in a fantasy book, it’s probably Guy Gabriel OK, I have to look that up after the show, but essentially it’s a medieval fantasy, I think set in China or something like that, and there’s one of the characters is a poet. And like a famous poet that evokes much emotion with his work, and one of his fans basically asks, how do you do it? How do you come up with these words that are so moving? And he says, well, the key is the poet has to speak the words that are already in the person’s heart. The key is you’re putting words on something you already feel implicitly or believe to be true, or have an underlying sense that is the case, but finally someone has put these really poignant words on it, or somehow described in a way, and you say, yes, that right there. 00:24:22 - Speaker 2: Yeah, I feel like there are a lot of lessons like this and really the classic storytelling, you know, that hasn’t been invented in the last few years basically, there’s so many great storytellers that we can learn from and so many classic lessons about storytelling. 00:24:36 - Speaker 1: All right, so my next question then is how does design fit in with storytelling or how can one tell stories through design? 00:24:46 - Speaker 2: Yeah, I think the important thing to remember is that it doesn’t have to be a visual story that you are telling, but a lot of it is really stuff like world building, setting the context for something, and sort of conjuring up mental images in the user’s head. So one example I like is when you look at the original iPhone and look at the first apps that Apple built for the iPhone, they all were kind of built, I think, to tell a very specific story both about the iPhone and then also about sort of the features it has, right? So for example, you had the note sap which was very obscure morphic and was sort of built to look like an actual notepad, right? Like you had this leather bound top and the page looked like a natural page with lights on it and it was yellow and the font was some sort of handwritten scribbly thing. 00:25:33 - Speaker 1: Yeah, and you wanted to touch it. I feel like that’s morphic and the leather. And even that makes me think of something like this slide to unlock, which we sort of take for granted now, or, you know, has actually has gone to the dustbin of history a bit, but it had this kind of shimmering effect, and there was a lot of effort put into the physics when you pull it across or whatever. It’s easy to forget this, but at the time, a screen that you touched was just not a very common thing, and so inviting you to want to touch it, seems like it was part of how you conveyed what was special about this product. 00:26:08 - Speaker 2: Right. And since it was a very new product, like if you just look at it from like a key tech perspective, it doesn’t look like a product that is necessarily interesting to basically the whole world. Like if you just compare the spec sheet, it’s basically still something like a BlackBerry that has all the basic functions of the phones of that time. And so what you really need is to sort of build up a story around it that connects it with something that people are already familiar with and that helps those people kind of understand how the product fits into that. 00:26:43 - Speaker 1: This also reminds me of an ad for the first iPhone, and while we’ve may beat up on paid ads, paid marketing a little bit, you know, part of what Apple is great at is ads, these little vignettes that tell a short story that show more than tell what this product is and how it fits into your life. So in this ad, which I’ll see if I can find a link to it on YouTube or something, they have the person watching Pirates of the Caribbean, which at the time was a popular movie. They see like a sea monster with these tentacles, and they kind of go, hm, calamari, and they hit the home screen, they pop up in the maps app, they type in a search for seafood in San Francisco, they find a place and then they tap on it to like call and make a dinner reservation. And obviously they’re showing a lot of different things in this, I don’t know what it is, 20 seconds that you can watch a movie, that you can search on the map, that you can do things very spontaneously, that you can do things very fluidly, these different apps coexist side by side, that you do this all on this screen with no buttons, essentially other than the home button, and it’s just a fun and cute little story as well, little vignette. So yeah, the product tells a great story, the apps tell a story, and the marketing that goes with it also tell a story, and all those things fit together very holistically. 00:27:59 - Speaker 2: Right, and I think each of those kind of multiplies the effect of the story, right? Like if it’s just the marketing that tells the story and then the product is kind of really bland and doesn’t implement the story at all, then that story is not as effective, right? And I think you can also go the other way and look at, OK, we have a great story that the marketing is telling and the product is also telling it. And the whole company is living it like maybe even the support team is trying to incorporate that story into their work, but then you can also go down a few levels deeper and look at, OK, what is actually a specific feature of this product doing as part of that story. And that will kind of help explain not just the product itself and the role the product has in the user’s life. But it will actually make the product much easier to use if you can actually tell a story for every single feature and ideally even for every single UI element and you kind of know its place and know where it comes from. 00:28:54 - Speaker 1: Yeah, so this sort of progression or hierarchy from the company or the team story, and then the product has a story and then each feature within that product has a story and then maybe that even goes down as detailed to each UI element, button, whatever that’s on the screen, or non-UI such as our chromeless UI that’s really interesting. One that comes to mind for me right away with that is the pencil toolkit. Which is, you know, essentially it’s this little thing you swipe in from the edge of the screen with your stylus, and we did the very custom and pretty unique thing there as opposed to using the standard Apple pencil toolkit, for example. And at first glance, and sometimes people do have this question, why did you make this weird custom thing rather than using kind of the operating system default? And of course you could argue that there’s sort of our company and team in general and certainly the product has a bit of a do it our own way, you know, follow our own path, story, or maybe more of a theme throughout. But it was actually the very first episode of this podcast where we talked about tool switching, and at the time it was still just an idea. Mark had this technical pen store idea of you go through and they have 1000 different pens, but you pick out the 10 you want and you put those in your kit for what you need for a particular purpose, so that you’re not overwhelmed with choice each time. And that was kind of, we told that story or discussed that philosophy through this podcast, and later on, we went to build it and you designed it, we incorporated some of those ideas, as well as many other ideas, and came up with something that eventually we did a memo about talking about whiteboards and the choice of pens there, as well as the pen store and just looking at a lot of inspiration from These various kind of real world drawing settings and ultimately described why we built this feature the way that we did, and then that in turn boils down to this very specific detail of why does the tool switches show up the way that it does, why is the choice of pen thickness or color, why do I need to go to the settings menu for that, you know, it’s. Taps to get there as opposed to something that’s sort of right there always present in UI, which is what a lot of drawing apps do, but that connects to this philosophy and this concept and story we have about trying to bring some of these elements that we think are good for creating a flow state from the analog world into a digital tool. 00:31:16 - Speaker 2: Yeah, the pencil token is a great example because as you said, it really incorporates a lot of these ideas that I think at the very core of news and what we want news to be. And so it’s not just about like a single element, right? Like it’s not just about the pencil case that you have on your desk and like that’s the story of everything that’s related to pencil music. It kind of draws from all kinds of ideas that matter to us and in turn that sort of creates a really unique angle that wouldn’t be the same if even any of those ideas is taking away. And so then the product design challenge, I think, is you have this long list of things you wanna incorporate and these values you have, the ideas you have, but it’s not a simple, concise story or a simple concise design yet, right? So that’s sort of the challenge to really figure out the essence of these ideas and turn that interaction that incorporates all of these different ideas. 00:32:16 - Speaker 1: It’s often the case that it does emerge organically from following a hunch. For example, in the pencil tool kit, we did have the sort of pen store idea from the start, but many, many details of how the actual implementation ended. I think with you following your hunches and instincts as a designer, it was Julia following her hunches and instincts as an interface engineer to eventually land on this thing that felt good, that looked good, that seemed to be a reflection of our values and pragmatic. just serve the purpose that it needed to serve, and all those things come together, and then maybe it’s sort of post hoc, you end up with a story where you look at the finished thing that you iterated towards and followed hunches and followed instinct, and you look at this and you say, you know what this reminds me of is, you know, a set of whiteboard markers and why that kind of setup is good for a freeform thinking environment where you’re not going to get hung up on the exact thickness of your pen. And maybe, you know, we had some of that upfront, maybe that was part of our inspiration, but sometimes you sort of look back and realize why you ended up where you did, or I don’t know, do you agree with that? There’s some elements of that? 00:33:24 - Speaker 2: Yeah, I think certainly at the start, that’s often the case. You know, if you compare to writing, you have this fear of starting with a blank page. And so you aren’t going to just start by writing down the whole story, but you’ll need to start somewhere and then you kind of go through this long editing process and at the end of it, you’ll know what the story is, basically. And I think we are a bit further along now where we already have a lot of the pages filled out and it becomes a lot easier to add new sections to the story basically and new subplots to it. 00:33:54 - Speaker 1: So that’s sort of the role that maybe product design has to play in storytelling or the use of storytelling and product design. What about brand design or visual design? How does that fit this picture? 00:34:06 - Speaker 2: Yeah, I think for us, our experience has been that marketing design works best and there’s some underlying truth to it, which in our case is the product. So since we already have a really compelling product, I think a lot of what we do is transform that into different marketing channels and talk about the very same story there. So one example there would be this podcast we are on, which is also a channel for us to talk about the ideas we develop with use the product. 00:34:33 - Speaker 1: Yeah, for me, one example of where brand design or visual design can be very helpful in telling your story is, obviously, the podcast is super important for us telling our story of the team and the product and that sort of thing. But for some time we first made the podcast, which as I’ve mentioned before, was just a weird thing that Mark and I were doing for fun on the side, and at some point we realized it was something really worth investing in, but we had basically were just redirecting to the overcast public pages because they were, I don’t know, better than nothing. We needed like some home on the web, they kind of give you a default one, but it really didn’t convey that we cared much about the podcast. And so you designed the page for us, which was both the MUA.com/podcast page, which included figuring out what is the podcast actually about. We’ve been recording it for a while and we needed that like top headline, and that required me to sit down or we sat down together, but mostly it was on me. What is this podcast actually about if we boil it down to 3 ideas or 3 areas, 3 themes, what are they? And we ended up on tools for thought, product design, and how to have good ideas. There’s lots of other stuff in there about like independent software development or we talk various things about company building and team building, but you know, we felt like those were the three really top level things. And related to that also is self-hosting the pages, and we have the embedded media there, and you did this little illustration for kind of a riff on our app icon, brainy guy, just sort of wearing headphones, and that conveys something sort of calm and serene and fitting in with our brand vibes. And that in turn, in a way, having this home on the web and having had to figure out this headline and what the three themes are that actually clarified my thinking about what this podcast is for or what kind of things we should talk about and what kind of guests we should have. So there’s a nice feedback loop between the, it’s called the product in this case, which is the podcast and the brand design or marketing design or visual design that goes with its home on the web. 00:36:42 - Speaker 2: Yeah, and those projects are kind of always the most interesting to me where one part of it is, of course, like the visual side and like the purely design side, but then the other part is, OK, we actually still haven’t completely figured out the story or the message yet, and we kind of need to develop both in parallel, because then one can inform the other basically. We can do a bit of work on the design side and then see if that is sort of the vibe you have in mind for the message you want to get out there. And then once you develop that, that will also inform the visuals. I think we’ve been doing fairly well on that. Like we have a few projects like this that I think tell a story both through the messaging and the design side. But yeah, I do also feel like there’s still a lot we kind of wanna do and either I don’t have the skills to do it or we don’t have the time to do it. And so that’s the reason we are hiring and looking for a person to fill in those gaps and really help us out, both with storytelling and brand design, visual design. 00:37:45 - Speaker 1: Yeah, for sure. We have a lot to say at this point and more than we have the sort of bandwidth to get out of the world, whether it’s through our website or other means. So I think that’s part of what they would do is just this potential person to join the team would be to just help us say more, right? Our website is pretty minimalist at the moment and as we expand the product offering and in general, expand our story, I think we would like to add a lot more content there, but it’s just hard to do with the size of the team we have. That’s one is just kind of more. And then the other dimension is the one you mentioned, which was skill-wise, you know, someone could come onto the team. I think you’re underselling yourself a little bit there, you managed to do both incredible web design and product design, and you’ve argued before that there’s a lot to be said for having one person that does both, so that you have an integrated look and feel between them, but then at some point that’s just too much, right? It’s too much for one person to carry on going. And that, of course, is always the tension with the smaller teams. It’s great to be able to, everyone’s kind of jack of all trades, and you span a lot of different realms, which means also the whole thing can feel a lot more holistic because it’s not split up among so many different craftspeople, but then, you know, you’re just both limited in time and just where you can invest in your skills. So, I’m hoping that a great designer and storyteller could come in here and help us both with uh doing more about telling our story and all the unique and interesting things about our company and our amazing users and customers, and the reason to have thinking tools, you know, reason to have our computers help us with thinking, as well as many, many more details within all those realms, that we can do more of that, but also do it better. 00:39:26 - Speaker 2: Yeah, I’m really excited for that. 00:39:29 - Speaker 1: Let’s wrap it there. Thanks everyone for listening. If you have feedback, write us on Twitter at MuseAppHQ or we’re on email below at museapp.com and you can help us out by leaving a review on Apple Podcasts. Leonard, I don’t know about you, but I’m really looking forward to meeting all the folks who might find it worth their time to apply for this and eventually to add our 6th member to our tiny little band here. 00:39:56 - Speaker 2: Yeah, I’m especially excited since I’ve been the only designer on the team so far, so, you know, I get to socialize with designers again. That’s something to look forward to. 00:40:05 - Speaker 1: It’s well and good to have colleagues that have complementary skill sets, but there’s a whole lot to be said for someone you can really talk shop with very directly about your area of craft. I look forward to that too.
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: We both really, really like writing and are good at it, and care a lot about the written quality of the product, and we both also have this product DNA where we’ve built software products before, and we know how that works, and we’re trying to figure out if you put those two things together, what can you make? 00:00:23 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for thought on iPad. This podcast isn’t about Muse the product, it’s about Muse the company and the small team behind it. I’m Adam Wiggins here today with Mark McGranaghan. Hey, Adam. Joined by our guest, Dan Shipper of every. 00:00:40 - Speaker 1: Thank you. Thanks for having me. 00:00:41 - Speaker 2: And Dan, I know you like me are quite a reader, reading anything good these days? 00:00:47 - Speaker 1: I am. I’ve been actually reading a lot. I also just have to say, like, the way that you do that intro, it feels so calming. I feel like I’m in good hands. I wanna like slow down and just bask in it a little bit. Perfect. Yeah, but what am I reading? I just finished this book by John Green, who I love called The Anthropocene Reviewed, and John Green, he typically writes novels. I know him for his novels. He’s written a couple books called like A Fault in Our Stars, another book called Turtles All the Way Down, which have been really impactful for me, and this is the first series of his essays that I’ve read. It’s basically a collection of essays. And the conceit is that in the Anthropocene, which is the era that we’re in right now, which is the era in which humans are affecting the environment. One of the central things that we do is we give reviews to everything. If you go on Google Maps or Yelp or whatever, everything in our world has like a review that boils everything down to between 1 and 5 stars. 00:01:43 - Speaker 2: Yeah, I always find it funny when you look up something like, I don’t know, the Atlantic Ocean or like an abandoned power plant or something like that, and there’ll be reviews in there, which are often hilarious to read, but yeah. 00:01:57 - Speaker 1: Yeah, it’s really funny. He opens it up by saying that he noticed that someone had given a park bench, like a 5 star review, and it’s like, what is that? What is that about? Why do we do that? And so the conceit of it is every essay in it is a review that boils everything down to between 1 and 5 stars of lots of things like sunsets or sycamore trees or bacteria or every single topic at the end of it, he’s like, I give sunsets 5 stars, and then every time he does it, it’s hilarious, but it says something I think really interesting and I just tore through it in like 2 days. It was really good. 00:02:30 - Speaker 2: Yeah, for sure. I feel like he’s got quite a personality as a podcaster. I think YouTube was even maybe where he got started, kind of classic blogger, but yeah, great observations on the world, but also, yeah, very poignant observations, but also just really funny, really entertaining, and so that makes it, yeah, easy to read. I am at the point in my life actually, where there are many great books that have had a big impact on my life that are kind of a slog. But with being a busy parent and business owner and whatever else, I really appreciate something that’s just easy to read. It’s fun, it’s written in a way that it just flows smoothly and you can both get those great insights and widening of perspective, that is the reason why we consume media, especially things like long form books, but in a way that maybe it’s a little less costly in terms of your own personal activation energy. 00:03:22 - Speaker 1: I totally, totally agree. Like, there’s all those books where you’re like, I should really read this and I should really like it, but I’m just feel like I’m kind of out of gas, like, I don’t have the mental energy to do it, and then there are other books where you just kind of tear through it. I just went through this whole series of books. I basically went through the ouvre of this guy Irv Yum, who’s like a psychiatrist, and he writes, basically what I would term therapy fan fiction. And it’s so good. I read like 5 books in like 3 days and I just could not stop reading it, and I just like finding those things sometimes as a refresher to all the heavy stuff that we end up thinking about and reading day to day. 00:04:00 - Speaker 2: Absolutely. Well, tell me a little bit about your background. You kind of come from maybe a more classic Silicon Valley tech entrepreneur background, but then you had this journey of being early as a kind of substack paid newsletter, and now you’ve got your business every, which is very interesting, kind of modern internet media business, writers collective has some elements of some of the small giants, the business stuff we talk about here, but yeah, tell us the journey that brought you here. 00:04:28 - Speaker 1: The journey that brought me here, so my background basically started in software, really in technology and software. I started programming when I was in middle school. I read a Bill Gates biography and decided I wanted to start a Microsoft competitor, so I learned Basic, and I was going to build a Microsoft competitor called Megasoft, and Didn’t actually end up ever writing an operating system, although I really wanted to, but just fell really in love with that whole thing because I was super interested in business, and the only way to really start a business when you’re in middle school, is to be able to program cause that’s the only way that you can start a business where the only cost is your time. So, built a lot of apps, started with apps for BlackBerry in high school. And then the iPhone came out and I started building iPhone apps. That’s kind of how I paid for gas and food in high school, and then in college, finally met people that were also programmers and were also into like starting companies and stuff like that, and started my first company, it’s called Firefly. And there was an enterprise software company we built co-browsing, which is kind of like screen sharing, but all of that happens in a web browser, and we applied it to customer service, so built that for several years, primarily bootstrapped, so you’ll notice like a thread in my life is kind of this whole bootstrapping type mentality, and then sold it to Pega, which is this big public enterprise software company, right as I was coming out of school, and that was really, really good experience. I learned a lot about building a business. I ran the firefly business inside of Pega for a little while, and then I spent the next couple of years just like trying to figure out what I wanted to do with my life. 00:06:06 - Speaker 2: And I think this may have been the point where we met and I think what you described to me at the time and you had just started the super organizers newsletter and you were starting to interview people. Correct me if I’m wrong on this, but what I remember is you’d reached out to me and said, you know, hey, can we chat? I’m working on this kind of interview newsletter and the way you described it was, well, you didn’t exactly know what was next, but you figured talking to lots of really Interesting, accomplished, productive people might lead you to that somehow, and it really resonated with me because I was working on ink and Switch at the time, which in some ways had a similar origin after my sort of big career success in the form of Furoku and that ending and me trying to figure out what was next. Starting a research lab was a way. To kind of maximize my optionality, stay in divergent mode, not pick a thing to work on, basically, and eventually that did turn into something that was pretty focused around some specific goals, but at least in the beginning, the point was to do a thing that was incredibly exploratory and didn’t like tie me down to one very specific path. 00:07:10 - Speaker 1: Yeah, totally. And I definitely did that and the newsletter that I started Super Organizers was part of that. I think like, I went through this phase where I was writing a novel, which I wrote like 4 drafts of. I did tons and tons of other like little software projects and worked with a bunch of different people and had a bunch of different ideas that I was excited about. And eventually, I started this newsletter called Super organizers, cause I realized that I was just super interested in productivity and note taking. I’d had a bunch of ideas. In the, I would say like tools for thought space for a long time, kind of stemming from my first company where I just felt like I was this information processing machine, but my tools for processing information were like not great, and I was really interested in building software to like make that better. So when we talked to you, I basically started super organizers and the conceit for me, the reason for starting it was I wanted to build a productivity software company. But I didn’t exactly know 100% what I wanted to build, so I decided, hey, I’ll start a newsletter. I’ll interview like really smart, interesting people about how they think about their own productivity systems, and I’ll use that to inform the product I make. I’ll write the interviews up and get an audience, but like the real idea is it’s a way for me to do customer interviews with smart people. And so talk to you, published a bunch of interviews with a bunch of really, really smart people, and along the way, I just actually decided or found that people loved the newsletter, and loved the writing, and I could build a business with it, and that was very exciting to me and not something that I’d really considered before. So it kind of put me on this path of like, how would I do this as a business instead of like actually just going and building software cause I love writing, I love business, and this is a way to put them together. 00:08:56 - Speaker 2: Another interesting thing here, I feel like is the timing that sort of email newsletters were on the rise, maybe as kind of a replacement for blogs, RSS. I’m not sure exactly. Substacks obviously a big part of the story. You were early there and sort of the concept of paying a subscription for an email newsletter was something that I feel like kind of came out of nowhere, but then suddenly was getting a lot of traction and you were, I felt like very much in the right place at the right time to take advantage of that. 00:09:26 - Speaker 1: Yeah, it was a really, really interesting time. It was that wave about a year and a half ago where this started to really pick up that I was running super organizers and starting to think about this as like a business, and at the time I didn’t really understand that it was becoming this like trend, and it was kind of at that time that I started talking to my co-founder Nathan Behez. We’ve been friends for a long time, and we just both, at the time he was the first employee at Substack, so he was really feeling it and like, had been on this train for a long time and kind of knew that this was coming, I think in a lot of ways, and we started talking together at the time he was no longer at Substack. And we started talking about what could we build together, what we do together, and what that turned into is us kind of thinking about what would it look like to build a media company in this kind of environment where solo paid newsletters are becoming a thing, lots of writers are leaving their publications to do it on their own, and there’s a lot of benefits to that, but there’s also a lot of drawbacks, both for writers and for readers, that I think People maybe aren’t as sensitive to right now, but will become more and more important over time. And so we started thinking about how do we build a publication or a media company under this kind of environment, and we knew we wanted to build something that had a group of writers that was covering topics that we’re most interested in, which is basically topics in tech, topics that are about business, but that, you know, when you read them, you’re both entertained and you kind of feel like you’re getting something out of it. I would put this podcast in that kind of category too, where you feel like you’re getting something that is going to help you think better, make better decisions, be better at your job in some way. So we’re kind of like toying around with what is that kind of a media company look like? How do you build that? and how do you build the supply of writers and create incentives for them to all be in one place when there’s so much incentives to be on your own, especially if you’re someone that can write well enough to do that. And so, that’s where we started to come up with this idea for a writer collective, which I can explain, and start on this journey of like taking all these individual writers who could really write on their own in this environment and figure out how do we actually write together because in a lot of ways that’s better. 00:11:34 - Speaker 2: Well, that brings us really nicely to our topic today, which is, let’s say, building a media empire in the internet age, or just simply creating a media brand, an internet era media brand. And I think one of the things that was maybe eye-opening for me, watching your journey on this was thinking about what I would call classic media brands, I guess that’s the way to put it. Something like magazines and newspapers like The Economist is one that comes to mind, or The New York Times, maybe if you go more to entertainment, you have something like Disney, there’s one that I’ve read quite a bit about just because, yeah, Walt Disney is a really interesting entrepreneur and everything that’s been created there and how that company has evolved over time, is also really interesting. But I remember you telling me a bit about some of these what I would now call I guess like internet native media brands, and that’s something like Vox, for example, or Vice. So both of these to me are very evocative of like I know instantly what their voice is and what their kind of view on the world is, but they’re not one single media, right? Like you know, the Economist is a magazine. And so it’s writing, and that’s pretty much it. And then they have, I don’t know, data visualizations and things, but Vox, well, they have articles on their website, but they also have a bunch of podcasts, and then they have some YouTube videos, but they also have like a Netflix series and there’s definitely something that unites all of them, but at the same time they feel different to me in some ways from these more classic brands. And then you’re on this journey of bringing your perspective as a software entrepreneur, I don’t know, maybe it’s a software is eating the world kind of thing to, OK, how does the internet change media and especially if you’re doing it more at this indie level and yeah, as you said, like, how writers and publications and stuff even gets distributed to people, all of that is changing, which maybe creates confusion. It’s hurting some of these existing classic publications, and people have talked about the death of journalism and that sort of thing, but that it also creates new opportunities. 00:13:35 - Speaker 1: Yeah, totally. There’s a lot in there, there’s a lot to unpack. I think on the kind of like traditional media side, the way it has worked for a long time is, yeah, you have an editor at the top that is kind of assigning stories, is responsible for the voice and the vision of the publication, and writers kind of like slot into that more or less, and the publication is. Well, for, they pay you a salary, they give you an editor, they give you kind of like support, you kind of know what to expect. And a lot of cases, they don’t even give you a salary now because it’s too expensive, but like they give you some money and the publication’s job is to go figure out how to get distribution. Sometimes it’s like magazine stands. Now it’s on the internet. And if they get more distribution and then can sell a lot of ads or can sell more subscriptions, the writer doesn’t get paid more necessarily. And so they kind of like make the difference there. And I think for a lot of those non-internet native publications, it’s been a difficult transition to the internet because the style of writing is not really native to what gets shared on the internet, like a headline. In The Economist is usually not something that people are gonna want to like click on on Twitter, but it makes a lot of sense in the context of the Economist, where you’ve already bought this thing and you’re kind of like going through the full piece of content and you kind of like reserve time versus like, you’re just seeing something in the stream of information and you kind of like click it, cause it feels really worth your time like right now, it gives you that little dopamine hit. 00:14:58 - Speaker 2: And I think the bad version of that or the immediate interpretation of this is not a good thing. We might have talked about this a little bit with Tobias back in our social media episode, but sort of in some ways the clickbait headlines of the internet era are all throwback to kind of yellow journalism where because every newspaper was sold on the street corner and there’s just some kids saying. Extra, extra, read about, you know, war declared and blah blah blah, and they’re just very incentivized to have these flashy headlines that would often just be completely false. And the subscription model where you essentially buy a year’s worth of whatever newspaper it is that’s delivered to your door, they’ve already got your money, they’ve already got your attention. So now it’s more about this long term value building trust and giving you really good and useful information, they don’t need to catch your attention with flashy headlines. 00:15:48 - Speaker 1: Right, totally. I think your history there is really good, and I think that’s what the internet native brands that we know have figured out how to do is they have writers and editors that have grown up with the internet and know what is going to catch people’s eye. And so the way that they have built their brands is to try To amass large audiences, usually by getting them from existing big social platforms like Facebook or Twitter, and then still advertising against those audiences and they’re trying to get as big and serve as many people as possible, and it has worked, it hasn’t worked like as well as I think a lot of investors hoped when they first invested in them in like 2012 or 2013 or 2010 because These brands are still really subject to platforms, and when Facebook changes its algorithm, a lot of them have had a lot of trouble, and they’re still around, like Fox and BuzzFeed and all those companies are still around, and I think they’re probably going public soon, but it’s been a really tough road, basically. And I think that you’re right, people are feeling like a lot of those brands ended up. Doing things that are more clickbait, and so you end up losing trust in them and you don’t feel like maybe they’re doing as high quality stuff as you want, and I think that has been one of the reasons why we transitioned to subscription media is people feel like they’re developing a relationship with a specific writer that they like, that is not feeding them just kind of garbage that they have to write in order to get them to pay attention and get the algorithms to put it in front of them. And I think that’s a really interesting move. I don’t think it at all solves the problem. I think you can still be kind of outrageous and not fact-based as a subscription writer, but it solves some of the problem for sure. If we write something controversial, it definitely still gets views and we can convert those views into subscribers. You still have to think about top of funnel if you’re a subscription writer, you do. 00:17:39 - Speaker 2: How do you find this as a business owner where you know you need to sort of justify your existence and make sure you can keep the lights on and everything like that? Do you find yourself compelled towards kind of the controversy, clickbait titles just a little bit? I mean, I don’t think you’re very much in that vein, but do you find yourself with the mental debate of we could title this this way, and I think that would get a bunch of like outrage posts, and I know that that’s worth $10 to me because I know how that converts, right? 00:18:09 - Speaker 1: Sometimes, I think for us, I’m pretty probably afraid of controversy. I don’t really like outrage, so I’m not tempted to. I think some other people that I work with are a little bit less afraid of that and are a little bit more tempted to do it, but I think that there are definitely incentives around what kinds of topics we cover, what we think people will pay for, and those are not necessarily the same as what we think we should cover in every single case, and like a really, really easy example is We know if we cover crypto, people are gonna read it and probably buy it. It’s the most interesting thing that is happening right now to most people, and it’s just hard to find writers, and I think we have them, which is really great, but it is actually kind of hard to find writers that cover crypto in a way that feels actually balanced and responsible. And if we just found someone who was more of like a crypto, just a pro crypto, like all the way person, like really, really breathless, I think we would get a lot of readers and subscribers. We just would. It would sacrifice our brand and it wouldn’t be the thing that we want or care about, but it would work pretty well. And so I think that the trap that it’s easy to get sucked into is thinking about what is everybody else covering that’s in the ecosystem at our level of the value chain, what is everyone else covering. And why aren’t we doing more of what’s working for other people? And that’s a really quick way to just kind of court disaster, because you can never do anything actually interesting or that actually moves the conversation to a new place, if you’re just trying to figure out what everyone else at your level of the information value chain is. Chasing trends. So we try not to get sucked into that, but business incentives wise, it can feel like the local incentives are to do more of that. Hm. 00:19:56 - Speaker 2: And maybe we can talk about the writers collective part of things. You entered that a little earlier, so we talked about the sort of the sub stack thing, the paid newsletters. Something I like a lot about this overlaps really well with what we’re doing with the muse business, which is this kind of indie thing, which is if there’s a smaller team, especially. One person, obviously it’s one writer, but even if it’s just a few, where you feel a very kind of personal relationship to them, you know, their personality and style, and it feels like a much more human transaction somehow you want to support this one person or a small set of people than sort of the big faceless corporate monolith. And so that’s part of what SubStack potentially offers when you see some of these writers go off and go indie. I know I like this one writer. I like their take on the world, and I want to support them, and therefore it sort of has a farmer’s market vibe a little bit there, but obviously there’s many downsides to kind of being independent like that. How do you see the writers collective as fitting into that equation? 00:21:00 - Speaker 1: So what a writer collective is, or the way that we defined it is we’re trying to be for writers somewhere between having your own sub stack and working at a big media company. So on the big media company side of things, what we try to provide for writers are things like distribution to an audience, so you’re not just fending for yourself, trying to get views on Twitter, you have an organization that’s going to put your stuff out to readers and find readers for you. We give you an editor, so you’re not just kind of alone trying to turn out as much content as you possibly can. There’s someone there who can help you think about the sentences and the ideas. You have a group of other writers, so it’s not all on your shoulders, you know, Ben Thompson writes 4 days a week and it’s all him, it’s not all you in this model. 00:21:41 - Speaker 2: Yeah, interesting there, Ben Thompson, I think is also sort of a prototype or an archetype in this. He writes tracheri. I know I’ve linked to their articles a number of times in our show notes. He’s been doing this quite a while, but yeah, kind of independent business, charges money directly through his own website, and yeah, apparently it’s just able. To continue producing really good content essentially every day and has done so for I don’t know what, better part of a decade or something like that. That’s obviously a pretty remarkable case, but it has shown, I think he served as a role model for a lot of the modern email or kind of independent writer, independent subscription paid writers. 00:22:18 - Speaker 1: Right, totally. And so what we want to do is give people those benefits that Ben Thompson doesn’t really have access to, and give them a lot of the benefits that they get if they write their own substacks. So we want to give them more of an ability to write stuff that is their own voice and vision, not something that they have to conform. Like if you write for the economist, you have to write in the economist style. We want to be less like that. There’s obviously always a spectrum, but we want to be more allowing people to do the thing that’s most interesting to them in their own voice, cause that’s what we think the best writing is. And then we want to share upside, so we want to measure who is subscribing to the collective for a particular writer and pay that writer, we pay writers 50% of the profit from each reader that is subscribed for them. So writers don’t have to ask for a raise. If they’re writing good stuff that’s attracting readers or obtaining readers, they get paid more. And then we also want to give writers the list of emails. What we believe is because we’re in this world where readers primarily subscribe to publication for the voices of the people that they most like, that when a writer develops a relationship with a reader, they should be able to contact that reader, even if they leave, and we’re not interested in retaining writers by holding their audience hostage. And we think this kind of a deal where writers get upside and maintain access to their readers is more reflective of the reality of who is driving value for publications in the internet age, and is the kind of deal that we think more publications will do or have to do over time. So that’s the basics of a writer collective and I think it comes back to this thing that you mentioned earlier, which is this realization that we had that most people 50 years ago were thinking about reading The Economist. But today they’re more thinking, I really like Matt Levine, or I really like Ben Thompson. So if you want to create a publication where you have multiple writers together, which is what we want to do because we actually do think that that’s better for a lot of reasons, which I can explain, you have to both market it to readers as being voice first. It’s like, here are the voices that you’re going to get when you subscribe and you’re gonna like those people, but you also have to compensate the writers as if they’re the ones driving the value, which they are. And so that means sharing upside and sharing emails. 00:24:26 - Speaker 3: Yeah, it’s really cool to see that you’re actively exploring different approaches here. We’ve had this incredibly important change with communication and media that’s ultimately gonna have massive impacts in terms of how we organize ourselves as wild as it seems, we’re still in the very early stages of that. But anyways, when that first hit, of course, the first thing that we tried to do was transliterate the old world onto the digital world. So we took a magazine and Put like www in front of it and said, oh, we’re an online magazine now, right? And you know, that’s a very common pattern, but now we’re in the more interesting phase of exploring what you can do with the new affordances that you have with digital mediums. And so things like direct subscriber relationships and smaller writer collectives and different platforms that support those in different ways with substack and Ghost and whatever, and uh just a very interesting time. 00:25:11 - Speaker 1: Yeah, I feel really lucky to be a part of it. It’s something that I kind of stumbled into, but it’s such an interesting amalgamation of my own interests and such an interesting time in history to be figuring it out. And obviously we don’t have all the answers, but it’s really fun to get to think about. 00:25:29 - Speaker 3: And I think it’s interesting to think about what are some of the underlying reasons why we’re getting pulled towards these other solutions that are not called the online magazine transliteration, and we’ve talked about some of them here, like one is You can have a much broader variety of voices just because you’re in these long tails and you don’t need to funnel everything through one of a small number of oligopoly media publications, right? But also you can have that long tail effect also applies to like the subject area and even the balance of the opinion, you know, whether that’s political opinion or whatever. Another thing I think that’s happening and that we’re starting to see with this little bit of tension call up between the legacy platforms and The newer smaller outlets and even individuals is there’s a little bit of kind of escape and routing around institutional dysfunctions in the larger legacy publications. And I don’t have a fully developed theory of what’s happening here, but I think it’s something like these older public like take like the New York Times or The Washington Post, they’ve built up an incredible amount of capital through tens or hundreds of years of in many cases, quite good journalistic work. And now I think there’s a constant temptation if you’re an individual at one of those firm. Terms to basically draw down the capital for your own benefit or for the benefit of whatever your pet cause might be, that might be you basically take advantage of the masthead to like write some wild opinion piece that doesn’t make any sense, you know, for example. And it feels like it’s become so compelling to do that and people have developed basically better strategies for doing that, that I think basically we’re seeing that happening and indeed, if you look at the Just broad-based opinion polling in the US, these legacy media publications will be at almost the very bottom, right? I think that reflects this capital getting drawn down. And meanwhile, the individuals, the entrepreneurial publishers, these individuals, they see that they could potentially build. For themselves and write for themselves either as a single individual or as part of a small collective, and you get more of this builder’s mentality of like, you’re basically accruing capital, and you’re getting 50% of the dividends that get paid out because of more readers. And I think that’s just a powerful dynamic that’s happening right now. 00:27:38 - Speaker 1: Yeah, I haven’t really worked in one of these big publications before, so it’s a little hard for me to like, comment on the internal dynamics of why people do the things that they do or how they maybe kind of draw down the institutional capital or whatever. It is true that if you’re working at one of these large companies, it’s easier to hide, right? Like you can write an article that’s like, OK, and it doesn’t matter as much cause it’s got the New York Times masthead behind it, whereas if you’re on Substack, if you don’t write something awesome. Until you are Ben Thompson, Ben Thompson gonna write lots of bad stuff and it doesn’t matter, but until you are Ben Thompson, you have to write good stuff, right? So I think that’s one interesting thing, and then I think the other part of that is that there are a lot of people who can hide at those big publications, and then there’s a lot of people at those big publications that are the ones that are carrying it today, that are increasing the capital, right? And sometimes they feel underpaid or undercompensated. 00:28:29 - Speaker 3: Right, and that’s a big piece of this tension that I was alluding to, right, where basically people are looking, these individuals are looking at both sides of the fence and saying, hey, wait a minute, I’m building up all this capital here. I’m not getting paid and it also seems like it’s getting drawn down by others for nefarious purposes. What if I just, you know went over here and, you know, paid myself a $250 million a year with really nice news on there, right? That’s the sort of dynamic. And then The tension is that that reveals a sort of fundamental problem or issue with the larger firms, organizations, so they’re basically scrambling to either fix that or address that somehow in their approach. 00:29:00 - Speaker 1: Yeah, totally. I think that. 5 years ago it was not seen by people as a legitimate thing to like go and start your own newsletter like that just seemed crazy. And it’s something that writers over time are learning is something that you can do if you are a certain kind of writer, and I really underscore if you are a certain kind of writer, it’s not for every writer, and if the only option was to start substacks, the world would be like way worse off because the kinds of writing that you can do on substacks successfully are very specific, and the kinds of people who can do sub sub stacks are very specific. But I think the trade-off for those people that do leave is they’re a losing security, which is really important for a lot of people. Oh yeah, if you’re a writer and you haven’t really been making a lot of money in your career and you have a family, like the security of working at a big company is really important to you. But you’re also really losing the respect and credibility that comes from being able to say I write for the New York Times, I write for The New Yorker, and I think a lot of people in those communities really deeply value that. It’s not something that they want to just throw away. When you grow up dreaming of writing for The New Yorker, like, and you get to do it, it’s like a big deal, and it’s a big deal for more than just the money. It’s very similar to growing up wanting to be a movie star, and then being like, well, I could start a YouTube channel. I think for a long time, starting a YouTube channel was not acceptable to people that grew up wanting to be movie stars. I think kids today, it’s different. I think most kids today are interested in being internet famous, or interested in being TikTok stars, and being a Hollywood star is just, it feels old. or just like less like the thing they want. And I think the same is true of writers. And it’s probably just taking a little bit longer because like just happened and YouTube’s been around for a longer period of time. But I think previous generations of writers wanted to write for big publications. They wanted to have their books published by large publishers, and that’s a huge thing in their psyche. And that’s why you get into writing is not for the money. It’s for this kind of thing. It’s for having a chance to be in a bookstore and win the Pulitzer Prize or whatever. I think now we are starting to see generation people where that stuff is a little bit less valuable to them. They’re more interested in internet native types of respect, credibility and success. So those institutions are a little bit less valuable to those people, and that creates an opportunity for players like us that we feel like we’ve also grown up on the internet and we can give them something that they want, but also give them kind of the experience of being part of a collective, which is something that I think a lot of people value. 00:31:22 - Speaker 3: Yeah, for sure. By the way, this reminds me of one of my pet peeves, which is you’ve probably seen this like meme or statistic that in the US, the number one job aspiration for young people is to be like a YouTube star. And in China, it’s like to be an astronaut or something. And people often say that in a way that’s like derogatory to the US or as if it reflects badly on the US. But the way I always saw that is people in the US. to run their own small businesses and control their own destiny and make their own way in the world. And it’s obviously lots of good things about aspiring to be an astronaut, right? But it does have this element of like, you got to be one of the three people that the government picks every decade, versus having a shot to make it on your own. Right. So, to kind of reflect your point, I think there’s a lot to be said about having the desire and the initiative to strike out on your own, whether that’s to run a traditional small business or the sort of emerging class of small businesses with online media. 00:32:12 - Speaker 1: Yeah, it’s so easy to just be the kids these days meme, like kids are so shallow and whatever, and I would rather just be actually interested in what does that mean to people to be YouTube stars and how is that actually probably similar to other things that have happened in the past and what are the good things and the bad things about it and not just like, oh, yeah, everyone’s just terrible and shallow and. Losing so much to China because they want to be astronauts. It doesn’t mean anything to me. 00:32:35 - Speaker 3: We could probably do a whole episode about this, but there’s this fascinating, it’s actually a big and serious business to be a major YouTube personalities. People like they have multi-channel media empires, they have staffs with organizational hierarchies. They have like these huge discords. They have all kinds of payments going in and out. It’s no joke of a business. I think people sometimes forget that. 00:32:54 - Speaker 1: Totally. I mean, It’s really hard when, and this is one of the big things that we try to address for writers is, if your business is about you, then every single moment that you’re not making content is a moment you’re missing out on money, and it’s really easy to burn out that way because you have to be on 24/7. If you’re a YouTube star, you haven’t got to produce a video a week at least. A lot of them produce more than that. Casey Neistat, a vlogger, famously vlogged every single day for like 2 years, 7 days a week, while having kids. Like that is crazy. And these vlogs are like edited. They’re not just like 10 minutes of staring in front of a camera, it’s like highly edited 10 minutes of his day told in the story format. It’s crazy, but the same thing is true of writers, like, the fact that Ben Thompson every single day, 4 days a week for years, has to have an opinion. That’s hard. It’s really, really, really hard. And I think that there’s a generation of people who are starting to do that. And in 2 years, a lot of them will be like, fuck, I want to do this once a week, not 4 times a week. How can I do that? 00:33:59 - Speaker 3: Yeah, totally, which brings us right back to the importance of experimenting with these new platform technologies, whether that’s, you know, collectives, I think is going to be an important one. Also different recommendation algorithms can kind of address this by basically helping out people who make good content, but like take a month off, the algorithm can bring you right back and not kill your business. So yeah, much more to explore in this space. 00:34:21 - Speaker 1: Yeah, I think the weird thing is that the algorithms right now are not built that way for creators. They’re not built with creators like mental health in mind. They actually just penalize you if you go away for a while so that you don’t go away. And a lot of creators just end up feeling terrible. And I hope that that is fixed over time. It is within the power of these platforms to do it. It’s not clear yet that they really care. 00:34:43 - Speaker 3: Yeah, or, you know, be the change you want to see in the world and start your own media company where you have different incentives. 00:34:48 - Speaker 1: I mean, that’s what we’re trying. That’s what we’re trying. We’ll let you know how it goes in a couple of years, you’ll have to have us back. 00:34:53 - Speaker 2: And the algorithmic recommendations, and I think that touches also on something you spoke about earlier, Dan, with the audience ownership, the email basically that your writers get the email list, and I think Substack also and maybe newsletters in general, I think part of why they emerged in that moment in time was a sort of Push back to these platforms and their algorithms that decide what you see and people realize that, OK, someone following me on Facebook, following me on Twitter, subscribing to me on YouTube. I think YouTubers in particular, there was a lot of outcry and concern over algorithmic changes where someone can subscribe to your channel, but they still actually don’t even know that you put out. a new video, because the algorithm doesn’t decide to recommend it. And they have this bell where you can get notified. And in any case, I saw a lot of YouTubers basically decide, OK, we can’t have our fate be decided totally by this platform. I need to collect my own email list so that I can let people know when I have a new video, so people that really want to follow me and I can build my own audience and own that separately from this larger organization, this larger company that decides where to take a platform may decide in the future, and I think that’s a lot of where the substack thing came from. OK, here’s still a platform that can help you with, you know, the software and the distribution and the monetization, but in the end, if you’ve got an email address for every person in your audience, that’s extremely portable and you’re trying to do that with as well. 00:36:22 - Speaker 1: Right, totally, and I think that one part of the problem is, even if you are a YouTuber that can ask for emails, your conversion rate from a video to an email is like pretty low. It’s a pretty leaky funnel. You have to go type in something into the URL bar and like put an email and that’s not great. And 2, I think that platforms that are already established and have huge, huge distribution like YouTube, just like. have very little incentive to add the ability to go off platform right now, but I think that younger platforms that understand this dynamic better, so subst is one, I think we are kind of like in between a platform and a publisher in a lot of ways, but we are another where we’re thinking about this from the beginning, are going to be a lot more friendly about that and give creators that option, and I think that these kinds of platforms will end up being dominant over time. We’ll see, but I think it’s the kind of deal that incentivizes creators to use you in a way that they might not use a legacy platform for fear of not really having any ability to access their audience aside from what you allow them to. 00:37:31 - Speaker 2: The positive side of the algorithms for a person who’s consuming media, whether it’s video, writing something else, finding new stuff that you wouldn’t have come across before. This is the classic long tail article, I think from the early 2000s where they talked about, OK, the internet is going to allow us because we don’t have this limited number of channels or this limited number of places to discover content. And therefore, what’s on your television channels when you don’t have that many of them, it has to appeal to a very wide audience. There’s just no space for niche stuff. Maybe cable helped out a little bit, but with the internet, yeah, you can have infinitely long tail and furthermore, you could find it through algorithmic recommendations through a Spotify recommendation or an Amazon product recommendation. Or whatever, you start with something pretty mainstream and then based on those likes, you can in pretty small number of hops get something much more niche and in theory, that’s really good for small creators. 00:38:27 - Speaker 1: Totally, I think part of the problem for small creators right now is that if you monetize with ads and you’re writing niche stuff, you don’t make a lot of money, and so a lot of creators are starting to use subscriptions, and that’s kind of what we overall want to be able to do is You have a bunch of creators who are writing on little niche topics that are all bundled together under one subscription price, so those creators can basically make a subscription, be part of a larger collective, and we can be in the middle kind of directing traffic from readers to the writers that they should be reading. But within a sort of walled garden where not everyone can write on here, it’s like there’s a certain bar for quality and a certain tone that we want to meet, and then within that we are kind of making connections between writers and readers and distributing the subscription to the writer that is driving most of the reader attention. 00:39:17 - Speaker 2: So you’ve curated the writers, the topics, there is a kind of, if not a unifying brand voice, then at least maybe a general vibe that cuts across it, unlike a YouTube or a Facebook or a Twitter, that’s just wild west, anyone can post anything. But at the same time, you could potentially. This is where your background as a software entrepreneur and just the affordance of the new tools, unlike those traditional media, you know, the newspaper that’s delivered to your front door, you can send someone an email that is, here’s things that you will like based on your past interests the same way that Spotify does. 00:39:54 - Speaker 1: Exactly, and this is something that my co-founder Nathan, who first employed Substack, he basically built our entire CMS almost by himself. We also have a couple developers who are really talented, but it’s really a lot of him, and I think this is one of the things that he is most excited about and pushes deeply is that we have this like, I think one of the things that we have that I will say is rare, which you tell me if it’s rare, is we both really, really like writing and are good at it, and care a lot about the written quality of the product in a way that I think is similar to a lot of the like. I don’t think we’re as good as the New Yorker or Harvard Business Review, but it’s similar to the attitudes that a lot of those people have, the reference that they have for writing, and we both also, and Nathan really primarily leads the way here, but we both also have this like product DNA where we’ve built software products before, and we know how that works, and we’re trying to figure out if you put those two things together, what can you make? And we have a bunch of ideas for what can come out of that, but we think that that’s somewhat unique in the kind of media landscape. Usually you’re one or the other. You’re either like a product person that is like trying to build some sort of aggregator or platform and you don’t really have too many opinions about the writing, or you’re a writing person and you’re just kind of like, I use a WordPress, you know, and if you can be kind of in the middle and have both, like what can you do? And that’s the animating force behind every. 00:41:15 - Speaker 2: Yeah, that’s really interesting and I agree that that is part of what makes your team unique. And I do wonder how you balance those, which is, I think curating great writers, providing those editorial services, really caring about the content. is one whole huge job, and then there’s what I would call the software business side of it, a lot of which is just, yeah, you built your own CMS so that means, you know, you got to spend time on, does it work in this browser. What about this responsive design thing, oh this person’s having trouble logging in because of this, that and the other thing, the payments. You know, all that stuff. So do you find that you’re sort of pulled in two directions, or do you have a good way that you even think about how to allocate like your own time, but also your team time? Do you think, OK, we got to put 70% into the writing and the curation of the great content because that’s what it’s about 30% of the software, or how do you find the balance there? 00:42:11 - Speaker 1: Yeah, it can be hard, and I would say most of the burden is on my co-founder Nathan, but I think first of all, at the heart, we know that the business survives or dies based on the writing. It’s not based on the technology. The technology is going to help the writing reach the right audience and it will be a multiplier on the quality of the writing, but like if the writing is a zero, the technology can’t do anything to fix that. So, the heart of it has to be the writing, we have to get that working and get people excited about the things that we’re writing and then on top of that, the technology is the thing that can help us, you know, if we want to, for example, have a bunch of overlapping niche audiences that we’re serving. It can help us figure out, OK, who should see which article. It can help us figure out, OK, who should get paid based on this reader’s behavior or the survey that this reader filled out, like, there’s all these mechanics of the business that the technology can help make smooth and work better and especially scale better as we get bigger, but the heart of it still has to be that really high quality writing. And I think it gets back to this thing that you mentioned earlier, which is that we’re not totally bootstrapped. We’ve raised some money, but we haven’t raised so much money that we can just like hire a gigantic engineering team and like not have to worry about it. Like, we are constantly thinking about, we have a small team. We have technology to build and writing to produce, and we’re constantly thinking about what should we do and where should we focus our resources, and that can seem painful, but I think it’s more like the kind of pain that you get working out at the gym versus like the kind of pain that’s gonna like really end up holding you back, because When I think of venture money, especially for business like ours, like a media business, it’s a little bit like an anti-gravity machine, and if you’re in the anti-gravity machine for too long, your bones get weak, and it’s much better for us right now while we’re still kind of figuring out the model to have some gravity. We don’t want full gravity, we’re not at like 1G, we’re at like, you know, 0.8gs or whatever, because we have money in the bank and we can run experiments and all that kind of stuff we don’t have to be profitable every single month. But we have enough drag or enough gravity to deal with that we can’t be stupid for too long, and that is, I think, really, really important. So we’re kind of constantly figuring out what’s the balance between these two parts of the business, and we know what the focus is, and we just got to make sure that we’re balancing things correctly. 00:44:28 - Speaker 2: That’s really well said, Mark and I in many episodes and many different forums have talked about venture money and yeah, the Silicon Valley Standard Model and some of our pushback to that, which is why we’re doing something a little different with Muse, but also part of the reason it’s a reference point is that it is this incredible thing to get a bunch of money to work on an interesting problem space, especially in an emerging domain where there’s so many unknowns, you just don’t even know what the opportunity is because all the variables are in play. And so if you’re totally focused on survival and earning money from customers so that you can keep your lights on from day one, that can hold you back from being experimental, seeing all the opportunities, trying weird stuff, but the other extreme which is having so much money that you don’t really Feel the, it’s called the discipline of the market, the real world, kind of like peering over your shoulder and sweating a little bit. When you see the bank account balance ticking down, then I think you lose touch and become free floating, ivory tower, as you said, you’re more likely to do things that are unwise. So I think there’s a middle ground there. I’m very much in favor of businesses taking investment. But I also am really in favor of not taking too much investment, even though that seems like a good thing. So I actually find myself in when I’m just like having kind of, let’s call them advisory calls with people, people that come from a really strong bootstrapping mindset of like, I’ll never take investment. I end up trying to convince. them know, you should take a little money, but then people who come from more of a Silicon Valley, or they just see, oh, great, I can raise 10 million bucks for basically me and my two friends and our idea, and I go, wait a minute, I think you’re setting yourself up for failure by doing that, you should take less or try to be more close to the middle, you might say. 00:46:16 - Speaker 1: Totally, yeah. I mean, it’s been a journey for me. My previous company was bootstrapped and I was never like outright against taking money, but I felt like I wanted to prove a lot before that seemed like a good idea. My default is for any business, like don’t take money, basically. My co-founder Nathan is the opposite. He took money for his last business and I think his default is to take money for various reasons. One is just like money and people help you kind of figure out your business, and then another reason is Being able to participate in the venture funded entrepreneur community is like a real benefit as much as bootstrapping is an identity, being a venture backed founder is an identity, and it’s a little scary to like take yourself out of that if you’re in it. I was a little bit more bootstrapper identity, and he was a little bit more venture funded identity, so we had to kind of like figure out how do we merge these two things, because there are real things that bootstrappers feel that are worth taking into account when you’re thinking about how to build a business and they’re a real thing that venture funded entrepreneurs think about, and they’re real trade-offs to each. And so how do you figure out the middle ground or figure out, not even a middle ground, but like a smart way to address each of the concerns and each of the benefits of both paths. And so where we came to was, let’s raise some money. We’re going to raise some money from A venture fund and some smart angels who we think are going to be able to help us. So we raised about 600, 700K led by Bedrock, who’s the main investor in the athletic, which is a big consumer subscription media company that is very similar to the kind of business we want to build, so we have and we raised pretty much of. So we have smart people on board, we have some money where we can experiment, but when we raised it, we said very clearly to everyone, like, this might be the last money that we raise, and we’ll raise it in a way that if we don’t raise more, it’ll convert into equity. So, you know, you’ll have a chunk of the business and all that kind of stuff. So it’ll give us time to figure out what kind of business this is. And if it is a venture right business, and we do overall believe that this is going to be a big business, and that’s what we want to achieve, it just may take longer than the venture timeline allows for. And if it does end up becoming a venture backed business, we will raise more money. And if it doesn’t, and we find that it’s not exactly that shape of business, we still want to have people on board and want to have the optionality to take that route without it kind of being taken off the table too early. And I feel really good about it. Like, I feel really good about having taken money. Had never raised money before, so going through a fundraising process was kind of fun. I’ve been an investor, so I’ve seen it from the other side. It was very interesting to get to do that and actually kind of fun, even though it was stressful. And I don’t think it has materially changed how we think about the business. It has just allowed us to do more, a little bit more quickly and not have to worry as much. And we’re still in some gravity. So we’re still finding a shape of the business that can survive without having to pump more money in every 18 months. And I don’t know what the future holds, but I feel pretty good about this kind of path for us. 00:49:05 - Speaker 2: Well, before we go, Dan, one thing I’d love to get your take on is how the changing media landscape here, for me, there’s these very deep questions about who we trust to help us interpret and understand the world. For example, when there’s something in the technology world, there’s technology news, some big company goes public and I think I want to understand what this means exactly and who do I go to. Do I go read Divination, which is Nathan’s newsletter? Do I go read Ben Thompson and Strachery? Do I go read The Generalist, for example, and this is also true for political events and every other part of understanding the world around us and how it’s unfolding. And you’ve talked about the history, we’ve talked a lot about the history of these big institutions, the New York Times and whatever, and where all this kind of trust or what Mark calls capital that accrued to these long term brands and institutions, the writers then were kind of cogs in the machine for maybe now we have this more transition to yeah, individual YouTube personalities, individual writers on substack, people where I follow this one person and I trust them and their voice. How’s that gonna evolve, do you think in the coming decade, let’s say? 00:50:17 - Speaker 1: I think that there’s obviously there’s a lot of issues of trust at the heart of our society. I don’t know that I have like a answer for like how we begin to trust, cause it’s not just journalists, as politicians too, it’s like our socio-political establishment more, that feels like definitely outside of my pay grade, but I do know that when it comes to business topics, people feel like They’re less likely to trust Business Week or like Bloomberg or Entrepreneur magazine to like really tell them what’s going on, and they’re more likely to trust certain individual voices that have experience and credibility on a particular topic to help them understand the world. And you’re seeing that kind of play out as you mentioned with like voices like Ben Thompson or Nathan writing divinations where people go to him because they know his background and experience is relevant to the topic that they want covered. And I think the problem with that is being someone like Nathan or being someone like Ben Thompson, where you’re one individual voice, and you are the publication in its entirety, is it’s really fucking hard to do that for years on end. You have to be Willing to grind it out for day after day after day and constantly be putting yourself out there in a way that most people are not prepared for, and in a way that like a lot of topics are not well suited to. If you’re going to be a person like that, you have to have a specific beat, there has to be news a lot that you can comment on really quickly. It’s not particularly good for someone who’s doing a lot of like long detailed reporting or in-depth thinking about a particular topic. You basically do all the thinking and put out a couple of those big Essays like aggregation theory, and then you just continually refer to them every single time a news event comes out. And so what I think we’ll we’ll see over time is writers and readers beginning to realize that there’s a lot of benefits to being attracted to a specific voice, but there’s also a lot of drawbacks to like, subscribing to like one man or woman publications. And what we’ll find is, I think more collectives people emerge where writers are navigating the trade-offs of being part of a group and also trying to retain a lot of the things that they got used to or would have come to expect from writing on the internet, which is like upside and money and all that kind of stuff, and we’ll we’ll see groups emerge that are voice focused, so when you subscribe to the publication, you’re doing it because it has a writer or two that you really, really like and trust. And the writers are compensated in a way that reflects that reality. I think you’ll see that in writing, you’ll see that in other types of content creation like video and audio and all that kind of stuff is, it is generally better if you can do it to be together rather than alone. It’s better to share the load. And people are going to try to find new models for being together that are more reflective of the new reality of what it means to create stuff on the internet, and that’s what we’re trying to do. We have one way of thinking about it, but there’s going to be lots of other people that are going to try to do it, and I think one will emerge as kind of a new standard over the next 5 to 10 years. 00:53:24 - Speaker 2: Well, let’s wrap it there. Thanks everyone for listening. If you have feedback, write us on Twitter at MuseAppHQ or on email, hello at museapp.com. Really helps us out if you leave a review on Apple Podcasts. Dan, thanks so much for letting me follow along with the every journey so far. It’s made me, I think, much more aware or just interested in what’s happening in the media landscape, which I think is not only intellectually interesting, but probably important for our society. So looking forward to seeing the next steps in that story. 00:53:57 - Speaker 1: Thank you, thanks for having me.
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: Which by the way, something that’s a little bit unique to digital systems versus classic analog systems, you know, if your wrench is rusty or doesn’t work as well, but it still basically works as a wrench, whereas if you have one bit off in your software, just crashes, you know, you’re out of luck. 00:00:21 - Speaker 2: Hello and welcome to Meta Muse. Us is a tool for thought on iPad and Mac. But this podcast isn’t about me as the product, it’s about me as the company and the small team behind it. I’m Adam Wiggins here with my colleague Mark McGrenigan. Hey, Adam, Mark, you were giving us a very interesting little workshop at a team summit recently about the use of iPads in aviation. 00:00:44 - Speaker 1: Yeah, so aviation is one of the most interesting and powerful use cases I’ve come across for iPads in the wild. It’s so powerful and important that folks are willing to spend $100 200 dollars, $300 a year for high-end aviation-related iPad software. So there’s something right going on there, no pun intended. And as I’ve been exploring that world, there’s a very interesting contrast and sort of technology share between these super shiny iPads and this new software that’s being updated constantly, and the very old general aviation aircraft you tend to see out there. This is the Cessna from the 60s, which by the way, is basically exactly the same as it was 60 or 70 years ago. And then they’re being flown with these iPads from 1 to 2 years ago, and it’s very interesting to compare and contrast those worlds, and it led into this topic today actually because we were noticing that longevity of the aircraft versus the almost ephemerality of the iPads and the software and how much churn there seems to be in that world. So we want to dig into it on the show. 00:01:51 - Speaker 2: So Cessna, which is kind of a small private plane, is an extremely complex piece of technology and also one that is used in very high stakes situation, i.e. if it fails, you fall out of the sky and die, and it has very complex controls as well, but those are all I guess analog is the right name, but, you know, again, they look the same as they did in the 60s, even new ones built today, and the ones built in the 60s, they continue to, essentially, you need to maintain them, you need to replace parts and upgrade them to comply with newer aviation regulations, but Again, they haven’t changed much in that underlying technology and that’s so wildly different from the world of not just iPad, but software and internet in general where change is at an incredible pace and in fact that’s probably desirable in this what’s the piece of software that’s kind of the commonly used pilot software. 00:02:44 - Speaker 1: For flight is the most common one. 00:02:46 - Speaker 2: So that’s got maps, it’s got weather, it’s got flight routes, it’s got locations of other planes, all of the stuff is being presumably downloaded or even streamed in through APIs. It’s all very real timey and current information, and you want that, in addition to just keeping up with all the new capabilities of the iPad. So you get maybe that separation is nice, you get the benefit of the really fast moving software and internet world that’s on this device that’s strapped to the pilot’s knee, but it’s completely decoupled from the safety reliability oriented core instruments that are built into the plane. 00:03:24 - Speaker 1: Yeah, researching this reminded me a lot of navigation in cars. So my experience has always been if you buy or if you see a car that has like built in navigation, it’s always gonna be bad because it was designed 2 to 4 years ago and it wasn’t designed by a software company, but everyone just wants to use their iPhone, right, to navigate and they want to be able to plug it in and have it just their iPhone apps be displayed in the car. That’s a good way of embracing the reality that there is some shear between those two layers in terms of how fast the technology tends to evolve. 00:03:54 - Speaker 2: So then our topic today is software longevity, and I think you can slice this two ways. One is the software itself and how long that lasts or how durable that is, and then you can also cut it the other way, which is, yeah, software is eating the world or is invading everything from, you know, toasters to cars, and how does software’s dynamism impact the longevity of everything else as it creeps its way into the rest of our world. But as always, I like to start at the very beginning. So I guess first I have to ask what it means to you to talk about something being long-lived or having longevity, whether it’s software or a plane or something else. 00:04:35 - Speaker 1: Yeah, I think it’s the software being able to serve its stated purpose, which sounds very straightforward but has several important constituent parts. First of all, you actually need the software, you know, sometimes we just lose it. It needs to run, it needs to run correctly and needs to have access to the relevant data, needs to have access to the relevant pieces of the outside world in terms of APIs, and it needs the appropriate substrate to run on and interact with, and that’s probably other pieces that we could come up with. But there’s a lot of moving pieces that go into the software actually serving its original end goal. 00:05:07 - Speaker 2: For me thinking about that word longevity. I tend to think about what is long, I guess, what is a span of time that counts as long and of course it depends a lot on. What you’re talking about. So if you’re talking about all of society, culture, humanity, then perhaps you’re talking in the thousands of years, hundreds or thousands of years. So for example, the long now is a phrase that we used in the local first paper, we tend to use it internally on our team to refer to longer term thinking. This comes from the Long Now Foundation and the Long Now clock project, which is sort of this idea to build a clock that can keep time for, I think it’s 10,000 years. And it’s basically an art project, but it’s designed to inspire us to think longer term, and that can obviously connect to things about climate change or human culture, and since humans are naturally inclined to think probably pretty short term, actually really short term, we think about the day that’s ahead or the week that’s ahead of us, maybe at most, the year that’s ahead of us, we don’t tend to think in 10s or hundreds or thousands of years. So it’s maybe a society level thing. I think for individuals and thinking about, you know, softwares that impacts our lives as individuals, I think there a human lifespan actually is a pretty good chunk of time to compare something to. One interesting subreddit that I stumbled across years ago and still subscribe to is called Buy it for Life, and it’s essentially people just posting. Photos or anecdotes of products they purchased, they’re often something like a cast iron pan handed down by their grandfather or a pair of work gloves they bought 30 years ago that are still working just as well as the day they were purchased, and I think implicit in that is that there’s some kind of inherent beauty or virtue in something that does have this long lasting value versus something that’s more flash in the pan. And it’s interesting for me to try to tease apart the pragmatic aspect versus the, yeah, that inherent beauty. Which again, it feels to me like a virtue, but I’m trying to like dig a layer deeper and see if there’s something practical that drives that. Maybe it isn’t, maybe it just comes from a place that it seems right to me that something like products you purchase, that their lifespan of the product could be measured in something that is a portion of a human’s life that’s not thrown away in a month or a year even. 00:07:32 - Speaker 1: Yeah, and I think we can come up with a few good reasons why longevity is valuable. The zero reason would just be economic, depending on how long lived a product is, it has different economics. On the one extreme you have consumables like toothpaste, you know, you use your toothpaste, it’s gone forever. On the other extreme, you might have. Extremely durable things like stone tablets and mason reconstruction that could last hundreds of years. And in the middle you have the classic capital goods, durable goods, things like really nice hand tools or really well maintained car that you expect to last at least several decades, potentially longer, like you were saying a lifetime or more, and the economics of those things are all very different. This goes a little bit back to the pricing podcast that we had a while ago. Another thing is I think just continuity, like, for example, if you run a business on a piece of software or you run your own creative process on a piece of software, there’s real costs to churn in that. And another thing would just be preserving history, you know, having access to the past. I think this is especially important with software because it’s very easy to lose that both in the sense of the software itself and the data that it was manipulating. 00:08:36 - Speaker 2: And that side of it makes me think of some of these submergent field of sort of digital preservation, archive.org is probably the one of the biggest players they’re doing incredible work to save copies of websites, but also product manuals and old video games, and indeed other kinds of software. And maybe that brings us to, when you do leave the world of durable goods, it brings us to the world of information and information longevity. 00:09:02 - Speaker 1: Yeah, and one other point I want to add relates information is, I think there’s a dimension of longevity, which is, and I’m gonna make up a word here, roll over ability, you know, the ability to buy a new or get a new version of something that rolls over your previous state. So for example, like maybe you rebind a book or something in that way roll over the pages, or you can put a new engine and transmission in a truck and you roll over the truck frame. But some stuff can’t be rolled over. Classically the black box data, just some opaque binary format now you basically like once that software is gone. So I think that ability to roll over is an important dimension, even if it’s separate from a single instance having long longevity. Hm. 00:09:42 - Speaker 2: Yeah, well, information has this particular property that exists on a substrate or a medium of something physical atoms, but in the end, the information is not the physical thing. So, the book rebinding example, you can either rebind the same book or in some cases just transcribe it completely and as long as it’s a correct and accurate copy. Older books are an incredible artifact, maybe they have margin notes, something about how the pages were made or whatever does carry some history. There were the artifacts and objects of their own right, but ultimately the contents, the words on the page are probably what we care about. And so on one hand, information technology has actually been getting worse in the sense of the durability of the underlying thing, right? stone tablets were very durable, papyrus and later paper were less so, then we go into the digital world and it’s actually vastly less so, you know, everything from CDR. to cloud storage, the failure rate is pretty high, but because it is so easy, cheap to copy those bits from one place to another, to replicate it, you potentially have the ability to roll it forward as far as it’s worth your while to do so. Right. Then if we sort of come to software as a special class of information, and it is information, but it’s highly dynamic, and I think that points to some of the particular challenges with it in, I guess that would be sort of the first category that I mentioned there at the beginning, which is the software itself and its ability to be long lived. And I think some of this is cultural, you know, the tech industry is dynamic, it thrives on change, that’s sort of the nature of it and many things that are good about software and the internet and the tech world come from that willingness to embrace the new and almost an endless seeking of novelty. But the downside is, yeah, you get something that is not just an upgrade treadmill, but it just seems like it can be very much the case that the lifetime of a product or of data or any particular piece of software can be measured in Again, years and only a small number of years, which is comparatively just a very, very short time span. But I guess one question is, why is that? Why should software sort of default beyond just sort of tech? Maybe that’s what it is, but I, I feel there’s more to it than just culturally, the tech world doesn’t do the buy it for life, built to last thing. I feel like there’s something inherent to the dynamic information nature of software that makes it hard for it to be long-lived. 00:12:11 - Speaker 1: Yes, I think that’s true. There is a lot of things that need to go right for software to work, and you can see it in fact as something that’s strictly harder than preserving simple textual information for the following reason. You have at least that problem to start because you have the source code, then you need to preserve information about the dependencies, you potentially have the compiled source. And then you have the whole run time around it very broadly defined, you know, the computer, the APIs, maybe even the data, and it’s just a very broad multi-dimensional, and in many cases ill specified. State space that if you don’t get your thing exactly right in that state space, it doesn’t work at all, which by the way, something that’s a little bit unique to digital systems versus classic analog systems, you know, if your wrench is rusty, you know, it doesn’t work as well, but it still basically works as a wrench, whereas if you have one bit off in your software just crashes, you know, you’re out of luck. It’s very high dimensional and it’s very sensitive to errors in preserving the environment. 00:13:15 - Speaker 2: I think it’s one wants to even think of a binary artifact. So here you’ve got a compiled executable, you can download it, you don’t need the dependencies, you don’t need the compiler chain, and I think there’s the feeling that shouldn’t that just kind of work forever, but of course it’s as you said, it sits within this context of the system. If it’s accessing files on your file system, it’s calling out to APIs on the network, it’s accessing APIs in the operating system, even something like it just makes assumptions about what kind of hardware exists on the keyboard and mouse as being standard input devices that exist, and then you go onto a touch device and those aren’t there. And so over time those fundamental assumptions and APIs and the system changes around it. And I think that’s gotten dramatically more so with the internet, where you might call out even something as simple as a static website that has a Google Maps embed. Well, now, a big portion of that website, this big pain is depending on this exact integration to the service, and that that service is still online. And so I think that the one-off binary build shouldn’t have worked forever, does make some sense, for example, games, which kind of don’t have as many hooks, so let’s say just like a single player game, not some Complicated cooperative thing, but it tends to have very simple inputs and outputs. Displays things on the screen, maybe it needs to save a high score file to the disk as opposed to productivity software where all those little integration points you drag and drop and how do you open a thing in the browser and what all the different APIs that use to be a good citizen on the system, and those change all the time. They should with an operating system that’s growing and improving and evolving, but then that means the apps have to keep up with that, and if they don’t, they fall out of date and eventually either become Somewhat irrelevant or more commonly just stop working. 00:15:05 - Speaker 1: Yeah, I think this idea of the complexity of the surface area and the APIs is very important. You mentioned games. I think we actually had it much easier back in the good old days of games where he’s had keyboard input, mouse input, you draw to a pixel buffer, and that’s it. The issue with games now in addition to stuff around networking and multiplayer is the graphics pipeline is incredibly complex. And unless you end up emulating earlier versions of graphics pipelines, I think there’s little chance that this stuff rolls forward, whereas you could plausibly roll forward writing into a pixel buffer, you can kind of go the other way. You can emulate a pixel buffer with our advanced graphics APIs today, but you have no chance of going the other direction. And I think this generalizes to API complexity broadly, and it’s one of the reasons why it’s gotten so hard for software to persist. 00:15:54 - Speaker 2: Games also make me think of the, we’re speaking briefly about the Internet archive and yeah, you mentioned emulators, and it turns out that games seem to be both something that people do want to preserve as a cultural history, but in a way, the best way to do that is not try to get the original hardware, but in fact, just to have these emulators like Maine, for example. And it’s really impressive, yeah, you can play almost every arcade cabinet video game from the 80s, just in your browser with these kind of JavaScript emulators that would load up the ROMs, which are basically the way they distributed binaries in those days, and play them, not quite as they were intended, because again, the hardware is different. Certainly the displays are different, but certainly we do preserve some of that legacy. Now another one from Games that maybe is your roll forward idea. I really like what ID software does, which is they take their classics, Doom and Quake, and so on, and after, I don’t know, they’re 2030 years old, something like that, they open source them. And that creates this interesting effect where maybe it’s less that people are playing the original, although I’m sure that happens. But then it becomes fun to just port it to weird places, right? Like you’ve seen quake that’s been ported to like be 100% Asky. I think I saw a Twitter thread recently where someone managed to, they broke open one of these digital pregnancy tests, realized that it had a reasonably good processor and display in it and decided to like get Doom running on it. Oh yeah. 00:17:24 - Speaker 1: Yeah, it’s a whole culture, you know, people running on the refrigerators and exactly, yeah, so in a way, it has turned this over to remix culture and the internet. 00:17:28 - Speaker 2: And so it gets rolled forward and becomes something that maybe people will experience none of this original form necessarily, but becomes woven into the cultural tapestry, let’s say through these fun little projects. 00:17:46 - Speaker 1: I think this also speaks to the importance of that API environment that we’re talking about either being specked or at least specable for the software to be rolled forward or actively preserved, either one. Like we’re saying, old timey games, that’s a pretty specable environment like you need to build a compile C and relatively straightforward input and output. System and even if the games weren’t designed specifically with a really clean interface there, you could basically back it out after the fact and then do the porting. Books and paintings, by the way, are examples of analog things that are very specable. They map down to text streams and bit maps respectively. But some stuff like our modern software is much more difficulty being specked, and so it becomes harder to do that sort of rolling forward or active preservation. 00:18:34 - Speaker 2: Now, some have argued that perhaps part of the challenge here is the rapid pace of change of that underlying system of those APIs. I think it’s interesting here to contrast the Apple versus Microsoft approach. So I think that, you know, Microsoft with DOS and later Windows really focused on backwards compatibility, quite an impressive level. I’m not exactly sure when the cutoffs are, but I think you could run DOS stuff natively on Windows till well into the Windows lineage, and then Much later versions of Windows could run much earlier versions, but that’s part of, I think what also created the relative instability and unreliability of that line of operating systems, such as when you need to support every conceivable thing that’s ever existed in the past and put it all together in the same box, things get messy pretty fast, and Apple, at least with the iOS world has gone very much the other route. Which is they basically are releasing new stuff, a new OS update once a year, and if app developers don’t keep up to date, you pretty quickly just fall out of the App Store. So, I experienced that with, I wrote a little puzzle game for the iPhone 10 or 12 years ago, I think it was on like iOS 3. And yeah, my collaborator did some work to try to rebuild it with the new stuff and keep it in the app store, but I think by OS 5 or 6 it just fallen out. And it’s a shame there’s basically no way to play this game that was, you know, fun side project and we spent some good effort on it’s just sort of lost to history because you have this very kind of demanding operating system that requires developers to be doing active maintenance or else it tends to go away. 00:20:16 - Speaker 1: Yeah, and while I don’t doubt that there was some contribution in the Windows situation to instability from needing to support all versions forever. I think what really gets you is when you need to do that and things that are really end user facing like visual in particular, because the strategies that you typically use for providing stability are not viable in that world. So if you look at things like Unix style server operating systems, many programming languages, these are things that can have backwards compatibility for a long time, certainly decades. But the way they do that is they just never ever ever ever break any APIs and if you want to do something new, either A too bad or B, call it thing 2 and just keep thing one around forever. 00:21:00 - Speaker 2: Python 2 versus Python 3 comes to mind. 00:21:03 - Speaker 1: Oh yeah, well that one, that’s a whole thing. There’s an element of that of not wanting to break Python too, but even just individual methods, you know, when we write our own programs, we think of, oh, we need to change the method, just like edit the source code. Well, not so much if you have the entire universe relying on thing one, you just gotta keep thing one around forever and write a new thing too that people can call into. Anyways, you can’t really do that with like a windowing system, for example, or a user interface paradigm or how things look on the screen, right? You just gotta pick something and do it, and the old thing needs to go, and so I think it does become very hard to have that culture of very long lived durability that you see in some of these more systemsy programs. 00:21:43 - Speaker 2: Yeah, maybe that points to the fundamental trade-off there, which is durability in many cases means stability, which means less change. But change is how we get things that are new and better in the world of technology and computers and the internet is so at the very beginning. There’s so much unexplored space, and it would be a shame if we just said, OK, well, we’ve been working on making these computers here for a few decades now. Yeah, pretty much how they are is probably it, it’s probably good for the next several 100 years. Let’s just hold it there. That’s not what we want to do. Uh, we want to keep changing and improving. So, yeah, there just is a trade-off between those two. 00:22:18 - Speaker 1: Yeah, I think there’s a very real tension, and I agree we want to keep exploring. I do think that in adopting this attitude of exploring and taking risks, we are going to find some things that in retrospect were not good choices. The intuition here is, I think we’re projecting these very dynamic system benefits over lives that we have historically associated with durable goods, you know, so we get the shiny new computer enabled software enabled thing. And it works great the first year, and we think things like this, before we had computers, they worked for 20 or 30 years, therefore this thing is gonna work for 20 or 30 years, and it’s gonna be awesome. And we’ve kind of projected that all forward, and I think in many cases that’s not gonna be true, and so we’re going to have to confront the downside of that trade-off. 00:23:04 - Speaker 2: And do you think the downside there is mainly economic? You buy the smart refrigerator seems great for the first year, some cloud service goes offline, suddenly your refrigerator doesn’t work anymore and you got to throw it out and get a new one, or do you think there’s something beyond the economic side? 00:23:18 - Speaker 1: Unfortunately, I think there are several potential very serious downsides. And just to give you a couple, one that we’re already seeing is this issue of repairability or even modifiability. Again, if you look at these durable goods categories like tractors is a very prominent example right now. Traditionally people could service and maintain and change and modify and improve their own tractors, but as tractors increasingly become like iPhones, you know, these black box computers in many ways are highly computerized hardware, potentially you can’t service them yourself, you can’t repair them yourself, you can’t modify them yourself, and that has all kinds of second order effects. There’s also this whole thing about like surveillance basically, that I think we’re sleeping on a little bit, but we don’t need to go down that whole road today. 00:24:08 - Speaker 2: On the economic side, I think there’s also the incentive, which is basically Apple and other phone manufacturers have done very, very well by always creating that shiny new. The thing that comes out every year or two and you think I want to upgrade, it’s even often built into cell phone contracts and things like that, that people want to get a new phone very frequently, and I think that’s paired with sometimes the operating system upgrades or maybe the visual refreshes. It’s almost more like fashion, right? The fashion industry found this very clever way. To get around the fact that their IP isn’t really protectable, which is they just make new fashion trends that totally change for a couple of years. So then you like need to go out and get a new wardrobe. It’s not that the clothes wore out necessarily. It’s that you want to be up to date and you look behind the times when you’re strolling around in your bell bottoms and those have been out of fashion for 3 years or whatever it is. Yeah. And so I think there’s an element of this kind of a fashion desire to get the new thing. That has driven a lot of revenue for, for these companies. I don’t mean to imply that that’s some kind of a cackling in the back layer, they’re using this opportunity to prove and genuinely make their products better, you know, each version of the iPhone has a better camera, that better battery life, the bigger, brighter screen, it is genuinely better, but it’s also the companies are very incentivized for a high pace of change that has you buying new products all the time as opposed to something longer term. All right, so let’s say for the sake of argument that we’ve decided that longevity in our technology products is desirable, whether we because we think it’s about preserving history or because we think there’s inherent beauty and timelessness, or we think there’s a good economic argument. What can we do as engineers and designers and product managers to make our software stand the test of time? 00:25:55 - Speaker 1: Yeah, I do have some techniques there. I do have to preface it by saying that I think there’s a large element of just draw the owl here. I don’t know if you’ve seen this meme before. But you got to sit down every week for 30 years and make sure the software doesn’t break. And that’s sort of a necessary but not sufficient condition, I think. 00:26:13 - Speaker 2: And the implication there is also just maintenance, right? And that maybe ties into some of our discussions about sort of software supported by subscriptions versus one-off payments, which is it really is an ongoing effort, an important ongoing maintenance effort rather than a one and done. 00:26:32 - Speaker 1: Now that said, I think there are things you can do to make this maintenance effort much more feasible. One thing we’ve alluded to is this idea of narrow defined APIs, your software has to run in something, and the broader, the more complex, the more ill specified that environment is, the harder it’s going to be to do this job of keeping the software running. And this would include things like taking on few dependencies. Minimizing weird binary compendencies that are hard to compile, limiting the APIs that you access, things like that. Another thing that I’m very big on is really focusing on data. Often, especially in this world of rolling forward over multiple generations, what you really want to keep is the data. This is more true probably for like productivity type stuff than games, for example, but data is very important and if you want to roll forward data, you either need to adopt an existing open data format, existing data format, or you need to do your own, which can be done, but it’s a lot of work. I think that programs or program lineages, if you call it that, embrace this idea of really focusing on the data so that that can always be ejected and rolled forward into the next generation of software. 00:27:47 - Speaker 2: And one good example of that from my personal life is I’ve had the same calendar in some ship of thesis since, I think I started using a product called 30 Boxes, I don’t know, 15 or 20 years ago was my first kind of like digital online calendar, and then have migrated from one to the next as new stuff comes along. And hopefully there are some standard formats here, I think it’s Calav or something like that. There are also, I think these companies are often incentivized to make importers where you can kind of slurp down from the other company’s API or whatever your existing calendar, but it would just make it much harder to move forward. I probably could, but it’s just I do put things on my calendar that are either annual recurring things like, you know, pay the taxes, but also things that I really wanna make sure I remember that are pretty far out, and I like having that history in the past. I like to know when a particular thing happens, so I can look it up occasionally. So having that my calendar is something that for me feels distinct from the particular calendar software I happen to be using at the moment. 00:28:51 - Speaker 1: Yeah. I also think there’s a social slash community element here, where if the thing that you’re building is used and demanded by a lot of people, there are a lot of forces that are going to be pulling in your direction for that thing to be preserved. It’s kind of like this data quality issue that I think we’ve talked about before in the podcast where the quality of data tends to be determined by how often and carefully it’s read, not how often and carefully it’s written, and I think similarly with software, if you have many people constantly trying to run the program in different environments that will encourage it to become persistent. And that by the way, goes down recursively to your dependency. So one of my favorite examples is Site. If you use SQLite to write even your semi custom data format, if you write it into SQL database, you’re absolutely going to be able to read that in 30 years, even if you do nothing yourself. Whereas if you roll your own format on disk, there’s a very good chance that it will at some point become totally lost. 00:29:49 - Speaker 2: Yeah, SQLite I think is a favorite example for us in many cases of sort of well made simple software that does one thing and does it well. They have a great page though about their long term support. I’ll link that in the show notes, where they list off some techniques like testing and making their database files cross platform and disaster planning and not embracing hot new technologies with too much gut. But actually, I think one of the things that points to that to me feels like maybe the most fundamental is to just think about longevity in the first place and just care about it in the first place. Part of the reason I thought this topic would be an interesting one. I think again, tech industry skews young. I, I think also had the same. What is it like gap in my thinking as a younger person, which was I just didn’t have the longer experience to be able to see what it is like for a software that I’ve created that’s in production for 3 years, 5 years, 10 years and longer, and what happens over time. So part of what I like with the SQL Light long-term support page is they basically lead with a statement of our goal is to support this until the year 2050. And so, will they achieve that? Hard to know, but just by like making that statement, calling it out as a value for themselves, and thinking about it actively, maybe this comes back to the long now clock idea, which is, they may or may not succeed, but certainly one good way to not succeed is to not think about it in the first place. And so this makes it a first class concern. 00:31:20 - Speaker 1: Yeah, I think that’s a good point. You gotta think about longevity for sure and for me that circles back to this idea of data. I see people typically design and implement programs again thinking, for example, productivity type software. We tend to focus on the interface and the behavior because that’s what users are demanding, that’s what the short term success of our business depends on. But the reality is that interface, including its implementation, is going to almost certainly fully churn, at least once, potentially several times over the course of software, but what’s not going away is data. And so one thing that I think is helpful for longevity of software is really focusing. On the underlying data model, not only in the sense of how it’s stored, which is mostly what we’ve been talking about in the podcast so far in terms of text files or SQL light, but also what is the data model itself, like if you were to draw out the SQL tables or equivalent, what are the boxes and what are the labels on them, it sounds really basic, but it’s a step that I feel like people often skip over and then it leads to all kinds of longevity headaches down the road. 00:32:21 - Speaker 2: Futureproofing, I think is a word we sometimes use in general for talking about helping things be longer lived, but certainly I think that’s most notable in the data model, precisely for the reason you said, it’s just much less changeable and harder to change, and heavier weight to change. 00:32:37 - Speaker 1: Folks, you want a practical tip? Here it is. Put a ID on everything, put a version on everything, and only write new data, don’t plete all data. 00:32:45 - Speaker 2: Yeah. That is a deceptively simple list, but I think it probably reflects some pretty deep, I’m guessing painful experiences in your career. Got any war stories for us? 00:32:58 - Speaker 1: Well, the version one, I remember well, cause you’re the one who taught me. We were working on the Hiroku runtime, where the runtime builds applications into binaries and they are deployed and run. And I was working on, what the time was the unlabeled version one of the system. And you point out, Mark, I’m sure at some point we’re going to have a different version of how we package up these files. So I’m going to give you a tip, which is that you should write version 1 next to all of these, and then when we go to do version 2, it’ll be a lot easier. And sure enough, that made a huge difference, and we did eventually get to version 2 and then 3456, I think after that. 00:33:37 - Speaker 2: And that was something at that point, you know, you were earlier in your career and I had had a few of those bumps and difficult data migrations and had realized that this one simple trick can save you some headaches. Now, of course, the future proofing should be balanced against what’s usually called, you’re not going to need it, which is over, I guess, engineering for something that an unknown future. So you’re not trying to create a system that has totally flexible properties and tries to take into account every feature you might ever want to possibly add, I think that tends to create abstractions that just get in your way. It’s more of these small, simple tricks that don’t get in the way, but create opportunities to more easily make changes that you can’t guess right now in the future. 00:34:23 - Speaker 1: Right. On the data modeling side, the advice that I always give is, you’re just trying to accurately model the world as it really is, cause the world as it really is, isn’t going to change. It might expand as you add more features, right? But if you have incorrectly portrayed the world in your data model, and then you also go to model more of it, you know, now you have 2 problems plus there are section 3 problems, whereas if you had correctly modeled the part of the world that you were working with, it becomes relatively straightforward to extend the model to the new features. 00:34:53 - Speaker 2: And to go just a little bit technical for a minute, the version thing is also making me think of, I think it’s the image file format, maybe TIFF is the one I’m thinking of, but this approach, I think, has been used in a lot of different places, and I feel like you’re doing a version of this in the local first sync infrastructure we’re working on right now, which is to have chunks that have kind of a type in front of them. And so you can add new chunks to a stream of data or to a file that older versions of the software can load, recognize, they don’t know this chunk, and they can kind of skip past it and just try to interpret the rest of it the best that they can, you know, maybe this is something that web browsers do pretty well, which is you load a new. Page in an older web browser, if there’s some unsupported features, it doesn’t completely break. It just does its best to render it. Of course, the older the browser is and the more new features you’re using, the more and more sort of ugly and unusable the page is going to become, but it makes its best effort. It’s not that it just gives up the moment it sees something it doesn’t understand. 00:35:54 - Speaker 1: Yeah, and this gets into the peculiar challenges of longevity with distributed system software. We’ve been talking about longevity in terms of supporting the past with distributed systems. You gotta support the future because the future arrives unevenly. So that’s the sort of challenge you deal with when you’re working on distributed systems like the data synchronization layer from use. 00:36:14 - Speaker 2: Yeah. As usual, Link and Switch has some good research on the subject with the data lenses in the Cambria project, and one of the things there is about sort of data migrations, but it’s assuming you need to translate both ways. You need to translate, I guess you say back in time to older versions and forward in time to newer versions, but in fact it’s actually more complex than that because there may be just a branching tree of systems that all understand the data in slightly different ways. And the other small thing, it’s sort of obvious in some ways, but I think it’s kind of a Lindy effect of file formats. So Liny effect here, of course, being sort of the idea that something that’s been around a long time probably will be around a long time. So I’m always a big fan of those flat file formats, PNG, JPEG, PDF, plain text, because they’ve proven themselves to be durable over the long term. And they don’t always do everything you need, but where you can, it’s really nice to just kind of go down to that simple common format that’s understood by many applications, both now and in the past, and potentially will be in the future. Bringing all these ideas together in a very practical and relevant area for us. How do we think about this for Muse, the products, the data aspect that you mentioned, but also the team and the company? 00:37:37 - Speaker 1: Well, I think there are layers. I think the first layer in the sense of what’s likely to be longest lived is from basically day one we’ve supported flat file export. So you can export your board to a PDF or your images to a PNG. You can export your whole corpus to a zip of a bunch of flat files of these types, and that way you know you’ll always at least have your data in this format that everyone knows how to store essentially forever. And yes, it’s lower fidelity. Obviously you can’t easily edit it, like you can’t amuse, but that’s sort of the tradeoff you make there is you have access to this very durable format for all that data. 00:38:17 - Speaker 2: And I often find for archival purposes, I have put a lot of effort in the past to preserving things I’ve created, whether it’s an essay or back when I used to make music, trying to preserve all those kind of source files, video, similar thing, and usually I find the kind of flattened artifacts read only. is really kind of what I want in the long term because I do go back to reference those things or look at them for inspiration or just for take a walk down memory lane, but I very rarely want to edit, even if I could. And so in that sense, just it’s actually superior to flatten out to an image or a video or something. 00:38:55 - Speaker 1: Yeah, it’s a good point. In many ways, it’s a benefit, not a downside. I think especially when you have this habit of building up an archive that’s all in these handful of formats, everything is basically Texts, PNG, PDF, maybe video or MP3, you can browse it all together and you can do it very quickly, basically ininder or the equivalent, whereas you can imagine, if for every picture you wanted to check out, you had to open up Adobe Photoshop or whatever, you had to wait 2 minutes. So it’s nice just to have that very lightweight archival copy. 00:39:25 - Speaker 2: Now for the app’s kind of data itself, and we did toy early in the company with having it be part of our product to try to make that be something that’s more like the native format that Muse is saving to is like a Dropbox folder, for example, and it just turns out that we couldn’t achieve this. Things we wanted to either being on iPad or things we want to do around sync, just wasn’t compatible with that sadly. Right. But what we do try to do is really make the format that the app stores its data and on your device, on iPad or now on the Mac, a format that is something we will support over the long term and obviously we’ve only been at this for 2.5 years, 3 years if you count the research time. But already we’ve had people who have been around from, you know, the early days of the beta and we’ve had to, including our own personal corpuss, you know, I’ve got 20 some odd gigs of stuff and use from my now years of doing all my thinking and strategizing in it. And the engineering team spends a lot of effort on carrying forward as we build major new things, whether it’s something like the flexible canvas, or whether it’s something like, yeah, we at one point converted the ink from raster to vector, we have another huge sort of data migration here with the introduction of sync that the team’s working on right now. It’s a high stakes, but really important operation to bring that across. So ideally, you could have been, and in fact, many people have been using these that whole time, and you can go back and access your very earliest boards and everything is pretty much just as you left it, you can still edit it. It’s all still right there. 00:40:56 - Speaker 1: Yeah. Now that data layer and rolling forward versions does become much trickier in a world where you have multiple writers and especially if those writers are potentially not programs under our control. Certainly right now with Muse in the near future, the deal is gonna be, you have Muse, the app, writing your data, like a traditional cloud app would. But you can also imagine a world where, and we have in fact imagined a world where we have things like bots and end user scripting, and plug-ins and extensions. And that while everyone’s participating in a data model, so the stakes becomes much higher and you can’t just roll forward the world when you deploy a new version. So that’s why as we are working on sync right now with an eye towards this world of scripting and extensions and so forth, we’re thinking very carefully about the data model because you basically need to support that forever or go through a very troublesome migration process. So we’re trying to lay that foundation now even though it’ll be some time before all those end results come to fruition. 00:42:02 - Speaker 2: Now that’s the data, so how about the software, the app you download or the product more broadly over time? Is it important for that to be long-lived and how do we think about accomplishing that? 00:42:14 - Speaker 1: Well, I think it’s harder for that to be as long lived as the data because that’s less in our control, you know, you’re participating in the Apple ecosystem, as we talked about this ecosystem has certain characteristics that lend itself to being medium term life in practice, you know, apps or individual builds of apps don’t last a decade, even if the app itself does. So we do, we can there, we have minimal external code dependencies, and we have no critical dependencies on third party network services except the ones that Apple requires for any app to be able to, you know, be downloaded and paid for and so forth. But we are participating in that model if you got to keep the app sort of up to date on that time scale of quarters or years as the underlying runtime environment on iOS and Mac changes. 00:43:01 - Speaker 2: Yeah, exactly. I would think of the software as in any particular build as being something that at least I hope would continue, you know, in some future where I don’t know, someone’s running this in an emulator, for example, as long as the operating system, APIs are kind of what’s expected, and again, we don’t tend to use heavy amounts of those, we tend to keep it pretty light, but assuming, you know, we can read pencil data, for example, on the API that’s expected. That should still work. And a big part of that is the network side. So many apps on your phone, on your tablet, and increasingly on the computer, they expect some kind of service to be online and I tend to discover that because I really like working in offline environments. I like taking a long train ride or working on a plane, or just going to one of our team summits in some weird rural location with weak internet and actually that’s good. To be more kind of focused on what’s in the moment, but then you really quickly get exposed to these weird timeouts and network errors and can’t contact or whatever and I’m thinking, why is this software even contacting the network? Those hooks are just so pervasive now, we hardly think about it, but we’re working for use to make it be very much the network is optional. You get some nice benefits, but you don’t need it once you’re logged in. And then I would probably say, you know, that’s any individual build of the software, but I would say on the product side it comes down to more of a team and viable economic model and things that we’ve talked about extensively on the podcast here, but if we have a product vision we think is good, that the members of the team are invested in that long term and We’ve got a sustainable way to sort of fund it or work on that over the long term, and it even ties in with something like just running the team at a sustainable pace, right? Avoiding this drive to burn bright but burn out quickly that maybe does tend to come in the kind of hypergrowth world of startups. And instead be thinking a little bit more about, yeah, we want to be doing for this for a while. We know great products take a long time to build, and that’s not just like total person hours to build, but in fact it’s wall clock time for people to use in the real world and get back feedback and expand and improve upon it. So running the team in such a way and having a vision that we think that we’re all committed to in the longer term, again thinking in terms of human life scale spans, not months or Just years, but maybe slightly longer than that. I think that’s how we get a product, you can really depend on the longer term. 00:45:31 - Speaker 1: Yeah, another way you could think about this is lining up the reality of the software environment, what you’re communicating to users with how the team and the company is run. So it’s not even necessarily that you want all stuff to be exactly the same forever. It’s more like you want these promises to line up. So for example, as we’re developing new features, you’re really annealing them in. You’re not saying as soon as you come up with an idea, oh we’re going to support this forever. Initially you do a beta and you say, we’re gonna support this for the beta, it’s gonna be there for a few months and longer if it works well and not if it doesn’t. But then when it kind of graduates to the next layer, it becomes something that you support longer term you have corresponding infrastructure around what the company to do. 00:46:12 - Speaker 2: And from the perspective of customers, maybe some of that comes back to trusting the team and knowing the team, right? That’s why I think it’s important to communicate our values, our philosophies and our motivations through writing, through podcasting where someone can Dip into that world a little bit, get to know us and have some sense of what’s driving us and where we’re going and what we value, and if you share some of those values and you see a similar vision, then you can maybe trust that the software will change and evolve over time, but it will change and evolve in directions that on net will hopefully be Improvement for you, at least not a downside or a disruption, whereas if, yeah, you listen to us talk for a few hours in this podcast and you think, um, these folks are, you know, thinking about things in a different way than I think about things, and then maybe it’ll happen to be that the product does something useful for you right in this moment, but maybe over the longer term, it won’t be evolving in directions that are as useful to you. So that’s the reason in my own life. I try to use software as much as I can from teams I know, which it helps that, you know, I’m in the industry, I’m reasonably well connected now thanks to Twitter and other sources. And of course, it’s really fun to use your friend’s software, you know, using The Arc browser or something like that, for example, or some of the not boring apps from our friend Andy works as a couple of examples, but I also like that because, yeah, it feels different when I know who’s behind it and what they’re trying to achieve. It feels good both to support their work, but also the sense that sort of, not quite like we’re a team, but we’re working together to reach a similar future, where they’re working hard to make this software that can serve my purposes, and I’m, you know, giving them feedback and using the software and paying for it, and that’s my contribution, and together, hopefully, we work towards a better future. Well, let’s wrap it there. Thanks everyone for listening. If you have feedback, write us on Twitter at @museapphq. We’re on email, hello at museApp.com. And of course, we definitely appreciate it if you leave a review on Apple Podcasts. And Mark here is hoping that in addition to our business venture being long-lived, that indeed this podcast will be long lived. 00:48:30 - Speaker 1: Right on, Adam.
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: Also something that makes it very unique is this like you’re you’re basically floating through space and you’re zooming deeper into your hierarchy and all of this is like a perfect illusion of seamlessness when it’s actually not seamless at all. 00:00:22 - Speaker 2: Hello and welcome to Meta Muse. Use a software for your iPad that helps you with ideation and problem solving. But this podcast isn’t about Muse, the product, it’s about Muse, the company and the small team behind it. My name’s Adam Wiggins. I’m here today with my colleague Mark McGranaghan. Hey Adam, and my colleague, Julia Rogats. Hi, Adam. And Julia, you have now made 2 have 2 years in a row to spend the entire winter in a sunny location away from your home in Germany. How’s that working out for you? You can repeat that again next year? 00:00:56 - Speaker 1: Oh yeah, I mean, I guess we’ll see about next year and what traveling is going to be like in the future. Um, but at least for the past 2 years, I’ve really enjoyed that. I think, I mean, I love my hometown, Berlin, um. And I love being here in the summer, but in the winter it can get quite gloomy and dark and cold, uh, and I’m very much a sun person, so, um, yeah, I’ve really been making good use of this remote company set up and you know, make your own work hours for the most part. So spending lots of time in Adventurous places, kind of splitting my workdays in half, which is something that I really like to do, get some work done in the morning and then do something nice outdoors and then work some more hours in the night. Um, it’s been really been a really nice balance for me throughout the winter time. 00:01:42 - Speaker 2: You have a very impressive ability to get stuff done while also interleaving it with adventure. You’ll, you’ll ship some major new feature and then go whale watching. 00:01:57 - Speaker 1: And then fix a bunch of bugs and then go kayaking or I’d be like, guys, I’m going to be 20 minutes late from the meeting. I’ve just got back from a scuba dive. 00:02:04 - Speaker 2: That’s yeah, absolutely. But it’s also a reflection of the kind of work environment we built. Mark and I talked about this on a previous episode of trying to make a space that is flexible. For all of the the people on the team to live the kind of life they want to live. And for you apparently scuba diving and uh whale watching and kayaking is is the life you want to live. 00:02:23 - Speaker 1: Yeah, it’s definitely been amazing to not have to separate your life so much between like work and traveling. Like usually traveling for me always happened on vacation, um. And I actually find the mindset that I’m in uh when I travel, when I’m in a different country to be extremely stimulating in many ways and actually that to make me more productive. So being able to mix that has been quite a blessing. 00:02:47 - Speaker 2: So our topic today is iOS development, and then from you specifically, kind of our gesturerer system and why that’s so challenging to implement. But I thought maybe for contexts for people that don’t know how IS development works either because they know about software development generally, but not necessarily kind of mobile development, or even people who aren’t necessarily that familiar with how software gets built. They might like to know, what does it look like for you? You sit down in the morning or maybe the afternoon to work on some features or fix some bugs, you’re going to start crafting muse out of artisanal ones and zeros. What does that actually physically look like? What devices are you using? What software are you using? 00:03:31 - Speaker 1: Yeah, so in terms of devices, I use a MacBook first and foremost, as far as I know, you still can’t develop iOS or Mac software on any other platform. So that’s where everything starts and it comes with the with the IDE basically to develop for the iPad or iPhone, which is called X code. 00:03:51 - Speaker 2: IDE being integrated development environment. 00:03:54 - Speaker 1: Yes, correct. Uh, so basically it’s kind of the entire tool kit that you need to write software for the iPad or the iPhone. You write all your code there, you compile it there, you debug it there. So what I usually do um is that I plug in the actual physical iPad. The XO also comes with a simulator and you can run all of your um iOS apps in the simulator itself. So basically just brings up a little screen on your computer that looks like an iPad or an iPhone and you can do most things there. But for an app like ours, which is extremely gesture driven and we use the pencil for many things, it’s a bit tedious to actually um work with the simulator and some things aren’t possible at all. So I work with the physical device plugged in. You can actually also build to it wirelessly as of a couple of years ago, but it is a little bit unstable, so I try to just depend on the cable there. Um, and yeah, then I just write some code, like click one button and then it runs on the device and then I can test everything there. 00:04:59 - Speaker 2: And this is the SWIFT programming language. Uh, we’re storing our data, or sort of the persistence layer is core core data. Do we use any other fancy libraries or APIs or is it mostly just kind of the Apple gives you a pretty complete kit for development, everything from the editor through to the language and all that stuff, the simulator like you said. Uh, whereas like I come from Mark and I actually both come from more of a web development background, there you’re putting together more mix and match, uh, the tools, the language, and the different pieces. But here you get this one kind of, it’s the Apple style thing, you get this one pretty complete kit. 00:05:33 - Speaker 1: Yeah, pretty much. Um, so I think. It’s fairly rare for an IOS project to have no like zero dependencies to any sort of third party libraries, but ours are actually quite minimal. I think we have something in there, for example, for like zipping and unzipping files. That’s something that as far as I know is not built into the IRS kind of standard library. But for the most part, really like the IOS SDK is extremely comprehensible. You can do all kinds of things with it. They over the years they’ve added um much more stuff, especially from kind of open source third party frameworks that were very successful, have often been integrated in one way or another into the um IOS ecosystem or they’ve basically rolled their own, their own version of it. So our dependencies on on external frameworks is actually quite small. 00:06:28 - Speaker 2: And at one point we were doing the, maybe this is back when Muse was still a lab project or a persistence layer was Firebase, which is this kind of mobile back end data service from Google. Um, what was our, I think you like we like that pretty well, developer experience wise, but what, what led to us kind of replacing that with the Apple standard on device storage? 00:06:49 - Speaker 1: Well, I think the main motivation here was that we basically didn’t want to be dependent on Google and kind of giving giving our users data um to be stored on Google servers. So I think that was that was the main motivation. 00:07:02 - Speaker 3: Yes, speaking of Sending or not sending user data to Google. I’m really proud that we don’t have any third party analytics libraries integrated into Muse because these are notorious for scraping all kinds of data and sending it to a bunch of third parties. You saw this recently with Zoom, for example, where they had, I think it was the Facebook SDK integrated and apparently unbeknownst to them was sending all kinds of user data to Facebook, presumably for advertising purposes. Um, so I think that’s a really healthy thing that we have with our current minimal dependencies. 00:07:30 - Speaker 2: We do have analytics, but this is a, a system built by you or, or it’s sort of a roll our own type thing. 00:07:37 - Speaker 3: Yeah, and it’s it’s extremely minimal and deliberate. So every single field, which is like basically like 3 or 4 that we send this analytic service, are handpicked by us. It’s in our code, it’s it’s explicit versus a dependency that’s updating every week and it’s scraping new random things from the OS and sending it to third party servers where you have no control over it. 00:07:58 - Speaker 2: Mark, you end up building the back side of things. Ya, you do the client side of things. How do you coordinate around that API? How do you, how do you figure out how to make those two ends meet? 00:08:08 - Speaker 1: I think um for the most part, it’s been pretty lightweight. We chat on Slack about what’s needed for a certain thing. Um, often Mark ends up kind of drafting a notion document or something that like API docs or design specification kind of thing. 00:08:24 - Speaker 3: Yeah, exactly. So, so typically these notion docs will have first the mental model, which I think is really important, like what’s the shape of the domain here, what are the key objects and key verbs, and then a sketch of the HDP API which again is usually very simple, and then a discussion of the behaviors that are behind that. 00:08:41 - Speaker 1: And then as soon as we get into implementing that, um, it’s usually we end up being online around the same time and I’m telling him, OK, I’ve just implemented this API. Uh, is it deployed yet? Can I, can I start hitting it and then I’ve just, you know, depending on what it is, I send some sort of event and mark checks in the logs if you see if he’s seen the right thing and you know, often there’s a few things from there that we need to fix like something is not encoded in the right way, but we basically just tackle that together via Slack or a video call. 00:09:12 - Speaker 2: Be just to round out the tech stack discussion since we referred to the front end there with, you know, SWIFT and core data on the back end we’re basically doing Ruby postgrass and Hiroku, which for Mark and I is kind of our very standard tool kit. I think they say, you know, we came out of this research lab where our goal was to push the boundaries of technology and what what we can do there and try lots of Weird and interesting cutting edge things. But once you have, once you’re moving into the realm of production and commercial products, they say, choose boring technology. Choose the boring things that are workhorses that have worked really well. I’ve used Postgrass, for example, for, I don’t know, now 15 or 20 years, um, and there’s always a shiny new thing, but the stuff that’s really reliably and the stuff that is performed reliably for you for a long time is often just the thing to do. 00:10:02 - Speaker 3: Yeah, I’m really happy with our back end stack, and of course, Hiroku, but also Postgrass in particular, such a great database, super rock solid, super flexible, and now we can use it for both our sort of online um data as well as our analytics data. 00:10:16 - Speaker 2: Yeah, and a quick shout out on that kind of from the product perspective to data clips, which is a little way to bundle up a SQL query in a form that you can share it as a, um, as a web page. We use that quite a bit as our kind of our ad hoc analytics sharing system. Right, well, let’s get into the media part. I hopefully that gives some good context for um technical or um less technical folks about exactly what the pieces are here. Now getting into something that is pretty, and all of that I think is fairly sort of standard stuff that you might see in a in an iOS app or an iOS app that has a small back end. But getting into Muse, which is trying to really push the boundaries on what you can do with a tablet app, with these unique gestures, the different treating, treating the pencil differently from the the hands, that there’s multi-handed gestures and all this. So we have quite a bit of both design and engineering effort that has gone into our, our gesture system. But maybe we can start at the very beginning. Julia, what is a gesture? 00:11:20 - Speaker 1: A gesture is uh it’s a good question actually. I don’t think I’ve ever defined that for someone. Um, in terms of IOS development, there’s actually a whole system around gestures and gestures can be of one or more categories. So there is a pen gesture which would be just setting your finger down on a screen and moving it somewhere. You might be actually touching an item that you want to drag along, but you can also, you know, pen for any other reason, for example, to draw something. Then there are things like swipe gestures, which are also a pen in a way, but they’re like distinct here like just flipping through pages. Then there’s scrawling, which is a more of a continuous leaving your finger and scrawling something. There’s a scrawl gesture, um, there’s pinching, which is sort of you’re zooming in and out of of things and there’s a whole bunch of uh other gestures that you can. You can combine in your app to achieve different things, but they usually triggered with your finger or in our case or in some other apps cases also with a pencil. 00:12:22 - Speaker 2: Yeah, probably from a user perspective, you don’t even think that much about something like a tap, a double tap, a swipe, a pinch. These all part of the magic and the beauty, I think of multi-touch screens and why they’ve um Sort of taken over the the world in terms of interfaces, is that they do seem so natural, and it seems so obvious, the difference between, for example, a swipe, a scroll, and a pinch. But in fact, it’s quite a bit of logic to um make sense of that stuff. And I have experience with sort of mouse, um, wouldn’t call them gestures, but basically interpreting what the user does on a desktop computer with a mouse, um, in my past life as game developer, and There things are actually a lot simple because you’re a lot simpler because you generally have the X and Y position of the cursor and whether the buttons are down. And there is a time element for some things like double clicking, but it’s pretty minor. Most things are really discrete. Uh, the thing that I think really opened my eyes on this was, um, we both were at UIO last year where you gave a talk. And another talk there was, uh, Shannon Hughes, who worked for Omni Group. They make the some great productivity tools like Omnigraphle and Omnifocus. And she had worked on, I think the iPad app for one of these, and had done gone pretty far on these um these gestures and even has written an open source library for basically making a diagram. And she showed this, these kind of these gesture disambiguation diagrams, uh, in real time and you could see that actually this, there’s this huge time component where what makes a gesture a gesture is not a discrete moment in time. It’s a collection of positions and You know, touches in different places and movements of those touches over time and the accumulation of those things eventually resolves itself into the system deciding, OK, I just saw a pinch. 00:14:17 - Speaker 1: Yeah, exactly. And gladly we’re getting pretty much. All of that for free from the iOS SDK. So you could, if you wanted to and you, you know, you had the time or which is an interesting experiment for you. You could actually write all that yourself, so you can get just very raw touch input events from the system. If you have a screen. You can basically just implement a couple of methods that will fire whenever a finger goes down and moves somewhere just with a position and nothing else. And you could go from there and build your own, you know, this now. I think these fingers moved apart from each other, so it must be a pinch out. But um gladly the folks at Apple have gone through all of that work for us and uh developed this concept of a gesturerer that you can just attach to any view and that will make that view respond to specific gestures, for example, a pinch and just notify you when when that gesture first starts and then when it changes and also give you for a pinch, for example, it’ll give you the scale. So it starts out with a low scale and then As you pin, as you move your fingers further apart, the scale value will change and it will just notify your callbacks and uh then you can zoom or do whatever, whatever else you want to do with that pinch. 00:15:33 - Speaker 2: Now, if I was to look at the raw data, and I think I’ve seen test programs that do this, the screen or the the system that’s reading these touches, of course, doesn’t know which finger I’m setting down. So the difference between, you know, for me, where I can see my hand, it’s pretty obvious that if I, if I put down, for example, my thumb and my index finger near each other and move out, you know, that looks like a pinch gesture or put them down further apart and move in, that looks like a pinch. But the difference between doing that with my thumb and my uh pointer finger versus doing it with each thumb on each hand, which you could totally do. But the system can’t tell any difference. It just to text touches in certain locations and then those touches start moving. 00:16:17 - Speaker 1: Yeah, exactly. And that’s actually what makes everything so complicated that we’re trying to do. In fact, a pinch is even recognized when fingers only move. By only a very few pixels. So one example that I can give from from our app where this was a bit of a puzzle that we had to solve is we want to allow two fingers scrolling on a board. That means you sat down two fingers and you move them in, you know, either to the left or right to scroll the board. But we also have this sort of global pinch gesturerer that listens to you pinching out to zoom out back to the parent board. And that gesture is triggered by, or at least in the past has been triggered by even the most minimal movement. So we wanted to build the app in a way that is, that it’s super fluid so that it responds to your touches right away. That means that even if you set two fingers down on the screen and they converge by maybe 5 pixels towards each other, the system will consider that a pinch and will immediately start the zooming transition. So when you’re actually just using two fingers to try to scrawl, there’s basically no way that you can, you know, you’re not a robot, you’re not gonna be able to keep them completely parallel to each other. So we had to add a bit of custom disambiguation logic where. Pinche is only triggered after the fingers moved, you know, maybe by. a scale of 1.1, um, so by, you know, more than 10 or 20 pixels depending on, on where you started with your fingers, and that adds a little bit of delay to the system, you know, actually responding to your actions when you do want to pinch, which is a trade off, obviously, but it’s basically the only way that you can make these two gestures work together, um, and dis disambiguate them in some way. 00:18:13 - Speaker 3: Yeah, this delay issue is really interesting. One of our top level design goals for you is that it’s super fast and responsive. So the idea is, as soon as you touch the screen and do something, the app should respond. So you always feel like you’re directly manipulating your content. And as Julie was saying that’s really hard with these gestures that are potentially ambiguous. And in some cases we’ve taken this approach where you Uh, just try to have a very small delay, basically imperceptible delay that allows you to disambiguate. I mean, that seems to work pretty well. Another approach that I’m excited about trying is actually doing both optimistically, and then retroactively picking one once the disambiguation becomes more clear and rolling forward with that and unwinding the other one. So you can imagine with this pinch of You start doing a pinch last scroll. It’s ambiguous and it basically starts zooming imperceptibly and scrolling imperceptibly. And then once it becomes clear that you’ve done one or the other, it unwinds the thing that it wasn’t, you know, zooms out slightly, for example, and then keeps doing the thing that you were doing, scrolling, for example. 00:19:15 - Speaker 1: Yeah, we’re actually already doing some of that um in a similar, in a similar problem. So the same way that I was just talking about you can two fingers scroll anywhere on a board. Um, you can also drag any card on any board with one finger, and we deliberately, as you just pointed out, we deliberately wanted to make that instant. So most apps work in a way where you hold your finger down on something and then it sort of enters like maybe slightly lifts and enters into a movable state and then you can drag it around. Um, and that’s exactly the thing that we didn’t want, and I think one thing that makes news very unique that is like ultra responsive. So as soon as you set your finger down a card and you start moving it, you can even have your finger do a movement as you set it down. The the cart will start moving with you. And so the problem with then the two fingers scrawling here is that when you do want a two finger, you do want to use two fingers to scrawl, and in that case, we don’t want to move that cart as you sat down your two fingers, inevitably one of the two will set down first because again we’re humans, not robots. So even if it’s just a fraction of a second, that first finger that comes down and moves by one pixel will trigger the car movement. But then the other finger comes down and then the system actually recognizes, oh, it’s a scroll, and it actually cancels the car movement. So you might sometimes if you do it very fast and if your, your first finger goes down noticeably earlier than the other one, you will see your your card start dragging and then jumping, kind of animating back into place where you picked it up from and then the scrolling kicks in. So we’re using that trick already a little bit in the app, but it’s quite cumbersome to implement that. So I hope, I hope eventually we’ll have more of a unified approach for this kind of thing. 00:21:07 - Speaker 2: Can you talk a little bit about what the overall framework here is? Um, is it essentially a giant case statement or a series of statements or is it more of a state machine or what does that what does that look like? 00:21:20 - Speaker 1: Yeah, it currently isn’t really. Uh, very cohesive system, um, because of how some of the components interact. So you still want to be able to kind of give individual components the the ability to control themselves basically without writing this this global gesture handler. 00:21:41 - Speaker 2: By component to control itself, here you’re talking about. That there’s not one entry point for someone to touch the screen. It’s more you want to attach a, a snippet of code or a piece of functionality to say a card, and it, it sort of knows, so to speak, how to, um, how to manage touches that it it receives, and that can be somewhat dependent from what another card does. 00:22:04 - Speaker 1: Yeah, exactly. So for the cards, actually, um, we do have a bit more of a global approach because of how much the card dragging interacts with other things like zooming in and out of boards while you’re dragging a cart along. 00:22:16 - Speaker 2: So is this the maneuver? 00:22:19 - Speaker 1: Yeah, this is the maneuver that made everything so difficult for us. 00:22:23 - Speaker 2: OK. Well, in the backstory here is it’s pretty critical, right? There’s, you know, if you’re inside a board and you have one or more cards you want to take elsewhere. You can, um, you can stick it in the inbox. There’s kind of, you know, maybe you can use copy paste, but that’s kind of a hassle. Really, what you want to do is grab it and then navigate to your new location. And in fact, that’s how it works. Sometimes we call it the two-handed card carry. So you can put your finger down, you’ve kind of picked up, so to speak, that one, and then if I pinch out with the other hand, I’m essentially now I can freely navigate around and I kind of keep this other card in this floating state. Um, but that’s the thing that doesn’t work if the gesture handlers attached to the card itself. 00:23:04 - Speaker 1: Yeah, exactly, because the gesture, uh, in, in order to be able to carry the card into a different space, we basically have to detach it from its parent. So before I was living on this board, and then if you had a gesture recognizer attached directly to the card, you can move it around the board, but as soon as you put it uh to a different parent, The gesture uh recognizer actually cancels and you basically lose that gesture. And so in our case, in order to be able to carry it to a different board, we basically have to put it um on the top level hierarchy, basically attach it to your window. So that you can zoom potentially many levels deep or or further up your hierarchy um until you find the board where you want to put that card and let go. 00:23:52 - Speaker 2: So many of these things that are challenging is because Muse does come from a a different set of product design principles. And one of them is this certainly the spatial zooming um interface, but also that we want to maintain this illusion of a continuous fluid space. Um, I think with many other kinds of applications, you have this sense of going to different screens or different pages, and you know that when you go to, when you, when you navigate to that new screen or page, all of the kind of stuff that was on the previous screen just goes away or isn’t relevant in this new place. And I think that’s fine for a music player or something like that, but what we’ve tried to create this space where you have this big workspace and you can move stuff around freely between it. But then the kind of libraries and the APIs that come with, certainly the iOS system or I think any kind of UI system is just not built, uh, assuming that, assuming you want to do something like that. 00:24:47 - Speaker 3: Yeah, this is, this is an aside, but I really like that there’s no loading screens in Muses. You don’t open documents or load them, they’re just there when you look at them, and that seems obvious, but when you go back and use an app where you’re constantly loading documents, waiting for them to open, it’s just a totally different experience. So I think it’s worth the effort that we go through on the technical side. 00:25:07 - Speaker 1: Yeah, and uh you know, not, not least of that um the the sort of challenging model that we chose for Muse, which is also something that makes it very unique is this like you’re you’re basically floating through space and you’re zooming deeper into your hierarchy and all of this is like a perfect illusion of seamlessness when it’s actually not seamless at all. Basically every new board that you load has to be rendered by the system. It has to be, you know, loaded into memory. And we, there’s some tricks we’re using there, but it’s uh it’s certainly not, not easy to keep up that illusion all the time. 00:25:43 - Speaker 2: Mark, I think you’ve made the comparison to video game development at various points, and this does actually remind me of, you mentioned loading screens. Video games with big continuous worlds, which is, I think, pretty common in today’s um kind of open world games. This actually has a similar technical challenge that you don’t want to interrupt the players' movement and and give them a now loading screen that really kind of is a kink in the experience or or removes that illusion of being one continuous world. But in fact, when you have this huge world that can’t possibly fit in memory, uh, you do need some way to handle that. I think there are similar, I think, I feel like a lot of the tricks that we’ve landed on to make this work, uh, for Muse actually would be quite right at home in the video game world. 00:26:29 - Speaker 3: Absolutely. Circling back to gestures, then perhaps we can talk about gesture spaces. So this is the idea of the A kind of set of gestures that is possible in the app and the the actions that you can do with that, we found that to be a really interesting challenge with Muse. the set of things that you could do with your hands or the pencil and the actions in the app that that maps to. And one of the reasons this is so challenging is it tends to be much more constrained than a desktop app. So on desktop, you have the mouse, you have the two buttons, you have the mouse scroll wheel, you have the whole keyboard, and then you typically have the menus and the pattern of a right click menu or a press and hold menu. Whereas on mobile, you know, traditionally you just have like basically one finger, and with uhm we’re trying to extend it to, you have 10 fingers and uh the pencil, but it’s still quite limited. You don’t have, for example, a menu where you can just add a bunch of stuff as you have more functionality in the app. So whenever you add a new feature, you need to find a way to invoke that with your hands, which isn’t easy because there’s a quite limited uh space um to draw from. So, so that that that results in a few concrete challenges. One is, you need to come up with particular gestures. So an example for us is we need to find a way to um pick the color of ink you’re using, and for that we have the swipe from the edge of the screen. Gesture, which is I think pretty novel, and I guess that’s something that’s built into iOS. 00:27:55 - Speaker 1: Yeah, the, the swipe from the screen with your pencil gesture is actually quite a harrowing thing that’s still an ongoing problem for us. So IOS actually does have a deliberate, I think it’s called UIH swipe gesturerer or something like that. So that there’s a way that you can attach a gesture listener to only swipes that happen from outside the device into the screen and I think iOS uses that for all of their system-wide thing like you can summon the dock from the bottom or you can. Gate back by swiping from the left. Um, and I was when I was initially implementing this menu, I was like, oh great, we’ll just use swipe gesture recognizer like that and we make it fire only for the pencil because notably those gestures, the system-wide gestures and IOS don’t work with the pencil. You can’t summon the dog with the pencil or you can’t pull in the Control center with your pencil from the top. So I thought they would just be up for grabs, those gestures, but unfortunately that edge swipe gesture recognizer does not work with the pencil. 00:29:05 - Speaker 3: Surprisingly often, we’ve run into the sort of edge of the map on the iOS APIs uh because we’re doing things that are quite unusual in Muse. 00:29:16 - Speaker 2: And what do you do for testing and debugging this stuff? You, you’ve talked about the simulator, but that’s pretty poor for uh for this kind of thing. There’s obviously you have the physical device there. How do you test this stuff? 00:29:28 - Speaker 1: Yeah, so testing gestures um is, is, you know, obviously a little bit harder than than other debugging in some cases because you can’t just put a breakpoint in the middle of a gesture to see exactly what’s going on. I mean you can but then you basically, when you then focus your attention back to the screen. And to try to see what’s going on, you have to lift your finger from the device that you were just testing on and then once you, once you continue execution, that that gesture will have ended. So what I usually do is I put a lot of logs. So if I’m trying to disambiguate some gestures and often it’s like very finicky, like which one fires first and then what what like what finger went down first and was it on a card or on the board um and then I just go manually through those locks and try to try to figure out um the the sequence in which things are happening and where I can where I can intervene and uh tweak things. Another thing that we uh that we use internally for debugging is that we have a little system that actually visualizes your touches on the screen that often helps to kind of explain to other people in the team, look, when I’m doing this gesture, um, something happens that shouldn’t be happening and there’s a way that we can activate um basically little blue circles showing up around where your fingers are and little um and different colored circle for your pencil. And then it’s really easy to kind of record a video or do a screen share where you show your um your peers what exactly you’re trying to do and what where where exactly your fingers are when certain things happen. So that’s, that’s kind of been a useful team, team. I would say. 00:31:11 - Speaker 2: Yeah, by sharing a video, you’re showing a not only a reproducible case, but then you can even kind of slow. I find it useful sometimes to slow down the video or pause it to to figure out exactly what’s happening there, where and can, can make it more reproducible. I’m sure we can get more sophisticated with those tools over time, but yeah, those colored circles have proved, combined with the screen recordings have proved, uh, remarkably useful for us in testing. Uh, you mentioned earlier the uh the operating system gestures like summoning a doc from the edge, uh, talking about the stylus from the edge reminded me of the, uh, take a screenshot by going uh stylus in from the um one of the corners. I wonder what happens in the case when we end up colliding with OS system gestures. For example, we had some some capabilities in the app when I was more in kind of beta prototype phase that did involve dragging up from below, and those would get in the often interfered or or had a bad interaction with the. Uh, with the OS summit a dock, and notably, I think when we started working on the app, it was before the dock had been introduced, so that gesture to summon the dock didn’t exist, but later it became totally foundational. Hall, now iPads and iPhones don’t have home buttons to take you. Home button you swipe up from the bottom. But then we basically had a swipe from the edge of the screen and specifically the bottom gesture, and that was colliding with that in a pretty bad way. And we, we basically had to make a make a change there. 00:32:43 - Speaker 1: Yeah, well, I think the general rule is here um that the operating systems. So this this has been a trend over the past couple of years where where um DOS is actually has been taking over more and more. gestures, particularly around the edges of the screen, and in many cases for apps that means they’ll just have to change their gesture system. There is a way that you can, you can basically override these gestures once and tell them that you know, I actually want to get this swipe first. So this is something that we we tried out when we had the the thing that you were able to pull in from the bottom. Um, you can tell the system to defer its system gesture to let your Uh, your own app, get that gesture first and what that does is that it, um, it makes your app execute the gesture, but then also brings up this like little arrow thing. Um, and if the user actually if the user’s intent was actually to pull up the dock, then they have to basically do the gesture again on the arrow and then pull up the dog. But that makes a lot of users very angry and I think rightfully so if you, yeah, if you, if you learn how to how to use your device and you kind of have muscle memory about around certain things and certainly Uh, such fundamental things as, you know, switching an app and pulling up the dock, then you don’t really want apps to interfere with that or kind of override it with their own default behavior. So you basically just have to cave in. 00:34:11 - Speaker 3: Yeah, and there’s a risk here of major gesture space reflow. So I mentioned how we’re using basically all the gesture space that we know of for the app. It’s all packed with our different features and functionality, and so, if the OS takes away just one. You could have this musical chair situation where one of the features of the app doesn’t have anywhere to sit. And so then you need to, you know, figure something totally different out for your gesture space, you know, open up a whole new room, for example. Um and we’ve gone through that a few times where we were just short of the degrees of freedom that we needed, so we need to basically rethink how all of our gestures work. 00:34:47 - Speaker 2: Just recently, a friend of mine was learning the terminal, the Unix terminal, and in the process of doing this, this was on a Windows computer, I was surprised to learn that the copy command does not work, so they’re used to pressing control C. But it turns out the Control C has a long history well predating the existence of copy paste buffers to break out of a program in the Unix command line. So typically these terminals on the Linux and and uh uh Windows will basically take over that control C because they need it for the sort of for the historical compatibility. And in fact, users are quite used to that as a way to break out of a program. But then if you’re expecting that that’s a copy, which is an absolutely crucial uh capability that people rely on all the time, uh, it’s quite confusing, distracting, annoying that that gets blocked and you need to use essentially another key command or another way of doing copy. So that sort of thing has existed since time immemorial, but maybe iOS and the iPad in particular, such of a quickly evolving. Uh, new space. And so we’re trying to push the frontier, but then the operating system maker is also trying to push the frontier and then simultaneously, of course, as we explore the space, the likelihood of collisions is reasonably high. 00:36:05 - Speaker 1: And I think we’re already trying to do a lot of things differently, um, but we can’t possibly overload the user with too many weird things. So in some cases just doing the standard thing is probably also a good idea. 00:36:17 - Speaker 2: We’re definitely pushing right up against the ceiling of a number of weird things for the for the user to learn. 00:36:23 - Speaker 3: So, Julia, looking forward, what are you excited to try in the gesture system? 00:36:28 - Speaker 1: So I’m actually still kind of flirting with this idea of um something that you you referenced earlier um talking about this uh this new icon talk by Shannon Hughes where she introduced this idea of actually building an entire state machine that manages all the gestures in your app. So that way you you have one centralized place that always knows about what’s going on and what’s possible to go from one state to the next. So if you One if you set down a finger on the screen. From there it might be possible to go into a pinch or into a drag cart and the state machine would handle all of the valid states and state transitions and that way you you have a more deterministic and consistent approach to things and you don’t have to. scatter different different um dependencies across different components of your app that I have to check, am I currently dragging a card? Do I need to cancel that drag in order to start the scroll. Um, so I think a bit more centralized approach there could actually be interesting, but it would also be a lot of work, um, so currently we haven’t. We haven’t made that a focus yet because what we have is working pretty well, but if, if, if we ever get bored or if this ever becomes a huge issue, I think that would be something that I would be excited to try. 00:37:50 - Speaker 2: While there’s way more to talk about here since we’ve invested a huge amount of time into uh this gesture system and certainly will going forward, uh, perhaps we’ll leave it there. So if any of our listeners out there have feedback, feel free to reach out to us at UAHQ on Twitter or hello at musesApp.com by email. Love to hear your comments and ideas for future episodes. You very glad that you’re uh working hard to make it possible for Muse users to have this fluid and powerful interface for interacting with their ideas. 00:38:25 - Speaker 1: Thanks. Yeah, it’s been uh obviously a lot of fighting but also a lot of fun.
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: A product launch needs to prepare and calibrate the potential user for how much the world is going to get shaken up by this thing. So Muse 2, it’s still muse, but it’s a major version change, so prepare for a moderate amount of novelty in your life. 00:00:21 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for thought on iPad and Mac. This podcast isn’t about Muse the product, it’s about the company and the small team behind it. I’m Adam Wiggins here as ever with my colleague Mark McGranaghan. Hey, Adam. And there’s a little bit of excitement in the air here. Uh, those who’ve been following the Muse story know we’ve been in a pretty deep maker cave for a while working on our 2.0 product. And I think we’ve talked a little bit before about the sort of big releases versus incremental, and I think there’s much to be said for both. Incremental has a certain momentum, velocity, you feel more in touch with the people that you’re serving, your users and customers, but of course the big releases are where you can really kind of reinvent the universe and there’s the feeling that anything’s possible, something like that. And of course we’re undertaking something pretty ambitious here, at least for our small team with Basically adding a whole new platform, which is the Mac, in addition to iPad, and then on top of that is this local first syncing technology that we’re trying to take from the research lab and bring it into our product is a pretty big bet here. So we’ve been grinding away at that for a few months, but very happy to say that the Beta is now available to prom members, so we think it’s, we’ve been using it internally for a little while, you and I both have used it quite a bit as our kind of daily driver in our work, and it is nowhere near bug-free or glitch-free or even total feature parity with Muse one, but it all does work, and it’s quite a thing to see, I think, but I’m really excited to share it with everyone and see the reaction. 00:02:02 - Speaker 1: Yeah, very exciting times for me, actually, the multi-device and local first sync capability was perhaps the thing I was most excited about with the original Muse vision, and it’s taken a few years to get up to that point, so I’m really excited to be releasing this capability into beta. 00:02:20 - Speaker 2: And I’ll link the memo in the show notes for those that are interested, we do a little bit of a, a walkthrough, particularly on the Mac side, but also take a little look at the sync side of things, although that will certainly bear much more explanation in the future. But with that be kind of out the door and baking, as we sometimes say, so folks will be trying it out and sending us bug reports and feedback of all kinds, and while we let that sit for a while, we can start to think forward to the product launch, the Muse 2.0 release. Which is very exciting for me. I get excitement from shipping things in general, even something like a beta, but doing a full product launch is quite its own wild ride, I think, and we haven’t done one for a year and a half since Ms 1.0 came out, so I’m kind of looking forward to that, and indeed, that will be our topic today, which is launching products. 00:03:11 - Speaker 1: Nice. And now Adam, I’m gonna turn the tables on you. You usually ask me to define these nouns that we talk about, so I’m gonna ask you what does a product launch mean? 00:03:22 - Speaker 2: Yeah, I see now being the other see why that’s difficult, because it seems like everyone knows, right? And you go to kind of actually define it and realize you don’t have a real good crisp definition. And I probably like you, have been involved in product releases of many different kinds over the course of my career, and I think it was really only the Muse 1.0 launch where I really sat down to try to more deeply understand what is the anatomy of a product launch and what even is it, because if you’re sort of iteratively releasing improvements and features all the time, what is it that makes kind of a launch? And I think one of the descriptions that I saw someplace is the idea that you’re creating a moment. You’re creating kind of a feeling of an event, and you can think, of course, of the really dramatic examples like Apple, right, they do these just completely huge events, you know, back when they were in person, but even now with the kind of virtual stuff, hugely produced, all these, you know, press are lined up, you know, all the product review people had their stuff ready to go, and so it’s this big event, big moment. But I think you can equally as well do that on a much smaller scale, right? Even if you’re just like, for example, making a little app to share with your 10 friends, if there’s a moment where you release that and everyone feels excited about it and they’re kind of talking about it with each other or sharing the link with each other or something like that, I think that serves it just as well. And then the other part of it is just like, what actually are you launching? So the moment of the event is an announcement, something exists, something that is truly new. And I think here we get into a more subjective definition for sure and product hunt, which is an interesting piece of this puzzle, we’ll come back to a little later, but they actually do have some rules around. They don’t want you to launch just new features, but new products. Of course, that begs the question, well, what actually is a product launch was a feature launch? It’s not really that clear and there’s a few guidelines there. Being on a new platform, having a totally redesigned interface if you’re covering some new use case, but I think there is just an implicit feeling or sort of subjective feeling just like we’re talking about here with Muse 2. This is something that feels really new and different, even if it shares a lot of the fundamental qualities of what we’ve been building all along. 00:05:40 - Speaker 1: Yeah, I actually quite like this definition of product launch is creating a moment cause it’s user centered. It describes it from their perspective. When we’re talking about product management, we often say that you should describe the benefit or the capability and not the functionality, like at least think in terms of what the user is getting. And when I was thinking of launches, I was thinking of like a marketing push or you turn the thing on, right? It’s these things that we’re doing versus the moment that the user is experiencing, so it’s a great lens. 00:06:09 - Speaker 2: I may have gotten that from uh there’s a series of posts on the site, launch notes. They have one that I’ll link to in the show notes that I quite liked about a launch Mailchimp did a couple of years back, and they’re obviously a huge company, so what a launch for them means is quite different than what it means, for example, us, but I think again, those concepts. Your channels are different, the scale is different, the quantity and quality of the materials you can create are different, but the basic idea I think is in there. And by the way, you can also launch a product that has yet to be built. So I think the landing page with a waitlist is absolutely a thing you can launch. And in fact, we did this, that was basically the first Muse launch. We kind of call it the soft. internally, but, you know, we had come to the point where the team was working on it. We had made a Slack channel named Muse, we’d registered a domain, you know, we had incorporated new software, Inc. and we said, you know, we should tell people we’re working on this. So we made a little one pager landing page with just a little place you can sign up and it would just kind of store the email, and we weren’t sure what we were going to do with it quite yet. And our launch was just, we all tweeted it, and maybe the incode Switch account tweeted it. But that actually got us, I don’t know, first few 100 signups and some energy on the team in the sense that like, OK, something exists now that didn’t exist before, when it’s just a one-page website with an email sign up, but that indeed is a launch. 00:07:33 - Speaker 1: Yeah, indeed, one of the first lessons that I learned about product launches from you and from Hiroku was that you can and should separate delivering the product, turning it on from doing the launch. You can do the launch before you ship the product, you can do it afterwards, you can do multiple launches, you know, you have all kinds of flexibility and you should take advantage of that. 00:07:52 - Speaker 2: Yeah, I think that’s key in thinking about the when part of things. I am big on decoupling a product release from a launch, a marketing launch or a storytelling launch, whatever you want to call that. And so, the Muse 1.0 launch was a good example. We went live in the App Store, I don’t know what, 5 or 6 months before we launched, and we had turned on payments, and we had migrated our beta, a good portion of our beta users over from test flight, but we had a new website, and we had A chance to say, hey, everybody, we exist now. And so the MS 1.0 release wasn’t necessarily something that you couldn’t get before. It was just something you didn’t know about because we hadn’t really publicized it beyond our little internal circles. And we may have pushed some kind of release that had something or other in it, you know, maybe a 1.0 version on it. But really there was no big change to the product, and I think that becomes even more important, you know, there’s obviously things like getting through app review, but if you’re doing infrastructure, you don’t want to be doing big changes to your systems exactly the moment you’re getting hit by a bunch of new traffic and a bunch of new people. I think it’s very tempting to feel like you need to do that, that wait a minute, you know, if I could have tried this product a week ago, what am I actually launching? And again, I think it’s really about you’re telling people that didn’t know about it before, or that maybe had heard about it, but you’re saying, hey, this is ready, it’s reached some new milestone. It’s 1.0, it’s 2.0, whatever that is. 00:09:23 - Speaker 1: Right. And this is a good example of where the user lens is so helpful from our internal lens, it’s this product that’s been released for a while and hasn’t undergone a big change in the past few weeks. This is at the time of the 1.0 launch, but the reality is, approximately everyone in the world has never heard of it. So you can’t think of this thing. Already existed or people already know about. In fact, people are hearing about it from the first time. And this is part of why creating a moment is important and valuable because you’re signaling to the market that there’s something important happening here. They can’t read every app store update to decipher when you’ve undergone a big step change in capability. You need to signal that to the market with your marketing. As an aside, this separation of product release from marketing launch reminds me of what we do in infrastructure engineering with gradual rollouts, so that the obvious thing to do with shipping code is you code up the feature and then you deploy the code and then the code is active and the feature is active. In fact, what you do with infrastructure engineering, once you get beyond any small scale, is you completely separate the coding and the shipping of the code from activating the code. So you’ll have a new code path behind a feature flag and you’ll ship that code up to production dark where it’s not running, and you’re very slowly in the case of infrastru. you do it slowly, you turn the knob to activate this code 1%, 2%, 10%, eventually up to 100%. And of course you can also flip it back without deploying the old version of the code. So it’s sort of isomorphic with this idea of separating product releases from marketing launches. 00:10:53 - Speaker 2: Gradual and iterative is essentially always better, but in the sense of doing a thing or making changes and being in the business of software and technology is essentially a change business first and foremost, but the point of a good launch is to make a little bit of a splash, and to do that, it should feel like there’s kind of a lot coming all at once, rather than being dripped out. But again, you can do that exactly like the feature flagging on the infrastructure side. One trick that we used on the 1.0 launch that hopefully I’ll get the chance to use here is we actually had our new website on a subdomain, like some preview URL, and then we can share it, for example, with press. So someone that has, for example, reviewed news in the past and we say, hey, you know, we got this new product coming, we’d like to give you early access. Here’s what our new website is going to look like. And that’s really important because if they’re trying your new product but reading your old website and then they’re trying to make sense of that for some review video, they might make, it will be a little bit incoherent. But on the other hand, you want to push out that website again, feel like there’s something big and new the day you’re announcing something. And so that’s kind of a way to do it again incrementally and a little bit iteratively. And I think that gets harder to do is for a small team like ours, it’s easier to do, certainly our 1.0 launch where, as you said, approximately every in the world had never heard of us. Um, as you get bigger, it gets harder, people actually want to, but that’s a nice, that’s a whole other set of problems to have, which is that like you worry about leaks and people getting early access. But when you’re at that size, in a way it’s a nice problem to have, but it’s sort of a whole other domain that I’m talking less about here, and then you need new techniques to kind of keep your secrecy or the press embargoes and all that stuff, but even so, I think that iterative and doing things in a gradual way, so that you’re not just flipping a bunch of switches and then everything collapses right in the moment you most need it to really be stable. 00:12:49 - Speaker 1: Right. I think there’s a theme here where if you execute a product launch, well, it should mostly be not surprising to you. It’s going to be news and therefore sort of surprising to a lot of the broad market, but you can basically understand what’s going to happen along a lot of these dimensions. So for example, you’ve already released. the product, you know, that it works. You should, by the way, be observing the rate that new bugs are coming in and that should be hopefully decreasing and reaching some acceptable moderate level, because the bugs aren’t gonna suddenly stop coming the day you release, right? So you got to anticipate that. Also, you were alluding to this, you can Basically beta test a lot of the marketing and messaging with the press. You can also do this with the users. You can say, here’s how we’re proposing to talk about the products and see if that resonates, if they’re nodding their head up and down, and if so, you can anticipate that will catch it will stick when you eventually do your marketing launch. I think people have in this mind as users of products that marketing is like big like basically frenzy where everything’s super uncertain and everyone’s figuring stuff out and who knows if it’s gonna work or not. That should be only the perspective from the outside, from the inside, you should have a lot of data about how this is going to unfold. Now that also speaks a little bit to, I think our bias, which is like B2B that is business to business and prosumer software and those domains, like especially with B2B, you have like 1000 customers, you just call up Amy, hey Amy, you know, you paid us $100,000 last year for a B2B software. What do you think about, you know, B2? Of course they’re gonna give you their take and we can sort of do that also with Prosumer because it’s something that the user has made a bit of an investment in. As you get into consumer, it’s harder because each consumer is worth whatever 7 cents or something, but that’s one of the reasons why I like B2B and prosumer software. 00:14:27 - Speaker 2: Yeah, that certainly comes to each individual represents a larger share of your revenue, so you can care about them more if that’s the right way to put it. But then you’re actually much more likely to have a relationship with them, you know, there’s folks that we’ve had as customers stretching all the way back to those early days, and they’ve written them with lots of great feedback and we’ve had our back and forth. And so then, you know, it’s pretty natural to go and say, hey, check out our new website, what do you think? And also that usually they’re comfortable with saying, I hate it, here’s why, which is important. And of course you can do that with consumer stuff, but I think it’s harder. The scale is bigger, the individuals matter less, and it’s more of these like gross trends, yeah. Speaking about numbers a little bit, I think another question that I’d like to make sure to ask on teams is, why are we doing this? Hopefully that should go with anything you ever do in a company, but I think you can take it, especially folks who have been in marketing a long time, take it as just a given that you need to launch. And I actually do kind of agree with that. You can’t expect people to know about your product if you haven’t launched it, sort of how I’d put it, unless you have some viral growth loop thing that’s really, you know, quite remarkable. For the most part, you’ve got to get some real effort into getting out there and both one packaging your message in a way that people will be able to understand it who are not part of your inner circle, and then 2, make sure that message gets into channels for people who care about what you’re doing or you want to serve her listening. So I think that is reasonable. But in the why thing or going a layer deeper there, I think it’s important to try to define success upfront. And one place I think it’s easy to get a little bit diverted here is the what I’ve called the press launch. So, especially if you’re in, as you said, B2B software as I have for most of my career, there’s tech press, Silicon Valley Press, so here I’m talking about TechCrunch or Gigaom, maybe the Verge, there’s a variety of sites like this, and at least back in the rogu days, you know, we got pressed pretty early on, we were just a couple people working on a thing, you know, barely worked. We were in my combinator, so that helped, but it’s nice to see those stories or a lot of folks maybe take it as a sort of ego boost to see those stories, but they actually don’t help that much with getting you users. And what they do help a lot with is getting you investors and helping you recruit people both in the moment, you know, you’re in conversations with investors, they see your TechCrunch article come out and that kind of adds some heat to, you know, bringing the deal to a close, for example, but also the Googling later on, which is you’re trying to recruit someone, they want to learn about your company, they type the name of your product into their search engine, and if some articles come up where there’s some, you know, headshots of the founders looking fancy. It just kind of confers legitimacy. OK, these folks are really in it. And so that’s part of your goal is to set yourself up for fundraising and recruiting, then that kind of press launch is excellent. If your goal is actually to get new users or new customers, particularly if you’re in a specific and narrow demographic, which many companies are in their early days or forever, then it’s actually probably just gonna be kind of a sort of an ego exercise and actually doesn’t serve you that well. 00:17:40 - Speaker 1: Yeah, I also tend to think that people over rotate on classic press outlets. I don’t have a whole lot of hard data on this. I just have an intuition that a lot of people’s media is now basically socially oriented, and it’s coming less through these hierarchical media outlets. So to the extent that that is true, I think of a launch as more about planting a new memetic seed out in the social networks about what your product is. OK, the Muse 1.0 seed is a flexible canvas for not taking in the iPad, for example. And then that propagates, people tell their friends they post about it on Twitter, it goes in the Discords or whatever. I guess there’s some media coverage of it as well, perhaps. 00:18:25 - Speaker 2: And if I can interject there, incidentally, that helps, and I think one of our goals for the Muse 1.0 launch was be in people’s minds around, yeah, fluid iPad apps for thinking and productivity. And one of the, I forget if we have this exact metric in here, but I think, you know, just in writing out what did I want from the. Launch some of it was new users, but one of them was, can I put it exactly, but if you see someone mention. Muse or especially tag us on Twitter in a thread where someone asks, hey, I just got a new iPad with a pencil, what sweet apps should I try? And it’s someone who’s sort of in the sphere that we’re in, I don’t know what you want to call that tools for thought or thoughtful people who are interested in sort of doing productive work. And if you see a couple of folks jump into the thread and say, hey, you should check this one out, you know, that means that the launch was successful in the sense that we’re sort of in people’s minds under that. Whereas if we don’t get mentioned, then it means, OK, we didn’t quite plant that hermetic seed, as you said, and that’s not what’s in people’s minds. They may think, I like this team, they may think they have a sweet podcast, they may think, I don’t know what they like the interface design, but for some reason, we didn’t come to mind when they saw that thread, and that meant that our launch. If that were to be the case, that would mean the launch wasn’t very successful. And so I was really pleased to see there was a significant difference, you know, this was mostly just anecdotally me just like spotting people tagging us, but after the launch versus before in terms of, yeah, people responding to those kinds of questions with, you should check out UA HQ. 00:20:03 - Speaker 1: Yeah, I think we did a pretty good success with our 1.0 meme seed. And I think if we have a successful 2.0 launch, we’re basically telling the world, you know, hey, memetic DNA update here, uh, we got a new and updated things that we’re saying about Muse, it has new capabilities. We have new ways of describing it. We have new words and phrases, and because we are the memetic source in a way, you know, obviously through the product itself, but also through our website and how we talk about it on our Twitter and so forth, that will then tend to propagate through the social networks, which is where people get most of their information these days. That’s kind of my intuition about how this works now. 00:20:39 - Speaker 2: Now other sorts of success metrics, of course, can be things like new users or, you know, putting a 1.0 on a product convinces people who are already using it that it’s sort of stable and trustable, that kind of stuff. But earlier you mentioned, you not being too external facing in your description of what a launch is, but actually I do think there is an excellent internal reason that exists for almost any launch, which is basically energizing the team, really something about seeing. Again, it’s that moment, but a conversation, and again, it can be in a small circle, it can be a hacker news thread, it could be a couple of Twitter threads, it could be comments on product hunt, it can be comments on the YouTube video for some person that decided to review your product, whatever it is, but seeing that what you’ve made is out in the world, part of the conversation, and they usually have this push leading up to it, which the push can be uncomfortable at times. Yeah, certainly, I experienced this a lot in the game industry. But you make this hard push, and then you see it out there, and then there’s just something really energizing to that and trying to explain yourself to the world, I think strengthens your own internal culture and sense of identity and why are we all doing this, and what’s our mission and what are we here for? We’re not just pushing pixels around on the screen, we’re here to X where X is, whatever your company’s and your product’s mission is. 00:22:00 - Speaker 1: Yeah, I think this is huge in terms of strengthening the team identity and sensible accomplishment. I have very fond memories of our initial launch of Hiroku Postgress, which you and I were a part of, along with Peter Van Hartenberg, and I think a few others, or Ryan Henry, and we were grinding on this thing for so long, and we felt that we had infinite work in front of us. And in fact, we did, we probably at that point had accomplished 1% of the engineer year’s worth of work that have since been accomplished on Haruka postgras if that. But I think if I recall correctly, you were in there saying, guys, we gotta basically pick a point and launch it. And again, we felt like we had so much more to do, but it ended up being great just to put a stamp on it and to go out as a team for a night and celebrate that we had accomplished this release. 00:22:45 - Speaker 2: Yeah, the milestone aspect of it. I’m a huge fan of kind of milestones in general as a life hack, that’s not quite a technique one can use in your personal life, in your company, in your family, which is, you know, it’s very easy that the day passed day by day by day and you’re doing all the things you’re doing and you’re very heads down and focused on the details, and I like Milestones that cause us to zoom out and look at the bigger picture, maybe birthdays and, I don’t know, holidays serve that in personal life, but in companies and products, I think that shipping a product is one of the most important milestones. It’s something you make happen, and then you get this results that you see of what you put into the world, which is sometimes bigger and smaller. Every launch goes differently, you can’t totally predict it. There’s certainly a big element of, call it luck or randomness, in terms of how it will be received, but the fact that you did this together, you pulled together, you had this singular purpose, it all comes down to kind of a date, you know, one day or a couple of days, and then afterwards you can have that shared celebration, that’s a really powerful thing. 00:23:53 - Speaker 1: And I think sometimes you gotta basically manufacture it a little bit, to the extent that you’re artificially manufacturing, it’s not gonna be an external product launch necessarily, but I think humans, creators, they have this natural rhythm where every, you know, I don’t know, maybe every 4 to 6 years you want a big change, like you start a company, you join a new company, something like that, and every 246 months you need to kind of win like a feature level win, and every week or two you need to get commit level win or whatever. And if for whatever reason, you’re not getting that, which can happen if you’re working on, especially these big enterprise products that basically go on forever, like you’re never done. You got to manufacture and say, all right, this is version 7.2, stamp, celebrate, take a day off, that sort of thing. I think it’s important. 00:24:34 - Speaker 2: I think we talked in an earlier episode about the Ubuntu release cycle, and I know you’re a big fan of using time boxing or limiting time rather than scope to figure out products. Now you do still have to package things up in a way that’s coherent. And in this venture where I’m in the role of, for example, writing a memo to describe what actually is in this product launch, it needs to be something good and exciting. We actually had this debate in the team quite a bit, because honestly, the Mac app plus this local first sync is a huge chunk of work for our 5 person team, like really big. Actually, it’s quite a big risk. I think we’re taking with the business that we essentially have been doing no changes to our core product, the one that people are actually paying us for. Other than critical bug fixes for quite a while to work on this, and we’ve been working on the look for sync technology for over a year, not even counting the research time, so it’s a big risk, but we really talked through, OK, can we do just a Mac app or just sync between iPads and, you know, it just didn’t feel like 2.0, it didn’t feel exciting enough, it didn’t feel And maybe we could have done a sync between iPads as kind of a smaller feature and then we kind of don’t make a lot of noise about it and then go work on them. I don’t know, something like that, but it just didn’t feel like a good package. And that’s why we kind of decided to go to put all this together. And again, I feel this when I’m writing a memo or in some other way trying to describe, here’s what the team did and why you should find it interesting. And when I struggled to do that, I struggle to find that narrative, then I go, hmm. We don’t have the right package here. 00:26:12 - Speaker 1: Right. And I think having a good compelling package is important because again, you’re asking people to sort of break their frame. You take 30 minutes out of their busy professional lives to read our new memo or whatever and digest it, and our side of the bargain is obviously you need to have good features as part of that, but you also need to have some way for it to make sense to be able to do the memetic transfer over and for a product that’s the size and shape of music, I think it needs to be a story size package. It could be a feature if it’s smaller or use 2.0 complex of features if it’s larger, whereas Another example we could look at is something like an operating system, so they’re Ubuntu or Mac. They don’t really have, I would say themes. It’s more like it’s better as 13 is better than 12 sort of thing, although even there, at least with Mac, I know, I should try to find the source of this story, but My understanding is that they try to shape the release such that it has good like optics in the sense of it’s not all bug fixes, it’s not all workhorse features, it’s this combination of like big shiny kind of showstopper type features that are very visual and understandable. You got a bunch of workhorse features that people have just been asking for and then you got a bunch of bug fixes and you got to kind of balance that for it to be a compelling release. 00:27:33 - Speaker 2: Now you told a little story there about theoka Postgress launch. Those were good days for sure. And now, after Hiroki, you went on to work at Stripe for quite a while. Now obviously they’re a highly respected and also much larger company. I wonder if you can compare to how they went about launching things or at least your view from the time when you were there. 00:27:55 - Speaker 1: Yeah, so at Stripe, I worked a lot more on what I would call horizontal systems, so shared infrastructure, developer APIs and tooling and risk and compliance infrastructure. This is stuff that’s sort of cut across all of our products. So whereas at Roku, for example, I was more involved with launching discrete products and doing the the core product development of that at Stripe I ended up doing more of supporting in my own small way, a bunch of individual product launches over the years. And so the view I got there was really focused around how do you coordinate and deliver across all these different functions in this very complex enterprise, these product launches, and we could talk about it if it’s interesting, but the short version is one does not simply launch financial services products. 00:28:42 - Speaker 2: Well, that’s true, that’s a highly regulated industry and also one where, you know, my very first business venture was a payment gateway, and I do remember bugs in my code causing, for example, people’s credit cards to be double charged. And you know, sometimes that’s a problem when you, it’s a debit cards, it’s actually reserving money, that’s actually real money sitting in their bank accounts and now they can’t buy other stuff that they need, etc. It’s a higher stakes situation, not to say that productivity software, people are using that to do their work, they’re relying on it, it’s important that it not lose your data and that you’d be able to do your work and all that sort of thing, but there is something about, yeah, financial products, i.e. money and medical products. I, I don’t know, life force, those two have a particular high stakes element. 00:29:31 - Speaker 1: Yeah, and with financial services software it really strengthened my sense of working across teams to launch products. So with a typical like a SAS product, for example, obviously you have engineering, you have product management, you have design. And hopefully you involve marketing with launch, although a lot of product development people, you know, kind of forget or omit that step, it’s very important. But with financial services, you got like, you know, legal compliance, risk, support, and you really got to bring the whole company along across whatever 8, 10 functions. So there’s a lot of product management work that goes into that. 00:30:05 - Speaker 2: And did you find being in that horizontal role and part of a much bigger team was that more or less or the same in terms of satisfaction for getting your work into the hands of end users. I mean, in some ways maybe your customers, so to speak, or internal ones, right, like building internal tools, you could still I guess you do releases, you’re not going to do a big press launch necessarily, but if you have 100 people in the company using your internal tool, you might need to do some kind of announcement, try to get people excited and get them to bridge the gap from the old world to the new. 00:30:39 - Speaker 1: Yeah, that’s an interesting angle. I’m actually a big fan of doing internal product releases for internal tools. That’s something you don’t get to until you’re a medium size or larger, where you have dedicated internal tools teams, but I don’t know you probably hit this around 50 or 100 people or so. I think a lot of the ideas and lessons and movements from doing. External product launches can be applied internally. For example, this feeling of accomplishment and team identity can absolutely be magnified by doing an internal product launch, which can be as simple as sending an email to the whole company. Stripe actually had this really cool thing called Ship at ship at stripe.com and email alias, where people would write. When they had released a new capability. Now it was used both for external and internal releases, but it was especially useful for internal releases because there was no, you know, blog or Twitter that they could post to, and I always found that very focusing and rewarding to articulate to the company, what you’ve done, why, and what benefits they’re gonna get from it. 00:31:41 - Speaker 2: Yeah, you have a bunch of people who are incredibly busy, focused on the things that they need to do in their day, and you need to kind of get a little piece of their attention and convince them that you have something that will make their life better or easier. And that’s quite hard to do. And yeah, high energy, big company, there’s a million things to keep track of, a million projects, a million people, and you need to somehow edge in, or you need to somehow. be heard for the people that you genuinely believe you could serve, and say, hey, there’s this new thing and it will make your life better, and here’s exactly how and help them bridge that gap. And some of that is just having them be excited because they see, oh wow, this is actually is going to make my life a lot easier. Great, because there’s inevitably going to be some transition pain. And so that excitement of glimpsing what, how their life will be better on the other side, helps them get over that hump. And so it’s the same thing with launching a product there, it’s obviously less direct because you’re not inside the same company, but you’re trying to get someone’s attention in this extremely saturated media environment, someone who is in your target demographic that you believe you can help with your product. And help them understand if, and if so, why and how your product is going to help them, because once they get in there, they’re going to have to do some things to transition over to getting that value and so if they come into it sort of excited and with a vision in their mind of how their life will be better, they’re far more likely to be successful or try it all. And maybe that brings us to another important question to ask oneself in launching, which is who are you launching to? And I think that is again a challenge with some of the press launches, particularly if you think, oh boy, it would sure be great to be covered by some really mainstream outlet, I don’t know, USA Today, The New York Times, something like that. And actually it probably wouldn’t in a lot of cases, like I don’t think it would help Muse very much if for some hard to understand reason. Someone wanted to cover us there, right? We exist in a niche, that’s a very broad channel, and what we want to do is find where the people are who are right in our demographic that we can best help. And even talk about channels actually in a minute, but when you think about the who and trying to, you know, be a little crisp about that, I think even once you describe your demographic, you know, here’s exactly who we, you know, our target customer, you also can think in terms of where they are in their cycle of awareness of your product. So I think naturally you tend to think of brand new people. And those are always interesting because. The gap may be between, especially when you’ve been at it a while, we’ve been doing this, you know, coming up on 3 years now, we have a very strong mental model for cards and open canvases and Gestures and all these things that we’ve been thinking about, as does people who’ve been following our work or using our product. So when we launch a product, it might be inclined to say, wow, this is great, now you can have nested boards and cards on an open canvas, but also on your Mac, and to folks who’ve been following our work, they might think, oh yeah, that sounds good. And then to a brand new person who may well be in our target demographic in terms of they would need or want the tool if they can understand it, but they hear that’s a nested boards, cards can’t. What are you talking about? And you know, they just don’t even understand it. And so thinking in terms of how do I explain not just this release, but you’re really launching everything you’re doing from scratch, right? You’re basically explaining from the ground up for that set of people, here’s everything that Muse is and represents and how it might help you in your life. But you also definitely need to think about your current users and customers, right, letting them know first of all there’s new capabilities, which is both to get them excited, so maybe they’ll use those things, but also so that they’re not surprised, right, because inevitably, and this is certainly going to happen with News 2.0, but I’ve seen it happen in other, for example, we worked together on launching Hiroku Cedar, and that had, I think it was overall a vast expansion of capabilities and improvement of the platform, but it did change things in a way that There were some small set of users and customers that maybe they didn’t like the new thing as much. What was there already was serving them well, or just they were used to it. And new stuff comes along and I got to learn some new things, and that’s annoying, why are you bothering me with this? And so again, creating that excitement or just helping them understand, here’s why we’ve made this big change to a product you already use, like and pay for. We think it will overall make your life better, but here’s some things, you know, you should know to be prepared for. And then there’s a third category which is people who are in between those, which I think will be quite important for us on this launch, but I can see also similarities there with, say, Hiroki Cedar, which is people who may have tried the product before but dropped off, or maybe they kind of been following you because they’re sort of like, I don’t know, for example, they think our demo videos on Twitter are neat or whatever they like us personally or something like that, but they just weren’t in our demographic before because they say, well, you know, I just don’t use my iPad that much. Oh, there’s a Mac app now. Now I’m interested. Now I want to try it again. Or it might not be that crisp, but maybe they tried the product before, and yeah, it didn’t quite stick for them, whatever, but now there’s this big new release. People seem to be excited. They’re like, oh yeah, that was pretty cool. I’m trying to remember, what did I think of it before, I should check it out again, and then you go check it out again, and of course, a lot’s changed, it’s more approachable, it’s more usable, maybe it looks cooler, whatever it is, and so you have a chance to kind of reactivate or reconnect with those folks. And so I think It is a challenge in the messaging that you want to speak to all of them. You don’t want it to be boring as you re-explain all the fundamentals of what you’re doing to your base. I think as they sometimes call it in politics, the folks who are already your users and customers, but you also want to make sure you’re not alienating the new people. A big part of the reason you’re doing this is to reach a new audience. And so you do need to explain that whole thing. And then there’s the folks in the middle as well. So I think there’s quite a bit of nuance in that, but I think it’s an interesting storytelling challenge. 00:37:44 - Speaker 1: Yeah, and I think there’s an important marketing fact embedded in that, which is people generally don’t buy and use software because they’ve heard about it once. Usually people will need to hear about it multiple times from different people on different channels before it really sticks. And we’ve talked about how we went through this with notion, for example, where you and I heard about it from several different people, you know, here and there, it took several passes for it to stick for us and for our company. I think it’s the same way with any other software. And so part of what you’re doing with the launch then to kind of reframe what you just said is you’re making another pass over everyone and hopefully for some people that’s the critical, you know, end pass where they get it or you’ve planted the seed that will eventually propagate to someone, you know, some YouTube reviewer learns about Muse and they do a video and then that is the end pass for a new customer. You’re always building this reservoir, if you will, of familiarity with the products. 00:38:45 - Speaker 2: So I mentioned channels, and that’s I guess a piece of jargon or marketing terminology that describes how people might hear what you have to say. And once you are an existing product or company, you do have the benefit or luxury perhaps of an existing audience, so all your Twitter followers, your email list, if you’re on other social media, and I think that’s a really important one to speak to right from the start. If those folks get excited, They will help and support you. And by the way, I’ll mention that one of the things that made our 1.0 product launch really rewarding for me was just how much support we did get from all folks out here, folks who listen to the podcast, colleagues that you and I have worked with, folks who were early beta testers in the product, and just others that just liked to see more innovation and cool stuff happening in the tools for Thought space. And so we had quite a lot of folks coming out and showing us. Really lovely support in comments on product hunt, comments on hacker news, retweets, all that kind of stuff. So I think your existing audience, now at the very beginning, you don’t have an existing audience, that’s where you bootstrapped it, maybe a little bit with that landing page, but we do have that luxury this time around. But then you go to more traditional channels, now it would be, yeah, aggregator sites, Reddit, Hacker News, it could be events. Certainly there’s, well, companies put on their own big kind of marketing events. We talked about Apple, but there’s also more conference style events. Hiroku got a lot of value from using basically the kind of rails comp and other developer community events, either to launch products or to make connections with the community. I press that we’ve talked about a little bit before, which includes classic press, but also, I don’t know, YouTube influencers, product reviewers, that kind of stuff, and even something like paid media. You know, I don’t think too many folks are big fans of advertisements. We dabbled with it a little bit from use and didn’t get great results, but I have been part of a lot of businesses where paid media was a huge part of how they managed to get started and get their early audience or how they managed to scale something they had that was working, so it shouldn’t be ignored. And I think you can think of all of these together, you have a single message, a single thing you want to say, that’s probably mostly conveyed through your website. And then you think, how do I repackage these things for all of my channels? It also includes even something like marketplaces. So you know, if you’re a game company, probably something like Steam or Xbox Marketplace or Switch Marketplace or whatever is probably a really important channel for you. Obviously for us, the App Store and being in the Mac App Store will be a big one for us and then there’s editors, you know, human editors who work in that and look through the deluge of new apps that come out all the time and try to pick out ones they think are interesting to kind of bump up to the top of the pile. And so, The challenge is each one of these channels has its own shape, right? You know, Twitter has, well, now 280 characters, and you can attach media. Instagram is very media oriented, not so much on the text, but you actually can’t put links. How you post something on Reddit, for example, just looks completely different from how you post it somewhere else. And yeah, paid media, it’s just a whole gamut of different things, right? Like every single ad, whether it’s banner ad or Google AdWords or whatever, they just all have very different formats. So you want to make sure you have the same message, but adapting that message to all these different formats and what’s right for the channel. She’s a huge amount of work. When I think I frequently underestimate. And as a reason why I think it’s good to to kind of focus in on a small number of channels that you think are really likely to get a good result for you and try to make those channels, try to invest in them in a way to make the message really strong there. 00:42:28 - Speaker 1: Yeah, honestly, it’s been especially challenging from you because it’s such a rich multimedia visual app to create assets for that for all these different channels can be tough. It’s one of the reasons, by the way, that I’m so bullish on trying to facilitate and encourage social distribution, cause then people adapt and use their own visual content and they’re perhaps more expert at the particular channel format, whether that’s YouTube videos or whatever. 00:42:56 - Speaker 2: Now, one that’s in this list that I think is sort of special in a way is Product Hunt, and I had never used them much or I guess I knew it had become a big deal in the sense of a lot of people use it and certainly use it to launch their products, but also find out about new products. And so it was just kind of an experiment with the Muse 1.0 launch to do product hunt. We did pretty well there, we weren’t the number one, but we were the top few and The comments were really good and so on. But actually, part of what I think is interesting about it is it is a channel incredibly specific to product launches. And so in a way, just trying to fit into that channel, I think helped me crisp up how I was thinking about launches, and Product Hunt has a how-to guide called how to launch on Product Hunt that’s quite comprehensive, really well written. And the process of reading that and learning about it as I did a year and a half ago, I think it helped me think more crisply about launching generally. So I think I would get value from that even if I wasn’t launching on product hunt. But maybe we’re coming back to this kind of event or moment. Part of what makes it work so well is your product page will basically last 24 hours. And so your website and even something like a blog post or, you know, a memo that you might do on your website, that’s something that’s obviously supposed to be long term. The website. And the core message and whatever is there, you may adjust it and adapt it, but probably it’s going to be pretty similar for the next, you know, 6 months, year, year and a half. You might have a blog post or something like that, but with any luck that’s getting shared around for a week or two, maybe people are still reading it, even, you know, they put it in the relay or tool or whatever, but product hunt is really specifically time limited. It goes live at I think midnight, I don’t know, it’s GMT or something like that, or maybe it’s midnight US East time, I can’t remember. And then you have one day where people can upvote and post comments and you’re there as the creator engaging and responding. And yeah, it’s a powerful thing because directing people to that link is a way to say, here’s our long term stuff, you know, go read that or watch this video or whatever, but here’s the event. Here’s the moment, here’s the place we’re gathering, and it’s a place for people to come show you support, but also people who are new to come and just like, feel part of that energy, maybe in a way that you couldn’t just with Twitter that has a very kind of fragmented social graph. 00:45:20 - Speaker 1: Yeah, now I’m thinking of Salesforce’s Dreamforce, which also had this property of being a known launch shaped container, although obviously it was a very different one. It was a very cool structure where my understanding was basically Salesforce said every year at this date, you can come to San Francisco and we’ll tell you everything that’s happening this year. And then people over a decade, they became accustomed to that and Salesforce was very successfully able to use that container to launch products. It’s going to show there’s value in having a place where both sides know they can go to get launch shaped things. 00:45:58 - Speaker 2: Yeah, that points to another reason why something like Dreamforce or Apple events work is you have to be kind of in a certain mindset to be interested in a new product, which is, for example, I remember at the start of the pandemic, we heard feedback from a few users and customers. Of course, we were pretty early on at that point, but they basically said, oh, I’ve been, you know, forced out of my office for a little while and I’m just using that as an opportunity to kind of rethink my tool stack before I I had a whiteboard on my wall, and that’s where I would kind of go to pace and think. I thought, OK, what other options are there for that in my home office that is more constrained in space as one example. But there a person’s in the mindset of changing stuff and I’m looking for new tools and I’m In that state of mind. And I think most of us, most of the time, rightly so, we’re living our lives, we’re working our jobs. We don’t want to change things. We don’t want to hear about new things. We wanna continue what we’re already doing. Necessarily introduction of new tools to anywhere in your life and your work is going to be a little bit disruptive, and that disruption can be well worth it, but you kind of have to be in the mood for it. So maybe when someone goes to, yeah, Dreamforce, Google IO, an Apple event, something like that or watches it, they’re in the, they’re getting their set themselves kind of in the mindset of, OK, there’s going to be something fun and exciting here, and let me open myself to the possibility that I might get exposed to a product, be able to think in terms of how does this fit into my life. 00:47:28 - Speaker 1: Yeah, totally, and perhaps there’s a generalization of this which is that a product launch needs to prepare and calibrate the potential user for like how much the world is going to get shaken up by this thing. So Muse too, it’s still muse, but it’s a, you know, major version change, so prepare for a moderate amount of novelty in your life, whereas a little update would be smaller and sometimes companies introduce whole new named products, which is a way to signal to the user, OK, like, you know, buckle in, we’re doing something pretty different here. 00:47:58 - Speaker 2: And we’ll wrap it there. Thanks everyone for listening. If you have feedback, write us on Twitter at MuseAppHQ or via email, hello at museApp.com, and you can help us out by leaving a review for the podcast on Apple Podcasts. And Mark, I’m excited to come out of our micro cave here a little bit first with the beta, but with the full launch share and share not just the 2.0 product message with the world, but also the larger message that we want to see folks be more thoughtful. We think that the right software could help accomplish that, and we hope that the software we’ve made could help accomplish that for you. 00:48:36 - Speaker 1: Right on, looking forward to it, Adam.
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: As software developers, maybe we go towards building a GUI with specialized inputs and forms and controls too soon, because it’s so much easier to explain to the computer what the user means if they use a specialized input tool like a button check box and so on. But if that weren’t the case, if it’s easier for the computer to understand what you mean as you’re typing in your note, then suddenly text input is the primary thing. 00:00:32 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for deep work on iPad and Mac. But this podcast isn’t about Muse product, it’s about the small team, the big ideas behind it. I’m Adam Wiggins, joined today by Jeffrey Litt. Hey. And Max Schoening, great to be here. Now, the two of you are working together with some others on an ink and Switch project we’re gonna talk about today, but first, I understand that there’s some cooking adventures going on in the lit household. 00:01:02 - Speaker 3: Yeah, so I’ve been trying to make my own stock lately. I’ve been reading this incredible book that someone recommended to me on Twitter called An Everlasting Meal by Tamar Adler, and it’s all about how to use leftovers and just like random stuff in your fridge to cook both as a way of not wasting, but also just cause it feels good. So I’ve been, you know, throwing random like carrot tops and stuff into a pot, and it feels really fun. That’s my recent cooking adventure. 00:01:29 - Speaker 1: Inspired by, we’ll get into it a little bit later with the project too, but partially by Jeffrey’s cooking. I’ve also started taking cooking maybe a little bit more seriously than before. Like I think one of the things that sort of distinguishes the amateur from someone who’s more seriously involved in something is consistency and my cooking was never all that consistent cause the loop of how frequently you repeat a dish when you’re just cooking sort of for fun is very long, right? So the learning is slow, so I’ve been getting into sous vide cooking. And just eating way more steak slash anything you can sous vide that I would like, but at least the results are getting better. 00:02:11 - Speaker 3: I’m a sous vide fan as well. It’s a major cheat code, I find. Everything is perfect every time. 00:02:17 - Speaker 1: I wish that had been my experience too. 00:02:21 - Speaker 2: Yeah, consistency and repetition, yeah, short feedback loops. I was inspired by a book, I think it’s called the Food Lab, where basically the author does some, call it like. Amateur science in the sense of taking common cooking claims, like should you salt meat before cooking it, or is it better if you don’t flip it, or you only flip it once versus twice or something, it would essentially just cook several side by side, varying this one thing. And then do a little informal taste test with his, you know, housemates or whatever, and sort of like try to answer that question, and many times found out that, or at least had the finding, let’s call it, that things that people swore by didn’t really actually make a huge difference in the outcome, but that idea for myself, I think even our Mutual friend and colleague Peter Van Hardenberg introduced a version of that in the Hiroku offices when he would do a little coffee workshop and essentially like brew a cup of coffee with several different approaches, you know, here’s the Chemex, here’s the French press, here’s the, and then you could taste them side by side and have new appreciation for the way these different techniques change the taste of the same source bean. 00:03:34 - Speaker 3: Yeah, I love that mindset. I think what I see as the challenge at home cooking is, you know, to bring in some of that idea of getting better and being a little rigorous without making the whole thing too overcomplicated and kind of perfectionist. There’s some aspect of amateurism and just having fun with it, that’s sort of the whole point to begin with. So I think that’s a fun balance to strike. 00:03:57 - Speaker 2: So longtime listeners of Meta Muse will know that we’re shaking up the format a little bit here. This is our first time with two guests. It’s usually me and Mark as co-hosts along with one guest, and this is partially my theory that it’s a little hard for listeners to adapt to two new voices, but in fact, you two are not new to our guests potentially. Max, you are one of our very first guests all the way back in episode 8 when we talked about principal products. And Jeffrey, you joined us for somewhere around episode 34, where we talked about bring your own client. So, anyways, I thought it would be fun, especially because both of you work together on this research project to get you here together. So you can go back and listen to those episodes if you want the full backstory, but maybe you could each give a 32nd summary bio of yourself before we dive into the project itself. 00:04:51 - Speaker 3: Yeah, so I’m a grad student at MIT as well as a collaborator with the In and Switch Research lab, and my research mission is to figure out how to make software more customizable so people can edit the tools that they use and make their own software, and the project we’ll be talking about today has a lot of resonance with that theme, so excited to be here again. 00:05:12 - Speaker 1: And this is my first foray into research. I’m a software designer. I’ve worked on things like Hiroku, GitHub, cloud app, way in the past, and generally I like to summarize. My efforts as I like to make things for people who make where make is the developer build tool. 00:05:33 - Speaker 2: And our topic today will be dynamic documents, which indeed is what the potluck project that you both worked on and recently published about is all about. So we’re hoping to dive into the specifics of that project as well as some of the research process behind it. Maybe we could start out with a description, kind of the, I don’t know if elevator pitch is the right way to talk about a a research project, but a short summary. 00:05:58 - Speaker 3: We’re not raising funding, but I can give a summary, sure. So, Potluck is a substrate that we’ve been developing, where the goal is to turn regular old text documents into interactive tools that help you in your life. And so there’s this idea that you can just start by, you know, jotting a note on your phone like you might in an app like Apple Notes, and then gradually you start enriching that note with little bits of computation and interaction. And if you keep doing that for a while, you might end up with something that looks suspiciously like An app that you might download from the app store, but it’s not like someone else made it for you, it’s sort of organically evolved out of just a note that you started writing, and, you know, some examples of the kinds of things that we’ve thought about in the substrate are You’re writing down a recipe that your mom told you for how she makes her dumplings, and then you decide, oh, I’m gonna have a party, so I want to make 5x the recipe. What’s like 730 g times 5. That’s something that a computer should be able to help you with, right? But if your data is in a text note, how do you bring in the computer to play its role and help you out a little bit? We’ve developed these primitives where you can start injecting these little bits of computation as you need them into your text note. And so, that’s kind of the overall idea of the project. One analogy that I think is helpful to understand the general ethos of it is spreadsheets. I’m a huge, huge fan of spreadsheets. I think they’re a really empowering medium that people interact with pretty typically on a computer these days. And the cool thing about a spreadsheet, right, is that when it starts out, it’s just a bunch of numbers in a table. It’s just data sitting there, and it’s already useful in that state. And then gradually you might add a little formula, you might add a V lookup, and if you keep doing that, by the end, you might end up with this ridiculously complicated app that’s running your whole business, but it didn’t start out that way. It wasn’t planned to happen that way, it just started out as this little bit of data that you were storing, and it naturally evolved, right? So that’s kind of the general idea. 00:08:04 - Speaker 1: Yeah, there’s the well known meme of this insert startup could have been a spreadsheet, and I think in this case, you could probably make the same argument that this app could have been a note. And in fact, I would love to be able to do this at scale, but like if you just open the average users notes apps, what kind of notes do they take and, you know, throughout the course of this research project. That was sort of a grounding force of, oh, what kind of notes do people keep track of and so we started looking at, you know, like Jeffrey was saying recipes. At some point we did workout tracking and plant water tracking and like collecting your favorite hikes and so on, and they all have this sort of very innocuous beginning. You’re not planning to make something big, you’re just sort of planting a little seed as a note and What was frustrating for us is, at some point, if you then want a little bit more help from the computer, you usually have to move it out of the notes app, which is a little bit sad because it’s this big drop off, and so that’s kind of what we’ve been looking at, like, how do you make that go away. 00:09:14 - Speaker 2: And I love the diversity of use cases outlined in the essay. You focus on this cooking use case as a sort of a central one, even baked into the name of the project, but indeed all of these different kind of personal tracking stuff that tends to get scribbled down in notes and and in particular notes in your phone, text notes in your phone, that they’re not very structured, you’re trying to capture them in the moment and move on. And certainly many of those are things I have done, but also there is a whole industry is a way to put it, category of app which is trackers. So, yeah, hike trackers and run trackers and sleep trackers. And yeah, fitness trackers, step counters, weight trackers, you know, and sometimes that’s paired with, I don’t know why, you know, Fitbit has their Wi Fi connected scale, and when you step on it every morning, it automatically records the data, but then a weakness for someone who is both curious and has some light programming capabilities is actually getting that data out or doing something with it in a more flexible tool like a spreadsheet. is often pretty difficult. Actually, Fitbit, I think even famously had a little bit of pushback for the, you had to pay for the feature to kind of like download your data as a CSV and even then it feels like this very discontinuous, OK, I’m exporting now, the data, who knows what format it’s even in, and there certainly can’t be a continuous using of the app, inputting of the data, and then also I’m gonna put it through my own, call it personal analytics. 00:10:43 - Speaker 3: Yeah, and I think another weird thing about this ecosystem of trackers is that it sort of splits up your life into these very specific categories, right? So, for example, after my workout, what if I have a nutrition shake and I’m tracking my nutrition, I need to switch from my workout tracker to my nutrition tracker, and there’s this sort of world that each app considers its space that it doesn’t go outside of, you know? This also happens when, you know, We looked a lot at recipe apps because we were thinking about cooking as one of our main domains with this tool, and a lot of cooking apps start out very simple with tracking your recipes, but then there’s sort of a natural force to bloat them with extra stuff, so, You’ll add grocery list stuff, and you’ll add menu planning, and, you know, meal planning for the week, and all these. 00:11:29 - Speaker 2: All of your friends, what are they cooking? 00:11:31 - Speaker 3: Yeah, like social, you know, and I feel like we’ve all experienced this tool starts out nice and small and grows in weird ways. And what I think is important here is, I’m fine with it growing in the ways that I want it to be useful. What’s annoying to me is having 100 things crammed in there that I don’t need and can’t remove from the tool. And then on the flip side, the one extra thing that I do need, I can’t add myself, right? So, we sort of like, let the developer of each tracker decide what does cooking or what does workouts mean, like, what’s the scope of that activity, and it’s really hard to permeate that kind of boundary that gets set there, and so that’s one of the problems that we were thinking about in developing potluck. 00:12:12 - Speaker 2: So some of the key concepts here, dynamic documents is obviously a spreadsheet is a dynamic document, but the idea here is taking text, plain text, which is incredibly universal. Everybody’s phone has some kind of plain text notes app just kind of built in by default, but then you can use gradual enhancement to add some computation and make it something dynamic while keeping that same basic medium of just simple text you can manipulate. That you also talk a little bit of the essay about personal software, which I think is precisely this concept you’re just describing here, which is rather than my run tracker being an app that I download from the app store and I’m more or less just have to use it as intended by the developers, that I can use the computational medium to build a quote unquote application that just suits my needs, is truly personal. 00:13:05 - Speaker 1: Yeah, personal software is, well, first of all, I think it’s getting more mainstream in the sense that if you look at a lot of people’s notion, usage, and all the other insert, you know, personal knowledge management tool here where people are sort of aggregating all of this stuff in their life into a personal OS and I don’t know where the appetite comes from. I don’t know if it’s tied to increased computer literacy, at least some form of computer literacy, or it’s people have been burned by their favorite app changing either by adding too many features or just being deprecated, but there seems to be a lot of energy around it and so one of the things that is surprisingly Or rather, something that you wouldn’t think about right away is when you start building these apps from scratch from a note, you never really notice that you’re actually making a big complicated thing. You’re just starting out with some text and at some point you start adorning that text with some functionality and you just keep going and going and going, and at some point you wake up and you’re like, wait, this is actually quite complicated logic. Am I a programmer? And for us, that sort of was quite important, right, like embracing this notion of personal software that is truly yours, not from some team somewhere in Silicon Valley or wherever else deciding what’s best for you. And I think Jeffrey, you gave this analogy early on to like imagine our homes were Just furnished completely by other people, and all the objects in there just are sort of almost immutable, like we would not have that, and we do with software, and so I think nudging at that is super interesting. 00:14:53 - Speaker 3: This is one of my favorite ways to Open up my own mind to how weird software is, is to use analogies to other parts of the world, you know, I think we sort of have gotten so familiar with these metaphors of how software is organized. Like, in some sense, in this potluck work, what we’re doing is arguing against the idea of applications, right? Which is a really weird argument to make to a typical computer user, you know, it’s fish and water, like, what do you mean? I love apps. Apps are how we do things on computers, but It doesn’t have to be that way. I mean, Alan Kay, who’s responsible for a lot of the metaphors we use in personal computing, has, I think, said that apps were like the biggest mistake that was made in software ever, or something like that. You know, another analogy to bring it back to the food thing, I think, is restaurant versus home cooking. And the reason I like that analogy is that I think it gets that, I’m not trying to argue that we should ban restaurants. I love going to restaurants. It’s more like, if you imagine a world where All you can eat is restaurant food every day for every meal, and you think about what kind of society that would be, it starts to feel a little weird, right? When you go to a restaurant, you are putting a lot of trust in someone else to give you a good experience. You’re accepting kind of a restriction in choice, whether that’s like a full on oakcase, you know, meal, or even, you know, picking from a menu with 10 items is very different from going to the grocery store, right? But also, you’re acknowledging maybe that chef can do things I can’t, and maybe I’m tired today and don’t want to cook, whatever the reason may be, it’s nice. But it’s also a certain kind of limited experience, I think. And when I look at home cooking, I see a totally different set of trade-offs and values almost, where I’m not trying to become a professional, I’m not trying to make the best thing, I’m just trying to make something nice for myself that I like, and, you know, for my family, whatever. It’s a very different scale and and feeling, and I think that’s sort of the right way to think about, you know. There are always going to be tons of professionals making software, and I think that’s great. I love Apple products where someone in Cupertino has thought for a year about what the width of this button should be. I’m not against that, it’s just that I think there’s also this complementary role for a different way of thinking, especially in these more personal domains. And one last thing I’ll say about the home cooking analogy that I think is interesting is that it’s a very cultural thing. If you imagine a world where everyone always eats at restaurants and you tell someone, you know, why don’t you start cooking in your house? They might be like, well, I don’t know, that seems really hard, like, all these chefs have spent like years in school or whatever, and, you know, you can see the analogy here to, like, currently software is so professional and difficult, that it just seems unthinkable that everyone would be making this stuff themselves every day, but I think we can imagine a culture where that’s a little different, and, you know, try to promote that kind of Thinking and culture more generally, and I think that would be a good thing for software. 00:17:51 - Speaker 2: Yeah, I think the restaurant versus home cooking comparison is a great one, and also just reflects the fact that in the scheme of things, computing is just so new, and we don’t necessarily know how it fits into our lives and our society and how to relate to it, and we’ve ended up in this, you can think of it as a local minima or just a particular circumstance of time, which is that software is built by these professionals who are typically far away and building for many, many users. That’s not where we started with computing, and I certainly don’t think that’s where we’ll end up, but hence the reason to invest in research to take us in this direction. Now one thing I think your project touches on that’s an interest of mine, obviously I would lump this under end user programming, something we’re all interested in essentially bringing programmability of computers to a wider audience, not necessarily in a professional app building context, but just in the sense of embracing the dynamic medium. But I feel one of the big unsolved problems of end user programming is really just getting it into a context where people can use it. There’s many, many really amazing research projects and prototypes and etc. where if you go into there, I don’t know what, here, launch this small talk browser and once you’re within that world, everything is malleable and composable and you have total power, but it’s not connected to anything you do in your life. And one thing I like about how your team went about this project is that You’re starting from text notes, which are on your phone. Now, it’s sort of an unanswered question is how exactly this computational medium gets into the notes app or whatever, that maybe it’s not a part that’s figured out, but very hypothetically, going from, I’ve got this text file or a series of text notes, and I wanna layer this dynamic medium on top of it, feels like a lot less of a jump than many of the other kind of programming accessibility research that I’ve seen. 00:19:47 - Speaker 1: Especially cause if you actually look, for example, Apple Notes, right, it already has hints of these data detectors. If you type a phone number and I don’t know, a few other dozen types of content, it automatically finds them for you and underlines them, and then you can, you know, tap and initiate a call and potluck just takes that notion to an extreme by saying, well, first of all, I can write my own detectors cause I don’t just want to find. A phone number I might want to find the quantity of a recipe and then it also just doesn’t limit you just to the oh I can tap and initiate a preprogrammed action. I can do something else with it, a calculation, fetch some different data and so on, but it’s a very gradual enrichment of the original note and it’s also already somewhat at home on iOS. I don’t know, Jeffrey, if you want to talk a little bit about the data detectors and the origin. 00:20:47 - Speaker 3: Yeah, totally. One of the more interesting kind of related work references that we found while we were thinking about this stuff was, what I think is the original paper describing the seed that has become these, you know, phone number recognition and stuff in modern Mac OS and iOS. But there was a research team at Apple in the late 90s, which included Bonnie Nardi, who’s sort of well known in the end user programming space. And it’s really interesting seeing the original rationale they had for how they got to this idea of data detectors. Their starting point was thinking about, OK, how can computers help us do stuff and be intelligent helpers, and they Sort of draw this distinction between two styles of how the computer can help you. One is the computer just does stuff for you, or like, you know, you sort of vaguely say what you want and it doesn’t, sort of more of an assistant metaphor, you can imagine, you might not even know it’s doing stuff, it’s just behind the scenes. And I think this sort of corresponds to some of the modern ways that people think about, oh yeah, AI will just do it for you type of thinking. But they realized that actually, both at the time that was totally infeasible. Computers weren’t good enough, weren’t smart enough to actually pull that off in a satisfactory way. And they also realized maybe it’s not quite what we want, and they went down another path, which is, let’s just have the computer find stuff for us that we care about, like, dig around in all the things on my desktop and find useful information, and then let me decide what to do with it. And You know, as Max was saying, I think their view of what you can do with the information was relatively like straightforward. You just right click on a phone number and you hit call this number, simple interactions like that. But still, this idea that the user was in control of what to do with the information. And so, I think that’s a really nice kind of design goal for these sorts of systems is carefully balancing what are the parts that we want to be automated versus where the moments that we want to be in control, you know. 00:22:49 - Speaker 2: And data detectors is the term from, I think that paper in the potluck essay, you call it extensible searches, is this a rebrand to be a little more familiar to current audiences, or do you see that as actually, it’s because it goes beyond these more automated kind of default types, like a phone number and address? 00:23:10 - Speaker 1: With a lot of the stuff, it’s very serendipitous about how it happens during a project, and we initially didn’t even start out with potluck having these continuously running searches. It was much more of a manual process. In fact, I think to this day, if you look at the code, it’s still like cold highlighters because we started out with this notion of, well, you have a note and then the sections that you care about, you’ll just highlight and you have different colors for highlighters to start imbuing those highlights with computation. And someone on the project at some point sort of said, oh, well, why don’t we just run a search against it? And at the time, I think we didn’t even call it search, it was just a pattern. But if you think about how mere mortals would maybe think about this as well, I have like a Google doc open. How do I target a specific word in the Google Doc? Well I hit command F and I try and find it, right? And so that’s where this notion of search comes from, which is sort of the Most maybe human way of thinking about these detectors. 00:24:11 - Speaker 3: Another small thing I’ll add is that one of the really cool parts of the original data detector’s vision that we share, but it’s kind of been lost in the modern Mac OS version, is this extensible part of extensible searches is also really important, the idea that you can define your own. You know, in potluck, this means that you can decide that these are the types of ingredients that I want to find in my document, and nothing else. I control the dictionary of what I consider foods, or I control the list of workouts. So if I write, you know, squat, my note will recognize that that is a kind of workout that I do, but all of it’s sort of very tailored to your life. And the original data detectors paper had this too. They had this idea of, for example, you would teach the system, here are all the names of the conference rooms in my office. So whenever I write the name of a conference room anywhere in my OS, the computer will just know that that’s what that means. And of course that doesn’t apply to every Mac OS user, it’s more of a personal data detector that’s tailored to exactly my context. 00:25:08 - Speaker 2: Maybe like adding a word to the dictionary so that it doesn’t show up as a spelling error because it’s some nickname for something in my life that wouldn’t make sense to add to a global dictionary. 00:25:20 - Speaker 3: Yeah, exactly. 00:25:22 - Speaker 1: It’s funny to think about how frequently we have data detectors in the software that we use, right? Like on GitHub, if you want to reference an issue, you do pound 247, and that’s a data detector, famously like Twitter hashtags and at mentions were all not built into the software. They were just ways in which people invented small little microsyntaxes very fluidly. And there is no primitive in the operating system that is not super far down to actually do something fun with those, right? And so by making it super easy right in the context of the note to write a new data detector and super easy, we can get into that a little bit later, is obviously a spectrum. Ours still involves way too much knowledge of programming to be super easy. But the power of inventing those small microsyntaxes is super addictive. Like you just start coming up with small things that only you are familiar with, kind of like in a notebook, you would have some sort of notation, and it’s just flabbergasting to me that operating systems haven’t embraced that at a more sort of a cross app boundary level, right? Like, I think to this day there is a class in Some SDK from Apple NS data detectors where I believe developers of apps can write data detectors for you, but you as a user have no influence over them, which is fine, like I guess some developer could build an app that lets you write your own, but partially what gets left behind there is that the same data detector should run across many applications. If I have that, you mentioned a meeting room. If I have a meeting room name, then you should highlight it in iMessage in mail app in notes and my 23 other apps that I’ve just downloaded from the App Store, and that’s sort of lacking. If you read the paper, I highly recommend it. I’m a huge fan of BonnRD. It’s very sad that we don’t have that in our computers today. 00:27:24 - Speaker 3: And I think this brings it back to what Adam was talking about earlier around integrating with the rest of your tools, right? Sometimes. I think a really important point to make about this research project that we’ve made is that currently, just to be able to move freely, we’ve built this thing as it looks like an app. You open this thing called Potluck, it is, you know, a web app, there’s a text box and you can do all these fancy things with the text, but the final form of this that we envision being good is not a separate app, it’s deeply integrated with all your other tools. You could imagine any app that has text, you should be able to pull this panel of searches over and just start pointing it at any text in your system. And we actually built a little bit of that into our prototype where we do some things where we actually interopt with.txt files on your file system. So you have a little bit of being able to open these text files in the text editor of your choice, work with them, and then when you look at them back in potluck, you see the interaction appear on top, but I think that one of the interesting open questions that we haven’t quite figured out yet is, how does it really work for this to be embedded at more of an OS platform level? Like, where do these search things live? How do you share them with other people? How do you share them across apps? It’s just sort of an interesting design challenge to think about there. 00:28:43 - Speaker 2: I feel like there is a commonality across many research projects that I was involved in and I can switch in maybe in general in the research world, which is if you could do it just in an app, you would try that, but the whole thing that makes a research is really this is something that should probably be operating system level or just cuts across. This tech stacks or the tools you use or the devices you use in a way that isn’t really well supported by the current ways that things are divvied up or the way that we kind of compartmentalize the various elements of our computers and hence the only way to try them and see if they are plausible or good ideas in. or how they feel to use is to do them in this research context where you kind of have to hand wave and say, well, imagine this was built in your text editor or cut across all your apps or you know was there in the browser or you have a good way to share these things. Would we want that? Would we like it? Would that help us? And that doesn’t get you all the way to what it would look like in the real world, but it certainly is a fair sight further than just sketching it out on a whiteboard. 00:29:49 - Speaker 3: The first one is figuring out what we want, prototyping the experience with enough fidelity that we actually have some idea of what platform primitives we would like to have available. And then the second part, which I think is at least as hard, is how would you actually enact that kind of change in the world. If the thing you’re doing is not trying to add another app to the app store, but totally change the structure of the app store, and all the economic incentives and the technical interfaces between things, that’s a very different shape of challenge, and so, yeah, it’s a lot. 00:30:24 - Speaker 2: Now obviously I’ll link the essay in the show notes, and there’s also a live web demo that’s pretty workable, I think, or at least in my experiments with it got pretty far, which is saying a lot for a research prototype, which tend to be, you know, focusing on the learning rather than the polished product. So I’ll link both of those in the show notes and people should certainly check them out. I’d be curious to hear briefly. On the findings and what you learned from building this and trying to use it in practice. Was there anything that stands out as surprising or unexpected? 00:30:58 - Speaker 1: I think there was this distinct moment in time where the prototype was actually good enough, that inventing your own syntax for something was very trivial. You could just say something like find every line that starts with plant emoji, and then suddenly do something with it. And I still remember it having the feeling of why doesn’t all software work this way. And so to me it wasn’t super obvious that personal microsyntaxes should be a thing, and the idea that the same way you can scribble personalized notations into a paper notebook, that we could bring that into software. If you make it easy, right? If you don’t make someone go into some settings screen that’s 4 pages deep to say I’m going to change how this works, right, like usual programming, but just ad hoc, you’re like, oh, I’m just gonna start these next lines with, and, you know, famously look at markdown, like, I’m gonna start the list with asterisks. Well, I can just invent that. That to me was actually a very surprising finding is the ease of creation of a syntax and then the utility. 00:32:07 - Speaker 3: I think for me, one of the surprising things was just how nice it is to work in text. This might be sort of a bit of my programmer brain, you know, speaking, but I’m not typically one of these, you know, everything I do is in plain text kind of people, but I found that We’re so used to editing text. We have really strong muscle memory around, for example, things like, I can select some text, cut it and paste it somewhere else, or I can even paste it into another app, or I can undo, and I understand how Undo is gonna work. And all these little affordances are really mature in the systems we use, and they’re mature in our heads. They’re really strong conventions, and I think One thing we found is that when you build software on top of that really solid foundation that we all have, a lot of things just sort of fall out of that. So, for example, when all of the state of your application and all of its UI live in a text file, you can just snip parts, move them around. If you undo your app has undo for free because it’s state is stored in the text. You get all these things out of that. And I think there’s some lesson there it feels about, I guess it’s about using the same well developed tool for many different things. I’ve used the analogy before of, it’s like a chef’s knife, where it’s like, good at all these different things and someone put a lot of effort into making it really good and versatile. It feels like there’s something similar there going on with text, and It’s not a new insight. I think there’s lots of people out there who do Emacs or there’s all kinds of to do list apps, or, you know, budgeting apps based around text files. I think that’s a thing that some people have been experimenting with for decades, but it was surprising to us just how far you can push that into so many different domains. Of course, you can’t do everything with text. There’s lots of apps that would be ridiculous to even try making them potluck, you know, YouTube is not the target, but I think that’s fine, you know, there’s some Kernel of personal use cases that fits really well with this medium, I think. 00:34:05 - Speaker 1: Yeah, plain text, or just maybe text in general, is a surprisingly good layout engine in the sense that if you want to make personal software very frequently you’re gonna have to go and come up with your own layout. Oh, I’d rather actually have these things at the top and not at the bottom of the screen. And I think maybe because as professional sort of software developers, maybe we go towards building a GUI with specialized inputs and forms and controls and all that stuff too soon because it’s just so much easier to explain to the computer what the user means if they use a specialized input tool like a button check box and so on. But if that weren’t the case, if it’s just easier for the computer to understand what you mean as you’re typing in your note. Then suddenly text input is the primary thing. And if you think about what we do on computers all day, including people who are not sort of in the industry, yes, Emacs and so on, great, but you spend most of your time writing texts to people, right? So if you can’t type on your device, then you can barely use it, which means most people who use devices spend a lot of type typing. And I think we should encourage software designers and developers to lean into text way more than we do, and like you even see that possibly in this resurgence of the command K command lines that every app now implements, right? Like command palettes, which are also just text-based entry. And so I think potluck maybe takes this to the extreme of saying, look, just write whatever you want, and then we’ll just teach the computer with you how to interpret what you wrote, and then you can do awesome things with it, and that’s kind of exciting to me. 00:35:47 - Speaker 3: In some ways, it’s like even one more step towards messy than spreadsheets. Someone at the lab was computing a spreadsheet, I think, to sum up how heavy things would be in like a backpack for a hike, and At some point they realized, oh, I should just do this in potluck, because even the effort to put it in a spreadsheet table was just felt like a little bit of ceremony, like, spreadsheets are sort of clunky to edit on your phone, for example, whereas text, it just kind of, it’s one dimensional, so it resizes onto your phone, you just type characters in, it’s very low ceremony, and so if you can get the interaction you want out of such a messy data substrate, in some ways I think it’s like a good go to before you start adding too much structure. 00:36:29 - Speaker 1: Yeah, there is this, I think we link to it in the essay as well, a paper, deferred formalism, which sort of encourages you to not get into structure really early on, right? and text is great, like I can just put the cursor in the middle of a line, hit return and now I have two lines. And if you think about some of the tools that are extremely popular, notion and so on, they always make that distinction of are you inputting pros and making a list, or do you want more structure to do some computation, which is, oh great, now you have to think like a DBA and the notion of being able to move between those two modes fluently, I think is really cool. And at the same time, if you can afford to push the formalism as far back into the process as possible, right? Like, hopefully without the app hopping, right, of like, oh, I started thinking in Muse, and suddenly I want some more structure. Therefore we have to go get out a spreadsheet and at some point you’re like 6 level deep writing a rails app with a SQL light database and you just don’t, you know, it’s it’s not the way to go. 00:37:34 - Speaker 2: And now when it comes to structure versus free form, I do think there’s a feedback loop when you talk about microformats where you kind of are inventing your own little structure as you go, just naturally, even like writing in a notebook can be something like this. Yeah, some of the trackers you mentioned there, one use case that came to mind for me was in the early days of parenthood, we basically had a log for things like feedings and sleeping and diaper. because it’s very useful, especially with handoff between caregivers to just at a glance, be able to look at this and see when was the last time they ate, when was the last time they slept, because that tells you a lot about trying to figure out whether they’re crying right now, what need they’re expressing when they’re crying right in this moment, as well as other maybe slightly longer term analysis in terms of like, OK, are we getting enough sleep each day, for example. But there does tend to be a feedback loop if you do add the rigor of the computer trying to parse it, even if I’ve written that search for myself, then that is going to enforce as a strong word for it, but encourage me to use a format that can be easily parsed and to be consistent with that because I make my job on the called the programmer side or the adding the dynamic aspect to it a little bit easier. Did you see something like that in your user testing? 00:38:55 - Speaker 3: Yeah, I think there’s a really interesting tension here where it’s exactly what you’re pointing out, where on the one hand, we don’t want it to feel like programming. So in textual programming, especially for beginners, you’re typing in characters, and there’s a very, very strict set of rules defining what’s valid and invalid, right? And if it’s valid, you get nice syntax highlighting and everything, it’s great, and if you have one comma missing, everything falls apart, and so we I thought that it was really important that you don’t start feeling that way in your text notes. It should generally have the sense that you can just type the way you normally would. But of course, on the other hand, we still need to figure out what you meant. And so you need patterns that are accommodating enough to let you write, but also rich enough to figure out what you meant and extract the meaning. I do think one thing we realized is that there’s a big difference between applying patterns later on to some text that’s already sitting there, versus having them being applied live as you type. Because in potluck, as you type, for example, if I type 5 minutes into a note, by default, potluck has this time recognizer built in, which will search for all the durations you add to a note. And when I type 5 minutes, this underline just appears and clicks into place, and I sort of get this live feedback that I’ve typed a duration that the system has understood. And we just found that that felt really good. It feels good to have the system give you that signal that it recognized what you did. And obviously, if you were expecting it to recognize something and it didn’t, then you realize that because of the lack of feedback. And so, what we found in our experience using this thing was that if you have the searches running as you’re inputting the data, it does have this natural nudging force of making you aware of the structure a little bit and maybe being a little more mindful of where you put. New lines or things like that, but again, shouldn’t be too rigid ideally. 00:40:45 - Speaker 1: Adam, you do bring up an interesting point. I think partially why notion is so popular and such a great tool is that it does invoke a little bit like this collector mindset of I’m just going to collect, you know, whatever you’re into and make a nice table so that I can actually reason about it as a collection instead of individual items, right? And like I always joke that sort of computers are really, really good at doing stupid math and for loops. And maybe one way of thinking about this is if you look at the user interface for potluck, on the left hand side you have sort of this messy, I’m just going to type stuff out, and as you write searches that match against the document, it populates a table and that table can have arbitrary metadata, right? So I can add a new column and say actually for this timer, I’m going to add a different property and The idea of having both, both this sort of reasoning about things in collections, large, you know, all ingredients or whatever, and the idea that I don’t have to do that from the beginning, or if I change my mind, it’s not such a big deal, is really appealing to me because I think we usually switch modes from reasoning about the individual thing to the collective thing and back and forth and back and forth and software today just makes you. Sort of jump through hoops if you’re switching between one or the other, and potluck tries to, as best as possible, sort of make that fluid. 00:42:12 - Speaker 2: One thing I wanted to ask about is, in the future work section, you talk about machine learning and language models, which is a pretty hot topic among certainly the tech world broadly and also in the tools for thought space. Since you are focused so much on text as well as detection, what role do you see that as having either now or in the future? 00:42:34 - Speaker 1: It’s really interesting timing because as we were writing the paper and like doing the research project, all these big language models and like stable diffusion and a bunch of other things sort of came out and became sort of accessible to like hackers, I would say. I mean they have been for a while. But at some point we were thinking about, well, we have these searches and the way we’ve implemented searches both sort of from a time perspective and maybe a little bit of a philosophical thing that we can get into, are all, I don’t know, like rejects, we have our own pattern language and so on, and you can if you want to write rejects. It’s obviously not super approachable to mere mortals. So how wouldn’t it be cool if I could just have a note and say, find me all things that are quantities of food. And then GPT 3 goes off and comes back and says, here are the ones that we found. And I think it is so obvious that the data detectors will get so much better the better machine learning gets, right? And you can kind of get a glimpse of that future in the photos app on, I forget the current photos app on on iOS, where if you take a picture of a recipe index card and it says 24 g of sugar. It’ll actually, you can tap and hold and it’ll do a unit conversion for you. Now, it won’t let you do anything else because somebody decided for you what you should do with those 24 g. That’s the part where we would hope some other, like some maybe some more extensibility, but that’s just machine learning, finding the 24 g for you and you don’t have to do it, right? And so I think it seems somewhat obvious to us that all the detectors that are currently patterns will just become much more human friendly ways to describe patterns. 00:44:16 - Speaker 3: I will add one interesting tension that we were thinking about a bit. We didn’t end up implementing AI based stuff in the project since we didn’t have time to get into it, but we thought about, you know, do you want the AI to find the stuff for you, or do you want the AI to essentially write a reject for you? And those actually end up being pretty different things because predictability and speed actually end up mattering a lot. When I’m typing, I wanna be able to learn. You know, if I type this string, is the computer always gonna see that as a food or not? And if you have machine learning in the loop for actually doing the detection, It’s probably pretty hard to get guarantees around, oh, you know, it depends on where it is in the sentence, or how the model’s feeling that day, whereas if you have a more deterministic pattern, that gives you something that you could learn as a human, like how it works, and sort of learn to wield predictably, but there is a tough tension there because the predictable thing probably is gonna miss a bunch of cases that the ML could have found. So, I think there’s an interesting design challenge there and how do you Get a system that does both of those things well. 00:45:22 - Speaker 2: And maybe an example of that from kind of an earlier phase of technology is autocorrect, which on one hand was this huge enabler to be able to type full sentences on a phone. On the other hand, is the source of huge running jokes, you know, it’s basically the butt of jokes, which is like autocorrect, does hilarious things all the time, people are used to that, it’s part of modern life in a way that, oh, I pressed the wrong key on my keyboard. I guess that happens sometimes, but it’s so infrequent for someone who’s a reasonably competent typist, that it’s just not a point of discussion, and, you know, it’s one thing to use autocorrect to bang out a quick text message to someone, but if you’re a book author and you can sit down and write your book, Autocorcrack is not the right solution for you. You’re gonna become a touch typist with a precise keyboard, maybe you get a mechanical keyboard with big chunky keys, because, yeah, you want precision from your tool and you’re willing to invest in that. 00:46:18 - Speaker 1: Yeah, I think it may have been Paul Shan on the team that came up with the funny analogy of, we were arguing about AI cause I think sort of just what role should it play in potluck and so on, and One of the things he referred to current AI models to is like, look, this is like the toddler stage, and if you go and say, hey, go toddler, find me the ingredients on this table, you’re probably not going to just blindly take them and then cook a meal. But at the same time, if you can send off 10,000 toddlers to try and find the ingredients on the table, and then you check their work, seems pretty reasonable, right? And so I think that the idea of having the ML try and suggest something to you. But then you check the work, commit that and say this is the correct thing that you found, then it’s a totally reasonable approach, right? Like, I think GitHub co-pilot does this for programming, like you’re not writing a method call that at run time. Goes to GPT 3 and says please sort this list. It gives you the text to autocomplete that then you commit and run. I say this as now there are examples where GPT 3 calls itself to do stuff, which is both super exciting, but at the same time, you probably wouldn’t want that to be part of your stack all the time cause you can’t rely on, you know, the model upstream changing and suddenly saying that the car is an ingredient and yeah, but I think that tension. is good. I think we haven’t really figured out what the user interfaces for AI and for that interaction looks like, right? Like right now, all these interfaces are just slot machines. Like stable diffusion is just, it’s addictive because it’s a slot machine. You type in a prompt, you have to wait 30 seconds and then you get the variable reward of nice picture or not nice picture. But for a tool, I think you would want something a much more fluid and fast, right? You can’t wait for 30 seconds and you probably also want something much more predictable. I think it’s a future research project waiting to happen to say, in an environment like potluck, what role does AI play and how would you go about designing that? 00:48:23 - Speaker 2: Well, it’s all super fascinating stuff. I highly recommend reading the essay, trying the project, but now I want to switch gears a little bit and ask you both about the process. What does it look like to, I guess, come up with research to work on in the first place and certainly within the can switch container, recruit the team and run the project and how long does it last and who’s on it. And I’m especially interested to get both of your takes cause Jeffrey, you’ve done a bunch of Ink & Switch projects at this point, as well as been in the research world for a while, and Max, this was sort of your first exposure. You’re very accomplished in the commercial world, but this was your first exposure to both the research world and I and Switch. So, yeah, give me the rundown. What does the inside of this box look like? 00:49:08 - Speaker 3: Yeah, totally. I guess I can speak to how the project originated as the person who kind of started bringing things together here. So I can Switch typically these days runs projects that are You know, around 10 to 12 weeks, which is pretty short from a research perspective, and what we try to do is bring together some small team of people for an intense period of time there and just really focus, you know, ideally everyone’s full time and just intensively work on some aspect of a bigger problem. And so, before that, there’s this phase that we call pre-infusion, which I think Peter talked about when he was on Metamuse, where there has to be some prep work to figure out, you know, who do we need on this project, what’s the question we’re asking. In this case, we knew we wanted to do something related to the themes of malleable software, you know, this personal tool stuff, but we spent a while kind of searching for, I think it’s important to have kind of a nucleation point of some kind, something you can latch on to as a place to start, especially, I’m a fan of having some concrete examples or use cases in the mix at that stage, because what I found is that if you start with your prompt being like, how can we reinvent the way people do work or something, it’s easy to get lost in the woods, basically, whereas if you can at least focus on one thing to start and then branch out from there, it makes it easier. And so, I think Peter, the lab director and I were having a conversation, and we’re both big fans of cooking, and so we just started talking about, you know, isn’t it kind of weird that recipe apps are simultaneously so popular and yet seem to do so little and have all these frustrating restrictions, and so we thought it’d be fun to run a project where the original prompt was kind of, could you make a recipe app yourself, and, you know, go from there. And a lot of the ideas that ended up emerging in pot, like, we didn’t really Set out specifically to answer that, you know, specific question, it just kind of more emerged from the original prompt. So that’s kind of on the idea side, and then on the people side, you know, I am a big fan of small teams where everyone can kind of do everything a little bit, generalists, especially in this case. I think one of the tough things about this kind of work is that there’s a lot of context you have to build up, and so I felt that it was important to get a team together that had at least been thinking about these general kinds of problems before. You know, if you bring a typical engineer onto a project and say, let’s get rid of apps, you know, that’s sort of a strange place to start, right? And so, anyway, that led to, obviously Max, as sort of a design focused person, and then Two other people, Paul Shen and Paul Sonnetta, who are both, you know, more engineering focused, but, you know, all four of us had previously thought about these themes, and so it was really fun to get this group together and kind of jam on, you know, each having a different perspective on what it means to make personal tools, but kind of find a way to blend them in a way that made sense. So, that’s kind of the general overview, I guess. 00:52:12 - Speaker 1: I think you had a comment early on when we were doing intros, because most people we hadn’t worked together yet, and I think you made the comment of, oh, it’s well, if any of the people on the team really wanted to, they could just make the whole thing themselves. And I would have actually loved to see a parallel universe where we all separately would have tried to make a malleable recipe app, cause I’m sure it would have been very, very different than what we ended up coming up with. But this idea that you don’t have to spend any time explaining basics and can just go into building right away is really important when you only have 10 weeks or so. And I mean, I loved working on this team, maybe my favorite team working experience I’ve ever had. 00:53:00 - Speaker 2: Wow. Now, how did you perceive Max, this kind of research angle where the end goal is not to ship something to end users, yeah, you want something usable, and even there’s a demo on the web, you can go try, but the goal here is not to build a product and iterate on that and bring it to market. How did that change the experience of building something for you? 00:53:22 - Speaker 1: It was both very refreshing and at times frustrating, so it was a little bit of a palette cleanser. Most of the time when I’m looking at, you know, building software, it’s like, OK, when do you get to product market fit and what’s the economic viability? How many users, how are you going to make money, whatever, right? And this is not the case with research projects. There, I think the goals are much more, can you find a novel take that maybe explicitly wouldn’t work. In the app store right away, because, well, either the tech’s not there yet, or you need to commit access to Mac OS and iOS to actually fix this thing, or Linux or whatever. And so I didn’t really have any notion of what it was gonna be like. The only thing I knew is that all the Ink & Switch essays are badass, and surely something about the way these projects are run contributes to it. And I think it’s that weird tension between both, well, we’re gonna think big and do something that might not be viable right away, and at the same time we’re gonna ground it in that use case of, in this case, Jeffrey’s idea of a, well, let’s just make a recipe app. That’s our use case. How would you make that malleable instead of much more generic and, you know, inventing something that maybe no one will ever want to use. 00:54:47 - Speaker 3: Another part of the research first product thing that I find important is the end goal of this project is kind of idea transmission, like, we succeed if we change the way people think. And so, the way you explain the thing and frame it ends up being super important, which I guess that’s also true of marketing a product or whatever, but I think it’s just When that’s the main artifact that you’re going for at the end, it puts a lot of pressure on that angle of things. So, one process that I think we all agreed was really helpful is typically on lab projects, every 2 weeks, there’s a demo day, basically where you just demo what you’ve been working on to other people in the lab, and I think it’s really important to take those opportunities to sort of practice the story and try to explain what the heck are we doing, what problem are we thinking about, what’s our prototype right now. And just rehearse that every 2 weeks. And if you can’t convince other people at the lab that this thing makes sense or is good, you’re never gonna succeed at convincing anyone else, right? This is like the most high context, sympathetic audience you could find. And we did have a couple demos where people were like, what are you doing? This doesn’t really make sense, we don’t get it. And that was really, really helpful for kind of refining both the way we explain what we’re doing, but also, you know, obviously the work itself and sort of guiding the direction of it. And I think that’s an interesting process question is like, what cadence do you work on? In some ways, 2 week cycles may seem pretty fast. A lot of researchers work on much slower sort of base cadences, but I find that I really like having an intense kind of pretty fast rhythm when you’re in this execution, or kind of intense momentum mode, and then Once you’ve finished this 12 week period, you can spend some time to like, walk around and think about what you’ve done, and think about what you wanna do next, and, you know, have a sort of on-off approach. 00:56:44 - Speaker 1: That tension or the 10 weeks, Jeffrey and I have definitely had some conversations about, is that too short? Is it too long for a research project and sort of, I think my view initially was. It’s like, 0, 10 weeks is too short to do any meaningful research, and I think that’s still true, except that you shouldn’t consider those 10 to 12 weeks as the entire research. It’s a season in an 11 season lost sort of show, right? And there’s this thread across all I can switch projects and Potluck will infuse other projects going forward, and I think if you bring that mindset, then suddenly the 10 weeks are really great because it’s this forcing function of just not wasting 2 years trying to see if there’s a there there. You have 10 weeks, go ship something, publish it, and have it torn to pieces because it’s not good enough, right? And if you’re not embarrassed, you’re shipping too late. I am definitely embarrassed by some of the UI and the UX and the Maybe complexity that exists and it’s not a product, but the idea that it kickstars, you know, a couple of other seasons of development, I think is a good framing, and in that case, the 10 weeks, the intensity, daily stand ups. I was only on it halftime, everybody else, which I do not recommend, everybody else was on it sort of full time, and the intensity is truly what leads to this pressure cooker environment of like building something that’s both good enough that you want to play with it. But not a thing that is ready for any kind of adoption by people outside of the lab environment. 00:58:24 - Speaker 2: I’m curious about the transition from that, yeah, 10 to 12 week more intense building phase to, OK, now let’s take what we’ve learned and turn that into a written artifact or it could be sometimes a talk, but in this case it was an essay. I guess some of the question is, is all the team involved with the essay or just the writing? How do you know when you actually have something good to write about? You’ve learned something useful, which maybe could happen halfway through that 10 or 12 weeks, or maybe you get to the end and actually don’t feel like you have a lot to say. How does that whole transition work? 00:59:00 - Speaker 3: I love the writing phase because it’s where you get to figure out what you’ve done, and I think it’s really funny. This is such a cliche, but like, you start writing and it’s like, wait, what do I want to say? And it can get really confusing, and I think in some sense, even once you’ve done all the work, you haven’t actually done the work yet of figuring out what you’ve learned from it. And so, on this project, what we did is we tried as we were going to Prototype the paper, kind of. We, you know, recorded little talks explaining the project or like, wrote notes of, like, here’s how I would explain it today. But even then, when we got to, you know, the end of this intense period, there was still a lot of mess to work through, and we’ve all been involved in co-writing the piece, and I think that’s sort of important to the extent that, again, the real value that this thing is trying to provide to the world is like, here is what we learned, and the writing process is where that gets clarified, you know. 00:59:53 - Speaker 2: Do you find you wanna go back and make changes to the software as a result of things you’re writing, or especially screenshots or videos you’re including? 01:00:02 - Speaker 1: Yeah, when I read the essay now, I’m like, OK, obviously an exaggeration, but this is all wrong. We have to start again. This is how we would design it, and it’s really not that it’s all wrong. It’s just that you want to do so much more to
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: Here’s my number one tip for listeners of this podcast episode. The most unreasonably effective thing to do in recruiting is to move quickly, especially as a small company where you have the ability to do that. 00:00:16 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for deep work on iPad and Mac, but this podcast isn’t about Muse the product, it’s about the small team and the big ideas behind it. I’m Adam Wiggins here today with my colleague, Mark McGranaghan. Hey, Adam. And a fun little announcement here, we’re growing the Muse team, or we have grown the Muse team, I think it’s the right way to say it. So the designer storyteller position we posted a while back, we’re very pleased to welcome Linda Ma to the team as our 6th team member, and indeed we’ve also had some great candidates for what could be #7, that’s the local first engineer, so we kind of hope slash expect to have a similar announcement on that in the not too distant future. And this is what made me think it would be time to finally do an episode we’ve talked about for ages, which is on the topic of hiring or recruiting or perhaps team building. And this is something you’ve done quite a lot of, particularly a little bit of Hiroku and a ton at Stripe, and indeed you even have an article on your website, Thoughts on recruiting that I’ll link to, but maybe you can start us off by giving an overview of what you think hiring is all about and why it matters. 00:01:28 - Speaker 1: Oh, I have so much to say about recruiting, and it’s hard to believe we’ll even fit it all in close to one episode, but A couple of things I’ll say at this stage. One is that obviously the team that you build is gonna be the company that you build and the product that you end up building. It’s really the foundation. That I think is pretty obvious, but I think people often forget that. The other side of it is that this is a huge part of people’s lives. If you work, say, at 4 years for a company, that might be 5% of your mortal human life, you know, spent much of your waking time spent there. And maybe it’s a 10th of your career. So it’s a really big deal on both sides, and I don’t think that people treat it with the seriousness and importance and gravity that it deserves. Just kind of throw something up on indeed and, you know, respond to the emails or whatever. I don’t know. It just seems like such an important topic that really merits deep thought. 00:02:21 - Speaker 2: It is certainly part of the Silicon Valley culture to say hiring is, for example, hiring is job one for the CEO. That might be a phrase that someone might bandy about, but I would argue maybe some of that ends up putting a lot of emphasis on the quantity of hiring and the speed at which you do it rather than the quality and the quality not just of the candidates in terms of how they fit the company, but the team that you’re building and how it integrates and fits together and ultimately can. Do what you’re there to do, which is, you know, build the product. 00:02:53 - Speaker 1: Yeah, I think a big theme of this discussion is going to be holistically thinking about recruiting, hiring, team building, and zooming out a little bit, and it’s not just about all the little tactics, it’s really easy to get to zoomed in on that. We got to keep in mind the goal of having an effective productive team, and considering all the things that can lead up to that. 00:03:14 - Speaker 2: I think an important part of what we’re talking about here as well is that we’re obviously talking largely about hiring the technology industry, which is where all our experience is, but I think an important part of it is hiring creative people to create something that’s often fairly novel in the world, and so you really need, there’s the whole mission driven concept and being aligned and sharing values, all of these things I think are an important part of it. That’s one piece of it is I think you really need to get people who are going to put their spirits into it in a way that It’s not just do they have the skills, it’s a do their passions line up with the things the company needs. And a related thing is the immense privilege we have being in this industry, which is it’s a very in demand field and so the people who are being hired side of the equation, they have a lot of options. Not only are they well paid, but they have the luxury, you know, if you’re good at interviewing and have the right CV and everything like that, you may be able to get offers from several places. So the hiring manager is often not just kind of this doing this transaction of here’s the work that needs to be done, here’s the skill set, and here’s the compensation. But actually there is an element of getting them to join your club, perhaps getting them to join your cult, buying in on the mission, believing in it in a deep way. And I’m reminded a little bit of this 80s movie Ghostbusters, where you have the original founding team of Ghostbusters, who are these kind of kooky types, or at least some of them are these kooky types that have all these beliefs in the supernatural and the occult and so on. At some point they realize they need help and they go to hire someone new and, you know, they’re basically asking interview questions about, what do you believe. This and this and this, and he just says, look, there’s a steady paycheck in it. I’ll believe anything you want. That’s probably not what you want for creative work. You want someone who is going to buy in because indeed the things they care about and working on in their career, perhaps things they’ve worked on in the past or their personal passions match up to some degree with what the company’s mission is. 00:05:16 - Speaker 1: Indeed, one of my little recruiting nuggets is that the primary challenge with recruiting in this technology industry is attraction, not filtering. I think people go to filtering things like, what are the interview questions and what are the criteria that we’re gonna use to knock people out of the process because it’s more inwards focus, it’s more about you and what you’re doing in the office day to day. And also because I think people are keying off of companies like Google, of which is a very small number that have a legitimate filtering issue where they have a huge number of people applying. The challenge for the overwhelming majority of software companies is that people don’t apply to your job, they don’t even know about it. That’s why I think this attraction problem is so important. 00:05:55 - Speaker 2: Well, I thought a good way to structure this might be to talk through the hiring process we use at Muse. Now, Muse, importantly, is not a growth oriented startup, but I think we do need to attract in your wording here in the same way that a faster hiring company would, and this is a process I think you and I have used a bit at Hiroku. I’ve used in different companies and it’s kind of what we use in Muse. And not to be too process focused, but maybe in talking through it, we sort of reveal the tips and tricks, the values, the approaches, the painful lessons we’ve learned over the years. Maybe also worth as a glossary here, kind of defining a couple of terms that I will certainly come back to a lot. One is team. And that the team of people that you’re trying to put together to again be sharing those values and having work in chemistry and a sense of creative trust and the ability to make commitments to each other and keep each other accountable, that’s a key part of this. You’re not just trying to hire individual people, you’re trying to build a team and each of those people needs to be integrated into the team. And I was like the anti- example of a team, which is something like US Congress. The members of Congress may be colleagues, but they are not a team because they really don’t have the same, many of them don’t share values or have the same end goal, and so it’s a contentious sort of finding of constant compromise, but I think a good team is one that does share more values, goal, mission, and so therefore you’re getting to great, great outcomes. The kind of team is one word in there. And then two others that will come up a lot, I think is manager or hiring manager. And actually doing a whole podcast on management is another topic that’s in my backlog somewhere, but at least for the purpose of our discussion here, take a hiring manager and then the person who not only figures out who should come into the team, but also helps them be successful is a big part of this equation. And then the job description is the other one, and we’ll probably start there. So a clear written description of why you want to hire, what problem is being solved, and what candidate would look like that would kind of fit that slot. 00:08:05 - Speaker 1: Yeah, it’s a good baseline to have. So, where does the process start for you? 00:08:09 - Speaker 2: Yeah, well, number one is the hiring manager writes a job description. And obviously that starts with whoever is going to do the hiring kind of recognizing a need. So this is why it’s important to, to my mind, label a hiring manager who is a single owner for this, as someone who’s identified. We need someone on the team and we’re going to figure out exactly what that looks like and do the filtering, both the attraction and the filtering that you mentioned, but also the onboarding and helping them be successful on the team. But that kind of clarity of here’s a single owner for this project because it really is a project and they may take input from a lot of sources to create the job description, which is a written thing you’re going to post somewhere that tells people what you’re looking for in the role and about your company, but that person is going to really own that whole process. 00:09:00 - Speaker 1: Yeah, and I’m a really big fan of having this alignment between the person who’s eventually going to be responsible for the person’s success on the team all the way back to writing the job description and sourcing the candidates and running the interview process. I’ve observed that in large companies, this often gets broken up among a bunch of different people. Sometimes, you know, for The defensible reasons, let’s say, but you have the recruiter and the executive, and the group manager and the manager, and the saucer, and the zillion people, and no one’s really responsible, a candidate’s bouncing around through all these folks, and you don’t get a strong, coherent, unified vision for what this job is gonna be and why it’s awesome. So I think we can get away with it, having a more unified approach is the best. 00:09:43 - Speaker 2: Yeah, I’m not a big fan at all of kind of recruiting in HR, playing a big role, especially early screening. I I understand why that specialization makes sense. I’ve worked with great recruiters and great HR people who are very good at what they do, and certainly they take the weight off of the team leads or hiring managers that have lots of other responsibilities. They have their own specialized skills in some cases for just Dealing with people and following up correctly and so on, but yeah, some more unified ownership, I think creates a better experience for the candidates, and I think it is more likely to make the whole process kind of be successful. What does a good job description look like for you, Mark? 00:10:23 - Speaker 1: For me, it’s effective in convincing the best candidates that they should begin a conversation. And let me contrast that to what I often see in job descriptions, which is speaking to sort of the median candidate and giving them as many reasons as possible not to apply, right? You don’t paint a picture of why the job is compelling, why the teammates are going to be great, what they’re gonna learn, and you get this whole laundry list of, you know, so-called requirements, many of which are not even useful. So when I’m writing a JD I’m thinking. Maybe I have a handful of people who are ideal archetypal candidates. Why, when they read this, are they going to be interested in speaking to us? And once they speak to us, you know, that starts a whole another part of the process and we can almost forget about the JD in a sense. But you just want to get that first conversation. So it’s again, it’s about attracting the right candidates and you don’t need to really care about what we candidates think, and you don’t need to care too much about strong people applying who aren’t exactly the right fit. That’s a good problem to have. You’re just trying to get some initial attraction from strong candidates. 00:11:27 - Speaker 2: Yeah, being specific so that when someone who is the right person reads it and says, this is me, and feels compelled to apply, but also not so specific that you, as you said, repel people. The requirements section in particular is a dislike of mine where it’s for example 3 years of experience with a particular technology, but I think it’s really a certain set of characteristics in the person’s personality and the kinds of things they’ve worked on in the past and what they’re drawn to and the types of problems they’re good at solving and certainly for a technical role technology experience is first of all important to talk about. But secondly, helps people know what the position really is and helps define it. If it says you’re a great swift engineer, then you know that’s going to help clarify a lot, but saying you have exactly this many years of experience with a particular technology in the Apple ecosystem is a little bit too, I don’t know, just leads to disqualification for not a good reason. But then you always have this balance between, you don’t want to be too vague. Because then it doesn’t speak to anybody, but if you’re too specific, you disqualify potential good candidates, and in a way, you don’t know who you’re looking for, right? You’re trying to like put this beacon, this attractor out into the world and you have a vague idea. Hopefully that idea is based a little bit on the exercise of dream candidates. So this is something I like to do, which is, OK, if you could get anyone in the world, even someone who’s completely ungettable because they’re a celebrity or they’re busy with their own thing or whatever. Who to be. And if you get 345 of those examples, and you look for attributes they share, and you write down those attributes in the job description, that’s very likely gonna, in my experience, do the job you described, which is help attract those great candidates without having the specificity that repels people for no reason. 00:13:19 - Speaker 1: And the flip side, by the way, of the industry not taking this recruiting process very seriously is that most jobs and JDs are actually not good. So if you have a really good job, if you’re offering a genuinely good opportunity and you write a really compelling JD, you can actually pull a lot of people out of the woodwork with that. 00:13:40 - Speaker 2: Absolutely, I always considered a good sign when we get people applying who say, I’m happily employed, I’m not looking for a new thing in any way, but this was just so interesting. I just had to talk to you, something of that nature. 00:13:56 - Speaker 1: One other thing I’ll say about JD, I do think the main role is outwards facing attraction. JDs also are helpful internally for getting the team on the same page about what this person is going to be doing. We were working through this recently with the local first engineer. We decide, OK, is this person gonna be doing protocol design and distributed systems, or is it more like working on the clients, the iOS client or the JavaScript client, or is it more like a just a pure back and go engineer or is it some linear combination, or is it choose your own adventure? And just having that conversation is good. And like to your point about concreteness, you paint a picture about what success is gonna look like and what they’re gonna be accomplishing, and that also is gonna be, you know, resonant and coherent with the team is expecting, which is good. 00:14:41 - Speaker 2: Yeah, a hugely important part of the job description is what they’ll be working on and as specific as possible past features, for example, that you shipped in your product that you can link to the blog post or some open source thing that says, here’s the sort of thing we’ve done in the past that is similar to the sort of thing that we expect this role would do in the future. Incidentally, I think in working through this process with our longtime colleague Peter van Hardenberg years back, he said something that stuck in my mind, which is he said, Ah, so I should think of hiring as being like looking for a new guitarist for my rock band. Yeah, I mean, I think there’s a lot to that. And if you think a little bit more in terms of the skills matter, but you are looking for a, obviously the rockstar idea is hackneyed, but someone who’s really going to add something new to your unique team, and they’re gonna fill a specific skill, but you also don’t want to be too prescriptive, and ultimately you also want to find someone that, you know, fits in your vibe, fits in your style of music, fits into your artistic point of view. Alright, so you’ve got your hiring manager, you got a great job description, hopefully you circulate internally, which often is by itself is a reveal in the sense that either people realize they don’t agree about what it is we think we’re hiring for, or in some cases with larger companies you actually end up with internal candidates basically showing up where they say actually I’d love to do that job that I basically shift from what I’m doing right now. That can be quite an interesting sort of internal recruiting approach. 00:16:14 - Speaker 1: Yeah, I think that’s very important. And by the way, you can also share it externally, including with some of your ideal archetypal candidates, because that already starts a little bit of a conversation and there’s a little bit of a stronger relationship and invariably when you read a really compelling job description, some little piece of your brain becomes invested in wearing that hat. 00:16:33 - Speaker 2: Yeah, that’s true. There’s also this element of long-term recruiting. I read a book sometimes back, I should have looked up the citation for the episode here, that basically is kind of a more classic business book on hiring, but talked about. Hiring like really senior executives, I think this is probably more like public companies or whatever, but they told a story of someone who worked a CEO who worked on hiring a specific person that they wanted on the team for 10 years, and it was the sort of thing like where every time the hiring manager would fly through the candidate’s hometown, they would, you know, basically pay. A visit. Let me stop in for a drink. Let me pitch you why you should join the team again. They did this, you know, every year or two over the course of a long time, and eventually, because so much of it is about where the candidate is in their life, right? It really is about timing when they’re in a moment where they’re thinking of something new or ready for a change, that’s just really key. And so you can’t always Guess that for your ideal candidates, especially the people you don’t know personally, but by floating the job description in front of them, you get that little seed planted in the mind, maybe you don’t end up hiring this time around, but maybe a year or two later they come back and the time is right. 00:17:42 - Speaker 1: Absolutely, recruiting is a long game. 00:17:45 - Speaker 2: So that leads us to just kind of getting the job description out of the world. There’s, yeah, sharing it privately with your ideal candidates. There’s sourcing, which can be anything from scouring LinkedIn to looking for people that might be a fit, to just like, kind of thinking through your own personal networks, and there’s direct advertisement, right? There’s job boards, stack overflow, GitHub jobs, hacker news, who’s hiring threat is very good. How do you think about all that fitting together? 00:18:14 - Speaker 1: Let me actually talk first about hosting the JD so, The issue with recruiting is that both sides of the transaction, the hiring company and the candidate, have very little information about each other. If everyone had perfect information, you would just go to the company that was right for you and start the job and everyone would be happy. The issue is that there’s imperfect information, and so whenever you’re undertaking some work in the recruiting process, the candidate is going to be performing a huge update in the Bayesian sense about your quality and fit as a company. And this is why when we go deeper into the interview process, there’s gonna be so many important things there. But potentially the very first thing they see is the JD. So when I’ve had the chance, I’ve invested a lot in making very high quality JDs not only just they were written right, but that, for example, they were on our domain.com/. The name of the job. They had excellent typography. We even commissioned custom artwork for our original local first sync engineering job. And you know, some of these things work out and some don’t, but just showing the candidate that you are walking the walk of really caring about this job and thinking it’s important, verse, you know, potentially you put it up on a third party job site. It’s like, you know, your subdomain.job site.com/sh, you know, some horrible EUID and then they go there and like the colors are all wrong and they fill out a form, it’s like 17 buttons, you know, it doesn’t send to me the message that you really care about this candidate in this job, so. I think it’s worth putting some effort into the actual posting. 00:19:39 - Speaker 2: Yeah, to me that might reflect the conventional power dynamic between a sort of job seeker and job offerer, which is very often the employer is the one in the kind of the position of power and the person who is being hired is kind of hat in hand, you know, please can I have a job. And that is really not how it is in the tech industry, and so I would hope if you were hiring anywhere, you would seek to try to make it feel like a very mutual and even and balanced transaction. I think that benefits everyone, but in the tech world, you know, you really do need to think in terms of you’re trying to get people who have so many options and Yeah, it’s really worth your while to do everything you can to give them a great user experience just the same way that you would a user of your product. 00:20:27 - Speaker 1: Yeah, and then to your question about actual sourcing. I mean, to be honest, I’ve had most of my luck with network-based sourcing and inbound based on really high quality public materials. So I think Muse has been a good example of this. We’ve had some sourcing and recruiting conversations via our network, often. In combination with all this public material that we produce, especially the podcasts and the memos, I can’t tell you how many candidates we’ve spoken to who come to our local first engineer screens, like, you know, I’ve listened to all your podcasts, I’m excited about everything you’re doing. Tell me more about what you guys are up to. And that’s a huge leg up versus going in cold to get up jobs or something, which is the thing you can do and we’ve done it before, it’s just much harder. So I think where you can do it in network and or buttress with high quality public material that helps a lot. 00:21:15 - Speaker 2: I think the two of them do really work together, and I’ve had good luck with paid job descriptions in pretty targeted spaces, something like you want an Android developer, so you go into the biggest Android email newsletter, for example, versus something more general like Stack Overflow. Also, conferences can, you know, you basically give a talk and you have the requisite we’re hiring slide at the beginning or the end is also a way to get the word out of it. Yeah, I think you need to tell people and you need to say it publicly and loudly. And that will get the conversations going in your network, right? So you can try to think of everyone you want to talk to and email them and say, here’s the link we’re thinking of hiring, but it’s really a lot better if you tweeted it a week ago. They saw it kind of looked at it briefly in that half distracted state that any of us are in or. Looking through social media, they saw it and they’re like, oh, you know, that’s really interesting, and it kind of, you know, the seeds in their mind, and then if you email them a week later and say, hey, we were thinking you might be a fit for this. Would you like to talk? And they say, oh, it’s funny, you know, that’s been in the back of my mind, and it basically opens the conversation more easily. So I think putting those two together is a really good idea. 00:22:21 - Speaker 1: The last thing I’d say on sourcing candidates is that I do think outbound is possible. It gets a bad rap because it’s often very spammy coming out of these large companies with just template emails and so on. But if you first make an effort to identify people who are genuinely a good fit, and then to show very good proof of work in your outreach email, like basically it’s not a template, it’s customized to the intersection of their public profile and your job description. I think that’s pretty reasonable, and I’ve gotten OK responses on those. 00:22:54 - Speaker 2: And the bad version of this is the classic LinkedIn recruiter. I still get these. I see you have written open source projects on Ruby on Rails. I have a Ruby on Rails developer position that may be exciting for you, and they just clearly haven’t looked at anything about anything I’ve been doing in the last decade. It’s all very automated, whereas, yes, if you say, hey, you know, I came across you by the work you did on this open source project. And I see you’ve been active on that recently, and I read more, you know, on your blog, and saw that you’re really interested in the space that we’re working in, and I thought I’d run this by you to see what you think. Something like that can at a minimum, just again, plant a good seed or something like that, rarely gives a bad impression, and it can sometimes produce some good conversations. Now once you get to the filtering stage, if you’ve done a good job, you should have lots of candidates coming through, right? And I think it’s important here, this actually connects to a larger perspective I have on kind of systematic searches, which I think can be applied to a lot of things in life, whether you’re looking for a university to go to or, you know, you’re looking for a school for your kid or you’re looking for a home to live in or something like that, and certainly it’s true for job seeking. And it’s true for candidates as well, which is that I think it should be on both sides. A job seeker should be opening many conversations with many plausible fits and then using that to do their own filtering down to the best opportunities for themselves, and then on the other side, the employers should be doing the same thing. 00:24:24 - Speaker 1: Yeah, and just to elaborate that, I think there’s a benefit for the recruiting company on having some volume. I think you want at least 5 to 10 people on what you’ve called the initial screen stage. We’ll talk about that terminology. Just because by having a little bit of volume, you basically get better at it. You get some practice and you start to better triangulate what you’re actually looking for because of the conversations with the candidate. For example, the candidate will ask, you know, am I gonna be doing this or this? and like, oh well, actually it’s a good question. You know, actually it’s more like this you go up to the GD and then when you have a subsequent conversation, it’s a little bit more dialed in. 00:24:55 - Speaker 2: It’s really important to know what you’re looking for when you start and have clarity about that, but on the other hand, I do often get more clarity through those conversations and realize in some of the early interviews, oh, maybe we’re looking for is kind of too many skills mushed together, it’s actually a little too broad, or maybe the other way around, it’s actually too narrow and we should really pair up with this other thing. I’m kind of realizing there’s really sort of two things we’re looking for, maybe it’s worth pulling those apart into two different job descriptions. You may discover that through the process. 00:25:27 - Speaker 1: And even just the words that you use, cause again, we’re trying to find a resonant frequency with the candidate, and that can be made or broken just by what you call things. And so after you go through a few of these, you find that, you know, local first resonates better than distributed systems. OK, and now I can take that to your next session. 00:25:47 - Speaker 2: Didn’t we for the job post where we eventually got Adam Wulf, I feel like we even had two variations, was there maybe like the systems engineer and the can’t even remember what we had, we basically couldn’t decide which one we thought would be more appropriate, even though we thought they would both feel kind of the same slot on the team. To parallel job descriptions essentially had them both out and we’re interviewing for both of them, right? 00:26:12 - Speaker 1: Yeah, that was a very interesting experiment. I remember one was systems engineer, the other one might have been iOS engineer, and like you were saying, they were for the same role. It was this idea of someone working on a very high performance, sophisticated iOS client. And we had one track that we imagined, which is we eventually hired Wulf with, which was more of a classic iOS developer who cared a lot about performance and systems thinking. And the other one was more like a game engine developer who was used to building up these systems from first principles, and then would kind of their novelty would be applying it to more of a consumer facing app. And that was a good example of how we just didn’t get a lot of resonance with systems engineering, cause it’s not that many game engine developers out there, I guess, whereas we were able to find more plausible candidates with iOS engineer. 00:26:59 - Speaker 2: Yeah, and it’s probably the same for candidates as well, right, when you maybe apply somewhat speculatively to a job and you kind of think, oh, is this me, is this what I want to do? And then in the process of the conversation with the company and, you know, understanding better what the role would be, you kind of realize, ah, this isn’t quite what I’m looking for. That’s fine. I think we all have to realize there is a mutual figuring out what are we looking for. Hopefully you go into the conversation, you’re serious and you’re not trying to waste anyone’s time by just fooling around, but it is also a discovery process. Which naturally leads into the next phase here, which is what I usually call the phone screen, and this is something, it sounds like a very small process detail, but it’s something I’m quite passionate about because I feel that I have wasted a lot of my time and others' time early on by having a more heavyweight interview right at the start because you can really read someone’s materials or see their online profile, maybe open source work, design portfolio, whatever, and just think, oh man, great fit. This is gonna be great and you schedule the like 3 hour interview where they could come in and talk to several different people in the office and really, and I’ve been in the situation where it becomes pretty clear in the 1st 15 minutes that how I was picturing them is not how they are and it’s not a good fit, but now they’re kind of, especially when you talk about they’re in your office. Sort of already there and but it sure would be sort of pretty rude to just kind of end the interview and you sort of feel obligated. So, the solution here, and again, it’s the same thing for the candidate on the other side, they may also discover pretty quickly that it’s not what they thought. And so the solution to that. as you keep that first contact just really low commitment, right? And so that’s the phone screen. It’s 20 to 30 minutes, 30 minutes tops. It’s a mutual respect for each other’s time. You’re there to make a human connection. I don’t need to hear all your background. I already read your thing. I don’t need you to demonstrate skills. I’m going to trust that what you wrote down is your skills are true, and the more proof of that will come a little later on. Right now we’re just making the human connection. Kind of getting some initial sense of who they are and how they communicate, they can ask me a few questions, things that are not clear on the roll, and then that’s the end of it, regardless of whether it was good or not, right? And if we make that habit of really brief screens, then you can basically do more of them. Holy, that’s good for both sides. 00:29:16 - Speaker 1: Yeah, now I tend to call these introductory chats because they do think screen is very focused on implies filtering versus attraction. And I do do some basic filtering in these initial chats. My experience is that Basically asking a candidate to describe one thing they’ve worked on and then asking 2 to 3 follow-up questions gives you a very large amount of signal. It’s enough signal in combination with the resume and what they wrote in their email to determine with a high degree of accuracy if they should move on to the next stage, which all you’re looking for is that if you promote them to the next stage, they’ll have like a 25 to 50% chance of passing that stage. And in my experience, I can basically dial that in with a few questions plus the resume. And then the rest of it is basically selling them on the company. So again we’re under the presumption that the case we care about is The exceptional candidate. So if it’s not a great candidate, either you can tell that now or you eventually find out in the future, that kind of doesn’t really matter. But for the exceptional candidate, you know, they’re gonna have multiple options and so you want to be basically beginning the selling process, which is like a hard sell. It’s more like you provide the opportunity for them to learn more about the company and the role, to ask questions, to establish that human connection, and you’re also beginning to understand what they value and want, like what you’re looking for in this role, what’s important to you. What’s your timeline, you know, more logistical stuff like compensation and location and travel, just trying to, you know, establish the baseline on which you’ll be basically selling this candidate in subsequent rounds. And then I’m doing that throughout the recruiting process. Every time we speak with a candidate is an opportunity to help them understand if the company is a good fit. And by the way, it’s also an opportunity for them to understand if it’s not a good fit. This is the thing that’s really important for me with recruiting. It’s about finding a mutual. Well fit, and I’m always really honest with candidates about that. I’ll tell them, I’m gonna help you understand if this is a good fit for you. And if it’s not, I’m gonna, you know, tell you. And, and a flip side, I’m even happy to help you find a job that is a good fit. You know, I know a bunch of other hiring managers in the industry. I can introduce you to them. That’s a very genuine offer that people have taken me up on. So I find that having that very congruent stance of, we’re here to find that this is an awesome job for you works well. 00:31:18 - Speaker 2: You mentioned here the 25% chance to go to the next stage or hopefully on the next stage, they have, you know, that chance of success. You can think of hiring as a funnel, same as a marketing funnel, where at each point, more and more people drop out and maybe again this is coming back to overemphasis on the filtering. But one reason I do like that visualization a little bit is, once you’ve opened communication with someone, I feel a kind of sense of moral obligation is too strong, just say, like, through politeness, that now they should get a clean conclusion, right? We either get to going to the next stage and eventually that proceeds to a higher or at some point it’s OK, one or the other or both of us have determined it’s not a fit, the process is now over. And one way to do this is just tooling and con on boards are a good way to do it where you have kind of a column for source and a column for introductory chat and a column for interview and whatever steps you have in your process, but part of what I like something like a trello or notion’s compound board for is there’s an automatic kind of date for the last update. And so it’s my personal opinion, you really shouldn’t let them set more than a week without an update. And again this is partially politeness, it’s partially a reflection of just you’re hiring in an industry where talent is in demand, and if you don’t keep that momentum up, they’ve got other opportunities. So I think a mistake I made at the very, very beginning of my hiring process, and I’ve seen lots of other hiring managers make is the solution for people you don’t want to continue with is you just ghost them. And of course that’s easier to do because it’s like sort of hard to write that email or whatever it is where you say, listen, based on what we know so far, this is a fit, so you know, good luck and everything. It’s kind of hard to write that email in a way, but I think you really owe it to them. Hopefully candidates feel that same way, if they decide, I’m taking another opportunity, or based on our last conversation, it’s not a fit, they can do the same thing. 00:33:16 - Speaker 1: Yeah, and it’s not just a matter of politeness, it’s a matter of effectiveness. Here’s my number one tip for listeners of this podcast episode. The most unreasonably effective thing to do in recruiting is to move quickly, especially as a small company where you have the ability to do that. So for example, on these initial chats, if the candidate is obviously very strong, and I know that they’re going to move to the next stage, I’ll just tell them at the end of the call. This has gone great. We’d like to interview you, and I’m gonna send you an email right to this call to schedule it. And likewise, you can do that on every step of the process. Ideally, you try to do it the same day, like, so for example, if they have a starter project presentation, talk about the team meets, and you basically make a decision right there and you email him or her right then. And often because of time zones or whatever it needs to be the next day, but I see all these companies, they take like a week to respond, and meanwhile, the candidate is like they’re hired, they’re starting at a new job, then they get this email a week later, you know, it’s like, we’re advancing you to the next stage. Well, that’s too bad. 00:34:14 - Speaker 2: Yeah, so then you’ve got kind of interviewing and pilot projects or starter projects, and I think interviewing is an area that has been given very extensive coverage by kind of blogs in our industry. So I don’t know how much time I want to spend on that, but I would be curious your take. 00:34:31 - Speaker 1: Well, it’s funny you say that because I think interviewing in our industry is like is completely broken and backwards, and there’s a bunch of cargo culting and mysticism and, you know, superstitions around interviewing, but there’s very little first principles thinking about what is effective. So I think it’s worth talking about. 00:34:49 - Speaker 2: Yeah, well, my take is it’s a scaled up version of that introductory chat slash phone screen, just getting more in depth, really trying to understand what drives them, what they’ve spent their time on in the past, where they want to grow in their career. And then telling them about your company, what the role is, and what the exact team is and what they would do there and trying to just get more and more, as you said, information for each side in order to just make it really obvious, wow, this is such a compelling fit everybody’s excited, let’s go forward, or yeah, to reveal that that fit just isn’t quite there. And that of course includes also the logistics that you already mentioned which is things like compensation and availability, right? It may be that you’re Really eager to hire someone basically right away, and there’s someone who says, well, you know, I’m on this project that’s wrapping at the end of the year and after that I’ll be thinking about a new thing or vice versa, maybe you’re on a longer cycle and obviously compensation is something that could vary really wildly, both cash equity. Basis on which it’s paid, you know, kind of salary versus freelance. Now you’ve got, you know, 4 day work weeks are becoming more popular, and, for example, in the Muse team, we have a mix of folks doing different total amounts of working time. So, you would just want to make sure all that makes sense and so it’s this constant exchange of information and you’re just trying to get the time necessary to get that exchange happening, as well as just finding that basic ability to communicate and whether you just sort of get along reasonably well. You don’t have to be best friends, but you do need to find a Good way to communicate and a good sense that you’re on the same page, and again, coming back to the shared values, shared working style, passion for the project area and so on. 00:36:32 - Speaker 1: Yeah, and I think that’s all good for the, what I would call the conversational piece of these interviews. I do also typically look for a sort of subject matter or skills piece of the interviews. And here’s my theory on interviewing. The best predictor of future performance is recent performance doing the same thing, which sounds so simple, and then you have these multi-billion dollar companies doing interviews that have absolutely no relation to the actual job to be done. So in order for me to get this information, I like to use two approaches. One, which is basically the interview and one is the pilot project that we’ll talk about. So with the interview, I do work history inquiries. Now, yes, you get some sense of work history from the resume, but often this is names of like companies and maybe projects, it’s very high level. So what I ask Canice to do is just describe to me. What you personally accomplished in your last one or maybe 2 jobs. And the thing is, the candidate know this question is coming, so everyone has prepared answer for the first question. The trick is you can’t prepare arbitrarily deep in the discussion tree. Just keep asking follow-up questions. OK, you said you solved the latency issue with the API. Tell me how you did that, right? What was the before and after, you know. Were you measuring the mean or median or percentiles, you know, why? And you just kind of keep going down. And my experience is that that’s extremely revealing on how a candidate operates and how effective that they’ve been. I mean, honestly, I’ve spoken with candidates who, they have a pretty nice looking resume, but you ask them about what they’ve personally accomplished in the past several years, and it’s kind of hard for them to come up with something specific. Meanwhile, sometimes you speak with candidates and there’s like knocking off stuff that they’ve done that they’ve personally accomplished, they help their team accomplish. It’s very concrete, it’s customer impacting, it’s business impacting, right? There’s all kinds of things they’ve done. So I find that that’s very effective on the interview piece. Now, the downside of that, going back to our original theory of interviewing is that that’s not gonna be exactly the same type of work and especially the same type of work environment as your company, and it is definitely a little in the past. So that’s where the pilot project approach comes in, which we’ll talk about next, I assume. 00:38:33 - Speaker 2: Indeed, if we should talk about the pilot project, which is, I think when I started doing these, and you and I certainly been doing them in our various shared ventures for well over a decade, maybe more like 15 years now, they were quite unusual. I got a lot of surprise both from candidates but also from others in our company who would say, well, it’s not the best way to do this, and it also costs you money, depending on how you do it. But for me, it’s just absolutely the way to find out what it is really and truly like to work together. There’s actually an older blog post on this just called 8 Simple Rules for Dating My Business. This is on the Thoughtbot blog, and they do this exact thing where they have the one week starter project, I think in their case, in their office. The basic concept here is that you kind of only get through so far in conversations, and I think everyone at this point knows that some kind of like faux demonstrations, whiteboard coding or whatever it is, whiteboard designing on the fly is probably not. Very useful. So the pilot projects is the idea of we’re actually gonna hire you on a freelance basis. We found that 1 week is a pretty good period of time or 2 weeks part time. This can be tricky if they’re currently employed, but I find it’s really worthwhile to just try to work with the candidates. To find a way to make it fit in, or we’re really going to hire you to join our team, come to our planning meeting, pick a thing to work on, work on it directly in our code base or design or marketing space or whatever the role is, and then at the end kind of present. What you learned. And of course a week is not a ton of time at all, so there is a little bit of a rushed aspect to it, but you still learn a whole lot in that, and then we’ll pay you for that week, because we’ve actually hired you to do this work, and that should be just incredibly revealing on working chemistry and their real ability to get things done specifically to your point, specifically in your environment. They may be really great at accomplishing something in a bigger company where they have a lot more resources and a little team like Muse, can they really roll up their sleeves? There’s not a lot of structure. You gotta figure it out yourself. Everyone does a little of everything. Some people thrive in that environment, others don’t. But regardless, we want to see one, can you be effective and then two for the candidate, maybe think, you know what, I don’t want to be in an environment like this. I don’t think I can do great work. I don’t think I’ll be happy, so it’s really real in terms of what their working life will be like. 00:41:03 - Speaker 1: Yeah, I find that these are incredibly effective. We had great luck with them at Hiroku, where if I remember correctly, I think we did maybe more like 2 or 3 days, although I think the flavor was a little bit different. They were more compartmentalized projects like you’re working on a specific module or something. It’s a little bit more self-contained, whereas the nature of our business and where we’re at with news, it’s like you’re saying there’s a lot going on. Everyone’s doing a little bit of everything, so you need a little bit of time to sort of dig in. Yeah, extremely effective, and again I think it’s because you’re simulating and indeed doing the work that you’re actually gonna be doing with the team if you were to join full time. And yeah, I found that between 235 days, you get an incredible amount of information, basically all that you could really use for the stage of the recruiting process. And again, it really goes both ways. I’ve been surprised, basically all the candidates that I’ve spoken to said that they really appreciated the opportunity or the perspective of the opportunity to have this evaluation period for the company. Like I said, you’re spending the next 2 to 4 years of your human life, 40 hours a week on this thing, you should have a pretty good idea of what you’re signing up for, and I don’t think you get that with 4 hours of interviews at the San Francisco office or whatever, right? You, you really need to spend some time working with the team. So I think it makes perfect sense for both the candidate and the company. 00:42:21 - Speaker 2: One thing worth noting is that a lot of jobs, full-time positions do have some kind of trial period built in. For example, in Germany it’s sort of encoded in law 6 months is sort of your maximum profit site where essentially the sort of very at will, just like this didn’t work out, you know, we gave it a try, but we have learned through really having you in the office virtually or actually that this isn’t a good fit and sort of both sides can walk away, but the important difference there is that the default as you continue. And I like the idea of a pilot project, obviously the one week is the shorter one, but we also do a slightly longer one, and there the default is end. That’s where we’re starting. And then we may, if both parties decide they want to continue, they do so. One variation on this is Zappos, which famously had or still has a 4 week training period, and then at the end, they would basically give them a bonus to quit, basically like a cash offer to quit, and it started pretty low, but eventually kept going up. I think it was something like 2000. Bucks, and it’s like pretty good, especially for some of these roles where basically like, look, you gotta really love this and think that this is great for you and you’re gonna be committed to a long term. And there’s this alternative, that’s cold hard money you can have right now that you don’t have to work for, and so that sort of like creates that natural break point as well. 00:43:44 - Speaker 1: Yeah, I think this idea of defaults is really powerful and moving it so that the default staying doesn’t happen until after both sides have worked together with each other for some amount of time is the right move. 00:43:57 - Speaker 2: All right, Mark, so we’ve been through all this effort to source candidates, maybe we’ve talked to 50 people and we’ve been through this mutual filtering process and getting to know each other and building trust and finding working chemistry through pilot projects. Now we need to make an offer. We need to negotiate that, but hopefully again you started from a sense of knowing where they are in their life and what they need to want and similarly, you were clear up front about what the company can offer, so hopefully that part is not too onerous, but then you get to their first day, and that’s it, you’re done, right? Like that’s the end of the hiring process. 00:44:38 - Speaker 1: Well, that’s the thing you can do, and in fact many companies do do, but I think it’s a mistake. 00:44:42 - Speaker 2: Yeah, I’m just trying to wind you up. My personal feeling is that this is the exact halfway point of the process. The new team members' first day is a magical moment when they’re excited for the potential, the team’s excited, they’re excited, you’ve just expanded your capacity maybe by a lot, especially if you’re a small team, you know, adding your 6th member is quite an expansion of potential, just bandwidth you can do as well as whatever new skills and perspective they’re gonna bring to the table. And of course you want to capitalize on that energy, but importantly it really does take a good while, 3 months, 6 months, longer to truly reach integration with the team. You know exactly what you’re doing, you’re successful in your work. Usually we have a concept of onboarding, which is a sense of, yeah, training, getting up to speed, just learning all the systems, just getting accounts in all the systems, getting to know how the company works, etc. And some of it is just a matter of just getting your first projects to work on and starting to get some wins and starting to learn your way around the project. How do you think about, you know, onboarding and the overall ramp from it’s your first day to you’re a productive and successful member of the team? 00:45:54 - Speaker 1: OK, there’s a lot going on here. Maybe we start with the simplest thing, which is the logistics. I think it’s worth having a checklist that you accrete over time of stuff that you need to do for onboarding. We’ve even done this and even though we’ve only onboard a few engineers. The first engineer, we start with a blank notion page, it’s like, OK, they can’t log in to GitHub, add that to the list, and then you do that for them, but also in subsequent hires or trial project participants. You have that list, and every time you find something that’s not quite right anymore, like there’s a new account that needs to be added and you update, you agree to list. I also think that the personnel is really important here, especially when you’re at a little bit of a larger company. It’s kind of different now with M, but I found that when you have a large enough team, you have a hiring manager, who’s like a full-time manager. It helps to have two people involved, named people involved in onboarding. One is obviously the hiring manager, who’s gonna be responsible for a lot of the personnel and HR and logistics stuff and the overall success and development of the new hire, but then also having them paired with. An onboarding buddy, who is their day to day person, basically the person that they can ask technical questions about, like, you know, this isn’t compiling, I can’t install a Ruby on my Mac. If that has to bounce up to the manager who’s dealing with all kinds of other stuff, they’re not going to get a quick response. And you really want someone who can respond right away. And then by the way, giving someone the responsibility of helping a new higher on board is very healthy for the team. It’s healthy for the individual, it’s healthy for the team. It’s like a good growing process for everyone involved. And then there’s sort of the scope of work piece, which is an area that I have pretty strong opinions about. My approach is to gradually increase the scope of responsibility for the candidate up to their capacity given their skill level and seniority. What I mean by that is when you’re first starting out, the only thing you can reasonably be expected to do is follow very specific instructions for a short project. It’s like OK, you need to install our build tool chain and compile the project and run the test. And then the next thing might be giving them a little bit more wiggle room, but still pretty contained and scoped out. Like, here’s a bug. We basically know how to fix it. We know it’ll take about half a day, but you should be able to navigate some amount of uncertainty there, figure out how exactly to fix it, what the test should be, get the pull request written up, merge it, deployed to production, and then eventually, The scope of responsibility is gonna keep growing, and I measure it in basically how many days they’re expected to go without circling back. So first might be, you know, a small feature, you develop the feature over a few days and then you’re circling back and you’re getting feedback or there’s a sort of checkpoint, but then eventually with very senior candidates, it might be a week, a month, even longer where they’re off on their own adventure, you know, they’re re architecting a system or they’re building a whole new Technical architecture or they’re developing a feature from first principles, but you got to approach that gradually, because if you jump right to that, even for a very senior person, they don’t have enough familiarity with the code base, the team, the customers, the business, and they’re just gonna get lost out in the woods. So you gotta increase it gradually. But on the flip side, if you keep giving an experienced engineer a small bugs, it’s not going to be fulfilling. So you gotta kind of balance the difficulty with the ability of the candidate to move up that line over time. 00:49:08 - Speaker 2: For engineers, a great source of inspiration, I think, is open source projects that often purposely groom a list of easy to fix, but not very important bugs in the project, and they have them there just as an easy on board ramp for anyone who wants to get involved. In the project, and you get that quick win and you learn what their processes are, the code base looks like, and then you can move forward from there, and there’s obviously equivalence for that sort of thing for all the other roles. The other way I would think about that kind of onboarding side of things, even for someone who’s, as you said, very senior, they really know what they’re doing. They have a lot of their own ideas and skills and everything to bring to the table, but when you get into a new team, especially a really established team with a lot of culture or if it’s a big team with just a little a lot of people or a building in talking about companies with offices, heard that’s still a thing somewhere that, you know, you need to like figure out where to go in the building and I like the metaphor of showing up at a house party. Maybe it’s pretty busy, maybe you don’t know very many people there, but you do know the host, and there’s a great hack, which is you can have new people that show up and seem a little bit sort of like they haven’t quite figured out how to settle in yet, give them a little task like here, chop these vegetables, something very specific and gives them like a sense that I belong here and I have my little corner of this. event that is sort of clearly mine and I’m contributing to in some way and then that can expand outward from there and I think there’s a version of this coming onto a team. It’s not a house party, it is more, you know, productivity oriented and there’s clear processes and things like that, but it does have the same quality of you’re stepping into someone else’s house, especially a team with a well developed culture or maybe one that’s In some ways different from places you’ve worked in the past, then there’s this period of just kind of, maybe you’re walking on eggshells a little bit, you’re trying to feel it out and you don’t know what the customs are in this strange place and you’re trying to learn how to fit in, in addition to wanting to obviously prove yourself and just the kind of skills area, and so that’s place where a hiring manager or even better yet, like you said, the buddy who’s not necessarily your boss, but just someone to help you get acclimated, can help you with a lot of that kind of host like, here chop these vegetables. Oh, did you know that, you know, the hallway over there leads to here, oh, did you know if this person’s name is so and so? 00:51:35 - Speaker 1: Yeah, and that reminds me that in, especially in larger companies, there are a lot of invisible social structures and relationships and work flow patterns that are very important to know the product could be written down and it may be useful to make that an explicit part of the onboarding process. Because what’s gonna happen is you’re gonna need to do something and then you’re gonna need to know what the magic incantations are, they’re necessary to do that thing at the company and you’re gonna want to have a relationship with the person you’re going to need to ask for help and advice. You don’t want the very first conversation with that person to be, you know, can you help me with this deploy. Or something that’s just kind of weird. So I would often give social assignments, people like, you need to go have 5 lunches with these 5 different people in the company and, you know, ask them about their lives and worlds and, and that really pays off down the road where you need to interact with these people in a more work focused transactional capacity. 00:52:24 - Speaker 2: And obviously trying to create some of those in the virtual environments for remote teams, all remote teams like ours is a challenge. Now we lean very heavily on team summits where we get people together in person periodically, not as often as we used to sadly, but still very important because you get to see someone as more of a whole person. Um, in a way that I think can greatly grease the wheels of your work in collaboration when it does come time to do the more transactional side of it. And one thing we try to do is try to schedule a team summit for people who are relatively new on the team, try to line up a summit we’re going to have anyways with someone who’s, OK, you’ve been here a month now or 6 weeks, now it’s time to kind of go a little deeper with meeting everyone and spending more time on this. More human level, not just being a square on the screen. Even to the point where we don’t have a summit scheduled, I think it’s important enough. We’ll just pull together a mini summit or say, well, you happen to be close geographically to these three people, so it’ll be convenient to get this group together in a city, and at least then you get partial exposure to the team. So do you have a sense of just timeline wise, what do you consider to be on boarding or training or getting up to speed, and when do you consider them to be fully onboarded and they’re sort of a team member that you sort of have the same expectations of someone who’s been there a long time, or is there such a clear dividing line? 00:53:54 - Speaker 1: Yeah, I think ballpark, after 1 to 2 weeks, they should be mechanically onboarded. They should know how to build and change and review and deploy the code and operate the key systems and things like that. And then I find it takes maybe 3 or 6 months at a larger company to be able to successfully take initiative on large complex projects and drive them through to completion. And for a lot of people, that’s sort of the plateau and then often though for executives, it might take 6, 12, even 18 months before they’ve built up all the relationships and capital to be able to execute effectively. So it kind of depends on what your goal is, but those are some ballparks. 00:54:35 - Speaker 2: Yeah, I do think different roles require different amounts of context. Probably engineering is one
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: You start with some seeds of an idea. Basically, it might be some sketches or a picture of a whiteboard you took or a voice memo, and what you want to end up with is, say, an essay, and there’s several steps to the creative process. And one of the things that’s exciting about the new text feature plus blocks is you can see it as a trellis for that growth. 00:00:23 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for thought on iPad. But this podcast isn’t about Muse the product, it’s about Muse the company and the small team behind it. I’m Adam Wiggins here with Mark McGranaghan. Hey, Adam. Mark, I’m pleased to report that Metause has broken into the top 200 charts on the technology category in Apple Podcasts. It’s a per country breakdown. I’ve been using a little thing called PO status that essentially sort of charts your position over time. Some countries were there pretty consistently, other places like Germany where I live, we kind of pop in and out at the whims of the algorithm essentially. That was quite surprising to me in a lot of ways, cause I just still think of this as, you know, me and you were having a chat sometimes with guests, just people we like to hang out with and seeing our logo alongside these what I consider to be kind of giants of the podcasting world like Cortex and Accidental tech and so on is kind of a thrill actually. 00:01:20 - Speaker 1: Yeah, I continued to be really pleasantly surprised by the reception we get to the podcast. It’s actually just at a family event about a week ago, and people would come to me and say, Mark, hey, it’s great to see you. By the way, I love the podcast, like, whoa, OK, I didn’t know you were listening to that, but that’s cool. So yeah, it’s been fun. 00:01:35 - Speaker 2: Nice. Yeah, and I also want to maybe make a little request. First of all, a huge thanks to all the people who have tweet recommendations or a lot of folks tell me that they do more kind of in person. Reminds me a little bit of our episode on social media where we talked about something going viral slowly kind of through word of mouth, sort of the ideal thing, and I think there’s a little bit of that here, which is great. But actually, if you haven’t had the chance to recommend us, you can actually help by leaving a review on Apple Podcasts. They make it a little hard to do, but if you go to the new podcast page and go to the Apple Podcasts, I’ll link that in the show notes. You scroll down to the bottom, I think you can tap write a review if you’re on your iPhone. I’m sure Spotify has a similar thing. We only have a few reviews. In a lot of countries, sometimes none, so even just taking a moment to drop in a star review in one sentence of what you think you like hearing these weird guys talk about, if nothing else, will soothe my vanity. So our topic today is text. Now that word even is so rich for me and many of the reasons I got into computing and tools for thought, and so on. The impetus here is we’re just now releasing into beta for all our pro members a text blocks feature, so essentially changing our text cards today, which are kind of these Post-it notes things, pretty basic, to something that is a little more inspired by the notion Rome craft world of things. And maybe we’ll describe a little more of that vision later, but of course I always like to start with the absolute fundamentals. So Mark, I have to ask you, what is text, and I mean not the dictionary definition, but what comes to mind for you with that word. 00:03:11 - Speaker 1: Well I’ll give you a very marked philosophical answer, which I’m sure we’ll hear echoes of in the rest of this conversation. Now, if you think about conveying information, there’s sort of a necessarily most primitive form, which is a string of 0 and 1’s, you know, you can’t reduce the dimensionality beyond a line and you can’t reduce the base beyond two, right, or else you have no information. And then in the case of human acceptable information, it’s perhaps a string of human readable characters. So in some sense it’s the most basic fundamental primitive way to communicate information. So that’s one of the reasons why I think it comes up so often in Tools for Thought, but we’ll talk more about that throughout the podcast. 00:03:51 - Speaker 2: For me, the word text, I think, makes me think of plain text or files that end in .txt and for a very long time, that was my whole knowledge management system was a folder full of text files. Maybe at some point I did mark down or something like that, but plain text is just one of the most fundamental formats on a computer. It’s how code is usually represented, it’s a very durable and long-term format, it’s very flexible, you can do Aski art and things like that, yeah. But I guess going back even before sort of the digital side of things, I really think of writing things down in any way at all as the original tool for thought. And in fact, it feels like almost all of the things that build upon that are essentially variations of ways to write things down. Ways to externalize thoughts from your mind. I think we’ve talked before about even something as simple as using a stick to draw on the dirt and I don’t know, cavemen drawing a picture of a horse on the wall of their cave, and certainly you have this whole history of, I guess there’s sort of written language, which of course is an extension of or a mapping of spoken language. And that leads you into the whole world of alphabets, but actually even before alphabets, you have logograms, things like hieroglyphs, you know, you have a picture of a duck, and that means the word duck, for example, and then you have all these technologies for mediums for writing on, mediums for writing with, for reproducing those things, clay tablets, styluses, papyrus, paper, pens and pencils, printing press, whiteboards, posted notes, etc. And then language, which we typically represent in modern times with alphabets which stand for sounds roughly, but are actually very abstract, you know, they’re pretty far removed from the pictures or diagrams we once had, and I think that leads us to one of the dualities I wanted to talk about or I’ve been thinking about a lot in terms of this muse product direction, which is the duality or the spectrum of symbolic versus spatial and visual. 00:05:46 - Speaker 1: Yeah, this could that something really fundamental, which is formats that are optimal for conveyance and translation and reproduction and storage, which I would say plain text, especially for that category versus formats which are optimized for matching how our minds work and think, which is closer, I would say to the music model of it’s multimedia, it’s free form, it’s kind of messy, and so. Forth. And so there’s constantly a tension, I think, between having a tool that better represents and better works with how we tend to think versus having a tool that, for example, can persist that data over hundreds of thousands of years, or just a few years in the case of today’s software. And I think kind of grappling with that, not to mention just the complexity of actually building such a multimedia canvas is a lot of what the tools for Though space is about. 00:06:35 - Speaker 2: Yeah, I would argue that at least the current tools for thought space, which is maybe a little bit overindexed on building sort of Rome clones and variations, and I think there’s probably much wider space to explore. I’m certain there’s much wider space to explore, but those, of course, yeah, Rome notion, they’re in the same vein of, yeah, plain text files, marked down, Emacs org mode. Very symbolic oriented and of course symbolic representation, yeah, mathematics, written language, of course, even programming is just an incredibly powerful way to do things, but this spatial and visual side, I mean, we talked about this with Anne Lohr back in the episode on thinking in maps and sort of diagrams and literal maps in some cases, as being a spatial and visual way to represent things. Or there’s something like data visualization. Of course we can’t go in an episode without mentioning Brett Victor, and I was just rewatching some of the humane representation of thought, where he talks about the invention of the modern chart or data visualization. I think it’s in the, maybe the 1700s, 1800s by William Playfair. And this idea of creating a chart where you got time on one axis, and some thing that goes up and down, like money or population or some other thing on another axis, turned out to be a really powerful way to tap into our spatial reasoning and a much better way to get overviews and see patterns in data, but that would be invented just like everything. So that’s an amazing tool for thought, I think, an example of in that sort of spatial and visual side that we think is Maybe under explored in the digital realm or right at this moment in the digital realm. 00:08:16 - Speaker 1: Right? And I also think there’s an element of time and process here. So there are some use cases where you want a very visual and spatial end product. A map is perhaps the canonical example of that, but I think much more common is a case where the process along some of the Steps asks for such a format. So for example, if you’re eventually going to write an essay, the final artifact is going to be plain text, essentially. But I find at least it’s quite hard to start ideaating and brainstorming and sketching an essay, like basically in a text editor, you know, maybe I’m going for a walk or I want to be giving myself a voice memo or I’m sketching some ideas in my notebook, or I’m drawing some diagrams, right? And so you have this process where often I find in the beginning stages of ideation, brainstorming, sketching, outlining, you can really benefit from this freeform spatial multimedia model. But then you have the issue of if that’s step one, but the final step is plain text, how do you navigate that jump basically? Do you jump tools? Do you have some kind of conversion step? I think often what people do or often what people have done in the past is they just kind of punt on it. And they find a tool that’s like flexible-ish enough to do some of the brainstorming and like presentable enough to do some final publishing. I think notion is actually a really effective example of that where it’s really nice to do the whole process in one tool, even if it’s not ideal for either end. Or sometimes people, I think they jump tools like they do some sketching in the notebook and they have an outline for their essay, and then they go type it up, they basically got to retype up all their notes. So I think there’s an interesting potential for tools that allow a more gradual and continuous process where the shape of the content evolves from a messy sketch to a typed up essay, for example. 00:09:57 - Speaker 2: Yeah, and there may even be some value to the transcription process. So in the coming up with what you’re going to write for a long form prose piece, let’s say you’re a journalist or you’re just writing a blog post for your own personal thing, of course, in the end it is going to be this linear one dimensional starts in the top left for left to right language readers and ends at the bottom right and flows very linearly, but when you’re figuring out what to say, maybe you draw on your whiteboard, you’s catching your notebook, you use index cards that you can move around on a table. And maybe you find what you want to say, but then actually sort of transcribing that fresh into, I don’t know, your writing tool or whatever works. Maybe that works OK in a lot of cases. There are some examples in the digital realm. I think we’ve spoken about them or linked to them before, but this company Literature and Latte makes one of the maybe best known kind of dedicated long form writer’s tool, which is Scrivener, I think it’s really intended, especially for novelists, fiction novelists. But they also have another tool called Skel, I believe it is. I’ll link that in the notes, which is kind of cards on a canvas, Post-it notes, desktop thing, maybe it’s not as sleek and modern as Muse, but I’ve run into people who use Skel in the same way you might use Muse, and notably they’re both from the same company. And they’re intended, but they’re just for those different stages, precisely like you said. One is this ideation, you’re figuring out the arcs of your character and maybe even want notes that aren’t even going to be sort of in line to the story. There’s backstory about a particular character or a place. You’re not necessarily going to just have a paragraph where you say so. So it was from here, they’re this old and what have you, but as a writer, having that floating around on the edges as a reminder while you’re near your other kind of plot elements can be useful. So that’s another example of the nonlinear free form, and then eventually you somehow collapse it down to this one dimensional long form prose format. 00:11:48 - Speaker 1: Yeah, I do think there’s just a ton of potential in that type of tool, and I feel like we’re only just beginning to explore it as an industry. We kind of take for granted that you’re gonna be starting with like a text buffer and you’re gonna type stuff in and that’s that. And I think it really impacts our ability to develop creative ideas, and I do believe that as we develop more tools that are more aligned with how we’re thinking, they’re more multimedia, they’re spatial, they’re free form, we will in fact have better ideas. That’s one of the big bets of news. 00:12:15 - Speaker 2: Yeah, thinking about the linear kind of top to bottom flow of text or symbolic language, I also had me thinking a bit about terminals, or reppel, sometimes they’re called. You know, when you think of computers, text is like really foundational, and then the terminal, at least for Unix folks like us, that’s a place where we spend a lot of time, it’s a venerable, it’s sort of a way to have a conversation with the computers the way I think of that a little bit, a little bit of the gliders, man, computer symbiosis, but I always find it interesting if you dig into why does the terminal. Work this particular weird way with a lot of control characters and whatever and then you get into this TTY thing. What does TTY stand for? Well, that’s short for teletype and these like teletype things date back to the 1800s, their stock tickers, that sort of thing. They were essentially these ways to have again the computer or some automated device produce a linear stream of symbols. I think later they were adapted to mainframes, maybe in the 1960s or something like that. And then even when you go to word processors, whether it’s like the WordPerfect and whatever in the 1980s or Xerox PARC and there what you see is what you get word processor, and even today Google Docs still has this quality. You start in the top left, you go top to bottom. That’s kind of it. Except, I do think a breakthrough or, and maybe this is less at the symbol level, but it is at the overall corpus level, is linked. Let’s see you had wikis first, I think the web with hypertext, you could argue is clearly the biggest and strongest example of that. And a lot of the excitement also around tools for thought right now, notion first, you know, sort of a modern wiki in many ways, Rome with its backlinks, lots of others have focused on the linking elements of things, and so now you do get a graph of your knowledge and so. The individual documents are still these linear streams of text, but you can kind of pop around between them and the web, I think, takes it even further and Notion I think does this reasonably well also, which is letting you put multimedia elements in images, video, that sort of thing. Although in the end I think notion is still very much inherits that sort of top to bottom, typing into a word processor kind of thing, and the web has more free form, but of course if you really decompose it, you know, you hit view source in your browser, in the end there’s a top to bottom linear document made out of characters. 00:14:36 - Speaker 1: Yeah, that’s interesting. This is clarifying for me that there’s a couple of dimensions at play here. There’s the dimension of what’s the datum type, and by datum I mean like the atom of information, which could be a text paragraph, it could be an image, and then there’s a dimension of call it like interactivity or freeformness, if that’s a word. 00:14:54 - Speaker 2: Unstructuredness maybe. 00:14:56 - Speaker 1: Yeah, and the examples that you gave are interesting because when we think of text, we often think of the straight up plain text buffer and sublime or whatever, but you gave the example of a wiki. Reppel, I would include social networks like Twitter in there. There, the datum is still text, but it’s very rich and interactive in other ways, right? And I think that that’s compelling because there’s all these nice properties of text as a datum, but there are a lot of limitations with plain text as a pure linearization of text datums, right? And again, this kind of gets into what I think we’re trying to do with Muse, where we really like text as a datum, and I think it’s really important, perhaps the foundational one. But you don’t want to be limited to putting just text just in a line. 00:15:38 - Speaker 2: Yeah, Twitter’s a great example. I hadn’t thought of that one, where of course as text first, it’s even famous for that 140 characters, now 280 originally started with essentially sending SMS messages before they kind of adapted to the mobile client world, but I would argue that its value and richness does come not just from the text, but from the links, from the images, from the video. And furthermore, that there is this atomic unit that can contain all of the above in a particular container, which is the tweet, which often is represented with this card, you can invent that. And actually that’s a nice note for what we’ll get onto later, which is sort of the block text concept, and that is an atomic unit, and then of course, news has its cards, so I think all of those sort of relate a bit. So in thinking about the importance of text and what we might like to do for use again, we love text, we believe in it, we just think it’s so well handled or supported, or that’s where a lot of the interest, innovation focus has been on computing tools and we saw the iPad and it’s particularly. The pencil, which as we talked about in the iPad episode here recently, was kind of the thing that starts to make it potentially a different type of computing tool that’s unique and so we wanted to take advantage of those making another kind of text first tool on the iPads it felt not quite right. But having done that, having invested heavily in the spatial and visual side, now we think, OK, we have these text cards, they’re pretty basic. Text is still really important, what can we do to bring that in? And in some ways I kind of draw the spectrum or something like that on digital products as you have the increasing number of I don’t know, tools for thought or something like that that again I think are very influenced by the notion and Rome side of things but are again lineage going back to Emacs org mode and work flowy and all that sort of kind of stuff tend to be text first. Yeah, you can do some multimedia, but the multimedia is in line with the text. That’s the focus. It’s on desktop computer, you’re using a keyboard, keyboard shortcuts, etc. And then you have the world of, I’ll call them digital whiteboards, which I think people often do want to categorize news as, that’s kind of what it looks like at first glance. I don’t think it’s actually quite right or that’s not at least our long term vision, but you have something like Mirro, for example, or fig jam, or even like these sketchbooks like good notes, I think you and I have both used quite a bit. That essentially allow you to do very free form stuff. It’s spatial. You can drop in images, you can sketch, maybe you can do so collaboratively, but notably I think all of those that latter category, you can put text in, but it’s not fun. It’s basically the same as putting text in photoshop. I mean, imagine trying to write a blog post in Photoshop with a text tool. It’s miserable concept. 00:18:27 - Speaker 1: It kind of reminds me of when you need to annotate PDFs for like legal forms, you gotta go like annotate, insert text, and it gives you the chunky text box, you know, you can do it, yeah. 00:18:37 - Speaker 2: Yeah, exactly. And I actually had the opportunity to speak to product people from both Miro and Fig Jam recently, and they confirmed, yeah, text is not something that’s important to us. We think it’s useful to drop in the equivalent of a Post-it note or a little title or something, but it’s just, that’s not what we’re doing. So I think or hope that the hypothesis we’re exploring here with this beta is that bringing these two together, richer tech support. And this visual spatial sketchy environment could be something really powerful and maybe a more useful thinking tool than either of those apart. Although I’m very conscious of the, let’s say the opposite side, which is uncanny valley, right? Sort of like not very good at editing text, but the text gets in the way of the free form stuff, that would be the downside of that, and that’s why I want to explore it through this beta. Now it’s Ben, our colleagues Yuli and Leonard, both of whom have been on the podcast before, they’re really driving the vision on this, doing some incredible work, as always, and I know you’ve been more heads down on the sinking side of things, so I think you got a chance to try the text blocks beta recently. What was your reaction as someone who is coming in a little bit cold or a little bit fresh to the idea? 00:19:52 - Speaker 1: In the most recent beta of the text blocks, I think I got a glimmer of something really special. It’s this flow where you have a series of blocks of text, sort of like a to do list or a brainstorming list, and you can move the blocks around, and the list automatically reforms, and I really like that because before I used to do this sort of thing with the pencil because then you can do lasso select and you can move stuff around, but it’s always so. to use the pencil for everything, or I could do these lists on a desktop, but then, you know, you’re sitting at your goofy office chair and stuff, and it just doesn’t feel very creative. But with this latest beta, I think we’re getting close to feeling like the text tools plus the blocks, plus how they are manipulated is a really natural extension of how you’re thinking, where you’re saying, oh, this idea I should move down or move up, and you can basically do that in the app. So I’m pretty excited about it. 00:20:45 - Speaker 2: Yeah, and you hinted there at um one of the core ideas, which is why we’re calling this text blocks, which is the blocks concept, I think. I don’t know where it started actually. My first real encounter with it was notion, although I feel like the computational notebooks that I used well prior to that, like IPython and Jupiter had a model like this more for the purpose of kind of almost calls back to the reppel type environment or this top to bottom execution flow, but this idea of stacked cells, it was almost like a spreadsheet that only went in one dimension, worked surprisingly well and of course the thing that makes it a notebook. is that it’s not just code, but you can drop usually mark down cells in there and you can move those around and have the explanations in line. It works out to be a pretty natural way to work to have this structure of the top to bottom blocks, and then within that you can have, in the case of freeform pros, you can basically just type however as you would in a normal text buffer. And so then I think notion, as again, my first real encounter with that, took that idea of essentially each paragraph is a block, and that by itself, it was just text. There’s some things that are cool about it for like reordering lines and stuff, but I think it wouldn’t be worth the hassle because it can be confusing when you switch between character select mode and block select mode. There’s still lots of ways that something like notion, roam, or craft behave in a way that’s quite different from the Google Docs word processor, them, whatever lineage of text buffer editing, where I think it starts to excel is when you bring in other things that aren’t text. So, images, video, links. Tables, convent boards, and I think this is part of the power of modern digital computing. You can do these multimedia documents, you can illustrate things, you can drop in screenshots, etc. Google Docs, for example, I use this kind of an internal memo thing for a long time. You can put images in there, but it tries to make it kind of a giant character. They’re very weird to work with. It’s just it feels wrong. And having these stacked blocks where most of them are texts, but they can be other things like images and Video and so on, somehow that makes the whole thing, even though it’s still a text first environment, it feels much friendlier and more natural to this multimedia world we live in now. 00:23:02 - Speaker 1: And I think we’re also getting a line of sight on this grow a document use case that we’ve been striving for for a long time. So this is the idea that you start with some seeds of an idea. Basically it might be some sketches or a picture of a whiteboard you took or a voice memo, and what you want to end up with is, say, an essay, and there’s several steps to the creative process. And one of the things that’s exciting about the new text feature plus blocks is you can see it as a trellis for that growth, right, where you start with Line, which maybe is initially just like one or two word snippets, or maybe it has some pictures thrown in, or maybe it has some handwritten notes thrown in. And then as you go through, you’re rearranging, but also sort of expanding each of these blocks. So your little block that says, you know, to do insert paragraph about food here, that grows into a full paragraph on the essay. And likewise, your little picture of a whiteboard of some diagram gets replaced with a nice diagram that you create, right? And that way the essay sort of organically grows and critically it also Happens in one place. So there’s no point where you need to jump from your notebook to your brainstorming tool to your authoring tool. You can sort of do it all in one place. And I don’t expect that you would do the full creative process in Muse. I think you would probably stop at like the sketch or the outline or the draft phase, you would move to an authoring tool and a publishing tool for the final step, but even the idea of growing the whole meat of the essay in Muse is really exciting to me. 00:24:24 - Speaker 2: Absolutely, and I’ve done this kind of writing workflow myself, and I’ve heard from lots of folks writing in to support or just that I talked to casually that they use Muse in this way for their own writing workflow. Jeffrey Litt showed something like this for his newsletter, previous podcast guest. We have a fiction author that described a similar way of working through sort of plots and character development and things. Now I think in the current kind of text cards thing, they’re basically like Post-it notes. And what I do like about that, and I do this in the analog world as well, I know I have a lot to say on the subject, but I just don’t know the structure. I don’t know the table of contents. I don’t know where to start. So you can just take a stack of index cards or Post-its and just write down the first thing that comes into your head, you know, the seven word version of it, pull the Post-it off the stack, set it aside, right the next thing comes into your head, and do that until you got 20 of those. Now go arrange them on a wall or something, right? And you might start to see a pattern emerge or a narrative arc or something like that. Right. I have used Muse for that for years now with the kind of post-it cards, but it’s like you said, you stop pretty early because once I have the rough ideas roughly in the order I want, and maybe a few scribbled arrows and highlights and things like that, I go, OK, I’ve made it this far. I don’t want to do any more substantial writing. I don’t want to do any really amount of big investment in the words. It’s really more just the high level concepts, and I want to go over to my writing tool. Now with the text blocks, potentially, you can do more of the long form writing. Again, it’s not a full-fledged text editor, never intended to be, but you can at least get a lot more of the core ideas written down and then basically use your select tool, just grab everything, hit copy, pop over to a writing. Tool like Kraft Ulysses or your WordPress blog or whatever it is, paste it in and then go and do your more substantial wordsmithing. But at that point you’ve got the flow, the order, the structure of the piece, maybe some of the major phrases and opening sentences of each paragraph and that sort of thing. And now you can go and start really putting the meat on the bone. 00:26:25 - Speaker 1: Now we’ve talked about jumping to a full-fledged authoring and publishing tool for writing, which I do think you’re gonna need to do if you have an external audience, you’re gonna want to create a PDF or something similar. But I’m saying is that often for internal communications within a company, you can get by with just using the ideation and brainstorming tool as the quote unquote publisher. So we see this a lot internally with both muse and Notion. People create muse boards or notion documents and use those as the final artifact that they’re gonna share with their teammates because yeah, they’re a little bit sketchy, but that’s fine. We recently had a good planning session where we used a beta of the text blocks and it was really cool to see that and it’s actually nice cause it kind of correctly reflects the state of the ideas. You know, it’s this notion that you don’t want it to seem too rough nor too polished, because the ideas are sort of in this intermediate state, which I think the muse boards with some text cards and some highlighting and some images and stuff that show which is nice. 00:27:23 - Speaker 2: Fidelity, the representation should hopefully convey the level of polish of the ideas as this uh carefully crafted plan intended to be conveyed to a wide audience versus a thing that we sketched together in an hour of a planning session. Right? It’s a really good point on the publishing side of things. And I think that any idea that you want to express, again coming back to that, writing something down as the original tool for thought, externalizing an idea, and you can start on one end of the spectrum is just you want to express it for yourself. And that’s the sketchbook, that’s what M is focused on today. It’s just, let me get this idea out of my head, explore it on the page, see if there’s legs, develop it. But I never intend to share it, at least not in this form with anyone else. The other extreme is I’m a journalist writing a piece for The New York Times or I’m a documentary maker and I’m going to put my thing on Netflix and it’s going to be consumed by potentially millions of people. And so there’s going to be a very high degree of polish and a whole long process going from ideation and sketches to drafts and drafts and revisions to Some maybe post-production process to make it really polished. So those are the two ends of the spectrum, then you have a lot in the middle, and I think internal memo culture accompanies is a very big, I don’t know if you call it a publishing, it is a type of publishing in a way. So for example, at Hiroku, I think we typically use GitHub and just. As a way to kind of publish memos, email, of course it’s a classic kind of internal memo. I’ve used Google Docs in the past, as I’ve mentioned, at Muse we use Notion pretty heavily, but more and more we use Muse just depending on what the item is. But Muse makes it hard to publish. We don’t offer a good or easy way to screenshot or PDF, that sort of thing. Again, that’ll be coming in the future, since our focus really has been on that individual ideation point. But yeah, if you think about, OK, when I write a memo in notion for my teammates, well, I only have 5 teammates, or there’s only 5 people in the muse team, which means I have 4 colleagues, so there’s a total of 4 people who are going to consume this, and I want it to be comprehensible. I want to respect their time. I want them to be energized by the idea. I want them to just understand what I’m trying to say, so it’s worth a little while. to make sure I’ve got my thoughts together and it’s not just a stream of consciousness that no one can follow, but it’s only for people and people I’m pretty mind melded with and we have a lot of context, so it can be pretty rough. And on that same note, we do share muse boards internally even though there isn’t great mechanisms for that yet, and it works well because again it’s sketchy and it’s It starts as this individual ideation, but it doesn’t take a whole lot of effort to cross that threshold to something that I can give to you or Leonard or all four of you, and you can understand because you have this context and we’ve already talked about these ideas before and this is just another iteration on an overall philosophy of what we’re trying to do with this company and product. 00:30:18 - Speaker 1: Yeah, super interesting, and I like that you mentioned spectrums because one of my favorite intellectual tricks is to look at spectrums or grids and interrogate each of the points on it or along it. And now that you’ve talked about spectrums, this kind of connects back to one of the original impetuses from you, which is to speak in terms of spectrum. There’s a lot Software for the extremely populated side of the spectrum. This is like enterprises where you have Lassian wikis and so on, just because there’s such a big amount of money there. And there’s a fair amount of software for the individual side, if for no other reason, that’s kind of the base case and you kind of got to start there before you add collaboration. But we had this hypothesis that a lot of the creative magic happens. In small groups, maybe it’s 3 to 30 people. It’s the whiteboard, it’s the brown bag lunch, it’s talking over dinner at the summit, and what would it look like to have a creative tool that really embraces and supports that. And if you back into the amount of fidelity, it’s probably this intermediate level that not coincidentally, Muse tends to work with. So I think there’s another way to look at how text blocks and the other features around it can support the type of group creative thinking that we want to see more of. 00:31:29 - Speaker 2: And I’ll make a mental bookmark to do an episode some time on our vision for collaboration. I know you and Leonard have been doing some deep sketching on that just recently here and some exciting ideas shaping up, but I think one of the core constraints that makes it interesting is that point in the spectrum where you’re talking about. I ideation to share with this small group of colleagues and that’s very different from, I don’t know, a presentation you could argue is something that is intended either for a larger audience or maybe you’ve got your keynote deck for your client, you want to press them because everything is super polished. You don’t need to impress your colleagues or hopefully you don’t need to if you have the right kind of team. Instead, what you want to do is really get those amazing ideas flowing. As Nicholas Klein would say, get the creative collaboration going, turn my ideas into our ideas. I think there is a big opportunity with digital tools to allow that to happen for these small teams, but on a remote basis. Now, what are the challenges ahead for trying to bring text into this visual and spatial environment? 00:32:35 - Speaker 1: Well, there are some interesting nitty gritty design issues with text. So one that we’ve been grappling with is text is only sort of spatial. So think about an image, an image definitely has a two dimensional representation. You can make it bigger or smaller, you can translate it, it basically works, where text, it’s really linear and you need to choose some way to wrap it, and by the way, the wrapping might change depending on your font or even your text engine. So we have a little bit of an impedance mismatch between the very visual spatial original conception of muse, where you just to be concrete, you could basically take a picture of your iPad and that’s how you would expect it to render in all cases, versus text which people expect to kind of reflow basically. And so how do you reconcile those two worlds? I’d say that’s basically an open design question for us. We have some ideas. Another related issue is that text, especially small bits of text, they don’t quite map as neatly to the card block idea that we’ve had throughout Muse, because Again, for something like an image or a PDF or a video, it feels sufficiently substantial that you want a card that has a different background, it has borders and so forth, it feels like a distinct item, whereas if you had a one word item on your to do list, for it to be a whole card, it’s like a bit much, which is one of the reasons that I think our current Text implementation feels a little weird in some cases because you have this like basically huge card for one word, just it’s kind of missized, but then you have these new items, I guess we’re calling blocks which are very related to, but they’re not exactly the same as the cards that we’ve had on boards previously, for example, perhaps they’re transparent or translucent. So figuring out how to evolve the mental model and the design interactions to support that is another tricky design problem. 00:34:29 - Speaker 2: Yeah, those are two very significant and concrete ones, and I think it does reflect going back to this symbolic versus spatial. The nature of a diagram, the fact that the circle is next to the arrow is very significant information. That’s important. You can’t put the arrow under the circle and now the same thing will be conveyed, but one value of this one dimensional string of characters is that you can display lots of different ways. The web is very good at this with responsive design. If I open something on the phone, it reflows everything. So that I can read it comfortably in that format, but if I open it on a big wide screen monitor, things look different there. But the text content, if I was to take a screen reader or just read aloud, a particular piece of text content there should come out the same, no matter where it wraps the words, no matter if I have the font size cranked up to make it more legible or something like that. And so now we have this mismatch. 00:35:23 - Speaker 1: And Adam, you also alluded to another big set of challenges with text, which is editing. So there’s two pieces to this. One is, as we introduce these text blocks, you have the issue of text at the block level versus text at the character level. And with a traditional text editor, all the manipulations are done at the character level or they’re basically macros for doing character level manipulations, you know, you double or triple click or whatever it is to select the whole paragraph, but that paragraph is two indices essentially at the character level, right? Whereas we want and use to be able to support manipulations at the block level to be able to reorder whole items. But then sometimes you’re kind of crossing that boundary, like, what if you want to select one whole block and half of the next block and delete it? Does that actually do that or is it like both blocks or just disallow it, you know, that’s the kind of design stuff that we’re grappling with on the text front. And then there’s the whole like actual editing in the sense of adding and removing. Characters, which, as we’ve talked about on the podcast before, is quite difficult on the iPad because people have different input modalities, they might have voice, pencil, touch, or keyboard, and even the keyboard is potentially not as high like throughput as a desktop keyboard for various reasons. So figuring out how to allow effective editing that also embraces the different input modalities that you have with the iPad. 00:36:47 - Speaker 2: Yeah, as we talked about in our iPad episode recently, the multimodal aspect, you’ve got a keyboard, a trackpad, a pencil, your finger, voice input, potentially, or some combination of those, probably you don’t have all of them. You have some subset of those. On one hand is part of what’s exciting about the platform and opens up a lot of new possibilities, but it also makes it trickier in some ways compared to the more known form factor and even posture of the user when you talk about desktop systems. Right. Yeah, I’ve used a folio keyboard for a long time, but I recently picked up the magic keyboard, which is kind of this thing that the tablet sticks to magnetically and has a little trackpad, and then you can pull the tablet off when you want to do tablet mode stuff. It’s really great. I see now why I got good reviews. The price feels disproportionate to me. It costs significantly more than one of the smaller test iPads that I have that I use for QA on Muse, so I’m not sure. that’s really something I’d recommend broadly or even we can expect users to have, but some kind of hardware keyboard is fairly commonplace, whether it’s a simple little Bluetooth keyboard or using a folio keyboard or something more like the magic keyboard, but it does mean you’re in typing mode versus reading, sketching and rumination mode. And maybe that’s OK, but what I found in my own testing of text blocks is that I tend to go into typing mode and I type a whole bunch of stuff, I’m moving them all around the board with my finger, but essentially it’s a bunch of texts, and then I pull the tablet off, grab the pencil, now I’m highlighting, now I’m Rearranging, and I think that works OK, but I would love something a little more fluid moving back and forth, but I think that’s probably out of scope for us. I think that remains an unsolved research problem to be tackled if the tablet’s truly going to become a new kind of creative tool. 00:38:33 - Speaker 1: Yeah, a super important open research problem. It’s not gonna be in scope for us for this iteration, but I do think it’s very important for us to solve it for the iPad if the iPad’s going to realize its full potential, which we know again alluded to in our last episode. I mean, just to give you a couple concrete ideas. I don’t know I’ve even told you about these before. I mean, so maybe this is your first time hearing them, but one thing I would like to see is a tool for much faster and slicker input of voice. So I always has like this voice thing, but it’s kind of slow and it’s laggy, and it’s like, OK, you’re entering voice mode and then you’re exiting, it’s like a whole thing, right? And what I would like is a tool in our toolbar that’s like the red ink or the eraser, where you press your finger down on the iPad, you say two words, take it off, and then you get a text card where your finger was, where you just said, I think of how good that would be for like building a to do list or doing some brainstorming. And another thing I would like to see is, I think the pencil is actually potentially very good for editing text in the sense of cutting it and manipulating around. So you can imagine a sort of exacto knife type tool where you can basically cut the paper, and then you can imagine a finger tool where you can move the cut pieces around, right? And the pencil is actually very good and precise for that, maybe even better than the keyboard. Again, both those, there’s just very little exploration of such input modes on the iPad to date, and it’s kind of a shame, but I do believe we will get there eventually. Maybe it’ll be us, maybe it will be someone else, but I think we need to see that to realize the full potential of text on the iPad. 00:39:59 - Speaker 2: Yeah, I don’t think I’ve heard you mention those ideas before, but I do find both of those exciting partially because there is sort of incomplete or let’s say implementations that exist on the iPad today that hint how those could be good. So in the case of the sort of voice quick input, I do use create a new text card, tap the voice thing, say three words. You wouldn’t want to do anything long form but for more the Post-it style thing, particularly when you don’t even care what the capitalization or punctuation is, and I like it quite a lot. There’s probably a little psychological hump to get over with talking to your computer, but that’s totally a thing you can adapt to, I found. Yeah. But yeah, you’re right, it takes enough tapping and special things to get in there that sort of nullifies the convenience probably. And then similarly with the pencil scribble, which is a feature in iPad OS that essentially allows you to do handwritten input, and we do have a pencil tool for that in Muse that some folks use, but it does have some downsides and challenges, but one thing it does have is the ability to essentially, well, scribble out words to delete them, and that feels great. I really love that. Now in practice, I don’t use that mode. Enough to kind of really that be part of my life, but again, you could imagine seizing on some of those sparks of something that feel good and this fast and precise and expanding on that either in a research context or in product development. Well, I guess that’s how we’re thinking about text overall, so I’m excited to see how this beta evolves. Now we’re trying something not completely new but a little new in the sense that this beta is very rough. It works, but there’s a lot of problems, a lot of quirks, a lot of bugs, but we really wanted to get it out as early as possible to our pro members to try it out and give us input not just on does it work, but how do you see this direction as making sense. Again, coming back to this. This is bringing together text and a visual spatial environment. Is that something really powerful, exciting, new, opens new vistas in your own creative work, or is it a weird uncanny valley where it’s sort of not good enough at text to use much? And so what we’d love is to get you to try it out and yeah, give us your thoughts. We did a version of this once before with what was called the Infinite canvas beta, later became flex boards, and it was similar in the sense that And the infinite canvas work was going to be a huge investment in engineering and design work. I think it ended up taking us something like 3 months of wall clock time to get it all done. So we really wanted to feel a strong sense of product validation, or this is valuable to people, you know, we’re a small team, we have limited resources, we want to make sure we invest them in places they’re gonna be useful, and that worked really well because we gave, I think it was just a test flight kind of beta, but we basically gave this pretty janky prototype. to people, but got this instant powerful response of this is great. I have to have this. This is so much better than what’s there today, even in its rough form, and that gave us both the energy to push forward to the bigger project, but also gave us useful context, things about disorientation and getting lost on bigger boards and stuff like that that fed into the final design. So we’re hoping to do something similar here and actually if this pattern works. Sharing data is pretty early to both validate the direction, but also really get key feedback from people. That’s something I’d like to make a really regular habit of. So yeah, if you’re listening to this in, I guess, summer of 2021, when the beta is still running, yeah, we’d love to have you try it out, try it for your workflows, and give us basically a thumbs up, thumbs down, is this a worthwhile direction. 00:43:34 - Speaker 1: Yeah, and I’ll be looking to see if the text blocks beta passes what I learned as the Wiggins product management test, which is, you suppose the feature is going to be going away and how mad would customers be about that? Would they really fight for it, because it’s easy to say, oh yeah, this is fun, this is nice, but where the rubber hits the road is, we’re thinking about not really adding this to the product and the reaction that you want to see is absolutely not, you know, I’m gonna fight you basically. That’s the level of excitement we’re hoping for, but we’ll see, you know, that’s why we do a beta. 00:44:01 - Speaker 2: Yeah, that’s right. I think it’s important or one of my values product wise is to keep things streamlined, simple, minimal, just what you need, not sprouting a million features, but of course you also have to try a bunch of stuff over time to find the right things, and so having a bit of a willingness to kill your darling. I think is the screenwriting term for this, which is, you might really like the idea, probably you can tell from our voices we’re excited about the direction, but we want to see that it truly adds something worthwhile to the product rather than just, it’s a nice idea, but in practice it doesn’t pan out. Well, let’s wrap it there. Thanks everyone for listening. If you have feedback, write us on Twitter at museAppHQ. We’re on email hello@museapp.com. I mentioned at the beginning, reviews on Apple Podcasts and elsewhere are much appreciated, and I’m looking forward to hearing all your feedback on whether text and muse makes sense. And of course, in general, we’d love to hear your thoughts on the philosophy of text and digital tools and tools for thought and spatial and all those other things. So please tweet at us if you have a reaction. All right, see you next time, Mark. 00:45:09 - Speaker 1: See you, Adam.
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: One thing that really stood out to me reading the original research article was that so many pieces of software I try out, they don’t really feel inspired, doesn’t feel like there was like a real driving passion behind like why this had to come into the world. 00:00:21 - Speaker 2: Hello and welcome to Meta Muse. Muse is software for your iPad that helps you with ideation and problem solving. But this podcast isn’t about Muse, the product, it’s about the company and small team behind it. I’m here today with my colleague Adam Wiggins. Hi, Adam. Hey Mark. And a guest on the show today is Lachlan Campbell. Lachlan, welcome. 00:00:39 - Speaker 1: Hey friends, thank you so much for having me. 00:00:42 - Speaker 2: Today’s show is about the journey of views and products generally from a research lab, an early idea, a private beta all the way through to being a commercially available product. And the way Lachlan fits in there is they were one of the very first uh users to try and really get news. So Lachlan, do you want to introduce yourself briefly in terms of your work and what you do with that club? 00:01:04 - Speaker 1: Yeah, for sure. I describe myself as a web designer developer. My primary creative work is uh designing and building websites, and I also am a student at NYU. I just finished my first year majoring in interactive media arts, which is uh making art with technology, so it’s not coming at it from a technical side, but more coming at it from an art side. And I work at a nonprofit called Hack Club, Hackclub.com. We’re a network of high schooler led coding clubs and high school makers around the world. I started a coding club back when I was in high school and then got involved and I’ve been working with the team for 3 years now, making websites and doing marketing and I my official role is head of storytelling. So I do a lot of open source coding and art making slash political advocacy as well as working at Hat Club and going to college. So it’s, it’s many hats. 00:02:05 - Speaker 3: And I’ll also throw in that you’re a pretty, I would say sophisticated iPad user or maybe passionate one, you have some great posts in your notebook about using the iPad for web development or how to install fonts, things like that. And I think that’s even in our first communication when you basically wrote in to um join the waitlist, you did a pretty long multi-paragraph, maybe multi-page thing about all these different apps you’d use on the iPad for research and so on, which is certainly part of what caught my attention and why you were in that first, that first batch. 00:02:36 - Speaker 1: Yeah, I, I got the original iPad when I was in 3rd grade back in 2010. It just kind of blew my mind downloading an app for the first time. That’s kind of what got me into building software and thinking about computers in the first place, downloading an app on that iPad. I tried to like use my iPad as my primary computer back in 2010 and it did not go very well. But fast forward a few years and then in sixth grade, I started looking into like building iOS apps. And eventually got into web development. Then back in 2017 with the 10.5 inch iPad Pro, I got that and switched to using that for most of my work, most of the day. Over time, then getting the 2018 12.9 inch, I’ve only increased and I use my iPad for the majority of my coding and design work as well as my everyday. I just absolutely love it and it works great for school and I’ve found coding and design setups that work and everything in between. So iPad has been a foundational piece of technology in my life, as well as something I use daily and love. 00:03:45 - Speaker 2: And so to set the stage a little bit, Adam, maybe you can briefly describe the arc of this journey and then we can go into the details and the philosophy behind it. 00:03:51 - Speaker 3: Yeah, this is something I’m pretty passionate about because I’ve been through this whole journey quite a number of times in my career because I’ve been doing this work for quite a while. The Muse origin story is a little different because we started in a research lab, but something I’ve seen in all of these examples throughout my career is this process where you start with something very raw and unfinished, and you’re still trying to figure out if it’s even useful, let alone. Uh, making it work in a lot of different cases on a lot of different devices for a lot of different people and then the slow process by which you bring it to a production ready released product. I think the the way we label those points in the in the story is quite interesting and yeah, it’s going to be fun to talk through the, the history of news, particularly right now where we just came out of beta. 00:04:37 - Speaker 2: So with that arc, Lachlan, maybe you can describe with Adam how you came into the story as one of our very first private Alpha users. 00:04:45 - Speaker 3: I’d I’d be curious to know where you even found out about it. Do you remember? 00:04:49 - Speaker 1: I don’t remember exactly where I found the original link, but I read through the entire uh research page that you made, um, exploring the initial interactions. It just felt like someone had finally answered my silent calls for, oh, a better way of kind of thinking and creating an iPad. Because it feels like so many creative tools lock me into like, I can only use a keyboard, or I can only draw something and then I have either too many tools with all this flexibility that I don’t want, or not enough, and Muse just felt like such a natural extension of thinking with an iPad. That you could just kind of interact with anything, drawing on it, or you could type or you could bring other stuff in. So I remember sending Adam an email with, I think a lot of all caps and exclamation points um that about how excited I was and um describing some of this. Systems I used already, um, like good notes and I writer and tons of shortcuts and other systems, and how I really wanted Muse to fit in. We, we got things started and I’ve been, I’ve been using, using Muse on and off, um, but a lot more recently, over, over the last year. 00:06:05 - Speaker 3: Yeah, well, maybe that design article you referenced was actually a good place to talk about sort of how this started, which was the research lab. We’ve talked about I and Switch on the podcast before, but essentially, I guess it’s true for any kind of product, you know, it starts with an idea that someone has, but we did a much more rigorous process through basically building multiple prototypes, including a thing called Dossier that was on iPad, a thing called Capstone that was on the Chrome uh platform and then because we’re a research lab rather than a commercial entity, we wrote these kind of academic style publications about what we found and actually that Muse design article, I think we had that was just right around the time we decided to start calling it Muse for one thing. Um, and then we were publishing, you know, they have these little videos and the design methodology that went into it, the studio for ideas concept, which was Mark’s Mark’s brainchild, but we were at this point right around the time we published that article, or maybe a little bit after when we started to say, you know, if we’re thinking about which things we’ve built in the lab that have the potential to spin out and become a commercial product, this one seems pretty promising and it was partially the response to that article, including the the. Uh, lovely emails like the one, the one you sent in as well as the talk that Julia gave a little bit later that basically made us say, yeah, we think there’s some potential people are are excited and they see the potential of these weird ideas that we developed in the lab and we tested in like usability tests, but not any real usage. Um, and so that was the, the transition to OK, let’s spin out the separate entity that’s going to be explicitly for profit and it’s not about publishing research, it’s about making a thing that people can use and then potentially buy and notably at that point also, so around the time you emailed in was when we were trying to, we had a kind of a collection of people who had written in based on that article. And we were trying to think, OK, we have this really, really rough prototype, but we want to make sure we give it to the right people who can maybe see the diamond in the rough or have the right use case, or if they’ve certainly if they’ve tried lots of other kind of apps, yet note taking or research or annotation tools and have been a little dissatisfied and they feel like from reading this design article that they have a sense that this This product might potentially fulfill a thing they want because of course we knew it was so rough and so raw and so, you know, so many weird interface ideas or whatever and so many things it doesn’t do, not to mention bugs or, you know, doesn’t doesn’t even work in portrait mode, etc. etc. etc. So we needed the right people to potentially see its, uh, see its potential. So I think at that point when we were making the commercial entity, that’s when I what I is basically what I would call like an MVP, which is minimum viable product in the startup lingo. The idea is, OK, this we can use not just to test research ideas but to give it to people and see this fundamental thing of like, is it useful? And it’s actually hard to ask that question in a way of people, particularly if you have design minded people. That includes you Lackland, but also a lot of other folks that wrote in, they’ll tend to focus on, well, this corner isn’t rounded very well or this animation is glitchy, but at this stage, that stuff doesn’t matter. You can polish that later. What we need to know is, does this thing, is it fundamentally useful and is it useful enough to sell it for a price, uh, that, um, you know, would make the whole thing a sustainable business. Now Mark, I’m curious your your perception of that kind of lab to MVP stage. 00:09:35 - Speaker 2: Yeah, that all lines up with my thinking on that process. I would add another angle to it, which is at each stage you’re trying to validate or de-risk or gain information about something in particular. When you’re in the research lab, what we’re trying to do is convince ourselves that we have some spark of novelty, things like the zooming UI plus mixed Media canvas plus 120 FPS plus Inc everywhere. That felt to us like a spark and we wanted to. pursue it further. So on the next stage, which is like the private alpha or private beta, you’re testing, does this spark go off for people outside the lab who don’t have our contexts. Now, importantly, you can’t quite jump all the way to do you have a product that properly works for everyone. So you have to find a way to test just that core spark. So you end up working with people who are very, you know, excited, they like to test new software, they’re willing to put up with some rough edges. they’re willing to see through, you know, a few months and a few iterations. So for example, when we had this original Private Alpha, I don’t think you could do much import export. I think it crashed a fair amount. Oh, you couldn’t turn it, uh, vertically, like you can only use it in landscape mode if you want to turn your iPad around, too bad. But despite all that, we had, I think, a half dozen people or so who were like, yes, I, I see the promise here. And yes, there’s all these rough edges, but there’s something more. Here and then once you have that, then you go on to the next stage, which is can you consolidate your design into something that fits more into the standard iPad app container. So for example, you can rotate your iPad, you can do import export, but early on, you’re really trying to validate that core spark. 00:10:59 - Speaker 3: I’d be curious to hear your perspective here, Lachlan, which is you read this article, maybe naturally an article like this has these little video clips representing the idea in its purest form, and you’re not seeing those rough edges as much, then you got a chance to try it. Um, and of course, as Mark says before we’d even, I don’t think there was even an action bar, there was no on-screen menu, everything was like how you grip the stylus and all this craziness, how much did the thing you got, you obviously did see a spark with it because you stuck with it, but how much did the thing you got match what you imagined or pictured in your head based on this article? 00:11:33 - Speaker 1: Yeah, I mean, one thing that really stood out to me reading the original research article was that so many pieces of software I try out. They don’t really feel inspired. They feel like a natural result of other forces around them that resulted in these, and then it’s been polished up into use San Francisco and nice rounded corners, and it’s a nice product, ostensibly, but it doesn’t feel like there was like a real driving passion behind like why this had to come into the world. That was a real differentiating factor reading that original research article was that it felt like you were focused. a lot less on rounding the corners and a lot more on like, what is the actual idea here. And it also didn’t feel like you were building a tool to make a tool. I know a lot of people love notion and things like that, but oftentimes I use them, they feel kind of like setting out to build a better tool instead of trying to do something and along the way, feeling like we needed to build something for it. Muse really stood out right from the beginning as feeling very inspired. That spark was amazing. And so yeah, the original version I remember being very rough. It crashed a lot. I, there was no drag and drop, there’s no rotation, there’s no split view, there’s no dark mode, there’s no like hundreds of other features. One day I like lost my pencil for like an hour and so I was just unable to edit any of my notes. 00:12:56 - Speaker 3: Um, yeah, the thing was completely unusable without a pencil, right? You couldn’t even move a card. 00:13:00 - Speaker 1: Yeah, I had to keep like trying to re-grip my pencil at different angles to try and figure out where the hidden gestures lay. Um, so it was definitely a lot of like secret incantations at the beginning, and there was like a frames per second indicator like flashing on screen all the time. It was definitely rough. Um, so it didn’t totally match like what I saw in the article, but it felt like, I mean, one, it felt really special that I was getting to like use such an early version and provide feedback at a time when there was still a long ways to go and making it something real. And it felt like such a special thing to be using that like I could forgive all the all those rough edges. And so I would just email Adam every 2 weeks with a list of like 20 bullet points and like 1500 words of like, here are all the features that I want this week. 00:13:48 - Speaker 3: Lots of enthusiasm, which I really enjoy. We we we fed off of of that for sure and and you’re displaying that now as well, so that’s great. Also plenty of sharp critique, like I hate this, this is terrible kind of kind of thing and that that obviously is really useful as as well. It’s the two together that make make for good feedback. 00:14:07 - Speaker 2: I think this points to another aspect of the arc, which is as you’re annealing a product at the beginning, you’re going to want to have a very high bandwidth customized, personalized relationship with your, you know, 5 users and then as you go to a large scale commercial product, you’re going to want to have mostly self-service, automation, things like that over the course of going from the prototype. To the products were kind of ascending that ladder. So Lachlan, when you first tried the app, like you said, there was no instructions, it was just a blank screen and basically you got in a car, got the email chain with Adam, and he explained everything to you personally and answered all your questions. 00:14:42 - Speaker 3: Uh, fun little anecdote there, we got a rejection the first time we submitted to the app store, and the reason was, when I run the app, it’s a blank white screen and we came back with that’s a feature. 00:14:55 - Speaker 2: Yeah, exactly. Around that time we were doing onboarding. Lachlan, I’m not sure if you had this, but we were getting on video calls with all of our initial customers. 00:15:02 - Speaker 3: Yeah, we did one, I think, part of the both, both the first walk through so I could kind of give a little demo because it just was so incomprehensible otherwise. But then I also wanted to watch kind of over the shoulder, so to speak, it was just like a screen, screencast. Yeah, share screen sharing thing. I wanted to watch someone using for the first time what that discovery process was and where they got tripped up and what things made their eyes light up and that kind of stuff. 00:15:26 - Speaker 2: And we were trying to do a combination of showing our motivation and use cases for the app, showing mechanically how you use it, and then also assessing where the potential customer was like how they use their iPad, or other apps they use, what their use cases are. And then our general MO is to try to do that until we basically start hearing the same thing repeated over and over again, cause when that happens, you’re not gaining any information. So everyone says they want to use their iPad, but there’s nothing that feels right, or they bought an iPad, but they ended up just using it for Netflix and they put it in their drawer. These are, these are stories that we heard constantly. Absolutely. Then you go to sort of the next phase where maybe there’s uh and maybe it’s an email onboarding where we send you some instructions and answer questions, but it’s a little bit less high bandwidth and therefore a little bit more scalable. 00:16:09 - Speaker 3: One note there, Mark, you mentioned um the those early people that um are excited to provide input or Lachlan, as you were saying, like it’s fun to be a part of something early on, even though it’s so rough around the edges or even sometimes painful to use, but it’s fun to know that your your input is going to be high. Um, or your feedback is gonna have a big impact, um, but I, I think this is one of the reasons why these pieces of terminology we use like prototype, MVP, beta, and then I don’t know, general availability release, something like that is important. For so that users or potential customers know what to expect. If it’s a beta product, for example, then you know that it’s still fairly early, but it should work. Whereas if if it is in that right out of the lab, basically just a prototype, you can expect both something fairly raw, but then you have a chance to have that input. Maybe people don’t feel like they have time for that, they’re just looking for a tool to solve their problem. They don’t want to give a bunch of feedback, they just want a thing. And so then they should probably stay away from that, but for others that might be fun or they might have the time for it to have the interest for it. Um, and so I really like if you, if you put the right label on each stage as you come to that stage, it’s a signaling externally so people know how it, how they should engage with that product and also for the team internally to know what what they should be doing again rounding those corners or fixing every la. little edge case bug may not be important when you’re still trying to establish the basic is this thing even useful? Should we even make this? Um, whereas later on when it’s something that you’re selling to people and you’re calling a general ailability product, it’s really important to, you know, do that fine craftsmanship for all those little details. Yeah, absolutely. So what point Mark, would you say that this felt like a sort of fully being a beta? And I’m reminded of the classic um Gmail beta, which I think lasted for 3 years, 4 years or something crazy, they had millions of users, um, and people joked that it wasn’t and it almost became a little bit of a trend because Gmail was so successful. I think people kept that beta label on for a really long time because it somehow seemed cool or something like that. But I think that’s an example of probably labeling it the wrong way. People have the wrong expectations, but I’ve also seen things go the other way, which is actually one of the very first technology products I ever worked on, and we were getting ready to roll out the first release of this, this product, and someone on the team said, oh, we got to call it 3.0 because people don’t trust products unless they’ve been around for a while. And that’s really the tail wagging dog because There, there you’re, you’re, you’re being, I would, I would argue a bit deceptive, but at the very least, you’re not, you’re not setting expectations correctly either for the people that are using the product or for your team internally. Um, so yeah, what, um, at some point I feel like news became a beta and not a research prototype anymore. What, what, what made it that, I guess. 00:18:58 - Speaker 2: Yeah, I think for me that was when We had validated to our satisfaction, the core premise, this mixed media canvas with a zooming UI ink everywhere, fluidity, and that was basically there to stay, we wanted it, our customers wanted it, and we were moving on to the phase of making it a full and complete stable app. So probably the first thing we did there with the with the quote unquote beta is making sure that the data was reliable, so we started to be able to tell people this is an app that you can put real work in and you can have some amount of trust that you’ll keep that data. And then we had to go down a whole list of things that you need to have while you’re in beta to make a real app. Things like it needs to obviously be much more stable and crash less, but also all the fit and finish of being an iOS app, so being able to rotate, being able to split screen, be on drag and drop, iOS shares sheets, and that when we were in the beta, that’s kind of the the stuff that we were working through, as well as I would say, having more of a commitment to making the app more usable to like regular human iPad users. Uh, so this is things like putting some consideration into onboarding and more generally I would say consolidating the design. So when you come out of the lab, you have all these wild ideas and you’ve made all these weird choices, and they don’t all fit together and they don’t fit with the standard iOS model. So when I say consolidate, you need to pick where you’re going to keep your unique choices and then find a way to mesh those with a normal iOS app in the regular ecosystem. 00:20:21 - Speaker 3: That actually makes me think of, I think it was around this time. That we removed the excerpting and wormholes feature. Lachlan, you brought this up right before we were recording that the wormholes were really cool and really quite distinctive feature of um was it in the version that you first used or did you just see it in the design article? 00:20:39 - Speaker 1: I believe I did have it at the beginning, but yeah, and then a few months later I was like, where did those go? I want those back. So yeah, I’m really excited to see what you come up with for a new version of excerpting. 00:20:50 - Speaker 3: Yeah, those are, those are on their way back in we’re working on that now. Um, but it’s actually a good example of something that was one of our weird research ideas, I think would prove quite successful in the. But when we’re in this process of trying to, as Mark says, consolidate the design and there was some technology things around it as well, we realized it was essentially in our way to make the rest of it, the more foundational pieces work well, both in terms of again design but also just the huge amount of code that was devoted to it. And we made the difficult call to remove it temporarily. There were some other things that that um such as the shelf, I think was probably an aversion. Um, that you originally had, which was kind of our, you know, our, our take on split screening, and, you know, we hope that those capabilities might come back, but at some point in a research prototype, you can do try a lot of weird ideas and then once you collide with the real world, so to speak, you need to conform to all these things, be a good IOS citizen and so on, it gets a lot harder to maintain all of those. So we made some selective choices to snip things out, which was, which was difficult at the time, but I, I think it was the right call. 00:21:57 - Speaker 2: Adam, you mentioned being an iOS citizen. For us, a big part of that is navigating the Apple App Store and pricing and testing both of those. 00:22:06 - Speaker 3: Yeah, that was, that was tricky in a lot of ways. I think the assumption normally is if you’re in the App Store, you’re a general availability released product and if you’re on test flight, which is Apple’s system for distributing builds to test users, um, that you’re in beta or still in testing. I feel strongly that the purchasing experience and the price is a part of what the product is. And you need to be to test that just as much as you do the what you would call the core functionality of the app, but unfortunately, the way that Apple’s payment system works is you can’t take live payments unless you’re in the app store. So we went through this little dance here where we basically implemented payments, got the thing in the app store, but very specifically did not distribute. The the App Store link kind of kept that up, not quite a secret, but you’d have to really be looking for it to hunt it down. And then at some point, we switched from inviting people to our test flight beta, which we’ve been doing for a number of months, to inviting them to the App Store version and that had this pricing in there. We were able to use that to get our first customers and essentially ask them questions about What felt fair and what the experience was like and things around this card limit on the trial and stuff like that, as well as just to buy dialogue and what it’s like to get your receipt and what happens if someone wants a refund and all of this kind of stuff. We were able to test all that while we were in the app store, but we were still in beta in the sense that our website says in beta and that’s the way we position it. So now going live is really just pointing more people to the App Store version, and then the test flight beta, uh, will basically won’t won’t ship features there anymore. 00:23:38 - Speaker 2: Yeah, so as we were testing this App Store version, we didn’t at the same time want to require that all of our earliest beta testers who had made a big bet on us be forced to migrate over to the new paid App Store track. So we’ve kept for some time our beta app, our early beta users can continue to use that as is for free, for some time and then at their discretion migrate over. So Lachlan, I’m curious about your experience with the beta versus App Store. 00:24:04 - Speaker 1: Yeah, at the beginning, definitely like for all of 2019, it was not something that I would pay for cause it felt like I’m using this and it’s like putting the data on the edge of a cliff, and like, I don’t know if I’m going to be able to use this in 3 months. It was really exciting to be using, but I definitely didn’t didn’t want to be paying for. Now, I still feel like even though I, I don’t have issues thinking and stuff, it still feels Like putting it in a place where like, I don’t have 100% confidence that like in a decade, I’m still going to have everything. And I think that’s, that’s a really important, like that kind of security is a big part of like paying for a subscription for a work tool is knowing that like, it’s going to be around and it’s not going to go away and the data is going to be corrupted and it’s going to get lost. I haven’t switched over to the App Store version yet. I’m still on the test flight, but planning too soon. And I think we’re really moving into an era, um, I think especially after when they’re sink, um, it’ll really feel like I can fully invest and like fully plant my feet and not be like, have always have one hand on a parachute that’s like, if this all goes wrong, well, there wasn’t anything really important in here, stability, trustability, that’s a lot of what you’re paying for in a released product, even if the feature set is actually all the same. 00:25:17 - Speaker 3: As a particular beta sense that the company is behind it, it’s here for the long term, they’ve done basic things around, I don’t know what backup or data export formats or whatever, um, as well as just the simple fact that what’s that heuristic where, um, maybe you know it offhand, Mark, but there’s a heuristic where you can basically say you can expect that something will be around roughly as long as it has already been around for. Um, and so you can say there’s a piece of software, I don’t know what, you know, email’s been around for 30 years, it’ll probably be around another 30 years, that’s a pretty good guess. Um, and that’s always tricky with a hot new startup or whatever hot new product, you get excited about it, what it’ll do for you, but the reality is it’s just hard to know what the future holds, and even though we’re really trying to make this a Built to last company and a product, built the last product and Mark and I have even written about this in the local first article long now and data the importance of your data integrity and owning your work and all that stuff for makers. The reality is just like, yeah, we have only been doing this, you know, a year, uh, and change since we left the research lab maybe 2. 2.5 years if you count the lab time, um, and so that’s over time it will get easier to justify paying for it and just even aside from that, uh, investing your data into it like you said, counting on it, um, not because something changed fundamentally with the product, but just because it’s been around and things that have been around are easier to trust both companies and products. 00:26:48 - Speaker 2: Yeah, and even though clearly not everyone was ready to jump from a beta type app to a paid app store. Generally available app, we still thought it was important for us to take the leap. We thought the right time to make that was when we felt like we were ready to stand behind the products for the long term, and we felt like we should have a non-zero number of people ready to make that jump, because people are going to be ready at different times because of their different use cases or their different relationships to this type of software. And we wanted to, as soon as Possible, but no sooner validate that there were some people who, when they came in cold to the Muse website, we’re going to be willing to pay $100 a year for the software. And I think it’s a big milestone for us that we’ve gotten to that point. And now we go through the long process of trying to expand the set of people who fall into that group. 00:27:38 - Speaker 3: One place I take inspiration on that a little bit is Uh, things like early access on Steam, or a lot of these Kickstarter campaigns or even Patreon, maybe where when people invest and there’s ways this can go wrong for sure, but often people will pay for something that is still in development or even in the case of a lot of these Kickstarter campaigns are really just a concept, and it blurs the line between investing. In the sense of Investor and purchasing something where I think when you choose to buy an early access on Steam, you’re saying I, I believe in this thing, I want it to exist. I’m willing to kind of proactively fund it, not for what it is today, but what it might be 6 or 12 or 18 months from now and certainly my tendency is to want to wait until something is really good and and. Uh, unequivocally worth whatever the price is, but we pushed ourselves, our team, it was a challenge actually, because I think we’re all craftspeople. We want to have something we feel is just amazingly good, and we pushed ourselves to charge a little earlier than we might have normally, partially because we structured our company in a way that that’s necessary if we want to survive, but partially also because we wanted to have that. Uh, those people that wanted to support us monetarily, there’s certainly the beta testers that gave us great feedback like you Lachlan and many others. We’re very thankful for that. There’s other people who say, well, I don’t have as much time for feedback, but you know, basically I want this product to exist. It’s already fairly useful for me today. I think it will be even better in 6 months or 12 months if you keep working on it. Here’s some money to go do that and I’m certainly very thankful to the folks that have taken that leap, uh, for us already. And then it becomes kind of a a a nice kind of loop or self-fulfilling loop, which is we, we charged maybe even a little before we were really ready to do, but now we really feel motivation and the people that trusted us and gave us that money early on. I really want to live up to what they’ve, what they’re expecting from us. 00:29:32 - Speaker 1: I also have really enjoyed this model with a website called Future Fonts. You can buy a font early on when there’s just like one style or version and it’s still in development by the designer, and so actually I found Hack Club’s font, it’s called Phantom Sands on Future fonts, and we bought it early on when there was like just regular and bold, and then over time they’ve added more and like it allows us to do more with the typography as they add to it. And so it does feel kind of like supporting creators with an idea where they’re not sure if there’s going to be a market for it early on. And I think Kickstarter obviously is is another example of that. I think it’s really exciting and kind of blurs the the line of validation and the traditional like startup MVP model of where validating and selling can be happening at the same time. 00:30:19 - Speaker 3: I hadn’t seen Future fonts before. I’m looking at their site right now. This is, this is amazing. I love this. It is totally steam early access for typefaces, and that fits together well also with, um, I think a lot of typeface designers are just independent people and they’re probably taking time away from there. Client work or whatever to work on this and having to wait until the thing is completely done versus getting support, monetary support from people that like what they’re doing, and then that also means those people presumably get a better voice or input into the evolution of it, and it is a kind of validation of a bunch of people. are interested enough in your work in progress typeface to give you some money for it, then that means you’re probably on to something and maybe you’re more motivated or more just, it’s just more rational to make the leap from, all right, I’m going to turn down that big client project so I can really crank on this thing and get this typeface finished because I think I can, you know, make a good chunk of my living from from this work. So going forward, we’ve got a fully released product that will stand behind and we’re charging money for and we hope to be as useful as possible to as many creators as possible, but we still need feedback. We’re gonna have new features including more radical, you know, there’s some features and capabilities I think that are just obvious and straightforward to implement. We need feedback and we need testing for bugs and whatever, but then there’s also the more, let’s not call them quite research lab wild ideas, but still. Slightly more, um, slightly more high gamble ideas. Mark, what are some of the ideas or what are some of the approaches that we want to use to continue to get this kind of high quality feedback for work in progress stuff while also not disrupting or cluttering people who just want to use the product’s stable features and not be bothered with, you know, they don’t have time to get feedback or interest or whatever. 00:32:04 - Speaker 2: Yeah, one thing we’re doing there is collecting a lot of. Feedback. So we have this feedback feature in the apps we can just quickly pull that up, type some ideas and send us stuff. And that’s relatively low fidelity, but we can pick up patterns there. For example, a lot of people might ask about a smoother ink or being able to add more ink colors, things like that. Um, and I think you complement that with having still some people who you have a deep relationship with. These might be testers who use the app from the very early days and who we’ve maintained correspondence with. It also might be new people that who for whatever reason you you choose to establish a deeper relationship with them and have a video call or have an in-depth email conversation. 00:32:42 - Speaker 3: Yeah, one thing I was thinking about a little bit is you and I together worked on this thing called Haruku Labs. Which we explicitly modeled after Gmail labs, Gmail Labs is a way to kind of go to the settings page inside Gmail and turn on some features, experimental features that they’re they’re working on. So it goes into your real Gmail for lack of a better word, you don’t need to use some separate website or separate product, but it turns on this thing that they don’t offer any guarantees, it might not be around, they might sunset it. It’s not yet, they haven’t yet decided whether they’re gonna make that part of the main. Uh, product, and so we borrowed that idea for Hirou with something called Hiroku Labs, and at least I felt like that was quite successful in terms of making it a lot easier to both experiment with, but also get feedback and real world validation from, from users. I’m curious what your experience was with that or what things you’ve done in other places for that same purpose. 00:33:35 - Speaker 2: Yeah, I think structures like that are really important because the environment that’s conducive to doing early stage validation and shaping is different from the one when you’re polishing an existing product. And when you’re first starting a company, you have that naturally because the whole company is undergoing that metamorphosis from a very early stage company and therefore early stage feature development towards mid-stage company and mid-stage feature development. But then once you’ve reached your first stable point, You want to go back and add more novel risky features, so you need to sort of detach an organizational container that can incubate uh that type of work, and that can look like things like a labs type feature flagging system. I think it can also look like structuring your time as a team, so you might carve out and say for these 4 weeks, we’re going to build a guaranteed to be throwaway prototype that we just try something and see how it works, and you’ve cleanly delineated the experimental new idea from the production app. 00:34:34 - Speaker 3: Lachlan, do you have any thoughts on what you think Muse’s future should be, especially in terms of continuing to experiment and try new things and branch out. We’ve obviously only just gotten started, but now we have this core product that we want to be stable and trustable. What do you think, uh, what do you think that looks like? 00:34:52 - Speaker 1: Yeah, one thing that strikes me, it reminds me a lot of IA writer at the beginning, back in 2010 was like using an app that felt very opinionated and I think that one way that manifests itself is that both apps had no settings, that like there’s no settings pane where you can customize literally anything. I think early on that makes a lot of sense because you can just you can like reduce the number of things that you have to do in cases to accommodate for. And also just like make a very clear statement to users about what this is for, and kind of not fear, like making peace with the fact that it’ll also drive away some people who wish they could change a few things and it makes the app untenable for them. And so, I find one thing in Muse that, you know, Iriter now has several panes of settings, and they’ve kept a very distinctive voice and it’s stayed a very distinctive piece of software and its ideology. And I, I see a similar future playing out for Muse that like by default, it, it has very opinion defaults and some of those things you can’t change. Like, I am glad that I don’t have a full rainbow of 200 colors in Muse to choose from, because that’s one of the reasons I switched to using it instead of an app like Goodotes. And so I think there will be finding a balance of like, well, there are a few settings that just dramatically expand the range of users that want it, while also keeping keeping the distinctive ideology um very present in the app. 00:36:22 - Speaker 3: I like your framing of talking about an opinionated product. I writer is a great inspiration as far as that goes. And if you’re making something truly unique, it comes from with this unique worldview and you and you’re conveying that through the product, then you also need to mesh with the real world and the fact that just different people have different needs and settings pages are one. Example of how that manifests in the real world and so finding a way to both mesh with the real world and accommodate what people need and want is practically, but not losing your soul because fundamentally an opinionated piece of software has something to say. There’s a philosophy, a point of view that it expresses and too much ability to change those things, you might as well just use a different piece of software. So I think that is a very nuanced, tricky balance, um, and it gets harder as time goes on, and you have more users and more customers and they’re asking for this thing and that thing, I got to have this, I got to have that. And you get pulled in that direction by the simple operation of the business, which is as it should be, you need to accommodate the accommodate the practical needs of the real world, but keeping that soul, keeping that fundamental philosophy or opinion alive and adhering to what your reason for existence is, well, I think that’s the ongoing challenge. Well, I think we can probably leave it there then. If any of our listeners out there have feedback, feel free to reach out to us at @museapphq on Twitter or hello at museapp.com by email. We always love to hear your comments and especially ideas for future episodes, and I’m very much looking forward to Muse being a real product out in the world, and Lachlan, thank you so much for your support and enthusiasm and critique and just following along on. Story, it’s really, really motivates me personally. I do this because I want to see makers make things with the tools that I create and nothing, nothing drives me more than both good enthusiasm and good critique. 00:38:16 - Speaker 1: Absolutely. It’s been a joy since the beginning and I still love opening news every time. So thank you so much for having me on the show and bringing me along on this journey.
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: One of the luxuries of industrial research is that you’re not bound to the traditional rigor and neutrality required of academic research or just science in general. We’re allowed to have an opinion. We had a number of people who are reviewing the essay comment, what’s what the feelings, take this feeling section out, it’s not defensible, and I felt like it needed to be addressed, because to me, that’s the most important part. 00:00:30 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for deep work on iPad and Mac. This podcast isn’t about Muse product, it’s about the small team and the big ideas behind it. I’m Adam Wiggins, joined by our guests today, James Lindenbaum. Hey there. And Shimon Kjeski. Hello, both from Ink and Switch. And James, you and I have been colleagues and friends for a pretty long time now, so I happen to know that similar to Muse team member Yula, you are a huge cocktail nerd. Any experiments in that area these days? 00:01:04 - Speaker 1: Oh, there’s always ongoing experiments. Yeah, I recently decided to move to keging cocktails when you have a bunch of guests coming over. I often will batch up a cocktail. So it’s faster to serve, and you can also be really persnickety about, you know, micro adjustments to amounts and things like that and really dial in the recipe, and I decided to move to kegging the cocktails on low pressure nitrogen, so they could be cold and pre-diluted and ready to drink. It’s basically front loading the work so that I don’t have to do much. I can actually hang out with my guests, but there’s always interesting things you learn when you start changing things around like that. 00:01:40 - Speaker 2: And I do feel like the cocktail preparation is part of the experience of being a host or something like that. I guess if you have a lot of people there and then you’re doing nothing but being heads down in your bar, then that’s not really being a very good host, but there also is something to the, yeah, the prep tool, I guess. 00:01:59 - Speaker 1: Well, as you well know, I’m a bit of a perfectionist. I enjoy having the time to really like try to perfect a cocktail, really dial it in. And one of the ones I made recently, I stole from this really awesome bar in San Francisco called Kona Street Market, and there’s this drink called the Banana stand. It’s an Arrested Development reference. 00:02:18 - Speaker 2: It’s the first thing that popped into my mind, always money in the banana stand. 00:02:23 - Speaker 1: And it really blew my mind when I had it, and then I’ve talked to the guys there about it, and then I’ve been just like gradually trying to recreate it on my own and get it dialed in. But I think we’re there, I think we’re close enough to perfection. We’re certainly close enough that you would have made me ship it at this point. 00:02:37 - Speaker 2: It’s a little inside joke there for the listeners, James and I have a long time, let’s call it productive tension, usually productive of, I like to ship stuff, and he likes to make it perfect, and hopefully somewhere in the middle of that is sort of an ideal place to be. And we’d love to hear a little bit about both your backgrounds, maybe Shimon, you can start us out. 00:02:57 - Speaker 3: Yeah, sure. So, for the last 2 years or so, I’ve been principal investigator at GSwitch and occasionally doing consulting research projects. Before that, my background is I’ve been running a small R&D studio and we’ve been basically working on unusual interface problems, things like designing and building the Spola acting engine for European Space Agency or some kind of like interface for exploring machine learning for molecular synthesis. And before that, my background was in actually creative coding. I was doing work on museum art pieces, doing for interactive art, data visualization, stuff like that. What I do also, other than work, I make a little bit of experimental music and various computing projects for fun. 00:03:40 - Speaker 2: Yeah, I feel that the music experiments that you do and performances sometimes, right? Also bleeds into your, yeah, creative coding, artistic interfaces, a little bit. And I think I personally take a lot of inspiration from the prosumer world of like audio gear and the interfaces there that are sort of designed to create art but also intended to be pragmatic, right? You’re doing a performance or something like that and those knobs. You gotta be able to grip it in the right way or whatever, so I feel like you often bring your music world, electronic music world stuff, and you work in I can switch, and I always enjoy that personally, but I’m also a person with a little bit of an electronic music background, so maybe that’s why it appeals to me. 00:04:21 - Speaker 3: Yeah, the word there is definitely a little bit different and interesting, so I know if there are any UI designers listening to this, I encourage you to just browse Pinterest for music stuff. There’s a lot of interesting differences there. 00:04:33 - Speaker 2: And James, you and I have worked together for a very long time, including perhaps most notably in co-founding Hiroku, and we also created the In Code Switch Research Lab together with some other great folks, but maybe you can fill in a little more of the story there. 00:04:48 - Speaker 1: Sure, yeah, well, I have always been, as I like to say, constitutionally unemployable, so I started a number of things over the years, but yeah, most notably was probably Hiroku with you and our other co-founder O Ryan. After that, I found that there were a lot of people coming to me, founders of developer facing companies who, you know, wanted help, and I ended up advising and sitting on boards and whatnot, and eventually starting what is now a venture capital firm called Heavy Bit, which specializes in, you know, developer facing infrastructure kind of stuff. And so I’m still there, I spent a lot of time there, though I’ve kind of worked my way from being a founding full-time partner there to being a more part time. Yeah, and then you and I co-founded the lab and can switch, which is where I spend, let’s say more of my time these days. I’d like to spend all of my time there, but, you know, there’s so many things to do. 00:05:39 - Speaker 2: Well, let’s be honest, when it comes to paying the bills, investing in developer tools companies is probably a better gig than weird research. 00:05:47 - Speaker 1: Yeah, I mean, you know, the path to money is more clear, that’s certainly true. It’s still enjoyable though, there’s so much innovation happening on that front, it’s still intellectually interesting, and there’s a lot of fun stuff happening there, but it certainly feels a lot closer in than the weird stuff we’re doing at the lab. 00:06:04 - Speaker 2: And you both recently published an essay on your latest research project called Ink Base. Of course, I’ll like that in the show notes, but can you give us an overview for folks who haven’t read the essay yet? 00:06:14 - Speaker 1: Sure, yeah. So, in the lab, we have a research track that is all about programmable ink, sort of a combination of doing stuff on tablets, thinking about digital ink, and thinking about end user programming. And this project Inkbase, it was basically the 5th, depending on how you count the 5th project in that track of 8 that we are now that we’re currently working on project number 8. Yeah, in that track, and we’re publishing this essay a little bit out of order because we wanted to take the time and this one to sort of lay a little bit more of the groundwork, sort of define what the problem is, what we’re trying to do. So we spent a little bit more time writing it than some of the write-ups of projects that came subsequently, like Crosscut and Untangle. But yeah, we’re happy to have this out there and have people, you know, start to grok what it is that we’re doing here with this weird program of link stuff. 00:07:05 - Speaker 2: Yeah, so this whole track of end user programming is certainly one that, I mean, you know, that concept is something that even fed into Hiroku. It was something that was a kind of founding idea that we knew we wanted to bring into the lab. The three of us worked on an essay titled End user Programming that kind of touched on a history of that field and some light experiments, some of the first work you had done with the Lapshaman. But part of what I like about this ink-based project specifically is this is taking the idea of sketches and trying to kind of take what do we like about spreadsheets and the rough computation that you can do there kind of on the fly interacting with the document in a way to take advantage of the dynamic medium, but not something that’s writing an app per se. Certainly has much in common with, for example, potluck. We had Maxson. Jeffreon just recently, but they were very focused on OK, classic plain text and the searches, etc. and I feel like this is almost a complete other take on that tablets, stylus, sketching, kind of very loose and informal, but informal and programming are not things that we normally think of as being combinable and indeed it is that for me, at least observing this kind of track of research from the outside in this specific project, it is that tension between the formality of programming. And the systems thinking and so forth that we want from our computational tools and the looseness, sketchiness, I’m just figuring it out, I’m not sure yet, messiness that is part of thinking tools, tools for thought. So I think it’s a very evocative idea to start with and then the resulting project itself, which you can see some videos of in the essay also is only further teases that. 00:08:49 - Speaker 1: Yeah, that’s one of the reasons we like working with digital ink. I mean there’s a number of reasons, but one of them is that it sort of forces you into this sort of sketching, informal, loose, fast and loose kind of mindset, and It just underscores how not fast and loose most of our programming capabilities are. And so it kind of forces us to think about, you know, what are the right affordances, how could we design a system that would let you stay in that sort of frame of mind but still get some of the benefits of a dynamic medium. This sort of weird analogy that was sort of the prompt for the Inkbase project was, you know, we look at spreadsheets and I personally am a huge fan of spreadsheets, as I think many of us are, and I think about the analogy, you know, if you think about spreadsheets as we have them today, as they compare to their analog predecessors, you know, a giant pad of paper and a slide rule or a calculator, it’s not just that modern spreadsheets let you do what you would have done with the analog version a little bit faster, it’s that they actually let you have thoughts you wouldn’t have had. Using the old version, because you can see this dynamic model and you can get intuitive understanding of how it works. You can play what if scenarios, it sparks new ideas. And so, we think, OK, you’ve got the traditional sort of actual spreadsheet, you know, the paper analog version, that is to modern spreadsheets as sketching in a notebook is to Question mark, right? Like, what is the thing that goes in that box? And I don’t feel like we know what it is or have really seen it. And so, Inkbase was sort of a little bit of a study or an experiment around that prompts. Like, what would that thing look like? What would it feel like? What would it be like to be able to work in that spreadsheet like way, but with ink. 00:10:28 - Speaker 2: Now I think a question that might be in the audience’s mind is how this prompt that you just described relates to visual programming, which visual programming is something where, yeah, maybe it’s more accessible to the average person or requires less programmer brain, less symbolic manipulation. Do you see it as related to that world of things or is it its own beast? 00:10:51 - Speaker 3: So I have a little rant. 00:10:53 - Speaker 2: I forgive you that. 00:10:54 - Speaker 3: Yeah, that might be too early in the podcast for a rant, but I don’t think a lot of these projects that people mention as visual program are really visual in the sense that we talk about or we think about, uh, things like, like not to taxonomize the whole field, but there’s things like projection editors, maybe scratch comes to mind where you have blocks of code that just snap together or maybe things like Max MSP for musicians, which is Basically nodes and wires interface. So, these kinds of interfaces. Still require thinking in this very like abstract symbolic way. You just manipulate the code, not in a text buffer, but on a screen, like moving it around in dimensions. What we think about in this thread is more about visual programming as a way of working with like actual embodied objects that you can see on the screen and interact with. So you’re not thinking symbolically, but concretely about the domain, the problem at hand, and this is kind of the thread we’ve been following. So, In a sense, both are visual, you could argue that code in a text box is also visual, but the meaning of visual is kind of different, the way we think about this and the way these sorts of projects think about it. 00:12:05 - Speaker 2: Right, when you think of one of those nodes and wires, kind of visual programming languages or something like Scratch, which I think is a great product for kids to learn to program, it is really about sort of taking a conventional program and making it not text, not pure text, but something that’s a little more gooey, point and clickable. There’s a lot of value to that and there’s many domains where that makes sense, but that does seem like almost a different realm from I have the sketch and I want to bring it to life using the dynamic medium of computation. 00:12:36 - Speaker 1: Yeah, there’s a really important distinction between programming with ink versus programmable ink, right? So, you know, what we’re not trying to do is help you write programs with the use of ink. What we’re trying to do is just use ink, you know, for the properties that ink has, digital ink, but also allow it to be dynamic in the ways that you would expect from, you know, the dynamic digital medium, and so, The programming is not the end, it’s the means to have ink that does more interesting things than just, you know, sit statically on the page. You know, a lot of times we have these amazing devices and we have this pen and all this computational power in the iPad, let’s say, but a lot of the iPad apps that make use of that basically just let you paint pixels on the screen with the pen. And it’s just, there could be so much more there. And that’s a big part of, you know, what we’re thinking about with digital ink in general at the lab, and then with the programmability in particular, you know, what if that ink could respond the way that a spreadsheet does reactively to other things on the canvas, or, you know, what is the nature of digital ink even at all, right? I think that’s a question that we’re still kind of asking ourselves and doing studies around, you know, what if it worked more like string that you could pull around the page, or what if it worked more like paper clips, right? Like a little wire thing. Where you, you drew it, but then it wants to retain its shape. So when you pull on it or bend on it, it tries to retain some of its shape so it preserves a little bit more of the intention or of the movements of the person who made that mark, right? A fun prompt that I like is thinking about digital ink as a byproduct of someone moving their hands. It’s more the moving of their hands that’s interesting and the ink is a byproduct. And if you think about it that way, then you start thinking about totally different kinds of affordances and ways to treat ink. So there’s a whole realm there that we’re kind of thinking about that sort of intersects in this Venn diagram with sort of end user programming and dynamic behavior. 00:14:27 - Speaker 2: I think you already teed up our topic there, which obviously is programmable ink, and I always like to start with definitions. I think we’ve gotten into it a little bit, but yeah, you’ve mentioned digital ink, and I assume here maybe the first thing that comes to mind there is I scribble on an iPad or potentially another tablet and stylus, and yeah, some ink like marks appear on my screen, and that’s it. Is that basically what you mean by digital ink or is there more nuance to it than that? 00:14:56 - Speaker 1: Yeah, I mean, I think that working out that definition is sort of part of the work that we’re doing that, you know, I expect to take a while, so I, I don’t have a crisp answer on that. When I say digital ink, yes, I’m mostly thinking of, you know, the things that appear on the screen when you move a, you know, pen or stylus around on an iPad or a a remarkable or, uh, you know, some kind of device like that. But I think there is this interesting question of, aside from those pixels, you know, what is it really that’s there? What is ink in general and certainly what is the digital version? I think those are really interesting questions. 00:15:29 - Speaker 2: And then, how would you define programmable link? 00:15:33 - Speaker 1: Well, you know, again, I think, or maybe taking a very shallow stab at it with this ink-based essay, but, you know, when we think about programmable objects or dynamic objects, we often think about objects that they have some behavior, you know, they respond in some way, or they change in some way, or they’re able to be changed by some part of the system. And so that’s mostly what we’re thinking about when we think about programmable ink or dynamic ink is just something that is aware of its environment and can be manipulated either by itself or by something else, you know, on the canvas or in that environment, or even by the user. I mean, a lot of ink that you make in these tablet programs are It’s sort of dead, ink, it’s difficult then to pick that ink up and move it around, you know, some will allow you to have selections or drag some things, but even basic things like scaling or deforming ink in a way that’s smart, like a classic example is you draw an arrow from one thing to another in your notebook, and then you wanna move. One of those items around, the arrow doesn’t follow. You then have to manually move the arrow yourself and reposition it and rotate it and scale it. And when you scale that arrow, it scales proportionally, sort of naively, and it no longer looks like an arrow, right? Or it no longer points in the right direction or the arrowhead, you know, isn’t facing the right way or whatever. And so, That’s a very difficult problem to solve from a sort of computer science perspective, from just like a human doing stuff on a screen perspective, it seems crazy that that doesn’t work correctly. And so, we try to look for places where there is that strong sort of dichotomy, where it seems like we’ve just gotten used to something being a certain way, but it actually seems kind of terrible from just a human experience perspective, especially when you get in the context of tools for thought, where I think The tools have a really huge impact on the thoughts that we have and the work that we do, and the output of that work. And so these small differences or small bits of friction, or small biases that the tools create actually are really important. 00:17:31 - Speaker 3: I think it’s hard not to mention McLuhan at this point, right? Like, first we make the tools and then they make us. I think we really believe in this feedback loop of how the things you use impact what you can do. And this is like a hope of being better at sketching, being able to sketch dynamic models. 00:17:48 - Speaker 2: Yeah, maybe one way to think about the, it’s called the current implementation of digital link, of which Muse, you know, counts in with us, but I think it’s something we’ve thought about a bit more than others, probably because I think it’s pretty clear if you’re procreate, you know, you’re a pure art tool and it’s just like you want nice brushes, so you can create a beautiful picture. And maybe if you’re a diagramming tool, it’s really clear that it’s important that your arrows and boxes connect to vertices on the thing, and you don’t want to just like draw a rough circle around something or underline something. But one of my favorite small examples that I certainly hope we’ll implement at some point is the idea if you highlight something with a highlighter, and then you go in and like, type in that text, as the highlight kind of stretch out the way that it would if you had selected the text and, you know, right click, select highlight, something like that. And that does get into the realm of, OK, how much do you want it to like automatically detect what you’re doing and make inferences about it. But if we do think of today’s digital link as mostly being just a direct transliteration of well I could draw on a sketchbook before, now I’ve got an iPad or a remarkable or a Android tablet and that more or less looks like a sketchbook and I can load an app that gives me a blank page that probably looks like a sketchbook and I can draw things and yeah, maybe I have a few more tools for manipulating. I can erase, I can undo, I can select and move things, I can duplicate, that’s nice, but it’s a pretty direct thing, maybe in the same way that the first word processors were essentially just, hey, what if we had a typewriter on this computer thing? And it was only later on that we started to get into much richer things like say hypertext, where you could never, yeah, that concept doesn’t make sense in a tight document, but once you’re in the virtual realm and the dynamic medium of the computer, now you can do more, but you start with that transliteration, and then over time you figure out how it can grow into something that goes beyond its kind of analog roots. 00:19:39 - Speaker 1: Yeah, I mean, I think there’s a lot of shared roots obviously between Muse and this track of work, you know, they have kind of shared roots philosophically and some of the ideas of the lab, and I think one of those big areas is when we talk about tools for thought, I think there are a lot of questions around what is thought work, right? What is thinking, what is thought work, what is the product of thought work. A lot of our current tools today don’t really respect the work product of thought work. You know, just a basic example that I’m always ranting on is browser tabs. One thing that a lot of people spend a lot of time doing these days in the course of thought work or knowledge work is basically curating their own sort of research path, right? Whether you’re researching, you know, a new toaster to buy or doing real serious academic research or whatever. A lot of times it starts in a browser and you click a bunch of links and open a zillion tabs, and then you go through those tabs and you decide, you know, each of these tabs, is it interesting or not, is it? relevant or not, you close some, you leave some open. Maybe you open some additional tabs from links that you see in there. And that is actually work that you’re doing. And then you end up with this sort of browser window full of tabs or multiple windows full of tabs, and that’s your work product. You just spend a bunch of time and used your brain to produce that work product, and you may want to come back to that or do something with it, or pause or whatever, but most of our tooling. With the exception of some interesting, you know, newer experiments, most of our tooling does not respect the placement of those windows or the locations of those tabs or the fact that they’re open or not as your actual work product. And so, it’s treated as ephemeral, it gets lost, it’s very difficult to manage. When we make notes in a notebook, most sort of personal note taking apps treat your notes as like this very important sacred thing that they shouldn’t lose. But to me, they have the same value, the same amount of work has gone into them as, you know, these browser tabs that are open, for example. And so, I think when we start thinking about what is thought work, what is work product, we start to get into these questions of what would tools look like that are more respectful of these different stages of thinking. And to me, you know, rumination, I always thought was an interesting word that was used around a lot of the muse idea, you know, there’s this point where you’ve piled all your stuff, at least for me. I think that there is a point where I’ve kind of gathered all my stuff, laid it all out on the floor, and I just want to stare at it for a while, and just like, move it around with my hands. And that’s a really important step that most people can relate to, but it’s not really supported directly as a first class thing by most tools. That are available today digitally. And I think similarly sketching, not the art version of sketching, like you might do with Procreate, but sketching, as in thinking with your hand, you know, sketching by putting marks on a page, whether it’s words or drawings or doodles, or whatever, that is also, in my opinion, a very under-supported activity. That is a really critical activity. And the earlier you are in the process of having an idea, the more fragile that idea is, and the more sensitive to your tooling. Those ideas are. So, you know, imagine trying to do that thinking type of sketching in a tool like Adobe Illustrator. It’s basically impossible because the interface is designed for this high precision, high fidelity outcome, and so, you just wanna like, stick a box in the corner and keep going, but in order to make that box, you’ve got to select the right tool, you’ve got to decide which kind of box, you gotta decide what kind of corner radius you want. Does it have a drop shadow? By the time you’re done with all of that, You’ve lost, at least for me, maybe this is ADD brain, but I’ve completely lost the idea by then, you know, ideas are like these little wisps that you’re trying to capture quickly before they, you know, dissipate. And so the nature of that tooling is really important. 00:23:09 - Speaker 3: Yeah, I’d like maybe to add two things to this, both kind of tangential. Like one thing that we started talking about, or maybe being able to like vocalize lately at the lab is this idea of the same way we have like napkin math or back of the envelope like mathematics, just figuring out orders of magnitude or something or whatever. And interesting parallel is back of the envelope computation, like how do you make these little interactive things with the same approach of like roughly just hand waving at the thing. And another idea bookmark maybe here is I lost it. 00:23:41 - Speaker 1: So you’re just proving my point. 00:23:45 - Speaker 2: Well, actually one thing I’d love to hear from you, Shimon, is, you know, there’s been a number of projects in this track. thinking base is certainly a very notable one, but you have become pretty accomplished. Obviously you were instrumental in creating the tool, but you also are probably the most accomplished user of these various research tools, you know, prototypes in the world, and indeed you’ve given some good talks including recently. Strange loop where you kind of give live demos or maybe they’re videos, I’m not sure, but in any case, it shows your depthness with these different tools. So I guess I have to just ask like, what does it feel like? What does it feel like to have programmable link at least in this early stage? 00:24:26 - Speaker 3: The phenomenology of to use. It’s kind of maybe hard to describe, right, like. It definitely feels distinctively different to how you approach doing things on your computer. So like, for example, like one thing that comes to mind is an idea we play around with crosscut, like a different paper in the same thread, where we basically create like a little drum machine, just about connecting a couple of dynamic objects together. We have one that moves left to right. We connect the line that says vertical, a box that finds things inside that box and that controls a drum rhythm. So working this way is completely different to how like, Create my own drum machine if I wanted to, which I did a couple of times, which often means I have to turn on my Max MSP or like Python or whatever, figure out what is the correct like MIDI signal to send somewhere, basically switch to this logical thinking, Oh, I will have like 16 steps, so there’s an array that I need to care about now. And this array has values in it and whatever and start thinking about very symbolically. I’m trying to solve versus kind of the tinkering pre-college like approach of the other things we’re doing. And there’s a lot of parallels like that to me where I have a very strong maybe programmer brain because I’ve been doing it for a while where The way you approach solving problems in these tools is totally different. Like, you explicitly tried not to have these things that feel wrong in programming. Like one example often comes to my mind is this spooky action at a distance, where you say, oh, there’s this database over there. It has like an abstract ID. I’m gonna grab that entity. And bound it, whatever, like grab a property from it, and so on. Where in inkbase, you say, oh, this thing the left, make it red. And that feels like very concrete. You can see results of your actions immediately and you also think it is very humane spatial way where like something to the left is much more obvious that ID with like UI ID that has 64 characters or whatever, right? Like there is a different way you use your brain and think about things and that really left a strong impression on me. 00:26:27 - Speaker 2: I think that is somewhat how research works, right? If you were starting with like a really burning pain point to solve in the kind of classic sense, you’d really be starting a commercial product. Whereas research, I think is, at least for me, is driven by a sense of how things can be different. You see the capabilities of the computational medium, particularly maybe emerging new technologies like tablet, you know, low stylus latency as one example that I think was an inspiration for us. And you think about how you would like computers and our computing tools to be, and you see what the potential is with either the way technology is today or the way it’s evolving, and you can kind of extrapolate out and think of some end state. You you’re not really starting with a specific use case, you’re starting with a vision of how things could be, so necessarily use cases do get a little bit kind of backed in there. To me that seems natural. 00:27:21 - Speaker 1: I also think we often have, at least for me, I have a lot of use cases that I want to have a tool like this for, but you need to have a pretty full fledged version of this tool in order to actually carry out that use case and experience it, and we’re quite a long ways from being there, I think. And so, with some of these projects, we’re trying to see how one of these use cases could be implemented. In some of them, it’s really more about the feeling of the tool, and Inkbase is one of those projects. We explicitly said with Ibase. OK, we’re gonna kick the can down the road on, like, what is the right programming model and what is the right interface for doing this programming and all that, and we just want to get to a place where we have dynamic ink that we have programmed, that’s on the screen that we can interact with, just so we can get sort of a little glimpse, a little vignette of that and see what it feels like. And I found the results to be very compelling, but again, these feelings are very sort of subtle and nuanced, and I think important for when you put them in context of the way that the tools you use bias the results, I think the nuanced differences and feelings of tools are really important, but they’re also kind of hard to describe, and we’re kind of grasping at that in this essay, one of the things we’ve started to talk about in the lab when we think about the design of different tools, is sort of the quote unquote natural grain of the tool. And we give a little definition in this essay, we think about how tools, most tools, physical hand tools as well as digital tools, have some sort of natural grain. A way or set of ways that the tool can be used that are easy, fluid, efficient, sort of encourages you to use the tool that way, and then there are ways to use tools that are against that grain. And not that you can’t use them for those things, but they just don’t work super well. Think, you know, using a machete as a screwdriver instead of as a machete, or think using Microsoft Excel to do artwork, you can absolutely do that. It’s just kind of against the grain of the tool, and so a lot of times we ask, what kinds of use, what kinds of feelings do we want to be with the grain? Like, what direction do we want this grain to go? And for example, With sketching and sketchy ideas, and early thoughts, we want the grain to be very much encouraging you to keep thinking and not get distracted with, you know, high fidelity thoughts, you know, is this thing pointing to the other thing? Is my square, you know, a perfect enough square, whatever. Another thing in that bucket in terms of trying to develop a sense of what things feel like we’ve started to talk about, I think this is one of Simon’s originally, is working with the material. Sort of a phrase we talk about, which sort of evokes this. More physical thing you might experience, like, like in art, if you’re working with, let’s say, clay or some medium charcoal, it has a very specific kind of feel, and certain things that it wants you to do and certain things that are difficult to do, and just having your hands on those materials kind of shape the outcome. You kind of just let the material in some ways guide where you’re going. And I think that we found that this ink base has a little bit more of that working with the material feeling, which is what we were going for, where you’re actually It’s sort of like, we talk a lot in the sort of end user programming world about direct manipulation. You know, where you’re working on something directly versus indirectly from some program on the side or whatever. This is sort of a flavor of that, but even more direct, where you’re not only directly touching the thing that you’re trying to manipulate, but you’re actually being influenced by how it feels. And ink, I think, is one of those things where when you interact with it, the way you move it around, the way you create it, you’re having something change color or change shape while you’re drawing on it, and not after you finish your stroke, but live while you’re doing it as a very specific working with the material kind of feel. And it’s hard to put my finger on exactly what that means, or it’s hard for me to describe exactly how your results would be different with that feeling versus another, but it is quite distinct, and it’s something that I personally am drawn to, and it’s something that I like about the real world that I feel is missing in a lot of our digital tools. And so I think part of this is a quest to obtain some of that in the digital realm. 00:31:24 - Speaker 2: I support your quest. The feelings or obviously you used that word a lot, how does it feel or what feeling does it create or what things does it encourage in that direction. You had an interesting aside in the essay titled Research and Feelings, which I’ll just read the first sentence of here. It says, perhaps controversially. At the lab, we believe, seeing what it actually feels like to play with an imagined system is itself a valuable research result and goes on to talk a bit more about that. And actually I think that is an interesting, I don’t know, meta learning or something like that site contrarian insight of the lab and something we were able to do because we’re somewhat unique, not quite academic, not Quite industry position, and I, I think it was Martin Klepp and I feel like was the first one that called out when he first started working with us, which is he said, basically the fact that we are not constrained by the conventional definition of rigor, which is, OK, we user tested this with 10 people, and with this P-value of whatever they were able to complete the task in 2 seconds less. Which is a very good reason science focuses on those kinds of very concrete, measurable, rigorous findings, but I think that misses something huge in the computing tool space. 00:32:40 - Speaker 1: I do think that’s a really interesting aspect of what we do at the lab, and the lab is engaged in what we call industrial research, which, you know, has been talked about a bit before on this podcast, and To me, one of the luxuries of industrial research is that you’re not bound to the traditional sort of rigor and neutrality required of basic or academic research or just science in general. You know, we’re allowed to have an opinion, we’re allowed to chase intuitions, and I, in fact, put that into the essay as sort of a defense or an explanation because We had a number of people who were reviewing the essay for me comment on, you know, what’s what the feelings, like, take this feeling section out, it’s not defensible. And I felt like it needed to be addressed, but I wasn’t going to cut it because to me it’s, that’s the most important part. So I kind of wanted to add a little side note, defending having a research result that says something about feelings. But, you know, I do think that that’s a schism that we often see where in sort of academic circles. Oftentimes it’s about novelty, and if an idea has been described before, then working on it further is not interesting. It’s not an interesting result, and we disagree with that. We think actually taking some idea for how something might feel different or work differently and actually building it and seeing if that is in fact true, is actually valuable. And sometimes we do that and we are compelled by the result and it directs, you know, further research, and sometimes it’s a disaster, and that’s surprising. It doesn’t work and we learn things about why it doesn’t work, and sometimes the results are sort of meh. You know, it’s, we have these great expectations about how this thing could feel different and then we make a thing and then it’s like, yeah, it’s kind of a hassle and it’s really not that much better. And I think all that’s really interesting fodder for understanding the nature of this problem and where we’re headed. I also think conversely, on these sort of more pragmatic sort of startup engineering, product oriented side of the spectrum, people build things all the time, but they often don’t stop to think for long enough about, you know, why they’re building them, or what the nature of those things are, or what the most important aspects of those things should be. You know, it’s sort of in the quest for ever closer to to use. To research, doing what the users are asking for, you kind of start to get away from these first principle kind of based approaches. So at the lab, we’re trying to strike this balance between this sort of overly pragmatic staring at your feet, just doing the next step kind of thing, and this overly, you know, impractical sort of ivory tower pontificating without actually seeing what the results are. We’re trying to be somewhere in the middle. And I think our research hopefully reflects that, and I think our talking about feelings is sort of part of that quest. 00:35:30 - Speaker 3: So if I can expand on this just a little bit, maybe from a different perspective, I think it might be on the metal. I think maybe a common critique of HCI as a field is that you’ll get what you measure kind. So if your focus is on making things that are measurable, there’s a bunch of research that you just won’t do because you, you can’t really measure it. Like I think that’s why a lot of people think that’s the problem with focusing on measuring mouse click speed or like how quickly you can get to a task done or whatever. Which prohibits this very like exploratory programming system kind of style of research, which is very hard to measure because what do you even measure and against what else which has its own problems. The Second thing that comes to mind is we keep research logs as we work at the lab on the mental level, and a lot of things in these projects start with like this specific approach just feels correct or feels right. For example, one of the recent ones in the project we’re on right now were about like measuring angles of things and someone made this example of just making like a little thing that you snap to the angle and that turns into a number that just felt good. That’s why we’re pursuing this further and I think this following feelings at some level is, is kind of correct of like leads to very interesting places, places that academia would go to basically because, yeah, again, how do you measure that? 00:36:49 - Speaker 1: Yeah, I mean, maybe back to this sort of the right tool for the job idea. Most of the things that we’re trying to do with these tools are certainly things that you can do with other tools, right? You can make a sketch a number of ways, you can think a number of ways, you can do calculations a number of ways. It’s more about You know, sort of having the right context, having the right tool, bringing the tool to the problem rather than the problem to the tool, those kinds of things. You know, maybe a concrete example, just yesterday, I was trying to get the square footage of a small space, and I made a sketch of the shape of the space, and then I went around with my Little laser, you know, measure and measured the lengths of all the walls. And I did this as a sketch because it’s very difficult to walk around a room with a computer and then put those numbers in and describe which wall those numbers are associated with. It’s much easier to just write those numbers on a sketch of the shape of the room. And it doesn’t feel right to sit down and open up a graphics program and try to make a perfect version of that room before measuring it. It really feels like a thing that wants to be a sketch on a napkin or whatever. However, once you have done that, I then need to break that shape up into a bunch of squares and calculate the area, and that starts to feel like a spreadsheet problem. Because once I do that, I often, when you measure things in the real world, they often don’t entirely add up. You know, the two segments of the wall on the left side don’t add up to exactly the wall on the right side, and you kind of need to figure out if you made a serious measuring error or if it’s just, you know, the world isn’t perfect. And so, you need to do this math, but then you need to check the math against the other side, and you may need to make some adjustments. It feels very spreadsheet like and that you want the machine to sort of help you check your math versus Pulling out a calculator and doing these things like 30 times. And so now I’m suddenly sitting here with this thing that should be a sketch with some numbers on it, wanting to do a little bit of math, which I want the sort of power of the digital medium for, but my options are basically, I have to set the sketch down and look at it while I open up a spreadsheet and do it in a spreadsheet, sort of disembodied from the sketch where I can’t associate this set of numbers being multiplied with this area on the diagram. Or I’ve got to do it with a calculator, and I don’t get the power of the spreadsheet, and it’s hard to check my math. This isn’t an important problem. It’s not like a thing I can’t solve. It’s not a thing that people don’t solve every single day. You can open up a sketchup, and then you can put all the numbers in there, and it’ll tell you the area, for example, but it just doesn’t feel like the right tool for this job. It feels like you should be able to sketch this thing out on your iPad, walking around with it, and then You know, do that math, and like, draw the boxes on there yourself, and then, you know, do the multiplication and see what it adds up to, and maybe jiggle the drawing a little bit. That’s when you realize that, you know, they don’t add up. And I think having tools like that, it’s hard to imagine exactly what we would do with those things, but I find personally that I have uses, little use cases like that every day. That I would reach for this tool if I had it. And then you start thinking about situated software and the way spreadsheets, one of the things I think is interesting about spreadsheets is that often a piece of software evolves out of that process. So you do that once and then you throw it away, it gets lost in your, you know, Google Drive or whatever, but then you go to do it again, and perhaps you want to, you know, rework some of that logic. An example from my life is batching cocktails, which we we talked about a bit earlier. You know, often when you want to scale up a cocktail, certain things don’t scale linearly and you start doing a bunch of math and you need to convert units, and it’s easier to weigh things than measure volumes when you’re doing large amounts and Blah blah blah. So, you end up building a little spreadsheet to do this thing and you throw it away after you make your cocktail, but then maybe you go to do this again a week later, and it saves you time to open that thing up and duplicate it, and then adjust it for a different cocktail. And then after you’ve done that 2 or 3 times, you might start to say, you know what, this seems to be a thing I keep doing over and over again. Why don’t invest a little bit of time cleaning the spreadsheet up, making it a little bit clearer, making it More, you know, sort of input output driven, so I can just paste in the ingredients and have everything turn out the right way. Maybe I’m going to invest in adding a table that does unit conversions from ounces to, you know, milliliters to weights or whatever, and you eventually end up with this little piece of situated software. And this is a true story from my life. I have this thing, and then a friend sees it, and then they’re like, Oh man, I have the same problem all the time. Will you send me your spread? Sheet so I can start using it. And now we’ve basically made a piece of software. And I think that’s a really important sort of flow that this is something we call gradual enrichment in the lab for lack of a better name, we’re still grasping at what the right name is for this, but this idea that you start out loose and sketchy like you would on a napkin and you end up with a piece of software, and at no point did you sit down to write a piece of software. You just keep incrementally adding little bits of behavior over time. And only as the payoff is obvious. You’re only investing little bits at a time when you’re gonna get an immediate sort of payoff for that investment. And we would like to see that same gradual scale up with sketching, staying right in place where you make that sketch, like having to stop and change tools to throw away the sketch, move to your laptop, open up Illustrator or whatever, that feels very discontinuous. And I would really like to be able to just do this continuous thing. I think the reason this happens in spreadsheets is that you’re doing the whole thing in the spreadsheet in the same place the whole time with the same tooling, and I think you need the same ability. To start with the sketch, stay in that sketch app, stay on that device, indefinitely come back to it in the future, keep adding little bits until you eventually have what is effectively a piece of software that started as a sketch, but all stayed in that one place. And I think, you know, for me, that’s the grand vision that we’re trying to get to eventually, and figuring out what that looks like in each of these steps. It’s sort of the aggregate of the research, right? You know, if we look at the first step, the middle step, the end steps, some of the end steps of this are a little bit more clear, you know, how do you add complex behavior to a big complicated thing already in an app. We know what that looks like. What we don’t know. Is what does it look like at the beginning? You know, we, we, we know you, you start with a blank canvas, you break some marks on there, and then fast forward a year, you’ve got a piece of software running in this canvas app. What’s the dot dot dot in the middle? And I think that’s sort of a set of questions that we’re working on in this track. 00:42:52 - Speaker 2: That very beginning moment with software creation, there’s a lot of ceremony, right? It isn’t, let me first make the sketch and add a computation, for example. And I would say potluck, another project I referenced there earlier, has some of this coming at it from a text angle, but you’re sort of starting with data that you collected or something you’ve written down in some format, and then you’re adding bits of computation to that, and the programming world is really built around the complete opposite flow, which is I am writing a program now and I begin with, I’ll say. new. I’m sure the kids these days have something sexier, but whatever it is, you’re creating the new project in the IDE and you’re initializing it and you’re setting up your unit tests or your models and setting up your database schema and it’s actually quite a while and quite a lot of super abstract programmer things before you get to the point of your specific data and Or specific problem that you’re going to work on. And of course I think is part of the reason we reference spreadsheets so often when talking about end user programming is this really is one of the few cases of successful commercial software or successful kind of end user application where you really don’t start with, I’m going to write a program, you start with, I’m going to enter my data, I’m going to type in a couple of numbers and then you can add computation to that. 00:44:14 - Speaker 3: It’s interesting that you mentioned potluck and not to put words in Jeffrey’s mouth. There’s been some interesting cross pollination from this project and that inba. So historically in based predates potluck and from a couple of conversations I had with Jeffrey, some of the ideas around like spatial matches and thinking about problem in a way where you find things on the canvas in a text document and enhance them with additional dynamic behavior. It’s interesting to see the parallels between these two projects, what I’m trying to articulate maybe. And have the same ideas in the lab keep like appearing in different places. 00:44:47 - Speaker 1: Yeah, potluck is a really interesting project, and certainly all these projects have influenced each other quite a bit. I think one of the most interesting things about potluck is this related problem that you don’t have structured data when you’re starting to do something in one of these tools, whether it’s something like Inkbase or something like potluck, which is based on plain text. Whether you’ve got a bunch of ink marks or a bunch of plain text, the goal with potluck was, you know, to take something that you would otherwise The way you would normally do something, like tracking your, you know, recipes or tracking your workouts or whatever in a plain text file where there’s no fixed format, and you can kind of enter them however you want, and maybe you’re not 100% consistent about the way you enter those things, and you stick little notes in there, use different units, don’t leave the units off some days cause you know what they are. That’s not very acceptable to a program, the way we normally do programming, but you don’t want to have to clean all those things up and normalize them, standardize them in order to be able to do something with them. And same with, there’s this analog in Inkbase where you want to do something like, I don’t know, you wanna attach something to the left side of an object, but if you have like a squiggly mark that you made with the pen, what is the left side, right? You want to align things or snap them together, but, you know, the bounding box and the actual shape of the rectangle that you drew are completely different. You didn’t even close the rectangle, it’s not even a closed polygon, it’s, you know, non-orthogonal, it’s probably not even a quadrilateral, whatever. So, It’s a very similar problem where you need to be able to work with semi-structured data or data that’s sort of evolving slowly from being totally unstructured towards being totally structured. Maybe it never gets to totally structured. And you know, I think the spreadsheet is another example of this where often you start out just throwing numbers in boxes all over the place and it’s kind of a mess. And maybe eventually you kind of Things up into columns and you make sure they’re all the same type or formatted the same way or whatever. But spreadsheets are very tolerant of this semi-structuredness. You know, if you sum a column of numbers in the spreadsheet and one of them is text, it doesn’t break. It doesn’t just break, the whole thing explodes, gives you a bunch of errors. Generally, it just coerces that text into a number or it ignores that. It has some Fault behavior where it still allows you to get an answer. And maybe it shows you that there’s this weird thing happening and you need to go fix it or whatever, but it’s very tolerant of this sort of looseness and this semi-structuredness. And I think that’s one of the interesting things explored with potluck is how do you do computations on a thing where some of your ingredients are structured as ingredients and some of them aren’t, or some of them have units and some of them don’t. And I think there’s a very significant parallel to what we’re doing. In Inkbase, and I think the sort of querying is one of the solutions that we’re both grasping at in Inkbase, you’re doing spatial queries, you know, find this thing to my left, find this thing inside of my bounding box, find this thing that I, it’s overlapping with me, and in potluck, you’re doing a text query, you know, find this thing that looks like this, that, you know, has these letters or whatever, and then you could do something and build on the results of that query. 00:47:40 - Speaker 2: And importantly in both systems, it’s a live query, so this isn’t run a query, look at the results, then iterate. I think you hinted at this earlier, Shimon talking about as you’re drawing and as your dynamic behavior is being applied, so something like turn this checkbox green when I check it. It happens as you’re going, and if there’s a problem with the dynamic behavior, or if there was a problem with your check that it didn’t land inside the box or something like that, you’ll really see that right away. It’s not an iteration process, it’s a just a completely live process. 00:48:15 - Speaker 3: Yes, interestingly, this also opens up a different way of solving problems, right? It’s like, You could fix your program so it catches the check mark a little bit off the side or whatever, or you could just wiggle it and move it into the checkbox because it will turn green as long as it’s like as quickly as it matches or finds the solution or whatever. Like this way of basically seeing responses from the machine as you interact with it, like promotes this different way of solving problems. You don’t always have to think in this very programmary way, you can feel this very like loose, sketchy vibey way where I’m just gonna wiggle some things until the machine does what I, what I wanted to do. 00:48:52 - Speaker 1: Yeah, we have a little saying on that team, just jiggle it a little bit. You know, it’s sort of like the old fix the TV reception by banging on the side. It’s sort of like, uh, just jiggle it a little bit. But it’s a really interesting interaction because, you know, you do a query, let’s say you’re trying to recognize the shape and it doesn’t recognize that shape. You could try to rewrite the recognizer, but you could also just like jiggle that line segment. Little bit, so the path looks a little bit more like what it’s looking for. And now, bam, it gets recognized and the thing starts happening. And this does lead into a way of solving problems. We were just the other day talking about this little sort of geometry problem. It stems from a real world use case where you’ve got like a counter sunk hole and you’re trying to figure out what angle the hole is at, so you can order the right screws with the right angle screw head. And it’s a similar to my example of the area of a floor plan. You sort of draw the thing and take a couple of measurements, but then you need to do some trigonometry to figure out what the angles are. And you’ve now got this sort of semi-structured information where you’ve got a sketch, which is not the scale, and you’ve got some numbers which are correct, and you’ve got to do a calculation, and there’s this question of, you know, different ways to solve that problem. One is to just do some math on the side. Next to this drawing, but another is to actually attach the functions that take, let’s say, the angle, you know, read out the angle of a sketch of a shape, attach those to your sketch, and then manipulate the sketch until the lines are to scale. Basically drag the lines around until the computer says that they are the lengths that you measured. And then you will know that the angle is correct. It’s a very different approach, but it feels very natural, if you’re working sort of with pen in hand, and you’re just kind of working in this sketchy way, and you can sort of just jiggle this around. Or there’s also examples that Simone demonstrated from the Untangle project, where it’s looking for matches against things, and sometimes it doesn’t catch one, and you just kind of jiggle the model a little bit until it does, and then you move on, and it’s just a very interesting way of working. 00:50:44 - Speaker 3: So this is maybe an interesting drawback to when we started talking about feelings, which is a lot of these interesting ways of using these things like are like second order, basically, you have to working in some way, you start interacting with it, and you realize that this is the way to do something in it, which is not a fault I would have one step back, right, without working with the material, working with the concrete thing that feels a certain way. 00:51:09 - Speaker 2: And wasn’t there also a concept in another project in the same research track around the bidirectional connection, that is to say in the sketch example there of like you have a number and you have a line and you want to make the number and the line the same size, and typically in programs you have a one way flow. I rate the HTML and that gets rendered by the browser. I can’t scribble on the screen in my browser and have that get reflected back in the HTML code to take one example. And there’s, I think, a world of bi-directional linking research that I think you folks did some with, and some of the prior argue list for Inkbase as well includes apparatus, now there’s cuddle, which I think was a good example of this of trying to make it so that you have these two ways to represent something, the line and the number, for example, and that you can change either one and they each update each other. 00:52:03 - Speaker 1: Yeah, I think it’s a really interesting way to work, and it feels very natural. Things that only flow one direction feel a little bit strange sometimes. You know, you imagine you draw this little sketch of, let’s say, a triangle, and you write some numbers from your real world measurements on there, you then tell the system this line segment is, you know, 27 units long. Well, what happens, right? Are you asking the system to make that line 27 units long, or are you asking to just leave it alone, but think of it as 27 units long, and then what happens to the other lines on the page? Are you rescaling the drawing based on that line, or are you mixing structured and unstructured data? You know, in spreadsheets, spreadsheets obviously are very one directional in their flow. Things get very confusing if you try to, you know, sum numbers and then change what the sum result is and have that back propagate into the column. But it also can be very powerful, and the number of people have made bidirectional spreadsheets, which are quite interesting to play with. But in this case where you’re associating sort of some freehand work with some numbers or something else structured, it feels very much like they should stay in sync. And you should be able to edit either place. It feels very strange not to be able to change your drawing that you’ve made, or not being able to change the number that you’ve associated with it. So it feels almost necessary for it to be bidirectional in order to not feel like you’re constrained arbitrarily by the tool. But then you get into these interesting questions of, you know, you’re creating error in the system when you change one of those things, and what do you do with it? Do you push it, do you back propagate it to the other side? What does it mean to change a drawing to match some numbers that you put in there? And I think those are really interesting questions, and and even just exploring the affordances, you know, what kinds of UI elements do you want to have on the screen for doing that sort of thing is a really interesting question and a sort of focus of work for us. 00:53:51 - Speaker 3: Yeah, and to add to that, this way of thinking is maybe very foreign to software developers like discovering these techniques or reading about them, like definitely felt very alien at first to me. It definitely feels interesting and more correct to work in this meeting where you have two representations for a thing to be able to manipulate each one of them. The problem is, of course, in the details and this leads to. Some very strange artifacts, a lot of technical problems or things like doing a lot of calculations on these values. Not everything is clearly solvable backwards in a way that feels natural, and then you start thinking about how do I adjust my calculations so the system does the thing that I wanted to do. And at that point, you’re lost doing the abstract symbolic thing again that we want to avoid. So there’s a lot of dials that we need to turn in proper ways for the system to make sense. 00:54:40 - Speaker 1: One of our early projects in this track was called Rectoverse, and it was a relaxation-based constraint solver, and, you know, you’d put things on the canvas and then you’d specify these constraints,
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: There are a lot of other projects that have very similar models to this dynamic land database, but it definitely pushed me to think a lot more in terms of having state exposed by default, ambiently, and the value of being able to make little quick debugging tools that can piggyback on this global state. That was a super influential model on the way I think about programming and the way I think about debugging, this idea of being able to make really lightweight tools or jigs to help myself as I work. 00:00:32 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for deep work on iPad and Mac. This podcast isn’t about used product, it’s about the small team and the big ideas behind it. I’m Adam Wiggins here with my colleague Mark McCrannigan. Hey, Adam. We’re joined today by Omar Rizwan. 00:00:49 - Speaker 1: Hi. 00:00:50 - Speaker 2: And Omar, I understand you have a collection of metro cards. 00:00:56 - Speaker 1: Yeah, I mean, I was just looking at this shelf above my desk, and it turns out I have this giant, basically the only thing on the shelf is this giant plastic pencil case that looks like a giant metro card. And so, I think a lot of people do this, but I’ve just started this habit of just filling it every time I get a metro card or transit card from wherever I go. So now there’s like, I don’t know, there’s a lot, there’s a lot of cards in here. It’s pretty full. 00:01:20 - Speaker 2: So let’s see, what must you have? It’s certainly a Bay Area transit card, and maybe, I don’t know, an Oyster card from London, or what, uh, you know, does this reflect kind of like a travel log of your places you’ve been? 00:01:32 - Speaker 1: Yeah, in a way, it’s kind of a nice, I guess we can connect it to one of the themes, which is that there’s like kind of an object for each place. There’s an octopus card from Hong Kong, there’s a card from Paris. It’s sort of like, instead of entries written down in a book, it’s like I have these like little cards that I can kind of pull out and look at. 00:01:50 - Speaker 2: Nice, and then it’s sort of like, I like the idea of keeping it around because it implies you’re gonna be back, right, that you’re a globe trotting, you know, person of the world, and you never know when you’re gonna need to whip out your Hong Kong transit card. 00:02:06 - Speaker 1: I think there’s also something like comical about the like very large metro card, like very large version of anything. It’s like, uh, you know, a prank we used to do in like middle schools. If people left their laptop unattended, we would just go and make the mouse pointer really big and like not do anything else and just like. 00:02:25 - Speaker 2: And you are an independent researcher with a very diverse set of interests, lots of things that overlap with the niche interests that Mark and I, and I think a lot of the listeners have, including end user computing and embodied computing, file systems, vintage computing, and so forth. But why don’t you give us a little bit of a summary of some of the stuff you’ve worked on over the years and where your interests in the computing world lie. 00:02:51 - Speaker 1: Yeah, I mean, so my background is mostly, you know, in programming, you know, I learned to program very early, and I sort of got interested in, like, new ways to interact with computers. Like, when I was a teenager, there was all this stuff on, like, building your own multi-touch table, and then I kind of got involved with Brett Victor’s work at Dynamicland, but also did a bunch of other different projects, kind of in that space, and just in general, I’ve always been interested in like, Different ways to interact with computing, both like future looking and also historical, like, what are their operating systems that people have done, what are other interfaces that people have done. And so, that’s my background. 00:03:28 - Speaker 2: And I feel like just looking down your portfolio the right way to describe your list of of projects, your research provocations, perhaps they’re quite varied, but they seem to have in many cases a sense of less of a like, here’s a, I don’t know, a library you’re gonna use or an application you’re gonna use and more of a Almost like an art project element of like, let me make you think a little bit here. For example, one kind of near the top, at least at the moment is hijack your feed, and if I’m not mistaken, this was one you did together with uh Jason Yuan, is that right? Yeah, yeah, who we’ve had on the podcast before as well. And yeah, I feel like that’s as much uh asking questions about social media feeds and the place they fill in our life and how we can like take a little more control of our computing world. But then you’ve got, for example, TabFS which mounts the open tabs in your browsers as files and lets you basically do, you know, The kinds of shell programmatic things that you can do with normal files, but with sort of your web browsing kind of history or current open topics. So I’m not sure how much, I mean, maybe I don’t know, Tabafest is in quote unquote production and you have people using it for serious things, but as I look down this list, I feel like they’re more of a, yeah, again, it’s just kind of like art project to make you think and question assumptions about the status quo in computing. Is that a correct conclusion to draw? 00:04:52 - Speaker 1: Yeah, I think that is a lot of them. And that’s also, I think a lot of what I do, you know, on Twitter or in my writing, or whatever, is sort of try to provoke people or come up with these really striking images. And I think, like, I’m often very skeptical when people sort of try to articulate this like philosophy of like what computing should be or, you know, explicit tenets of these are the things we want. I’m much more on the side of like, we should have a few very striking, like, concrete examples of like, things you might want to do, or like, interactions that are possible, and then those will kind of drive people in a certain direction. 00:05:28 - Speaker 2: I think the project of yours that was the first one I ever came across was Screenotate, which is essentially it seems to combine a couple of your interests here, including Provenance and OCR, but essentially it’s a screenshotting tool that makes it very easy to grab the text out. Now I’m not sure how much the latest changes in MacOS and iOS where there’s some of that built into the OS. Well, maybe we’re even inspired by what you did there, but that is well’s product. You can download it, you can pay for it, presumably you’ve been maintaining it for a while, so it’s not pure research in the sense of, and I use it also, you know, all 00:06:04 - Speaker 1: the time, that’s key, like I’ve probably taken 30 or I’ve probably taken like 40,000 screenshots in it, so, wow. Yeah, and I think there is, with a lot of the projects you’ve mentioned, there’s also this theme, and this gets at this idea of folk practices a little bit. There’s this theme of like, this is very vague, but like, connecting different universes in unexpected ways, like this idea of like, there’s your browser and your file system, and you jam them together, or there’s this like social media interface, and there’s this idea of tasks or productivity, and you jam those together, or even the dynamic land stuff, I think, has a little bit of this, like, there’s the objects in your computer and there’s the objects in the real world. You kind of try to Combine those in some way where you can use operations that you are familiar with on one and apply them to the other. And I think that also something that connects really well with people, because you’re sort of familiar with both sides, and so you kind of immediately see the combination of them, and you’re like, oh, this is really cool or really interesting, or like, I can quickly imagine how it would apply, you know, to my life in some useful way. 00:07:06 - Speaker 2: So you have the anchor points of the two things that you’re familiar with, and the novelty or the provocation, or the picture of what could be comes from thinking about how those two would combine. Yeah. So our topic today is folk practices, and this is a term Mark and I use quite a bit here on the podcast and even on our team as we talk about ways to look what people do naturally with existing tools or existing features. In, you know, a product that we or others are building and then sort of extract from that what they’re trying to do and in many cases you can even shape a product or a set of features or an operating system to embrace those folk practices. And I think Screen notate, the project we just mentioned, is one good example of that because the idea that like People sometimes complained, screenshots full of text, this is so annoying. Why not have the core text, you’re spending way more data to represent it, you can’t reflow it or do other things you can do with the text, and to some extent, Folk practices, I think is a saying like, look, screenshots of texts are really here to stay, and there’s a bunch of reasons why that might be, but just empirically, this is a thing people do and they do a lot. And so maybe we should learn from that and find out how to kind of roll with it. Like, if you can’t beat them, join them kind of thing, rather than kind of, you know, basically complain that you’re not doing it right. 00:08:32 - Speaker 1: Right, or at the very least, you might not join them, but at least you should look at it and be like, OK, why do people do this, rather than lecturing people about, you know, you should do this other thing instead. 00:08:43 - Speaker 2: We were at a conference together recently and you did a little demo to the group, and this is called Screen Matcher. Can you tell us about, yep, that one? 00:08:52 - Speaker 1: Yeah, so this is a project that I’ve been working on a little bit this year, and basically the idea is it’s this Daemon, it’s this app that sort of runs in the background of your Mac continuously, and it’s constantly watching your screen, so like the screen on your computer. And so this screen matcher, you can teach it to look for patterns on your screen. It’s like you’re taking a screenshot, like, you drag out a region of your screen, and then you kind of feed that torematcher, and it’ll look for whatever you took a screenshot of from then on. The example I usually give is like, you know, in the corner of every window on your Mac, there’s these traffic lights to like close, minimize, and maximize. And so you can teach Screen Maer to look for that pattern, it’ll find it wherever it sees it. And then you can draw on top of it. So, effectively what that means is you can add like a 4th or 5th button to every window on your computer. But, you know, there’s a lot of other things you can do once you have this kind of continuous screen matching mechanic. Like, you can kind of just like add buttons or draw or scribble on anything on your machine, and have these like automatic behaviors. So the other example I usually give is like, with the screen matcher, you can build like an alarm clock without traditional programming, because what you do is you’d be like, OK. I want to wake up at 7 a.m. tomorrow. So you’d set the clock of your computer into the future. You’d be like, pretend it’s 7 a.m. tomorrow, and then you tell Screen Matcher, hey, when you see this pattern in the top right corner of the screen, when you see it say 7 a.m. I want you to play a sound and wake me up. So there’s this idea of like, you can extend the functionality of your computer in a very natural way, and there’s this idea that you can do things you might normally take like programming or scripting or whatever, just by pointing at your screen. 00:10:25 - Speaker 2: It reminds me a bit, especially that example you gave there of an if this then that or a ZAPA or something like that, which do have this element of automation without real programming, but those really rely on APIs. So you need to have an API integration that that means that the vendor, the creator of whatever the thing is, in this case would be the clock or the operating system or whatever needs to supply an API that you can consume through some probably fairly complicated procedure. And I feel like a hypothesis or a concept that’s embedded in this project and maybe some of your others is to sort of say, well, look, it’s nice to have APIs on things, but realistically the output from computers is pixels on a screen. So if we want to give some kind of end user programming capability, basic automation, rather than trying to browbeat program creators into creating an API, just sort of give up, and maybe give up isn’t the right way to put it, embrace that folk practice or embrace that reality that That GUI interface exists and by the way, computer vision is really good now, and so something like recognizing the widgets in the corner of your window or a clock value is actually relatively straightforward, so therefore maybe that should or could be the sort of an everyday API. 00:11:45 - Speaker 1: Yeah, I think that’s right, that there’s this, instead of this closed world of whatever is available via API you have this open world, much like when you take a screenshot, you know, you can take a screenshot not just of things that are selectable text, but if anything on your screen. Similarly here, you know, you can automate based on anything on your screen, not just things that happen to be an API. But I think there’s also kind of like an interaction argument for this, which is that Even if you have all the APIs available from the end user point of view, it’s like, OK, I want to do this automation. I guess I have to like read the, like, dictionary of APIs and like figure out what the right APIs are, or if they’re even available, I have to figure out like what kind of input and output they take, and that it’s always felt to me like very disconnected from the actual experience of using the computer. Like, you know, if I want to make an alarm clock, why can’t I like point at the actual clock on my screen, instead of figuring out that there’s a clock API that’s like based on the same source as the clock on the screen. Like, it feels like you should be able to point at the actual things that you’re already familiar with, instead of having some like API dictionary that’s completely separate, that feels like this like skeleton of the app. 00:12:50 - Speaker 3: Yeah, I really like it. And Omar, so the idea with Screen Matcher that you can both sort of scrape the screen for input, but then also do, I guess you would call output of typing things and clicking things, moving the mouse around. 00:13:03 - Speaker 1: I think so. You know, the current prototype, basically what you can do is you can just add but so you like can search for a pattern and then you can be like, every time you see this pattern, I want you to draw these extra scribbles next to it, and then when I click one of these scribbles, I want you to run a bash command. I see, I see, but I think it’s very easy to imagine being able to have other responses. To seeing things on the screen, whether that’s like playing a sound. I mean, someone proposed to me that you should have all the effects happen by drawing stuff on the screen and then Screen Matcher would like match those things and do the effect directly. Uh, I don’t I don’t know if that makes sense, but it has like a very nice, like, kind of aesthetic elegance to it. 00:13:40 - Speaker 3: Yeah, I also kind of like the baseline of anything that you can do as a human, whether that’s things you can see or inputs you can do with the keyboard or the mouse, you can script. Yeah, that seems like a reasonable invariant. Yeah. And as far as that’s a floor on automation, so no matter how hard the programmers try to deny you the ability to have agency over your own environment, you can’t take away my eyes and my hands. And therefore, if I can control those things, you know, basically I have scriptability of them. 00:14:08 - Speaker 1: Right, right. You could imagine if you wanted something that could deal with keyboard shortcuts, like, let’s say every time I hit like control 9, I want the computer to send an email or something. You can imagine a plug-in that actually maps your keyboard into like a larger like screen space. So you have your actual screen, but you can imagine you have a bigger virtual screen and you like map your keyboard into it, and there’s like a virtual keyboard on the virtual screen that lights up when you have keys. And so you can sort of imagine mapping any sensor or actuator if you go the other way. Into screen space, and that would kind of make this like an entire programming system in a sense, cause you’d be able to address any kind of IO which, again, I don’t know if that’s useful, but it’s kind of like a cute idea, and I think this is like an interesting programming model, and it is in some ways a lot clearer than traditional programming, because like, if it goes wrong, you’re like, OK, it didn’t match the right things, like, that’s why it didn’t work. 00:14:57 - Speaker 2: Well, well, almost by definition, everything is what you are seeing, the computer is also seeing, and then what you are responding to that with by yeah, drawing something else or playing a sound or something like that. I mean, that’s one of the things that makes programming so incredibly difficult. It’s obviously very abstract, but the connection between the set of symbols and the thing that’s actually gonna happen as a result of it is so disconnected, and that’s what makes kind of professional programming, professional software engineering. Particularly really complex systems, you just have to model so much of what the computer is doing in your mind, that’s almost the hard part of it as opposed to just expressing concepts and symbols, for example, right? 00:15:37 - Speaker 1: And here, I think you sort of by default, get this ambient awareness of what the computer is doing. Which I think is something that’s also true of dynamically to some extent. I mean, I think that’s something that’s true of a lot of interesting programming systems, is like, you don’t have to go in and like, inspect what the computer is doing because your program didn’t work. You just like, look at the screen and you’re like, oh, that’s why that didn’t work, even though it may be a little wasteful from a sort of traditional programming point of view to be running all this state through the screen. 00:16:03 - Speaker 2: Mark, your earlier point about they can’t take away your eyes and your hands reminded me of another dimension of folk practice, which is what’s usually referred to as the analog hole when you’re talking about DRM digital rights management, where, OK, we’re going to give you this music, you can download this music and listen to it, but you can’t copy it, for example, but in the end, you can always basically just like take a recording device and hold it up to the speaker, and that’s the analog hole that no matter what you do with the computer. And screenshots are, I think, an even more pervasive and useful version of that. It actually happened to me just the other day. I think someone sent me a PDF maybe a financial document. I can’t remember what, but I need to copy paste something small out of it and I don’t know, the PDF you or said something like, oh, you have to have the master password to unlock the whatever to copy paste, and I’m like, cool, man. And then, you know, took a screenshot and immediately use the OCR to just like copy paste it out, right? There’s a version of this in the Kindle app and whatever, and they’re just working so hard at it, but like in the end, it’s like I’m looking at the words on my screen. In a really worst case scenario, I could just manually type them out if I wanted to. And so it feels like a lack of acknowledgement of the reality of I’m looking at it and part of what my computer can do is manipulate images. So how in the world are you really going to stop me or anyone else? It feels like a weird denial of reality. Now talking about the debugging visibility that you might get from, for example, an on-screen keyboard or just the fact that all of these things are flowing in the, let’s say the concept that’s suggested by this project that you sort of see everything and that visibility is going to make it more approachable and more comprehensible to sort of non-professional software engineers. I noticed one of the notes or prompts you put into our little shared notes document here was whether visual programming was overrated. I feel like those are related. The appeal of visual programming is if you can see everything, it becomes more approachable and more comprehensible, but it seems like you have some feelings on that subject. 00:18:09 - Speaker 1: You know, I think there is a notion of visual programming, which is like, you put together blocks on the screen, or like boxes and wires, and I think this like, Uh, especially blocks, I think that like doesn’t really have that much to do with the kind of visual programming that’s suggested by the screen matcher, because in the Srematcher, the visual things are actually the data, you know, you’re like, these are the patterns that the system is matching, and then these are the things I want you to produce. Whereas in block-based visual programming, the visual elements are like actually like if statements and for loops and stuff like that. It’s actually like not normal programming. But I think they’re actually fairly different in the model of what is visual. And I think it’s a very easy thing to fall into that like, there’s a lot of people who don’t like normal programming with a text editor and a compiler and whatever, but that doesn’t mean that they all have the same conception of what programming. It should be. Like I think there are actually many different ideas that are not necessarily compatible, and I think you know, visual programming is maybe too broad, at least it’s maybe too broad a category to be useful, and we should talk more specifically about what kind of visual representation you want for programs. And I think the other criticisms of visual programming that I think about a lot are One, it’s just like really annoying to manipulate visual elements on your screen with a mouse, compared to manipulating text for the keyboard. Like, you have this sort of bottleneck of like, oh, I have to drag things one at a time, I have to select things from a toolbox. I think this is part of the appeal of the dynamic lens stuff is it’s much, much easier to manipulate things on a table than it is to manipulate individual items on your screen. That might be better on an iPad or a multi-touch display. I think there’s like a lot of interesting work that somebody could do there, but I think that is actually a very serious problem, and I still don’t see it talked about enough, that it’s just like the ergonomics of visual programming are not that great compared to the ergonomics of text, on like current computing hardware. 00:20:03 - Speaker 3: Yeah, and I think the typical use of quote unquote visual programming tends to conflate a few different things. One is using the visual medium for high bandwidth feedback, which I actually think is really good. I’ll return to that. But another is it kind of forces programs to be structurally correct often, you know, the visual programming blocks, like you can only put the circle inside the circle and stuff like that. But then it also necessarily enforces the sort of 2D program, which is very limiting, usually catastrophically so. So I think some of those things are better than others, and also you can get some of them without going to a, what we typically think of as a full blown visual programming. So for example, the idea of things being visible, taking advantage of the enormous bandwidth that you get over the visual channel, I think that’s great. I use it all the time and you can use it without using one of these typical visual programming language and actually leads me to a couple of my favorite folk practices. I know, a very simple one, but a super common one is just print after debugging, you know, it’s like dumping a huge amount of visual information from your regular program. Another is this idea of shelves or scratch space and the related idea of lightweight copies. So an extremely common pattern that we see with great professionals is they’re working on something like a design for a web page. And they want to explore a branch, you know, a variant, and the proper programming way to do that is like get branch and so on. What people actually do is they select it all and they copy it and they paste it, you know, next to it, and they go fiddle with that. And if it works well, they delete the old thing and if it doesn’t work, they delete the new thing, and they’re off. That’s a very lightweight branching, but critically, you have both of them visible and it’s not like implicit in this really weird like get graph thing. 00:21:44 - Speaker 1: Right, right, like that’s another bottleneck cause like your git raff can only point at one thing at a time, and it’s hard to do comparisons unless you go into like comparison mode. Yeah, I mean, like, with your example of like high bandwidth visual information, I’m constantly like, oh, I wish I could print off like a graph this graph of the state of my program. And there are people on Twitter who do this regularly and have a good practice. But like, is that visual programming? I mean, it’s not like normal, you know, text programming with like string print off, but it’s also not block-based programming. Like, it’s somewhere in the middle, and I think there are a lot of things that are in that space of like, you can’t do it on a traditional. You know, stack where you’re running in a terminal, run your compiler, running your program, but it’s also not like you threw all that stuff out and you have this sort of your dragging and dropping workflow. 00:22:32 - Speaker 2: Wulf and Julia to the engineers on our team recently were debugging a pretty complex, essentially there’s an in-memory graph structure that’s used and things were getting complicated once we added linked cards within the app and they ended up dumping it out, I think, to JSON and then there’s a tool I say it’s called Mermaid maybe that does a nice diagram visualization, and it was actually like fun to look at. It was really interesting. Usually when you watch someone debugging, it’s like picking through these like monospace font logs and scrolling through the IDE but these visualizations were compelling and easier to understand, maybe for someone who is not someone deep in the problem space, like they were. So, yeah, there’s a lot to be said for that. I will point listeners to the classic Meta Muse episode with Maggie Appleton, where we talked about visual programming, and she makes this exact point that that is a label that is very broad. It covers a lot of things. There’s some good taxonomies, but her basic concept for it, an argument for visual programming is a thing to explore more is you start From hey, how do we make the whole program out of, I don’t know, boxing and arrows, but you start from how do we just make more visual parts of programs we already have today, things like the DOM Inspector and the browser is one possible example, and you could imagine those as we get better and better at visualizing both running programs and at rest programs and code paths and Get branches and whatever else that there’s an accumulation of making a more accessible programming environment because it’s more visible and more tangible and can be interpreted in different ways other than just reading the code, it’s sort of mentally running it in your head and that for her is kind of the argument for visual programming. 00:24:14 - Speaker 3: This is making me wonder if there’s powerful primitives we could add to help with. Leveraging the visual channel for debugging. So, OK, it seems obvious, but actually having the standard of a single stream of MySpace font logs is huge. We can’t take that for granted, but we would be totally down in the water if we didn’t have that as programmers, right? But you can also imagine some other really simple basic printers that could help a lot. So one would be in the browser environment, you get this thing where if you log like JSON or a JavaScript object. It sort of gives you a nice rendering of it where it automatically expands or contracts when you click it and it kind of pretty prints the stuff and it highlights it with different colors. 00:24:55 - Speaker 1: Right, it doesn’t flood your console if it’s a giant object, like things like that that make it, yeah. 00:25:00 - Speaker 3: And often in web-based environments, there’s this pattern of like, you basically use a web page or a piece of the web page as the debugging panel, and you have HTML and CSS and I almost wonder if that could be almost like a standard, like in the same way that you have the log output, you have a little HTML page output and it has to be like HTML and CSS, but then you could write your own little debugging panels with like heat maps and graphs and stuff like that. I don’t know. 00:25:26 - Speaker 1: Yeah, I mean, I’ve played with things like, you can actually console log like a bitmap image, and so you can do these really twisted things where you like render something and then like, console log it out, and even that, you know, can be very useful depending on what domain you’re working with. Like, if you have some domain object that’s like you have like a graph or a map or whatever, and you want to see that or like compare different instances of it, if you like log a bunch of sequence, that can be very, very useful, I think. I would also say, and I think this gets at the point you’re making also, that I think another probably unheralded issue with this whole space of visual programming, visual debugging, it’s just it’s just like very, very hard engineering. It’s like you have to reinvent a lot of stuff that you get for free if you’re using normal text, if you want to do visual stuff, you have to invent your own editors, you have to invent your own consoles, you have to come up with interactions that work, you have to make sure they can post correctly, it’s like quite hard. 00:26:20 - Speaker 3: Yeah, and it feels like there could be a little bit of an easier layer there. One example I’ll give is, I’ve often wanted to have terminal output that was in the, what’s it called, in cursive style. That means that instead of each line coming one after the other and scrolling, sort of replaces the screen as if you’re using a command line program. But oh my goodness, that’s a whole ordeal in a lot of languages. Like you’re looking at these weird libraries and you’re admitting these like crazy control characters and it’s a whole mess. It feels like it could be a lot easier. 00:26:46 - Speaker 1: Yeah, and I think about that. I thought about that specific example before too, where I think the nature of terminal output where you’re like logging one line at a time, it’s like, if you have a program like a game engine or like a web browser or something that’s live, that’s interactive. And your console logging, like, you just end up with this flood of console locks, right? Like, a lot of the time, the logging model you actually want is to see this live view of whatever the variables in the system are, and then they just like update immediately, rather than this sort of log that just like will spill out because you’re running at 30 frames per second, or 60 frames per second, or whatever. And I think the terminal makes it really hard, like, you have to do a lot of extra work to get to that point, just cause the model is not really compatible with interactive programs. 00:27:27 - Speaker 2: One term we’ve touched on here a couple of times and I think is known to the audience of the podcast here’s end user programming, but Omar would be very curious to hear what does that mean to you or what’s interesting about that space. So I think the audience here has heard Mark and I and our take on it, but I’m guessing you have a different perspective. 00:27:46 - Speaker 1: Yeah, it’s funny cause I was kind of asking this question on Twitter a few months ago. There’s something I think a lot of people are very attracted to about the idea of end user program, like, it’s almost this like charismatic concept of like, oh if only end users could program their computers. I mean, I think in a sense, everything end users do on the computer is end user programming, like programming is sort of an artificial concept, right? Like, if you’re using Microsoft Word or Microsoft Excel or PowerPoint, like these are all kind of like subsets of programming in a sense. And so it’s, it’s one way to think about it is is it’s just a question of like giving even more agency to the computer user um uh than they have right now. I mean, I mean, I think part of my Thoughts about this come from this dynamic land context where I think, like end user programming was very deeply built into the system. Like the idea is if you showed up at a dynamic land, a lot of the way in which you use the system is by programming it. And so, you know, if you had a community of people built around a dynamic land, they would all know how to program in the same way that we all know how to read and write. Some of that comes from the technical architecture of the system, but I think some of it would also just come from the social expectations. Like, it’s not particularly easy to learn how to read or write, but we do it because it’s useful to operate in the society that we live in. And I think part of the premise of dynamic plan was that you would kind of construct a context in which that was true for programming. 00:29:07 - Speaker 2: Maybe it would be worth taking a sidebar here to talk about dynamic land for a minute. I know that’s a topic of interest to a lot of our audience. I know you were there for a while. I think it was a pretty formative experience in your career to date. Maybe you could briefly just tell us for those that don’t know what is that and what did you do there and what were the kind of core concepts. 00:29:26 - Speaker 1: Sure, so this was or is research lab started by Brett Victor in Oakland, California. Basically, the idea of dynamic Lane was to build this physical computer, where, like, there was literally a room or an office that was the dynamic lab, and you would show up. And you would have these pieces of paper, and each piece of paper was basically a computer program. And the idea is you would have a computer where you interact with the computer by manipulating real objects like pieces of paper or eventually like cups or like handwriting or like things that actually exist in the real world, rather than having, you know, current computers where you have a screen or a mouse or keyboard or a touch screen. So you have this completely different mode of interacting with the computer. And I think importantly, it’s, this is a programmable computer. So not only do you use the computer. By moving real objects around, by manipulating objects, by pointing objects at each other. You also program the computer in this way. So you could actually do almost everything you wanted to, you could build software systems without needing to bring your laptop, without needing to bring your smartphone. So it’s this completely kind of self-contained end to end system in which you could do computational work. 00:30:34 - Speaker 2: And notably, I think everybody in the room is kind of in the same computer, if you do have a, I don’t know, a hackathon and everyone brings their laptop, they have their own. Discrete systems and I guess we’re all connected to the internet or you could connect to a shared server or something like that, but here if the room is the computer and we’re all in it moving the elements of that computational environment around where we’re all participating in the same computing environment. Do I understand that correctly? 00:31:02 - Speaker 1: That’s right. So basically, well, number one, there’s the physical element of like, you could see what other people are doing and kind of like go over their shoulder or work with them in that way, but there is also If you and I were around the table programming, each programming our things, there would be shared memory between our programs. So we could kind of insert things or respond to things in the same sort of room scale database. 00:31:22 - Speaker 2: And what were some of your either contributions on that project or maybe takeaways, especially now if you’re on the other things like, what were some of the core ideas that you carried with you? 00:31:33 - Speaker 1: Yeah, I mean, I think this idea of programmability is very, very important, and I think that’s something that’s missing in a lot of other physical computing work, whether it’s ARVR or also projection mapped or a lot of that kind of stuff, I think is from more of a traditional HCI uh or game development or whatever perspective. Like, in some ways, the dynamic line system was less advanced, you know, in any particular respect, like, less advanced in computer vision, less advanced programming languages, but like combined, it was a novel system because you could program that, and because it was a platform on which you could do lots of different physical computing stuff. So I think the program melody is uh is very important. I think that the sort of dynamic database architecture was really interesting and hasn’t been written about that much. It actually has a lot of close Relatives and I think a lot of what people are trying to do now with state management on the web or uh with distributed systems. There are a lot of other projects that I think have very similar models to this dynamic land database, but it definitely pushed me to think a lot more in terms of having state exposed by default, ambiently, kind of like in the screen matcher, and the value of being able to make like little quick debugging tools that can piggyback on these global state. So, you know, if you’re writing a program in dynamic, and it’s an idiomatic program, you would not use like variables and functions. You would kind of run everything through this database. And so, other programs could also respond to the state of your program just by querying the database, and everything would react live. So that was like a super influential model on the way I think about programming, and the way I think about debugging this idea of being able to make really lightweight tools or jigs to help myself as I work. And this idea of the value of like ambient state by default. 00:33:19 - Speaker 2: Jigs and visual ambient state, both of those concepts where I could see the thread into something like screen matcher even though that’s on the screen, because one takeaway you could have from the, I think it’s what we usually talk about as embodied computing, physical objects, you’re interacting with the physical world, you’re getting away from the glowing rectangles that Fundamentally are the core part of the computing experience that we all know and mostly love, and instead replacing that with something that’s more physical and in the world and humane, as Brad Victor puts it in one of his talks. But maybe for you, the takeaway was less the embodied computing and more some of those things like ambient. Visualization of state or programmability or you also have interest in the embodied computing, I think in some of your RFID work so I don’t know, maybe you’re just sort of following those threads in different projects. 00:34:11 - Speaker 1: Yeah, so the RFID work, we’re just getting underway, but we’re excited about that. I mean, I think there are a lot of directions. Like, I think this is a huge open space, and that was also one of the takeaways is that there’s just a lot to do, and there are a lot of problems with the dynamic client system, and there are a lot of areas where I think we were technically constrained, where I think there’s a lot of interesting things to do. And so I think the RFID stuff is kind of getting at that in some ways. 00:34:36 - Speaker 3: Yeah, and that reminds me of something that I thought was really important about Dynamic land, and this relates to the end user programming discussion. When people talk about end user programming, they usually focus on how you program. Now, here’s the IDE, here’s the programming language, here’s how you debug. What people care a lot more about is what you’re programming. And everyone cares about their physical environment. So that alone like almost immediately makes dynamic land. A huge win. And I remember, I walked into the room and just had this sudden urge to start programming stuff. You know, I want, you know, when this door opens and I want when this light turns on, I want to do this and that. It was a very natural urge. And by the way, one of the emerging end user programming use cases like the, the smart home, automated home, again, it’s because people care about certain things. And if you look at the history of successful end user programming environments, Unix, spreadsheets, SQL, MySpace, game scripting. A, these are all environments that people have absolutely fanatical interest about. It’s basically the center of their lives or one of the most important things in their lives, and B, it is an enormous pain to program these. You think about SQL, for example, like you’re going to send a single string to your production database that, you know, who knows what it does and It’s gonna give you back a result or like spreadsheets where entire pillars of the financial economy are contained in like a 500 character formula in a single cell, highly questionable, you know, programming language design, but people get through it because they really care about the data. 00:36:04 - Speaker 1: Yeah, I mean this is one of the lessons, and if you talk to Maggie, this is one of the lessons in the Bonnie Nardi book where she does like ethnography of end user programming. It it’s like, yeah, you know, Excel, it just has these formulas which are just like this, you know, it’s literally a text-based syntax that you type in, like, people will learn it because they want to learn it, like, and so this is also maybe another sense in which the visual programming is not quite, at least it’s not like the only thing you need, where it’s like, yeah, you can make it as easy as you want, but like people are willing to learn, even if it’s really hard in the same way, you know, people are willing to learn to rewrite or whatever. Like, if there’s value in it, I think people will be willing to learn it, even if it’s not, you know, pedagogically like the best thing ever. 00:36:42 - Speaker 3: This does to my mind imply a sort of lesson to aspiring end user programming environment designers, which you got to start with the environment, I think it’s so tempting to start with. I want to design a new end user programming language or IDE. It’s just, it’s really hard to get traction beyond like the educational and academic use case, but if you find something or create something. That people want to program. OK, OK, here’s an example. Minecraft. The way you program Minecraft is like you place these little blocks around in 3D space, and then you make your character walk around and poke them, like what? But it’s one of the most important programming languages in the world right now because people love that stuff, right? So you got to create an environment that people care about. Mhm. 00:37:20 - Speaker 2: Another one I like to point to is an end user programming success is Flash, because it did start from this kind of animator use case. You start from these animations and then you kind of use the dynamic medium of computing, and you go from static animations and something that become sort of games or full programs. Omar, I noticed you had some thoughts on software as a cultural thing, perhaps connected to that programming environment. 00:37:47 - Speaker 1: Yeah, well, first I think something that’s interesting about Flash and about Excel is this idea that like, it’s a useful system, even if you don’t get into the programming part, you know, like in Excel, you can just like write a list, and that’s a useful thing. Like, you don’t have to write formulas to feel like you’re being effective with Excel. And in fact, if you do want to write formulas, it’s a relatively, you can just do that in one cell, it’s a relatively quick ramp up, and the same is true with Flash, right? Like. You can just use it as a drawing app, and then you can be like, OK, maybe I want to animate a little bit. So I think that is like an interesting common element between those. But yeah, I mean, I was thinking about this, you know, I’m sure you all remember when the iPhone came out and it didn’t support Flash, there was this whole Sort of like Steve Jobs wrote the letter about how like, yeah, about how, you know, Flash is terrible for battery and you can do everything in it on HTML 5 anyway, and so we’re not going to support it. And of course, I think, you know, what is it 12 years later, it’s just like that was completely false. Like people don’t do in HTML 5, the stuff they were doing in Flash, and in fact there was an entire sort of flash. Cultural ecosystem of like new grounds and mini clip and all these other places and people making flash games and like being inspired by the flash games other people have made, that was completely destroyed. Like it just does not exist anymore, kind of partly as a result of that. And so I was tweeting about this and some people were like, Well, how can we make a new flash? Like, we could make an animation ID? And I think I see the appeal of that, but I also think, even if you made exactly the same IDE and it did exactly the same things, without that sort of culture, community, ecosystem. Of people, you know, playing flash games that they like and being like, I wanna make a game like that. I think it’s hard to replicate the same thing. Like, I think the IDE and the technology is only part of a I don’t know if you all know Max Kraminsky on Twitter, they had a good comment that I think you see this in a lot of programming systems, or even just like creative systems, people, I think they were talking about twine games, like twine is this sort of like interactive fiction creation tool, and they were like, you know, my students are not that excited about it. And then I show them some twine games and then they get more excited about it because people want to feel like they’re participating in this conversation with other people who have been working in the same medium as them. They want to feel like there’s like a canon of things that they can aspire to. They wanna feel like they’re placed in some kind of culture of stuff. And so I think, you know, when you’re thinking about making programming tools or creative tools, that’s a really important thing to think about is like, you know, if somebody looks at this, are they able to participate in some like medium or conversation or canon of things that are already out there? 00:40:19 - Speaker 2: Do you think that that’s something you can design for in creating a tool or is culture something that emerges kind of not quite serendipitously, but it’s some mix of things going on in the broader environment and what people want to do and to your point about the, you can make a flash style animation authoring environment for the web or that outputs to quote unquote HTML 5, probably people have, but Something about the way the world is now, probably you wouldn’t get that same kernel that then develops into that flash game culture that was so influential. 00:40:57 - Speaker 1: I mean, I think you can fail to do it, like, I think a lot of HTML 5 stuff has this property where, you know, like you can output stuff, but it’s just a web page like any other web like it’s sort of not constrained enough to constitute a medium in a way like I think you probably want something that has a more distinctive aesthetic. And then that kind of creates a distinct medium where people can look at like examples in that medium. 00:41:21 - Speaker 3: Yeah, I think something that supercharges this social propagation is being able to take some discrete artifacts and share it with a friend or they can copy it or fork it. So the classic example is a spreadsheet. And critically, when you copy a spreadsheet, you get both the output and the source code. And I think early web pages had this property where back then, you know, when I was a kid, the HTML and JavaScript and CSS was readable, so you could copy the source and paste it and then edit it yourself. But then to your point about these newer programs. It’s like this miniified compiled, you’re basically hopeless, so you can see the output like that’s cool. We have no agency to copy and fork it yourself, right? 00:41:59 - Speaker 1: Or I mean, with iPhone apps is another example, it’s like, yeah, you can’t copy an iPhone, or you could make an iPhone app, but it’s a huge process and like compared to, you know, making a web page back in the day where you just like make a dot HTML file and you put it online somewhere, it’s very easy to see yourself as a peer of the other people who are making stuff. 00:42:19 - Speaker 3: I’m gonna reiterate this, I think it’s so important. If you look at the successful end user programming environments, they all propagate this way. We gave the example of spreadsheets. The way SQL works in practice, it’s not like someone reads the SQL manual and then sits down at their company database and types out a query. It’s Mark has a query and he shares the query, and then Adam varies the query and then Henry varies the query from that. It’s like this like tree of life of SQL queries propagated socially. 00:42:46 - Speaker 1: Yeah, and that almost tells you that it’s something that’s genuinely useful and that’s like immediately useful, whereas it’s like, I feel like one of the problems with traditional programming is you have to learn how to program, like you have to go and like take a class or like work through a book or whatever, whereas with spreadsheets or SQL or whatever, you know, you can just copy and modify and like you’ll have something that works and it’s like a few lines. Something I was thinking about with this screen matcher thing that I think is interesting in this general area, is this idea of like trying to unlock, like latent demand. So, there’s a system called buttons in the early 90s, there’s like paper about it. It’s sort of like, I think of it as a predecessor to the screenmaer work, where they basically added this capability to this OS where you could stick buttons on the screen and make them do things. And that was the the only extension capability, like, it was not like a plugin system, it was like, we just added this concept of buttons. Maybe you could like record things into them or whatever, but it’s really interesting reading their reports of how that affected end users thinking, because now, once you have this concept of buttons, you can be like, oh, I wish there was a button to do this. Like, you can, I wish there was a button to do that, like, because before you didn’t have any way to articulate the fact that you wanted to automate something, but now that you have this like, actually fairly weak concept. There’s sort of all this demand for like, oh, I wish my computer could do this, I wish my computer to do that, that you can now talk about in terms of buttons. And so I think that’s one of the hopes for the screen mattress stuff is that, you know, having this automation capability brings out some kind of latent demand for things that people might already have been thinking about in an undirected way, but now there’s like a sort of means or um concrete way to talk about it. 00:44:23 - Speaker 2: as we think about the input and output of computers and that our ability to automate things which exactly as you said earlier, is just an extension of our agency, our general ability to control computers, and so we want to enhance that for people hopefully rather than reducing it or having it stay the same. And so, you know, here we’re talking about the IO of pixels. I know another one that you think about here is FFI is an underrated kind of problem area. Can you tell us about that? 00:44:52 - Speaker 1: Yeah, I mean, I think partly it comes out of This sort of frustration with like, If you get a programming language, whether it’s Ruby or Haskell, or JavaScript or whatever, it’s usually really easy to take in text and output text, like that’s built into basically every programming language. But if you want to like take in images or output images, or if you want to like respond to multi-touch gestures, or if you want to, you know, put up a web page that other people can browse like, basically any actually interesting capability, you need to talk to other parts of the computer in ways that are often not available in whatever programming language you’re working in. And so I think in practice, You know, at least I personally, I’m like, oh, I can’t use like most programming languages because I actually like want to do things that are not just like computing things and taking in text and putting out talks, computing Fibonacci numbers. 00:45:41 - Speaker 2: Yeah, yeah, it was uh I’ve been in the position a number of times in my life where I’ve either encourage people to learn a program because I think they’ll find it interesting that they have the right kind of mind for it, maybe because career potential for them. So I’ve seen folks go through this over the years. I actually think there was kind of a golden age, at least web-wise in the era of PHP, HTML, and FDP, where there was this very simple mapping from files that would save out of a text editor and those mapped pretty 1 to 1 to URLs and the concept of query parameters would come in and you could start to sprinkle in dynamism through the little PHP tags. A friend of mine went through a just Of an intro, it wasn’t even a boot camp, it was more just kind of like a little intro to programming course, and I was really curious what they were going to show them, and it turned out they did Python at the console, which means, of course, that they’re teaching these folks how to like boot up the, you know, these are like most people are using Windows, they’re loading a DOS console and installing Python to run Python programs so they can use, you know, essentially printF and get from the console. And this actually is a totally foreign interface because most of the folks taking this class have never done that kind of terminal input output, but it’s just such a good fundamental way to get started, exactly to your point of take some text in, do something with it, and then spit it back out compared to what you would actually want to do is let me make an app on my phone. Or let me make a web page, or yeah, let me like take an image and like, you know, turn it into a cat meme, but that stuff is just like a wild tool chain of dependencies and moving parts and who wants to even get into that, that’s just not the place to start, even though those are the things you would actually want to do as a person that’s dabbling in programming. 00:47:32 - Speaker 1: Right, like, there’s this weird tension between like, OK, what’s good pedagogy, what’s simpler, and like, what is the actual well motivated thing? And then, I mean, this is very similar to our discussion earlier, where it’s like, the things that are well motivated are the things that you’re already seeing around you. Like, I go to web pages all the time, I use apps on my phone, but those things are so complicated that you kind of end up having to learn by doing these things that you’ve never seen before, and like, not having any sense of why this is interesting or important. 00:47:59 - Speaker 2: Yeah, it’s probably unreasonable to hope for, but I’ve certainly a future I would dream of is something where the average person with their phone would have the option to, I don’t know, long press an app on their home screen, and one of the options down at the bottom is like, make a copy of this and edit its functionality. 00:48:14 - Speaker 1: Right, right. And I think those are important at a cultural level, to like communicate to people that this is the thing you can do. 00:48:21 - Speaker 3: Yeah, this connects to a very long running theme on the podcast around the system’s problem. And I usually describe that problem as something like, you want to be able to write a program in an end user accessible language that has full capabilities into the system, and that is also fast and secure. But because of the way that we structured our systems to date, we’ve kind of boxed ourselves out of that. And indeed, if you want to write in an appropriately high level and safe language, there’s almost no way to avoid. Reduce capabilities and high latency and inability to be promoted up into the proper application or even proper OS level. So I’ve long advocated that a very important research project that we or someone else should undertake is trying to squash all these layers down, so you would have. A programming environment that has direct access to all of the critical IO, so visual, sound, keyboard, mouse, pen, and it all comes in in a very direct and clean way. So for example, the touch screen should not give you just XY coordinates. It should be a full heat map of the pressure sensor at every point on the touch screen. Yeah, but it just comes in as a simple two-dimensional range, your programming language. So it’s not some weird API that you need to go through. And likewise with graphics, oh my goodness, graphics. I don’t know if you all have tried to do. Graphics programming from scratch these days. You know, it used to be, they had a pixel buffer and you would put an RGB value into the pixel buffer and it would show up on your screen. Now you gotta like, instantiate the driver and initiate the shader compiler and compiler and give it the vectors and start the pipe. It’s incredible. 00:50:04 - Speaker 1: Yeah, I tried this and then I gave up because I spent like 3 days straight trying to like install Vulcan or like, if you look at the Vulcan example to draw a triangle, it’s literally like 3000 lines of C code. 00:50:15 - Speaker 3: It’s absolutely wild. 00:50:18 - Speaker 1: I had a professor in college who, his doctoral thesis was about this concept he called exokernel, and he wrote a paper called Exterminate All Operating System Abstractions, which you might want to check out if you hadn’t seen it, which is basically the title communicates the message of the paper, which is that like operating system should, like, that sounds up my alley. Yeah, you know, it needs to like multiplex, like, the different programs can use the same resources, but it shouldn’t like turn your disk into files or turn your touchpad into XY coordinates, it should just like give you access to the underlying buffer and like do the minimum needed to multiplex it. And then if programs want a higher level interface, they can just like link that in, like, that should be the program’s responsibility, and not the operating systems. Yeah. I think it’s partly because of the kind of projects I’m interested in. You know, a lot of my projects are about pushing some system to the limit of its capability, like the web browser or the operating system, even the dynamicle stuff, it’s like, you know, we had to talk to webcams and we had to talk to projectors, you know, and like a lot of that stuff, if you want to do it well, you have to go to a pretty low system level. You want to like, get these buffers and not have to copy them, all this other stuff. And so I think from that experience, my default these days is usually like, well, I guess if I’m in a browser, I’m gonna write in JavaScript, and if I’m on like the desktop, if I’m in Unix, I’m gonna write and see, cause then I know I have all the capabilities. Whereas if I write in anything else, it’s like, OK, I have this third party like bindings, and maybe they’re not up to date or like, maybe they don’t expose the right things, like, it’s just a mess. The only guarantee you get is if you like, write in these super low level languages. 00:51:46 - Speaker 3: Yeah. Now it’s also the case that if you write in one of these lower level languages currently, you might have an intractable amount of work to get up to the full capability and richness of an app. So for example, if you wanted to write like an iPhone app on equivalent hardware up from C, it would be an enormous undertaking. That to me points to a really fundamental issue here, which is that a lot of programming language, I don’t want to call. Design, but like programming language, bringing into its existence and programming environment bringing into existence is an economic problem and not a technical design problem. The amount of resources you need to actually build out one of these new programming environments is enormous. You know, I don’t know. Maybe it’s a billion dollars, maybe it’s $10 billion maybe it’s $100 million. You know, it’s a lot of zeros, right? And so the only way that you can realistically get there is to have some multi-step strategy. And I feel like not enough people are kind of considering that, cause like, I wish, you know, we had this ideal programming environment where you could do X, Y and Z, but you gotta have some way to start. And by the way, I think a lot of it goes through like toys, games, fun stuff, you know, playing around with your home. Programming environment, that’s kind of a way to get some initial bootstrapping and resources, which is why I keep advocating for doing experiments in that direction. We could probably do a whole podcast about economic thinking at some point, but I just wanted to mention that I think you got to consider this resources and incentives and motivations angle. 00:53:07 - Speaker 1: Yeah, probably you all have seen, you know, there’s the whole famous essay about Unix worse is better, but I think like one of the interesting arguments, I don’t think it’s quite an argument against it, but it’s pretty close, is, you know, the reason Unix succeeded was not because worse is better, it’s because AT&T like gave it out for free to universities and like that meant that everybody learned it in their university, and then it was kind of like the model operating system that you would base your computer around. 00:53:31 - Speaker 2: I’m thinking of the meme first time founders think about products, sec
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: My experience as a team lead is that if your team is aligned going into a project, you get this incredible execution. It’s fun to do, you know, maybe hard work, but you’re all rowing in the same direction, you’re seeing those results when you put the pieces together, they’re all harmonious. Hello and welcome to Meta Muse. Muse is a tool for deep work on iPad and Mac, but this podcast isn’t about Muse product, it’s about the small team and the big ideas behind it. I’m Adam Wiggins here with Mark McGrenigan. Hey Adam. So Mark, it’s been snowing recently here in Berlin, quite cold, and of course I need to not only walk a dog 3 times a day, but now take my daughter to Kita, which is kind of a daycare kindergarten thing in the stroller. So spending a lot of time in the cold these days. How do you feel about kind of places with the full 4 seasons, which I think you grew up in the kind of East Coast United States versus the West Coast or perhaps more southernly lifestyle that is Yeah, I’m a huge fan of the Four Seasons, probably because it’s what I grew up with. 00:01:02 - Speaker 2: Actually, especially here in the Pacific Northwest, now I’m in the inland Pacific Northwest, and it’s just beautiful in the winter with the snow on the evergreens, and it’s very quiet and peaceful. I’m a big fan. 00:01:16 - Speaker 1: I certainly find that change of the seasons just keeps life interesting in a way. There’s something about the passage of that day night cycle. And there’s a similar thing with the 360 something days around the sun, and these quarters, essentially, they each have their own distinctive look and feel, right? The blooming flowers of spring, the high sun of the summertime, the rich autumn leaves in the fall, and then winter with it’s cold and snow and people wanting to stay inside and stay warm and cozy. I don’t know, there’s something about that cyclical aspect that works for me somehow. 00:01:56 - Speaker 2: Yeah, and you’re not only enjoying the current season, there’s an element of anticipation for the next one. So now we’re looking forward to, OK, we’ve shoveled the driveway enough times, we’re looking forward to the snow clearing out, and then perhaps it’ll get hot again, but then once it’s 90 degrees and smoky, you’re like, oh man, I can’t wait for the winter when it’s just cold. So around and around it goes. 00:02:15 - Speaker 1: So our topic today is leadership. I thought this would be a fun one because this is something both you and I have spent a lot of time on in our careers. I’ve been in some way or another leading sometimes reluctantly or with some surprise, small teams for over 20 years now. You’ve done quite a bit of that in your career also, and it’s come up a little bit recently in terms of our work on use for teams, in terms of the kinds of people we’re seeing that see the need for this product, we can talk about that. A little bit later, but as always, we like to start with basics. What is leadership? What does that word bring to mind for you? 00:02:51 - Speaker 2: I’d probably say creating an environment where the team achieves success. Now, you can unpack every word in there and it would be a whole podcast in itself, but I think the main idea there is that ultimately you’re accountable for results, that’s why you’re there, and you can’t do it directly, so you have to build the team and create the environment such that it happens. 00:03:13 - Speaker 1: I suspect a lot of people who are successful at being leaders do come to it, not from the perspective of, I just wanted to grow up and be the boss, you know, as a kid I always dreamed of being the one in the corner office or something. I don’t think that happens too much, but rather that you have some end you want to achieve, something you want to do in the world, and in the process of trying to do whatever that thing is, you realize, oh, I can’t do this alone. I need the help of others, and then that leads you to attracting those others to try to help you with that, and that of course leads you into team building and pretty soon you find yourself in this role of a leader. Another piece of your definition here is the team, and I think implicit in that is the assumption that there is a team, right? And that’s not something that comes from nowhere. I mean, maybe you get hired into some kind of leadership or management role and you inherit a team. But at least in my thinking, kind of coming from the more entrepreneurial perspective, or even if you are hired into a role, you’re often expected to build a team. And so essentially the pragmatically we can say hiring, but even more broadly, you can say the identifying what kind of people you need to achieve your ends, figuring out where to find those people, figuring out how to attract them, you know, what do you have to offer them that would make them want to join up with whatever it is you’re trying to do and Help you achieve the end, and then the onboarding process, as we talked about in our hiring episode, which is a way bigger deal than a lot of people make it. You don’t just hire someone and then they’re suddenly a fully functioning member of the team. There’s this long process that could take many, many months or even up to a year, I think, where someone can find their place and brings their unique skills to the team in a way that Enhances it, and more than offsets the cost of just having one more person around that needs to be in the loop communication wise, as well as the actual just cost of their salary or fee or whatever. 00:05:11 - Speaker 2: Yes, recruiting team is perhaps the most important aspect of leadership, especially in our domain, and I think that also leads into the ongoing personnel management. There’s a great document called the Netflix Culture deck, which we definitely linked to, and one of the insights from that was that. The things that your company values is not what you put on the plaque in the lobby. It’s what you hire for, it’s what you promote, it’s what you reward, and as a leader, you’re gonna be doing a lot of that and therefore creating and disseminating what are in fact the values of the organization. So by that channel and by other channels, I think setting the values of the group is very important. 00:05:52 - Speaker 1: Yeah, I would list setting vision and values as one of the top jobs of a leader. There’s obviously many leaders in an organization, particularly as it grows, but here, if we think of a small team, you know, something like the Muse team, for example, that, you know, less than 10 people, there’s probably sort of one person who’s mainly responsible for sort of leading the overall thing, and In that case, yeah, the setting of the vision and the values, the ongoing understanding of the values, which, as you said, are less what you write down or claim are your values and more what you live every day, and it’s partially determining what those are, which sometimes flows out initially from kind of some of the personal values of the founders. Obviously the vision is something that evolves over time as you get better understanding of the problem and work the idea maze. 00:06:41 - Speaker 2: And this matter of vision is very interesting to me. I think there’s a piece of vision, which is setting out someplace in the distant future, like you go and you sit and you think real hard and, OK, this is where we should be. That’s kind of the easy part of vision. I find that the harder part, and where the rubber really meets the road is conviction and belief. It’s actually incredibly hard to believe in something for the amount of time and the amount of work it takes to accomplish great things. Because if you don’t believe in it, why shouldn’t anyone else? So there’s a lot of, basically emotional work you gotta do to get out there and put yourself out there and put your beliefs out there in front of the team. 00:07:19 - Speaker 1: Believing and especially believing in something that is in the beginning, a true article of faith, something you believe in, but you really have no evidence for it, and part of what you’re doing in the entrepreneurial journey is creating that evidence. And we talked about this with Mario from the generalists when he was on the podcast. We’re talking about narrative and part of the job of a leader, especially a CEO is to create a narrative that captures that vision that is a dream, but an inspiring dream and feels achievable, and there’s a version of that that can become, you know, we’re talking here about faith and belief and narratives and all this starts to sound, you know, a little bit like cult leader like and indeed you can go off the deep end with that, and that is how you get some of these maybe bad examples of companies that seem to suck up all these resources and build this big internal culture of what turns out to be pretty false belief around some cult of personality. That’s like a far extreme, maybe failure case, but there’s a middle ground where you take a visionary, you know, take a Central, kind of almost mythological figure in our field now, which is Steve Jobs, and he would create that reality distortion field, tell that big story, inspire people, and then be able to make that thing come true that seemed impossible at the start. The balanced version of that is the belief, the faith, believing in front of the team, believing in front of the outside world and especially doing that when the going gets rough. It’s easy to believe in time when things are going well and everything’s up into the right. It’s harder to do that when you’re struggling for some reason or other, and there’s always moments of struggle in every company’s story. 00:09:00 - Speaker 2: Yeah, and I think it’s also easy to have conviction in a way that’s basically a fantasy. And again, we come back to the importance of results and accountability. The real reason it’s important is that the variance in human performance and achievement. Potential is enormous, and often people don’t realize it. Perhaps it’s because they’ve never seen it, they’ve never had anyone that believed they could achieve at a higher level, and the responsibility with vision and belief and foresight is believing that the team can operate at a higher level, and then seeing that they do, in fact, achieve that level. You gotta do both parts, right? It’s not enough just to say, you know, I believe we can do amazing things. Well, sure, don’t we all? But it’s taking the team there and really achieving it. OK, well, let’s pull out Adam Wiggins trick here and refer to one of the items from your crou lessons for leadership. I think the document was pull link to it. But one of the things that I remember was make it concrete. So, let’s talk about some concrete leaders that you’ve looked up to or learned from. 00:09:57 - Speaker 1: Well, certainly offhand, I think of people who have been leaders to me, which includes someone like Byron Sebastian, who we hired to be the CEO at Hiroku, and I learned a lot from someone like Ida Tin, who’s the founder and CEO of Clue, and, you know, these were both people that just inspired you, but also made you feel like they personally cared about you because in fact, they did. And they did for everyone that was on the team, and made it possible for me to do great, great work with under the umbrella of the leadership they were providing. But I think it’s interesting here to look at maybe public cases, people who are famous enough or maybe just got around to writing their autobiographies that you can sort of reference. We’ve mentioned Steve Jobs already. Bill Gates is another, obviously many folks have questions about maybe some of the ruthlessness he exhibited back in his Microsoft days, but you know, each in their own way, Gates and Jobs, maybe they had some. Problems with being a little too tyrannical in their own way, but this incredible drive, the vision, the unwillingness to compromise and shaped the computing industry of their eras in their own vision of how they thought things could be better, you know, Bill Gates believed in a computer on every desk and he achieved that, and Steve Jobs put a computer in everyone’s pocket and made design a household word. But those are sort of obvious cases. I was just flipping through some of the Books I’ve read, particular biographies or autobiographies, and it’s interesting to look at folks maybe outside the tech field as well. One that comes to mind right away is Ruth Handler. She co-founded Mattel, the toy company, and invented the Barbie doll, and also did other entrepreneurial things in her career, but obviously that was the big success, and there’s an excellent biography about her called Barbie and Ruth, the story of the world’s most famous doll, I’ll link that in the show notes. That is a good example of someone who, I guess maybe more an entrepreneurial leader who’s someone who looked at the toy industry as it existed at the time, looked at the dolls that kids, especially little girls were playing with and said, I think there’s a better way here and ended up not only inventing a new product, but founding a whole company around that and that, you know, company went on to essentially change the, the whole industry to match that vision for that better way. Some other examples there are Bill Walsh, who’s, I think, a coach of some MA football team, and he wrote a book called The Score Takes Care of Itself and the Philosophy of Leadership, lots of interesting stuff in there. That’s kind of what we’ve been talking about already, setting vision and values, you know, we came into kind of a struggling team. And did a bunch of things there in terms of setting a new precedent for how they would collaborate together and what kind of standards they would have, many of which was unrelated to, seemed unrelated directly to just playing the sport. A lot of it was about how they hired people, how they kept their facilities, how they treated each other, that sort of thing. So maybe that comes back to your point about kind of environments. And then the last one I’ll name is, it’s actually more of a book that covered a few different folks in the television industry, which is called Difficult Men, and this is about showrunners, which showrunners are sort of leaders of these within the media industry, but they’re not like film directors, which are sort of these, you know, one off two hour things and they’re not. Directors of individual episodes, they are owners of these big epic stories like I think a few that were profiled here is like The Sopranos, Mad Men, The Wire, and these are long, long projects with big teams, lots of writers, lots of directors, etc. but of course they’re quite a bit more involved at every level compared to conventional TV. It’s very interesting to read about how they do things and actually one of my takeaways from that book was, and indeed is in the title there is that people with strong vision can often also be very difficult. In fact, they can be, again, I used the word tyrant earlier, I think that people often use that to talk about Steve Jobs style and you see a lot of that with these folks. Now, one exception I do want to point out there is the showrunner from Breaking Bad, who apparently was kind of the sweetest, kindest person and ran the show there and all of that without all of that kind of classic intense boss stuff, which I like that a lot because it shows it can be done and there’s probably a conventional, probably pretty masculine way of kind of leading that is sometimes based on intimidation and I don’t know, various traits that I find not that compelling. But in any case, these TV shows, which are huge artistic efforts, big budgets to manage and over a very long period of time, right, like something goes for 78 seasons, there’s obviously all the build up before that, pilot episodes and things like that. And so, yeah, I don’t know if it’s quite right to say that I look up to any one of these showrunners specifically or see them as Great role models, but just that there’s good patterns across them. These are people who managed to make something unique in the world through organizing a lot of resources and people, which is something I find inspiring. 00:15:08 - Speaker 2: Yeah, I think that domain is incredibly rich, TV and movies, because it’s one where there’s this very complex multidisciplinary, creative, high risk project, and there aren’t that many great analogies, I think, to software development. It’s kind of a weird thing, but perhaps actually the closest is making a movie or a TV series. So I think there’s a lot we can learn from those domains. And by the way, This is a pet peeve of mine, you know, people always say, oh, you can’t estimate a software project. There’s no way to know if it will ever, you know, work or when it will be done, you know, you can’t say anything about any of that. I don’t know, man, people estimate complete movies with thousands of people literally filmed all over the world. I don’t know. I sometimes I don’t believe you when you say you can’t estimate a 5 person software project. 00:15:51 - Speaker 1: Do you have anyone that either you’ve worked with personally or is a more public figure, like one of the ones I’ve named there that you find inspiring or anti-examples, people you think that are not effective leaders or have traits that you think are counterproductive. 00:16:07 - Speaker 2: Yeah, I’ve certainly worked with a lot of different leaders in my times and feel like I’m developing notions based on those experiences that I try to give things more time and distance before I really weigh in. But what I’ll mention is Peter Van Hartenburgh at the lab. I’ve worked with Peter in several different domains, and he’s someone who’s just like a magician with getting the right team together and getting that alchemy happening. And I don’t know how he does it. And frankly, it’s often pretty messy. Leaders have different styles, but man, somehow people show up and they start doing amazing stuff. It’s really amazing to watch. 00:16:40 - Speaker 1: Yeah, Peter the great one, he comes to mind for me as well, and also to your point about styles, he and I could not be more different. I’m all about like structure and clarity and so on, and he has this more, you know, warm, but also kind of loose and flowing approach, and indeed we have together been in kind of like co-leadership positions, maybe I’m, you know, leading on the product and design side and he’s more leading. Engineering team to take one example, and there’s ways those styles don’t really fit together, but then when I’m just watching him do his thing and see the results that come out, it’s just undeniable that he’s got something that really works, even though it’s kind of a mystery to me because I come at it from such a different perspective. 00:17:22 - Speaker 2: And I also look a lot to history. I feel like in the case of historical figures, we have more distance and perspective. Often there’s a lot more data, and because the stakes were often so high, often indeed existential, it really lays everything bare, right? Like there’s no excuses, there’s no ifs ands or buts, there’s no mitigating factors, you know, kind of it is what it is, and it’s settled on the world stage and that’s that. Whereas, you know, if you’re a leader at a big company, is what you’re doing working well because the company is doing well or, you know, whatever, it’s kind of hard to tell. You need more time and perspective and distance. So one example for me is George Washington, who is an incredible example of, well, a personal character, but also B, this idea of vision and belief, you know, believing that you’re going to create a country contrary to the global superpower and, you know, fight a revolutionary war with farmers and merchants, it’s just an incredible story. 00:18:21 - Speaker 1: And one of the things I love about the Washington example as well is he did what was needed in the moment, right? There was fighting a war, but when the war was over, he didn’t try to continue that because he was pretty good at being a general. He moved into a new kind of leadership position, which was being the president of a young nation and trying to preside over building up a government and building up good processes for this new democracy. Something I at least aspire to do in my own. Kind of career as a team lead, which is do what the situation demands, do rise to the moment of what this exact team, this exact company or organization or situation calls for, which often means doing things way outside my comfort zone or having to educate myself about stuff that I have not done in the past, and it would be easier to stick to a thing I know, a skill set I already have, but that’s not what’s really needed in the situation. 00:19:18 - Speaker 2: Another reason that I like to look to history, is that I feel like much of leadership is made in the small details, and unfortunately, we don’t have the small details, we don’t have access to the small details for most contemporary leadership cases. Like the CEO of Microsoft, you know, we don’t really know very much about how he operates unless perhaps you work directly with him at Microsoft. But if you go back to the historical examples, we have, you know, basically all their papers, we’ve triangulated massively. There’s all these different angles that we have on it. We’ve collected all the accounts and you get a richer sense of how they operated day to day. So it’s not about just making a few big decisions and that’s it, even though when you zoom out, you’re seeing this huge global event. It’s really about the individual interactions you have each day, you’re hiring and firing decisions, who you promote, who you don’t, you know, how you motivate the one guy who’s struggling. That’s the really rich texture that I think you need to be able to develop a good sense of leadership. And unless you’re lucky to have a few of those in your life, which I think to varying extent, we’ve been lucky to have that, but there’s this, this incredibly rich historical bounty that we have if we’re willing to go back and look at it. 00:20:26 - Speaker 1: Now going back to a word I think you’ve used a couple times here so far is accountability. I feel like that’s an important one to zoom in on. What does accountability mean in the context of the leader’s job? 00:20:40 - Speaker 2: I think it ultimately means that your success is measured by whether your team achieves the goals that you set out to accomplish. And what’s tough about that is that that being accomplished or not is going to be a function of all the work that the individual people on the team do. So you basically, you’re not directly pulling these levers, that would be responsibility in the management language, right? Like you’re the person actually doing the frontline work, but you still need to be accountable for the results. The sum of all that happens rolls up to you. 00:21:11 - Speaker 1: Roll up is a good word for it, because I think the accountability or holding the organization, the team accountable is a combination of the leader themselves feeling accountable for the overall results, separate from any individual domain that a person might be responsible for, and that includes we just don’t have someone that owns a particular domain, that’s a big gap for us, and we need to do something about that because you’re accountable for what’s there overall. But then there’s also a holding people on the team accountable, and hopefully the team holds itself accountable. Individuals do, and they make commitments to each other and want to keep that commitment in terms of what they’re going to deliver and so forth. But I think the leader’s job is to be accountable themselves, and maybe that somehow goes up to, you know, if you’ve got a board of directors or shareholders or something like that, but in the end, it probably boils down to also just like, if your company fails, you know, that was fundamentally, that was the leader. Failing more than anyone else, but then that also gets echoed back into holding team members accountable, or if you have whole teams that are sort of under your, again, umbrella of leadership that you’re saying like, OK, look, I don’t necessarily know every detail about how you do your work. I trust that you know your skill and your craft better than I do or ever. Well, but look, we need to deliver X and here’s the resources we have to do that. And if you don’t think we can accomplish that, we need to come up with a different plan, for example, and then kind of keeping again coming back to that, repeating yourself and the reminders, not just forgetting about it, but coming back to it to say, OK, how are we doing on this? 00:22:50 - Speaker 2: Yeah, and I think there’s a related idea in there of standards. I think an important role of a leader is setting the level of standards within an organization and holding the team to that, and it’s not as easy as it sounds because, of course, we would like to have infinitely high standards and to see. Everyone reaching them, but what happens is if you set the standards too high, that is, you know, of course, if they’re not possible to accomplish, or it’s just the team members don’t believe they can do it, or they don’t feel like they have the support to do it, or they don’t feel like they’re gonna be rewarded if they do do it. Not only are you not reaching the level that you had set as a leader, you’ve lost credibility. So, You need to find the right balance of raising the standards such that the performance of the organization increases but not trying to raise it so high that you detach from reality. Again, I think this is so important in our domain because the level of variance is enormous, and I think people still, even though we have now several decades of experience and Making software. I think people still underestimate a lot, but it’s possible, how fast it’s possible to move, how high quality the software can be, how fast it can be, how reliable it can be, and so on. And so I still think there’s a lot of work left to be done as leaders in this area. 00:24:05 - Speaker 1: Um, one example that I read just recently is Patrick McKenzie and his nonprofit Vaccinate CA, which was basically a kind of information website for availability of vaccines first in California and later in the rest of the United States during our recent pandemic, and he wrote up a in his His usual sharp and humorous style, the full story of their experience and spinning up this nonprofit, the work that they did, and then eventually shutting down when they weren’t needed anymore. But that concept of what’s possible and what standards we hold ourselves to, I feel like permeated the story because there it really was about speed. And they’re doing kind of like a low tech, fast, but accurate thing that would ultimately result in their organization’s mission, which was to get more shots in arms. And so Patrick as a leader in this case, was holding his organization to the standard of speed because that was just everything in this case, getting this information, getting accurate information out to people as quickly as possible, getting the website built and the infrastructure that went with it. And that that sort of was in contrast to what, for example, is pretty commonplace in, let’s say government organization or even government contractors who are used to long cycles and a lot of process, and he came in and said, no, what’s important here is to do it quickly, and holding his team to that standard through a set of sort of practices allowed them to accomplish things that no one else could. But importantly there, and I think in most cases, as you said, it’s the trade-off of what standard are we holding ourselves to in the context of how that helps us achieve our mission. It’s not that we want to, for example, make the most beautiful design possible just because, just because we want the highest possible standard. There needs to be some reason, something we accomplish with a lot of craft put into the design, or for another organization, it might be. A beautiful design doesn’t matter very much, and we hold ourselves to high standards on other things. For example, safety might be something that an airline wants to hold themselves to a very high standard for. So I think it has to be set the standards in a way that fit with the reality of the world, but also the mission of the company and what you’re trying to accomplish and what you’re trying to deliver. Well, maybe now would be a good moment to mention why this topic is on my mind to begin with, which is our team has been working on our new product Muse for Teams, and part of what we’ve done in this alpha program is we have a survey where people can essentially fill it out and describe what they do, what their team is like, and how they idea today and so forth and what their frustrations are, and We didn’t really know what kind of people were going to answer that survey, and indeed we’ve had quite a wide mix, just similar to the new user base, architects, doctors, many students, many professors or other people in the academic space. But one pattern I think that we’ve seen quite a lot of is team leads signing up, and this is interesting because it seems that the problem of, let’s say, a shared collaborative whiteboard or shared documents generally to be a space for a team to idea is something that is a problem that team leads are just Very intimately familiar with, they feel this pain most directly, maybe more than the individuals on the team, and that caused me to be kind of reflecting that, OK, well, why is that? And maybe that’s not a coincidence, right? Part of why I’m driven to build this product is I’m also a team lead, and something that I consider a key part of that job is Yeah, manager speak for this would be alignment, you know, getting everyone on the same page or the basic idea that you can bring together a bunch of amazing craftspeople, but if you don’t agree on what you’re building and what you’re doing here and a direction and you have a meeting and you talk about it, but it’s kind of like subtly wrong and then everyone goes off to their individual things and they’re building stuff. And a week later, a month later, whatever you try to put it together or you come back and look at it and realize you just had all these false misaligned, mismatched assumptions about what you’re really doing there and then that slows everything down and people are demoralized and work has to be undone and so forth, and that my experience as a team lead is that If your team is aligned going into a project, you get this incredible execution. It’s fun to do, you know, maybe hard work, but you’re all kind of rowing in the same direction. You’re seeing those results when you put the pieces together, they’re all harmonious, and I think this is something where the historic solution to this called it alignment problem is these analog tools, right? We get together in front of the whiteboard and we talk about it, we go to the conference room, you know, maybe on a bigger scale, you got the all hands or whatever. But then when you come to remote work, OK, now it’s harder to take advantage of some of those, and I think this is where you have shared documents, you know, I got big into Google Docs basically once I got more into remote teams because that could be a kind of like internal memo. I’ve used email for that, that sort of thing in the past, maybe Slack to some extent or some of that, but I think there’s really nothing like a more kind of free form ideation space, and that indeed seems to be what folks who are Filling out our survey, who are founders or CEOs, particularly of small to mid-size teams, are seeing is that OK, I now have this remote team, we have these time zone differences, we do have all these collaboration tools and different kinds of shared documents, but none of them quite have that same flexibility and kind of all encompassing aspect that you can get out of just physical ideation tools. And as a result, that can be a real impairment for remote team to execute well, and again that moving more slowly and undoing work and frustration as people feel like the pieces don’t fit together. I found that very interesting. I’m curious how you see all that. 00:30:18 - Speaker 2: So we talked a while back about this book called Sketching User Experiences, and one of the key ideas from that book was that the medium that you choose to work in, it sort of tunes your wavelengths that you’re listening into and operating on. So, if you have a very precise medium, you think very precisely and you might therefore lose the bigger picture. If you have an extremely messy medium, you might not get concrete enough. And there’s an important middle there, which he called sketching, which has the benefit of being concreteness, but it’s not about being pixel perfect. And so, one of the original ideas with Muse was that you needed the same thing for, well, ideas, for creative thinking, for planning. It wasn’t super linear, like a text document, it wasn’t. Super mechanical, like a Gantt chart, but it also captured the richness of thinking that people and teams have, it’s multimedia and so on. And so, one of the things we’re hearing from team leads is that According to the medium that they choose, that tends to tune the thinking of the team. So if a team jumps right into Figma, for example, they’re tuned to think about pixels and what’s the radius of this curve and is the shadow rate, or if you jump right into Git and GitHub, you’re thinking, what’s the name of this function be, and so on. Whereas if you center the team around, you know, traditionally it would have been a whiteboard. OK, they’re stepping back a little bit, they’re thinking a little bit more expansively. They’re not worried too much about the details, but it does need to be concrete enough so that you can see where the boxes and arrows are and so forth. So I think the muse does help teams idea on the proper wavelength, if you will, for when you’re brainstorming and forming new ideas and starting to anneal plans together. 00:32:04 - Speaker 1: Yeah, the sketching user experiences book, which is Bill Buxton, if I’m not mistaken, I’ll link that in the show notes. That’s a great one, a little rambly in a way, but lots of good ideas in it, and he also talks about a sketch as being, it’s not about being a drawing specifically, although it often is, and more that it is a thing that proximates the final shape. So it’s cheap to make, so you can make a lot of them and compare them, but it is, as you said, still concrete and you can look at it and discuss it. And another important quality of the sketch is that it’s kind of vague, which is good in the sense that it invites a lot of interpretations, so you can have this kind of ideation experience, particularly between two or more people where you think, OK, here’s kind of what I’m thinking and you sketch it in whatever medium you’re using and someone looks at that and says, oh yeah, I see that that would solve the problem this way. You say, oh, no, no, that’s not what I was thinking. But wait, now that I kind of look at it that way too, well, that’s an interesting idea. So like, The sort of open to interpretation aspect of it serves as a launching off point for the kind of divergent thinking that you should be doing when you’re in the early phases of a project. 00:33:15 - Speaker 2: And that reminds me of another important aspect of ideas and plans is that it’s not just about the final artifacts. It’s about working through it, but I have one called chewing, and if you’re chewing an idea or a plan together as a team, you’ve, well, digested it better to continue with the analogy, right? Like everyone has a better sense of what’s going on, they feel more invested in it. They’re more aware of the trade-offs that you sort of traverse together and things like that. And so that’s part of the vision with use for teams being multiplayer is that instead of having a team lead, write up a document. And cast it about on the team and everyone going from there, it’s more a matter of the team is building this together incrementally, and not only do they share the artifacts at the end, they share the experience of having worked on it, and are therefore more invested in the final result. 00:34:07 - Speaker 1: And that highlights something that was a major piece of learning for me in my leadership career, which is working through the problem, you know, you start with all the inputs and you think about all the constraints and the opportunities in front of you, and you eventually come up with a solution, which might be a plan of action, it might be a rough design or a vision, it might be specific kind of task assignments, and I would tend to think, OK, well, let me bring this. To the team that I’m working with, because this is the plan, but actually that doesn’t work very well. You need to make the plan together, because otherwise, the people don’t feel shared ownership. They weren’t there for the process of seeing why we’re doing exactly what we’re doing. And in many cases, all the different disciplines you may have on your team and the different perspectives, those need to be folded in. Now, it’s not necessarily designed by committee, there does still need to be kind of a central organizing. single mind that can kind of look at everything and make sure it all fits together holistically, but you do need to take into account, you know, the classic example here would be if designers make a design without consulting with engineers, they’re gonna be unaware of both the limitations and the capability of the technology, and they’re gonna ask to be implemented maybe out of step with what’s possible with whatever technology they’re working with, just to take one kind of classic example. So yeah, that process of planning together as a group. And coming to that, like, this is our shared plan is immensely valuable, and I even resist the urge, you know, I like to think strategically, I like to think about what’s next after we finish this current work and What have we learned and how do we fold that into what our next step should be, but I’ve really learned that, you know, hold off a little bit, do it with the team because we need to all do it together, and it’s that experience of going through it together that is going to make it so that when you go to execute the plan, you can do that far better. 00:36:04 - Speaker 2: And I think the most effective version of this, by the way, isn’t all or nothing. The weakest thing you could do is come up with a plan as an individual and cast it over the wall to the whole team. We understand that’s not very strong. It’s slightly better, but still not very good to jump into a meeting with an entire large team and just start planning from scratch. And then end of the meeting, yes, also a mistake, a mistake, right? And so what actually needs to happen is there’s this very organic process. I use the analogy of the spiral, spiraling outward. So typically, you start with some kernel of an idea, like you have this notion that the team should move in some direction, and then you go and you balance that idea off one or two of your close trusted advisors. These are people who you trust to, you know, give you candid feedback, but also kind of keep the idea private because you’re still in the process of nurturing it. And then you might take that idea which is starting to take basic shape and discuss it with your leadership team. And you do some more shaping there, you gather some more data points, and then you might have each of those managers do a brainstorming session with their team and then take the results back to you. And then you might have, you know, some of the managers talk to each other and then you might develop a draft plan and go message test that with a handful of individual people on the team. And then you might send it out to the whole group, right? This is just one example of how a typical kind of communication development and dissemination process might happen. It has many steps with different size groups with different configurations. So one of the original ideas with Muse was to try to facilitate that better and to create this environment where you can have things that are moving between private, semi-public and public and back, and along the way, accreting information. 00:37:47 - Speaker 1: Indeed, and I feel that also touches on the kind of synchronous versus asynchronous discussion we had in our remote work podcast and certainly has come up a lot on the news for Teams product, which is people have the question, is this mainly for synchronous? We’re all on a call together and we can see our cursors flying around, or is it mainly for asynchronous, we’re gonna Send documents back and forth to each other, and I think some of each is the right answer. I think you get different kinds of ideas, different kinds of consensus and buy-in from each of these, but yeah, I think it’s too, I don’t know, laborious, probably wasteful of time, but also for me as an introvert, I just need time and space to think on my own, and I think many folks. It’s too much to try to kind of think in a group. Now you could bring ideas together and that’s where if you’ve all prepared a bit within the new world, you created boards. We do this exact thing, especially for really significant, you know, bigger planning meetings or just discussions about our future, where we say, look, you should think about this on your own if you can, if you can find the time, you know, write up your thoughts, which is could be just. of bullet points, but it could be a really extensive board. We’ll get all those boards, those kind of individual boards together on one shared board, and then we can go through it a bit synchronously and get to shared understanding and hopefully synthesize all of this together into our best solution. So I think there’s really places for both of those in the ideal work process from my perspective. Well, maybe a good place to end would be books or other resources that have been helpful to us and discovering our own path to leadership and what works well on teams. I think you’ve already mentioned the Netflix culture deck, I’ve mentioned a few books that I’ll link in the show notes. Do you have any that you think we should mention for our listeners? 00:39:37 - Speaker 2: I’d actually re-emphasize the history idea. I think it’s just incredibly valuable. And if I was to give concrete advice, it would be to pick some event or time period that you’re really interested in and try to read a half dozen or a dozen books on that same topic, because again, it’s all about getting that richness of Of historical perspectives and angles and information and really understanding the texture of the day to day decisions. And you can learn a lot of the same things from different periods because people have been and are the same. So just find one that you’re really interested in would be up for reading a dozen books and go for it. If I was to pick some more classic management books, the number one book that I recommend to new managers is Slack. I almost feel like it’s mistitled. 00:40:21 - Speaker 1: I mean, the core thesis of the book is I wanted to briefly interject to point out that this book predates Slack, the software product and is unrelated to it, and instead is about the concept of slack in the system in terms of making your team work at 100% efficiency means there’s no slack in the system and that has all kinds of negative downstream consequences for your business, even besides tired and burned out workers. 00:40:44 - Speaker 2: And if I was to give a bit of an oddball recommendation, I would say principles of product development flow. This is a highly analytical book. It’s a cutheoretic analysis of project management, which I know is quite a ways from what we’ve been talking about today, but there are a lot of important ideas, especially for people who work in engineering type domains. So if you have any affinity at all for that sort of stuff, I really highly recommend it. What about you, Adam? 00:41:10 - Speaker 1: Yeah, I think for me I get the most value out of stories, autobiographical or biographical accounts of the lives of leaders or sometimes teams in a particular high stakes situation. So certainly when you’re talking about history, I think of, I’ve read biographies of Abraham Lincoln, for example, and the challenges of keeping the nation together and everything else going on during his. Presidency. Another one I really like is about Catherine the Great, who was a really pretty visionary and forward thinking leader for Russia at the time and established a lot of precedents, including writing a super long manifesto about sort of some perspective on making Russia into something a step closer to a modern liberal democracy, which is quite interesting. So yeah, when you read these stories, they’re not telling you, hey, Lincoln. was effective because of this thing or Catherine did a good job because of this thing and therefore that’s a lesson you should apply to your leadership. It’s more, I don’t know, just examples and then those may or may not be directly applicable to what you do, but then you can bring those stories to mind sometimes if you find yourself in a dilemma or a circumstance that resembles in some way. What they went through and think about these examples you’ve seen and how they turned out for them and then think, OK, what can I learn from that? How can I apply that to my specific circumstance, my specific leadership style? And I think that tends to work better, or just be more memorable for me maybe than something that’s a little more prescriptive or abstract. But that said, something a little bit more pragmatic. There are the classic management books, take it, for example, high output Management by Andy Grove or Management by Peter Drucker. Although that actually leads me to maybe a final question here, Mark, which is, do you think that leadership and management are synonymous, essentially two words for the same thing, or do they represent different disciplines? 00:43:11 - Speaker 2: I think they’re very closely related. I think management done well, is just a superset of leadership. Now, when people use these two words, they’re often saying management in such a tone that they’re quite dismissive of it and think perhaps these circles do not overlap at all. And, you know, perhaps it’s valid based on their experience with managers, but I think management done well, includes all the aspects of leadership that we discussed, plus you necessarily have the people responsibility. What about you? 00:43:39 - Speaker 1: Yeah, I really was curious about this and thinking about how we would cover this topic. I think of it as a Venn diagram to the point of your circles, and there’s quite a bit of overlap, but they aren’t necessarily quite the same thing. I think of leadership as more of forging a new path, and I think of management as something that’s more continuing or having something operate smoothly. But I think it’s wrong to think that those can be completely separated or unrelated because so much of keeping, whether it’s a business or a property or anything else, kind of thriving is some element of change, some element of reinvention, so there needs to be some forging a new path. If nothing else, just cause the world is changing around you and you need to keep up with that. And similarly, I think earlier in my career, I, as an entrepreneur, I was so focused on the forge a new path side of things that I didn’t give enough weight and importance to the management side, which includes people management, but also includes Yeah, just what it takes to run a business or keep your offices open or that sort of thing. There is this very pragmatic operating element that is part of what I think of it as management and you can’t really build a thing and lead it without some portion of that. So yeah, I don’t know if that’s enough to do a whole podcast on management in the future or maybe the two are So bound up that it’s not helpful to differentiate between them. But for me, I think it was somewhat of an epiphany moment to realize that there is this discipline called management that it is, as you said, maybe it’s a super set of leadership or maybe it’s just an overlapping piece, and indeed that name or term or concept appears in product management, for example, and I think there’s a Subtle meaning to that that is useful to understand, at least for me, when I did start to understand it, also greatly expanded my understanding of what it means to be a leader and how I wanted to grow in my career. So, yeah, it’s a tricky one. 00:45:44 - Speaker 2: Flipping this around, I think it’s the case that one doesn’t need to be a manager to be a leader. Perhaps that’s a good message to close up the podcast with, but this is something that anyone can step up and do. And indeed, it’s the nature of leadership that people aren’t going to give that to you, something that you have to take on yourself and demonstrate initiatives going back to one of our very first points about vision and belief and conviction. 00:46:06 - Speaker 1: Yeah, to me, that’s actually one of the best moments on a team is when someone sort of unexpected steps up, takes ownership of something, takes the lead on something, and they don’t need to be the boss, and they don’t need to have vested authority. They just see a problem, see an opportunity for things to be better on the team and find a way to lead. In the direction of how that can be improved, and seeing that happen, spontaneously seeing that person grow into whatever that leadership moment is for them is, to me, it’s one of the best parts of being on a team and doing the work we do. Well, let’s wrap it there. Thanks everyone for listening. Join us in Discord to discuss this episode with me, Mark, and our community, the links in the show notes. You can also follow us on Twitter at MA HQ, and Mark, thanks for all the leadership you’ve shown in all the various teams we’ve been on together over the years. 00:47:02 - Speaker 2: Right on, well, learned a lot for you, Adam.
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: A theme that runs through all of this, whether it’s a big company or a small team, is it’s really about building our collective knowledge. We can extract all the most relevant pieces of information from everyone’s domain and bring them together. From that comes a plan that we all feel ownership for, and then when we go off to do our heads down work, we’re working off that shared plan where we for a brief moment, brief beautiful moment in time, we understood the problem in a totality that no single human could. Hello and welcome to Meta Muse. Muse is a tool for deep work on iPad and Mac, but this podcast isn’t about Muse product, it’s about the small team and the big ideas behind it. I’m Adam Wiggins here with Mark McGranaghan. Hey, Adam. And Mark, I don’t know if I told you, but my Christmas gift was a used guitar, acoustic guitar, and I’ve been blinking around on that, maybe not quite at the same level as devotion as your piano studies, but I’m quite enjoying it and I found myself reflecting on the tacit knowledge revolution of YouTube theme that you’ve brought up multiple times on this podcast because the last time I tried to play guitar, I don’t know if it was in high school or something. And you would seek out these COVID nuggets of knowledge from just people you would meet or whatever and lessons were expensive and time consuming, but now you just go on YouTube and there’s just tons of people who will just show you exactly what you want to know at whatever pace you want in great detail. You can watch it in slow motion if you want, you can rewind. That’s a really incredible way to do self-learning, particularly if you’re not that devoted to it. It’s just kind of a little side hobby when you have a few spare minutes. 00:01:47 - Speaker 2: Yeah, it’s amazing what you can find on YouTube these days. It’s so helpful. Now, for you, is YouTube the primary source, or do you also do an app or do you do Zoom lessons? 00:01:56 - Speaker 1: There is a guitar tab app, you know, essentially a tab is like the sheet music effectively for guitar. We can look up a folk song or a popular song and find out how to play it. Actually, our colleague Yulia, who plays the ukulele a bit, pointed me towards that. So that’s nice for learning a specific song, but it’s more about technique, which is, OK, you know, I’d always got to figure it out with like plucking with my fingers, but maybe, you know, playing with a pick could be a good technique to learn, but when I try to do it, it sounds terrible. How do I do that? And again, there’s probably a conventional method of, you know, you sign up for lessons or whatever, but I just don’t have time, interest, whatever for that. But this very self-directed method of I can just type into the YouTube search bar, acoustic guitar, beginner strumming technique or beginner picking technique, and inevitably there’s dozens of really high quality choices. Well, I’ve got exciting news to share. Muse for Teams is now in beta, so it’s open sign up. Anyone can go to the Museapp.com/teams/signup page and you can pick a team and try it out. And essentially this takes the thinking tool of Muse that we’ve been working on for a few years, but adds these collaboration features, what you would think of from like a Google Docs or a Figma with the avatars and the cursors moving around the board. But we’ve had this in kind of an alpha test with a small number of teams. The last 5 months or so, and we’ve done quite a lot. I’ll link out to the announcement there, everything from a new NavA and board Zoom and connection tool, as well as all these collaboration features you expect like comments and following and copying board URLs. So yeah, we’re really excited to share that with the world and it was quite a lot of hard work by everyone on the team, including both of us. So give ourselves a little back pat for that and we’re looking forward to hearing what everyone thinks. 00:03:48 - Speaker 2: Yeah, I’m really excited. This is one of the big pieces in our long term puzzle collaboration, so excited to see it finally land. 00:03:57 - Speaker 1: Indeed, yeah, I think we’ve often spoken about that long term roadmap as the do the individual thinking tool on the iPad first, then we go to the multi-device with kind of Mac and iPad and the local first sync between them, and this is that next step, is being able to collaborate with others when that’s appropriate. And yeah, I’ll link out to the announcement post that has all the goodies and screenshots and videos and everything like that. But what I’ll direct your attention to for the purpose of this podcast episode is there’s a whole sample workspace that’s included with the new onboarding, and there’s also a templates button in the toolbar that basically lets you add some templates, and if you were to click on that, you would notice that all the entries are things that are around this theme of planning. And so, we’ve decided that based on how people were using the alpha, that kind of narrowing the use case to or kind of a set of use cases around the theme of planning or planning together with your team, is a great place for us to focus. It’s a place that Muse can. Be kind of best to breed even though it’s a very general purpose app that can be used for a lot of things in the collaborative space. We think that this planning realm is where we can really excel, so we’re excited about that, but it naturally leads into our topic today, which is planning. So, let me first pose the question, as we always do, Mark, what first comes to mind when you hear the word planning or planning your work? 00:05:27 - Speaker 2: Well, I certainly get a lot of emotional connotations, as I’m sure everyone who’s worked in product development does, but simply I would just say it’s the team discussing and deciding what to work on in the future. What about you? 00:05:40 - Speaker 1: Yeah, so I think there is almost a knee jerk or an immediate thing that comes to mind, which is basically long meetings, listening to laundry lists of details about other people’s work that isn’t really relevant to you and is kind of boring, and yeah, just this really kind of nuts and bolts, just let me get back to work. Why do I have to sit through this doesn’t feel like work, something like that. Indeed, when we were first discussing on the team, whether planning is something that we really wanted to focus and use collaborative product around, there was some level of, I’m not sure what you call it, groaning or yeah, folks have that same, I think visceral reaction that I do in some ways, which is planning’s boring, and we don’t want to make a boring app for a boring thing. Why in the world would we want to make that be our big focus? And indeed I ended up writing a memo based on reflecting on this called Against Boring Planning, again I’ll link that in the show notes here, but when I stopped to think about it, it comes down to the kind of good versus bad planning. If I can go for such a direct value judgment there, which is planning your work as an individual or together with a group, when it has these bad vibes, I think it is because, so you’re not doing it right, and I have been on a lot of teams and have had a lot of experience. that are like that and reflecting back now, I think, OK, that wasn’t a good way to organize a team’s work. But when I think of the positive vibes and the good kind, let’s call it good planning, you know, I think, OK, I’m getting together with a group of people that I like, or at least I work really well with, to think about what’s the next step in achieving a mission that I really deeply care about, and we need to get into the difficult questions and the trade-offs and think about what capabilities our team. Has to bring to bear against the opportunities that are in front of us, which you know might for a product team be as simple as, you know, feature requests and bug fixes and things like that, and going into it and really hashing it out and coming out of it with a sense not only of specifics like, hey, we’re gonna work on this first and the second, but also who I’m going to work with, what’s exciting about the projects and Just a sense of being inspired because it makes concrete that next major iteration of work again against a mission that I’ve signed up for in my career or whatever team I’m on currently. And yeah, a great planning meeting is honestly a really enjoyable and inspiring experience and I come out of it thinking, OK, now I’m really excited for the work that’s ahead. 00:08:15 - Speaker 2: Yeah, one of the things I’ve learned, having experienced a wide array of planning processes and outcomes is that it’s a very a chemical process by which I mean in subtle ways it can go very well or very poorly, and a lot of it has to do with inspiration and motivation and interpersonal relationships and stuff. So it’s kind of a subtle process. It’s very easy to wear a lens in which you only see the mechanical stuff, you know, these tasks in this order and this assignments and so on. But I think the key to good planning is getting that alchemy right, and like you were saying, getting everyone motivated and aligned behind the vision. 00:08:48 - Speaker 1: Yeah, there does seem almost like a, I use the term working chemistry often, maybe we’ve talked about that in the context of team building and recruiting and so forth, but yeah, there is a special magic when you get the right people together, working on the right problem and you have a good plan. But it’s more art than science, that’s for sure. Yeah, when I reflect back on my own career, for sure, I certainly didn’t think that hard about it in the early days, but I think it was at Hiroku where I really started to think in terms of management as more of a first class concern, and the team was growing maybe more quickly there than other teams I’ve been on in the past, and I did end up going a little bit down the rabbit hole of say like agile methodology, which I found interesting or codified a lot of things that I thought were good about ways to work. But I also got really into say like project management software. So back then, yeah, you had probably Jira, there’s all kinds of different kinds of ticket trackers, open source and commercial that often had like the ability to do different kind of like timeline road mapping things and Gantt charts and you could do burn down charts and you could do all these things that seem to bring a kind of systemization to the work a group of people was doing. One that I remember liking was Pivotal Tracker, which was by a kind of a consulting shop in the Ruby Agile world we were part of and was really well made and encoded a lot of their processes, but using that product actually was an eye opener to me because it really encoded their team’s process and their teams. Way of doing things, which I think was good for them, but maybe was a questionable fit for us and indeed even through the course of Hiokku as the team scaled and as our needs changed and as the business was more mature, we just needed very different things all the time and so there was no one. Kind of single process and certainly no one single tool, and especially the more the tool encoded a lot of process and was really rigid and structured like a lot of these project management software tend to be, the more you’re forcing your work and your team’s shape into the software that encodes this process. Actually it was probably around that time I discovered Trello, which is still, I think, a great piece of software for its incredible simplicity, although I think to some extent the conbo boards built into GitHub issues and notion end up competing with it, but at least that had a certain simplicity, the swim lanes and the cards, and there’s a lot of different ways you can use that. It’s more like building blocks that you can use to develop your own team’s way of planning things. So I think it was the whole Hirogu experience that really took me into first of all, caring about this. As opposed to coming at it from the crafts person perspective, which is like, I don’t want to think about planning. I just want a process. I just want to get back to doing my work and I saw what a big difference it made to, you know, if you’re really all on the same page about what you’re doing, you just do a way better job and you go faster and you make fewer mistakes and you waste less work. And I started to care about it there, including the tools and the processes. What were some of your early experiences with planning, I guess, in the form that may have shaped how you think about it? 00:11:51 - Speaker 2: Well, at Rokku, I saw quite a range of both company scales and teams, so I sort of bounced around within the company, so I got a little sampling across both of those dimensions, and I feel like that taught me a lot, and we can talk about some specific examples if you’re interested. And then later at Stripe, that was a larger company, so I got more experienced with more involved and necessarily complicated planning processes, both because of the size and because of the complexity of a regulated financial services business. So I feel like I have quite the array of experiences to draw from for better horse. 00:12:27 - Speaker 1: Yeah, for sure. Well, and if you want to consider the low end of the scale there, you know, we started Muse, it was just me, you and Julia. So, you know, we just kind of sat in a room and said, hmm, what are we going to do? Well, how about this? I actually remember that at my very first business, even long before Hiroku, we just wrote everything we were working on on a whiteboard, the end, because it was me and one other person, right? And that really worked great for quite a while. But I haven’t experienced that bigger scale. I think for me the biggest, well, even company I’ve been a part of is around 100 people and you know, you can debate. It’s probably more about when you say team, does that mean the whole company? Probably not. You’re talking more about the people you work with kind of directly day to day, but you’re much more scaled up experience with Stripe, particularly I assume by the time you left there and they were getting a big company. I’d love to hear some more stories from that because that’s way outside my realm of experience. 00:13:22 - Speaker 2: Yeah, probably my most memorable planning experience at Stripe was, it was towards the end of my, my time there, and the company was getting bigger, solidly several 100 people plus, and we were just starting to grapple with company-wide systematic planning because the more informal and ad hoc processes that we had done were sort of breaking down, especially with respect to visibility throughout the company and dependencies, which are a big deal in a financial services firm. And so I ended up actually helping with this process whereby we did a company-wide planning and there was a there was sort of a template. I forget the exact form, but the basic idea is that a company had a vision and metrics and proposed projects for the quarter or the half, I think it was. And those were reviewed in several ways. Obviously the team worked on a draft plan. They were also reviewed upwards, so like the head of engineering or whatever would review engineering plans, but there was also a pretty elaborate dependency management exercise where I made a big spreadsheet. I think it had like 25 rows and 25 columns where each row and column was a team, and if you created a dependency on another team, so for example, if I was standing up a new payment method we needed to work with the risk team to ensure that risk was appropriately managed and the compliance team and the legal team and the infrastructure team and and the country team and so on. And so you would like fill in each of those cells in the spreadsheet and then the team that was kind of receiving that dependency would have to review it and basically sign off on it. It was sort of a forcing function because the problem we were having was Basically, product teams and other teams were quote unquote planning to launch a product and then like not telling people who are impacted about it, and then be like surprised and payment method or whatever. Not only was that a surprise, but often these products will get stuck halfway cause they didn’t have the full array of teams and support needed to actually fully launch them, so it’s kind of worse than doing nothing. Yeah, and so we had this huge spreadsheet and teams would go by and review and initially it was really bad because In accordance with kind of the original problem statement here, a lot of the receiving teams were like not aware of the dependency or didn’t believe they could support it or thought it was too much to handle or was out of scope or whatever, and so we had to iterate across the entire company on this huge like 25 by 25 spreadsheet over the course of a few rounds, but it eventually got much closer, like there’s a lot more green on the spreadsheet, you know, people were aware of the dependencies and could accept them and After that, we did some work and I hope that they have continued to do some work to kind of remove the need to have so much dependency management because the idea is, of course, that you don’t have so much dependencies. But that one really stuck out at me as one of our first big company-wide systematic planning exercises. 00:16:13 - Speaker 1: Wow, yeah. Also, I like you’re doing that on a type of a canvas, which might hint a little bit of why we think Muse is a good or canvas tools in general are potentially good approach for this kind of work. Yeah, well, the stripe example certainly reminds me of what I was exposed to just a little bit, kind of, let’s say indirectly through at Salesforce, and they had this kind of cascading top to bottom thing called V2 mom. Which was similar in some ways to OKRs, the details are different, but part of the idea is that, yeah, you need this cascade where things can go, we tend to use the up and down spatial orientation for, you know, senior management versus people doing the work directly, but you need this thing where the top level people are away from the day to day, but they also have maybe some of the longer term views on where the market is going and what the business needs, and so you need to kind of propagate information in both directions, and yeah, it is this whole giant exercise of dependency creation. And one thing that stuck with me from that time was, I was really trying to design the Hiroku organization and now we were getting into this like I don’t know, 75 100 people range where individual teams to kind of have their own autonomy and dependencies could be kind of expressed through APIs, but as much as possible, we try to just not create dependencies because, you know, we all know from software development systems that you want to keep your dependencies to a minimum. But I have a very distinct memory of spending time with a fellow named Jasper Jorgensen, who had come over from the salesforce side and had a lot more experience working in larger companies, and I was kind of articulating this to him and he said something that really stuck with me, which is basically why did you join a company if you just want to work independently on something. You wanna work independently, you know, you could be a freelancer or a really small team. The reason to sign up for a company or a major, you know, department and a company working on a single product is you can do more with that larger group, but then by definition you need those dependencies. The fact that Stripe, for example, has to launch a payment means you need to also think about Fraud, and you need to think about legal implications and you need to think about all these different things across the business. That’s sort of a feature. They can be big and do big things in the world and have this global impact because of that, but the cost of that is call it just coordination. 00:18:40 - Speaker 2: Yeah, and people like to, you know, dunk a little bit on V2 mom or make fun of it because it’s a five letter acronym comes from Salesforce, whatever. But in fact, I think it’s actually pretty close to the archetypal planning process. Like, regardless of how you do it, we’re going to talk a lot about a lot of different techniques and kind of methods that you can actually run the process with. I think most planning processes need the following, the team needs a vision or a destination, call whatever you want, but it’s where is the team ultimately trying to get. They need something like a strategy or values that is how are you getting there? They need to determine what they’re gonna do. They need some way to manage dependencies or obstacles, and they need some way of measuring if they’re being successful. And if you happen to read out B2 mom, I think it stands for vision, values. Methods, obstacles, and measures, something like that, you know, it basically maps correctly and even companies that don’t adopt such a formalized and rigid process, they end up more or less there. Uh, one thing I forgot to mention is you need the cross team dependency management, you also need the up and down review and harmonization, and that’s also part of the BTO process because they’re meant to roll up. So you can kind of call whatever you want, you can make up your own acronyms or keep it less explicit, but I do think that’s the basic core of a planning process. 00:20:00 - Speaker 1: Yeah, now I guess to contrast it, we’ve been talking about these very big company, heavy-handed, lots of uh cascades, vertical and horizontal. In contrast, on a smaller team, like on the Muse team we’re 7 right now, and It’s still just as important to plan our work to understand where we’re going, to know how we measure success, to know how we’re dividing things up, who’s working on what, who’s working with who, how we can all help each other best, how our work depends on each other either kind of in a technical sense, but maybe also just in a sequencing sense it makes sense to do this thing first and this thing second. And so, of course, it’s a much easier, and the easy is quite the right word for it. You just don’t need to be so heavy handed. So if you take the very far low end is the example I gave before my first business was me and one of the person we sat in a one room office together and we had a whiteboard and we just wrote stuff on it and that was kind of the end. You know, a step or two up from that would be something like what the news team does, where we basically have a weekly planning, what we call a chapter planning, which is roughly 1 quarter where we look at bigger picture things. We like to pair that up often with team summits where we can either meet in person or really just like set aside a lot of time to step away a bit from our day to day work. But it also includes, to me, that kind of umbrella of planning includes something like strategy, right? How are you tackling the technical challenges of, for example, we chose to start with building device to device syncing because that was a subset of the bigger problem of the multiplayer that we eventually wanted to go to, that’s the strategy, right? And it also includes something like retrospectives, which I think of as an end cap to a project and I think are really important and again similar to the planning upfront, whereas it is much about the energy and the inspiration and the teamwork, a retrospective is not just about, hey, did we achieve what we set out to do or some accounting of that, but also a discussion of what worked for us, how did we feel and how can we Do more of the stuff that feels good and works well and allows us to be productive in the future and less of the other stuff. And so there’s some combination of those things, right, planning and project proposals, a strategy, kind of the big picture, quarter planning, the weekly planning, the retrospectives on some regular cadence, um, that all of that is. I guess it sounds like a lot of stuff, but you can do most of that in a pretty straightforward way for a team as small of ours. It’s not a huge amount of time, but it’s incredibly valuable time and also time, I think I certainly and hope I speak for others, you know, enjoy this time. We get to come up from our work, you know, the heads down work, take a breather, look out at the larger vista, think about where we’ve been, what we’ve accomplished, and where we want to go, and, you know, get excited for what we might do next. 00:22:53 - Speaker 2: Yeah, and you’ve identified something that I think is really important, which is a nested periodicity to planning. So the most common period that teams will have is 1 week, some teams do 2 weeks. So that’s like one phase. Most teams also have something like we have our chapters, which is once every 2 months or so. Some teams have quarterly, big companies might have once every half. Some teams have every day with stand up, and sometimes you have like every year planning, especially around financials and then. Typically every 34 or 5 years you have kind of a phase change where you do a big reset and you talk about a new strategy and stuff, and I think it’s important to have a variety of periods, and it’s important to have a notion of cycling and change, cause if you just kind of go at one speed forever, you never look back, it just doesn’t work well, you get kind of stuck. And even if you cycle weekly forever, you get stuck in your weekly mindset. And so I think it’s important to have these different phases where you’re accomplishing different things, your daily is very tactical, it’s unblocking, whereas your big quarterly plan is stepping back, it’s strategizing, it’s thinking about if you need to make big changes. So I’m a big believer in having those periods, having them be different, and having a sense of beginning and end, and resetting with things like planning versus retrospective at the end. 00:24:09 - Speaker 1: Yeah, I really like your idea of like a rhythm or a cycle. It almost sounds musical to me, which is something where there’s a, or maybe even like the fact that we have cycles and rhythms built into our lives through the rise and set of the sun and the week versus the weekend and then something like the seasons or something like the holidays and the year’s end. It sort of builds in these different overlapping cycle sizes that are somehow it seems necessary or important to human experience, something like that. 00:24:42 - Speaker 2: Yeah. So typically with kind of the core planning around tasks, you need to understand what the possibilities are, what you’re gonna work on, and who’s gonna work on them. And so a lot of the mechanics stuff that we’ll be talking about is basically how do you do that. So with the effort to impact Matrix, basically anyone could suggest a project to work on, upgrade the postre version or convert to the new backup system or whatever. And once that was submitted to the team, the team would discuss where it goes on this. Two dimensional graph, how impactful is it to customers or if it was internal facing to the team, and how much effort is it? And this is very rough. It’s kind of like a 3x3 type thing, and having more precision than that is probably false, and it seems very basic, but a, in the process of Choosing where to place it, the team has to really chew on the item. Like, you gotta understand what you’re actually talking about, what the benefits actually are, a little bit of what’s entailed, so that helps concretize it for the team. And my experience was that often it was kind of surprising where stuff ended up like. There’s been this project you’ve been talking about forever, and everyone’s really wanting to do it, and then you place it on the Matrix and it’s like high impact low effort. Well, there you go, that’s why I never did it because it’s just not really worth it. 00:25:54 - Speaker 1: I’m guessing you meant the opposite of that. 00:25:56 - Speaker 2: Oh yeah, yeah, right. 00:25:58 - Speaker 1: High effort, low impact, yeah. Yeah, yeah. One thing I like about the effort versus impact scale is another good example of we’re using some visual thinking to lay something out is a nice way to have a concrete discussion about it. And I guess you can do something like story points or you can estimate the number of days something is going to take or estimate the I don’t know, percentage increase in active users or revenue you think something’s going to make, but this all seems just way too specific. Like that’s not the level of the discussion you’re having, but you need to be more concrete than just like, I think this project is important and will be hard or not hard, so that lets you take it a little better and put a whole bunch of things together and kind of compare, you can see where just things are grouped spatially in that sweet quadrant. And maybe there’s things in quadrants that are still high impact, high effort that you actually have to do for your strategy or for other reasons, but laying that out just creates a high level understanding and a conversation on the team that I think you wouldn’t be able to have just a like, I don’t know, a plain text list or something. 00:26:58 - Speaker 2: Yeah, and this question of to what extent one can estimate a project is certainly a matter of debate. I have a somewhat contrary opinion, which I think it’s actually pretty possible to estimate engineering projects. It’s hard and it’s a skill, but it can be done to a reasonable level of precision. But yeah, even the low medium high is not bad. One variant that I’ve used that does lean a little bit more on estimation is basically having the team work together to draw up a sequence, prioritized list of projects, and then as a separate exercise, draw the line. Now you can just eyeball the line and say, I think this is how much we can do in a quarter, or you can actually go in there and estimate how many weeks you think this will take and then add up until you get to 13 or whatever. I’ve had pretty good luck with that. Now the most character version of that is, don’t do this, is you have the product manager write the sequence list, and you have the engineering team write the estimates and draw the line. I say it’s character because there’s some truth to that, like there’s some truth to the engineering team as the best sense of how long stuff it’s gonna take, and people who are spending more time with customers have a good idea about what’s most valuable. But as I think we’ve been applying throughout this podcast, a good planning process is collaborative and energizing, and it’s not people telling other people what to do. 00:28:10 - Speaker 1: Exactly a theme that runs through all of this, whether it’s a big company or a small team, is it’s really about building our collective knowledge. And if it’s something where the boss is just telling you what you’re going to work on and you basically say, OK, or add a little detail, first of all, that doesn’t sound like a great environment to work in, not one that’s very inspiring, and I think for creative work, it’s important to be sort of invested and feel ownership in that. But secondly, it really is about the fact that there is knowledge in all these pockets or in everyone’s domain. So whether you talk about the vertical dimension of you’ve got company leadership who has big picture strategy and markets and you know, what do we need to do to raise financing or These kinds of things in their mind, you’ve got something like product managers who are maybe or support people who are close to customers and know their pain in a deep way that others on the team can’t, engineers who know what’s possible with the technology, not just how difficult something is in the sense of like how long is this project going to take, but also just in the sense of Yeah, what the technology can do, and you need to put all of those things and others together to get this like shared brain, shared understanding of all the elements of the business. And that can be very hard to do because yeah, we all even in some ways speak different languages or have different subsets of jargon for our different areas. We’re at different levels of zoom on the business, but bringing it all together and to me a good planning session, and again, I’m using that kind of as a theme that cuts across all these things we’ve talked about like weekly or quarterly. A big part of it is for a moment trying to see if we can extract all the most relevant pieces of information from everyone’s domain and bring them together, so no one’s telling anyone else what to do. We’re creating a shared understanding from that comes a plan of what to do that we all feel ownership for and then when we go off to You know, do our heads down work or go into our craft, we’re working off that shared plan where if we for a brief moment, brief beautiful moment in time, we understood the problem in a totality that no single human could do. 00:30:20 - Speaker 2: Another technique I’ve seen that leans into this is embracing individual excitement about projects, so you might start by having Any candidate projects be pitched, and a pitch is like a new board or a one-page Google Doc, something like that, you know, it’s a little bit more than just a project name, but it’s not meant to be heavyweight, and that’s meant to be. Exciting and energizing to the team. So you write out this document, perhaps you review it beforehand with the team. Perhaps you even do some one on one discussions to get some initial feedback, and then you basically pitch it during the planning process, and then you can complement that by using people’s excitement about a project to determine what to work on. So the most pure form of this would be basically, you put a bunch of these pitches on a new board and people put like emojis for their avatar. Next to 3 of them that they’re really excited about, and that could be their excites they want to work on it, they’re excited, they think it would be good for the company or, you know, some amorphous combination, and I don’t think you want to use that as like the only mechanism, but I like you were saying, there is information there, whereas certainly if no one’s even willing to write a pitch for something, but also if someone is excited about it, but they don’t want to work on it, you know, and no one’s excited to work on it, that’s also a data point. Mm. And you can kind of mix and match these techniques, so you could do the effort versus impact to get some candidates and then have people self selecting what they’re excited about, and then you might have some that are empty, even though they’re high impact low effort, you might have some there people are so excited about, so you kind of dig into that and combine the methods like that way. 00:31:56 - Speaker 1: I’m just such a huge fan of driving projects on what people on the team who have the right contexts, right? If you’re brand new on the team, you basically just need to be handed something because you don’t necessarily know what to be excited about. But once you do have the context, the thing that you are driven to do, you’re going to be able to do that at both a level of quality and motivation and instigation energy that is just different from something that’s sort of assigned to you. One little anecdote I have on that actually does come back to the Hiroku Department of Data, which is that was essentially formed when Peter Van Hardenberg, who now runs Ian Switch, he’s been a podcast guest in the past. He was an engineer working on some elements of the Roku system, and he kept coming to me to complain. I think our database needs a complete overhaul. Our database product is absolutely critical. People care about their data so much, it’s key to the scaling of the app. The product we have is not very visible and you know hard to work with and not very scalable, and he just sort of kept complaining about this and I kept basically saying, OK, you know, pitch me on a proposal for what, how this could be different, and eventually that kind of man on fire energy in him, he just couldn’t take it anymore and basically kind of in an entrepreneurial way. Came up with a proposal for what this could look like to have a separate team that’s dedicated to this, a product that is even sort of branded separately, has kind of an identity that’s almost a little separate from the Haruku core platform, and he went on to lead and grow that team and build what is honestly one of the best parts of the product. I know lots of folks who use just the database and even the rest of it in some cases, and obviously we use the whole Hiroku platform as well as the Hirou postgras database for quite a lot of our muse work and yeah, it’s really something special, but they don’t always go that way. But in my experience, the best things come from, yeah, the people who are going to work on it are also the ones who are really driven. To do so, rather than the boss identifies this as a business need, they identify this person over here has the right skills, they say, I think you should work on this, and then that tends to be a little bit more work a day. 00:34:12 - Speaker 2: Yep, this reminds me of another tool for the toolkit, if you will, which is trying to convince one other person or to get a lieutenant. What I often see is, especially managers, they want the team to do something, and then they tell or try to convince the team. Well, teams don’t decide things, individual people do. So advice I often give is if you want to do something or you want something to change, try to convince one other human being that that’s a good idea. And often people really struggle with this, and it’s a sign that they haven’t, you know, fully contemplated their situation, and that can be used by manager, but it can also be used by an individual. An individual wants the team to change in this way, I want the team to take on this project. You just convince one of your teammates it’s a good idea. That’s really going to encourage you to flush it out, to strengthen the idea, and once you’re successful, now you have an advocate who’s working to spread the word on a team. So it seems so simple, but I’ve often seen it work really well. 00:35:08 - Speaker 1: I’m reminded of this little video from years ago, I think it’s called Leadership Lessons from Dancing Guy, which is really all about that exactly what you said, getting that first other person who’s with you, and that that’s the start of all of it, or of doing anything big or anything great. So yeah, I love that approach. And you also mentioned kind of related to the finding one other person to convince or to work with you on it. You mentioned the project proposals or the pitch and what form does that take? And to me this is a key part of how I think of the muse way, both in the sense of how our team works, but also what potentially the Muse collaborative product, why it is useful for this kind of planning and strategy work, which is You can sit there and say, OK, I’m really driven to work on a database product or do something within our company that I think we should do, but what actually does that mean? And you can describe it in some words, you can, you know, write a few lines in the Slack channel or something like that. Very often I find, I say, oh man, we should just do this. It’s so obvious it’d be great. And you know, you write three lines about it and the people who I expect might understand what I’m saying are kind of like, huh, I mean, Like I trust you, but what? And that additional level of detail, whether it is, yeah, Google Doc, a notion page, something like that, and of course we think a new board is a really good place to do that, but something where it is fleshed out in more detail in the sense of like, here’s what it could look like, here’s some goals we might have, here’s some things we maybe are not trying to do. Here’s some inspiration we’re taking. Since at least for me, very often I get inspiration from looking at maybe a product in another domain that solves a problem in an interesting way and I go, oh, you know what, we could do something similar to that in our product, and that would solve this long standing problem we’ve had or customer request we’ve had or whatever. And so putting those things together and it seems so obvious in my mind, but you know, other people don’t have the contexts that I have. But if you can just put that into a little bit more detail, a couple of pages or a board that explores it a little bit. Now you have something concrete to talk about and indeed this project proposal we have a template built into Muse for that, but I think there’s a lot of different ways to do it. But the key thing is that planning isn’t you show up and say, huh, so what should we work on? Let’s throw out some ideas, you know, it’s actually having some developed ideas that you can look over, contemplate, discuss in smaller groups, and then come together and kind of compare in various ways, including something like the effort versus impact matrix. 00:37:48 - Speaker 2: Yeah, and with these pitches or proposals, I think it’s critical to make concrete what the customer is going to see, whether that’s an external customer or an internal customer. It doesn’t need to be at a very fine level of detail or refinement, but it needs to be concrete and it needs to be through their eyes. So easy as an engineer to write. Like we’re gonna make a new API or we’re gonna make a new feature. What is feature, you know? Show me like 3 little screen mockups. User clicks here, they see this text box, they press enter, it takes them here, and it could take you like 5 minutes to draw all that, but it’s so much more concrete when you have that. and relatedly, I think it’s critical, assuming you’re doing a project and not like an ongoing program, unless you really know what you’re doing, you should be doing a project, it needs to have an end. How do you know when you’ve finished and how do you know that it’s worked? Ideally with some sort of metrics. Again, I’ve seen so many proposals where it’s basically a direction and not a thing to do. So in order to be done, you need to know what the definition of done is. So if you explain what the customer is going to see, when you know you’re done and how you know it works, you’re basically gold and everything else is gravy. One format that I really like is the Amazon working backwards format where you actually write a blog post of what the customer is gonna see, and I like this because it actually forces you to confront some really important things. What’s it called, what’s the name? How is the customer going to be introduced to it? Like where are they going to find it? What’s the entry point and what does that initial flow look like? And the best of these are done with like concrete examples. So if you’re using the example of AWS introducing a new API, you’re actually show a call request, you know, you can post V7 slash servers and you get an EC2 box or whatever. But then doing that again, it seems so simple, but you’re grappling with, oh wait, what are the parameters here? What are the different scenarios I need to consider, how does it affect pricing, things like that, how does it relate to other products in the suite. Another thing that, especially for internal stuff that I often see is with respect to other internal efforts, does this replace or is in addition to existing stuff? So oftentimes I see these proposals that are proposal to migrate to a new system. Well, critically, does your definition of done include shutting down the old system or not? And you have a reasonable plan for getting there, including a metric that tracks it all the way to zero. But again, the specific format isn’t as critical as I think adapting the customer’s viewpoint, what are you gonna do, how do you know when it’s done. 00:40:14 - Speaker 1: Yeah, the press release driven development, I think I’ve heard the Amazon method called sometimes. I’ve also heard a variation on that, which is read me driven development, maybe for more developer focused thing, but really if you have to write, not the real documentation or the real blog post or the real press release, but a mockup of it where you’re explaining. Yeah, what it looks like, what it’s called, but especially critically to me there is just what’s the benefit? Why do I care? Right? And it’s very easy and especially if you get into something that’s infrastructure related or optimization related or something like that, but there are almost always is a benefit to the end. User somewhere or if you can’t find that, then maybe this project isn’t worth doing. So sure, the project is actually replaced the caching layer with a blah blah blah blah blah, but the benefit to the customer is this thing that you do all the time is now twice as fast as it used to be. And that’s great because XYZ, right, or it’s more reliable in these situations, a lot of people have reported frustrations when in this moment they get these certain errors or it goes slow. That won’t happen anymore because of this change. 00:41:22 - Speaker 2: Now, this talk about pitches and proposals and pre-planning artifacts, it kind of raises the question of who does that and when. So the failure mode that I’ve seen here is if you’re running a team at 100%, everyone is always booked all the time with tasks from Jira or whatever, you come to the planning, people are exhausted and they have nothing prepared. They don’t even have the mental headspace to think about it. So I think you need to create space one way or another for this sort of work to happen now. Listeners of the podcast will know I’m a very big fan of Slack, and this is one of the many reasons why it’s helpful. 00:41:59 - Speaker 1: If the team is running at say 80s, the concept as illustrated by a management book we go both like rather than slack the group chat product. 00:42:04 - Speaker 2: Yes, correct, thank you. So if the team is running at, say, 80%, you might say, oh, we’re wasting 20% of our time. Well, for a lot of reasons that’s not true, one of which is now you have some time to think and write out the stuff, and it might even be worth scheduling a block of time, you know, schedule a week for someone to research, scope out, sketch out, gather feedback on an idea. This is one of those things where it’s go slow to go fast, it’s an investment that really pays off. 00:42:37 - Speaker 1: Yeah, the technique we end up using on the Muse team is something where we have these sort of team summit weeks that are the break between our, again we call them chapters, roughly quarter time period where we typically are still doing work on the app, fixing bugs and There’s always stuff like that to do, but we try to as much as possible, have wrapped most of the big projects, have plenty of space, like explicitly in that week, you’ve got 50 to 70% of your time is slack and your Expected to spend that on project proposals, but also other kinds of just thinking and high level reflection about like what’s really working here, what are the big gaps, what is it that we’re excited to do in the future, what are we worried about and often that manifests in the form of project proposals, but it could also be something like a deep dive into, OK, we have all this technical debt in this area, or let’s do an honest assessment of this whole. Part of the product has been this way for a long time, but actually I think there’s some problems here. I don’t know what the solution is, but I think we should think about it. That kind of more open-ended thinking and higher level thinking, you just need the space for it, and we try to explicitly make that in a time when basically the whole team can be in that headspace at the same time. I’m curious how far that would scale, probably not super big, but it certainly works well for a team our size. 00:44:00 - Speaker 2: Yeah, and I think it’s not just wall clock time but like headspace that you need. So I think we’ve even done it where the week before you start to create that space like you’re not taking any big new projects, you’re working on smaller projects, you’re tying off loose ends, you’re doing bug fixes. And maybe you take Friday off, you’re starting to build up some distance and perspective, so you can have reasonable things to say going into the planning and maybe even starting to prepare some of those artifacts. Again, this is embracing the periodicity and every week not being the same. 00:44:31 - Speaker 1: One other principle that I think is embedded in some of what we’ve been talking about is the relationship between planning and a planning meeting. And I think a version of it that doesn’t make that much sense to me is thinking that the planning meeting is all there is to planning, and that is the thing that probably tends to produce, first of all, very long planning sessions where it takes a lot of time to get on the same page, which can, especially if your remote team can lead to zoom fatigue and all that sort of thing. But I like to think of planning as a session. And obviously the what you’re kind of planning for the scope of what you’re thinking about if it’s a you just finished a huge research project, for example, thinking of something like the research work on it and can switch where we have multi-month projects or even longer, and you want a lot of time. To think about what you’ve learned and how you can improve in the future and then what’s going to be next, whereas obviously a weekly plan, you don’t need a ton of time for that. You have the context already, you’re just kind of organizing the tasks for the week ahead. But regardless, I think the session is a super set of the meeting. And for me, the meeting ends up being, I guess the ideal world is sort of an end cap, and depending on how good you are at Assync and the tools you’re using and how much shared context you have and so forth, the planning meeting can largely be a matter of Reviewing what you’ve already kind of explored through some kind of asynchronous or documentation system and basically say, OK, yeah, I think the plan here is obvious, we all agree, let’s look each other in the eye and commit to what’s ahead and we feel great. Let’s go, and it can actually be pretty short in some cases. Now, not always, sometimes you dig into it together and things come out with a higher bandwidth of, you know, conversation and Especially if through even just emotional resonance, you see that there’s something unresolved and you need to dig a little deeper. So a planning meeting can be very important, but to me, the planning session is the superset of the planning meeting and all the other work you do around it. 00:46:35 - Speaker 2: Yeah, for sure. And remember, at least in a larger organization, you’re gonna have an iteration around reviews and peer team checks and dependency checks, so it’s definitely gonna take some time and remember that some of our best and most important thinking can only be done when we’re asleep. So if you try to do it all in one shot, you are almost by definition, not gonna be successful. Now for like a weekly planning. You can do it in one shot, but for things that are like what we call a chapter, which is maybe 2 months, quarterly, certainly longer than that, I think at a bare minimum, you’ve got to separate the time where you initially read on the proposals and when you discuss and decide. I like what we do at Muse where we have like 3 phases, there’s you’re generating and reviewing the proposals asynchronously as they’re being accumulated in the news board. And then you have a discussion section where you basically chew on the proposals together. People present about them, you ask questions, you know, you poke at them a little bit, talk about the impact and the feasibility, and then go to sleep, wake up, and then you have a decision time, which is a separate third thing, and you know, takes some time for sure, but I think there’s a real benefit to that. 00:47:48 - Speaker 1: You know, I think it’s one of those things where the time spent up front can save you a lot of time from going in the wrong direction, not being on the same page, and just the frustration of working across purposes with your colleagues or having a bunch of your work thrown away because you just literally misunderstood each other or didn’t generate that collective knowledge, that shared understanding correctly or well enough. So I do think of it as something that is a small investment, and we don’t want to spend our whole lives thinking about planning the work because We need to go and do the work. Indeed, that should be the bulk of the time that we spend, but the difference between, for example, those three sections you just talked about that we’ll do for the longer range planning, in the end, that’s probably around 3 to 5 hours. Which maybe could you cram it all into like a 2 hour meeting and just try to make it happen that way, probably, but I think the benefits over the course of the coming months or quarter as you’re able to be on the same page, that consensus about how things are working have previously dug out what some of the risks or potential complications are, is just pays so many dividends. Now when it comes to these longer term plans, yeah, quarter or half a year or even a year, how do you think about the fact that, you know, plans naturally change over time or can change, or do you think it’s important, especially with a larger group that you really make your plan, you commit to it and you don’t deviate from it unless you really have to. Or do you think of something as a plan, as something that can sort of morph and change throughout the course of the time period it represents? 00:49:28 - Speaker 2: No, I think your plan can and should evolve over the course of the period, but I think that should be a deliberate act, because remember, a big part of the plan is having people aligned, and if you change direction without kind of telling people and agreeing on it, you’re gonna defeat the purpose. I also think it’s important to note. And like a durable append only way when the plan changes or your actions or metrics don’t meet the plan for some reason, because when you go back and do your retrospective in your next planning session, and you’re definitely doing retrospectives as part of a healthy planning process, you need to take in that data to understand what happened, what was surprising, what went wrong, what changed, so you don’t have the same thing happen again in the next cycle. This also becomes more involved. We have a larger organization, you’re dealing with dependencies and alignment up and down the staff. They’re a change in plan or a metrics miss or a goal miss that needs to be flowed through, basically a whole many process again where it’s reviewed and it’s flowed out to the relevant teams. 00:50:33 - Speaker 1: Yeah, exactly, because our work all affects each other. I mean, it should. That’s why we’re all here working together on something and you know, you don’t necessarily want to deliver bad news, so it turns out this is harder or impossible than we thought, uh, or it’s going to take longer than we thought or has these additional risks or complications, but you certainly, it’s important to share those things if they’re real and true because they are going to have all those ripple effects. A phrase I like to kind of have in my mind is, when in doubt, revisit the plan. And I think there’s sort of twofold things. If you get into it, you know, you make your big plan together, everyone’s excited, this is going to be great. You get a little ways into it and just the reality is sometimes. You discover new information that you really couldn’t have only have gotten by trying to do whatever the thing is you’re trying to implement an algorithm or do a design or I think it was something like a home improvement project where you know, classic and like an old building or an old house, you go to open up the wall thinking you’re going to install some new electrical thing and then there’s something completely unexpected in there that’s different from what was in the blueprint or something is rotted out or whatever and yeah, you just discovered something new and very relevant that will have a material impact on what you’re trying to accomplish. But one of the reasons I like to have that, you know, doubts mean revisit the plan is that you can either one, take that new information and as you said, flow it back through the plan and the people and everything that’s affected and make sure that the updates happen in a way that allows you to avoid wasted work and confusion. But also sometimes the other thing happens, which is you get in, you’re in the nuts and bolts the day to day of it, you’re not thinking about the higher level thing, finding some doubt or getting lost in there somewhere, looking back at the plan is often like, oh, actually, you know, we thought through all this already when we were in a more zoomed out mode, we actually already anticipated this. We had Basically baked that into the plan and we just lost sight of it a little bit because the day to day. So either way, whether you realize there’s information that needs to be reincorporated into the plan or actually your plan is good, you just sort of forgot some of the higher level details because you were absorbed in the day to day. Either way, coming back to that plan will restore the clarity and help you get back on track. 00:52:50 - Speaker 2: Yeah, and it’s interesting that you mention risk. I think strong project managers actually really lean into this. I like the information theoretic lens of project management and with respect to risk that means Really the game is to get risk to zero. So if risk is in fact zero, you just turn the crank and you win at the end. And the way you can operationalize that is to identify your, your biggest and most important risks. As early as you can and then systematically eliminate them, you know, confirm that they’re in fact not an issue or surface that they are in fact an issue and why and address it. So often you’ll see in planning templates there’s like a risks section, and if you successfully identified the risk, that’s already half the game because then you can get out in front of it and start tackling them. 00:53:37 - Speaker 1: I agree the risk orientation mindset is a good way to go about doing at least the kind of work I like to do, which tends to be in more innovative products, yeah, startup or startupy type things. The fact that they’re not well known is exactly where the opportunity is. I always was surprised years ago when I learned that venture capital is venture is basically short for adventure or shares the same route. And it’s the idea that, you know, I think of doing a startup or some kind of innovative product as being a bit like an explorer that’s setting out in an unknown continent and wants to find something, reach the ocean on the other side or whatever. And You can’t know what’s there. That’s actually the whole point. That’s the whole reason you’re there is to explore and the opportunities that that presents, but that also means that you can sit there and go, well, you know, maybe there’s snakes, maybe there’s a mountain in our way, maybe we’re gonna run out of food. These are to work in your plan and plan around and that’s just part of the experience. So risk as kind of a desirable quality in the sense of that is the other side of the coin of opportunity of working in a new space. And we’ve mentioned retrospective a few times. Do you want to briefly say kind of how we think about those and why we think they’re important? 00:54:59 - Speaker 2: Yeah, well, in terms of why they’re important, we’ve been alluding to it throughout this podcast, but there’s a lot to be learned from the work that we’ve already done, and it takes some effort to actually surface those things and to process them as a team. These things are often stuck in individuals' heads. Often people don’t even realize that they’re there, you know, the individuals don’t even realize that they have these facts or emotions. So retrospective is a process of getting that out and metabolizing it as a team. And in terms of how to do it, we could talk about a lot of specific techniques. But as with planning, I think there’s a basic architecture. There’s understanding what happened factually, which sounds like it should be easy, but with big complex teams, often it’s not. How do we feel about it, you know, it’s a good, bad, and so on, and what do we want to do as a team as a result of this information? I can give you an example, concrete retrospective process. So we would do this on a canvas. Actually, I think we did it on like the Google drawing program back in the day, and the first phase would be, you would like draw a timeline. Where the left is the start of the quarter and the right is the end of the quarter, for example, and then people would just like put stuff on a timeline that actually happened. They would like go back and look at their calendars and look at their emails, and look at the blog, and see, OK, this is when we launched this, this is when we got this page of duty alert, and these are other things that happen throughout the quarter. That’s the what actually happened face. It’s quite important to have all that raw material out there. 00:56:28 - Speaker 1: And I think even just visualizing it that way or zooming out and looking back, you might actually realize things just from that, which is you go, you know, this 3 week period here was full of like we had these 3 incidents and this thing happened, it all stacked up at once. Everyone was stressed out and upset around that time, and at the time, maybe I was feeling. Just hypothetically here I’m saying like I was feeling like I wasn’t doing my job well or feeling bad about myself, and I look back at this now and I go, that was a tough time. So actually, you know, there’s a reason we’re feeling that way. 00:57:03 - Speaker 2: And this leads naturally to a phase two, which is like the the reaction phase. So one way we did this would be make a new Google drawing document, and anyone can put items in the document to represent things that we should start doing, stop doing, or keep doing. So maybe we want to start doing. Have a more robust on-call cycle with backups and stop doing is deploying on Fridays, and keep doing is using page of duty for learning, you know, but the idea is that anyone can put stuff that they want, and then also people can put like reactions basically, like I really like emojis, but you can also do votes or comment
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: We’ll just say that I’m so happy that you are taking this forward and making sure this product not only continues to exist and be maintained, but indeed to grow because there really is nothing like it out there for unstructured thinking. Hello and welcome to Meta Muse. Muse is a tool for deep work on iPad and Mac, but this podcast isn’t about Muse product, it’s about the small team and the big ideas behind it. I’m Adam Wiggins here with my colleague Adam Wulf. Hey, good to be here again. Well, we’ll jump straight into it today because we have some important and honestly pretty bittersweet news. So New Software Incorporated is the company of course that you and I and the rest of our team work for Wulf, and we’ve been working to build this beautiful product. Unfortunately, I’m sorry to say we didn’t manage to find sustainable business. This is something we’ve been working on for 4 years now, and yeah, somehow the particular combination we’ve tried to do hasn’t worked, so we need to make some big changes. So in the near term that’s big scale down of the team. I’ll be stepping away from day to day activities. Most of the team is moving on, but the potential silver lining here is, well, if you’ve offered to step up with a lot of passion and vigor to carry on, use the product as a solo printer. So there’s a lot to unpack there and we’ll dive into that throughout this episode, but I just want to lead with that news and maybe we can just start with a feelings check. How are you feeling right now, Adam Wulf? 00:01:34 - Speaker 2: Yeah, well, it’s a weird feeling because I’m very excited about the future of Muse. We can keep the product alive, and I know we have a very energetic user base, and so I’m thrilled that Muse, the product will continue, but of course I’m very disappointed, frankly sad that I’m gonna be losing my teammates that I’ve enjoyed working with for the past 3 years. It’s been just a fantastic company to work for, and a wonderful group of people to work with, and Everyone will be sorely missed, absolutely. 00:02:09 - Speaker 1: Yeah, I’ll echo that. I’m feeling a lot of sadness, particularly around exactly what you said, the team. I really feel this is one of the best teams I’ve worked with, just the perfect blend of skills and personalities, really perfectly suited for what we were working on, great working chemistry, and yeah, I think I enjoyed the day to day of my job here at Muse the last 4 years more than probably any other venture I’ve ever worked on. And yeah, leaving that behind, you know, you and I will still work together as, you know, be in an advisory capacity, I’ll probably be a podcast host, so we’ll certainly be in each other’s lives and I’ll be in the muse world, but it’s a whole different thing from having a big team that’s, you know, fully engaged and working together all the time. 00:02:52 - Speaker 2: Yeah, exactly. I think that’s the thing that’s been emotionally so difficult or strange or confusing to some extent. is so much of the muse I know is Disappearing or changing because the muse I know is the 6 of you, right? And so it’s all of my team is leaving and that’s, you know, extremely disappointing. But then the other side of it is there’s a lot of muse that is staying the same. It’s the product is staying the same. We have the 3.0 release, uh, that a lot of our users are on right now and are enjoying, and that’s been a huge effort for all of us this past year. A lot of exciting plans coming up to continue Muse and to grow the feature set, and so, I really feel pulled in kind of two different emotional directions. One is honestly a grieving process of the group that I know and the group that I’ve worked with is moving on and is going to different chapters, and that’s hard, and at the same time, we use the product is continuing and I believe it’s gonna keep growing and has now uh Business plan that does fit, even though our current one, you know, unfortunately did not fit. I think there’s new. Business stability now, which is a great thing and really gives it a strong future. But it’s such a weird dichotomy in my brain. My left brain is thinking one thing and my right brain is thinking the other thing, and I’m still trying to, I think, to pull everything together and see it for what it is, but it’s a lot to process, I think, for everyone, for all of us on the team and all the new places we’re going. 00:04:36 - Speaker 1: Well, before we get into what the future holds, what the new era of Muse might be, and why there’s still a long life ahead of it, I do want to address what I think is going to be the first question people will have, which is, you know, what happened or why is this happening? It seems like things were going great. Again, you have this beautiful product, we do have thousands of customers, tens of thousands of users, and how could you not make that work and The answer is kind of complex and I’m not sure I even have fully deciphered it, but I’ll try to give an executive summary of where I see it now and then maybe in the future we can dig a little deeper. So I guess to go back in the history, of course, Muse was born out of the ink and Switch research lab, and the lab’s charter. to look at how we can make productive and creative computing better, seeing the ways that computing has gone in the direction of consumption devices and sort of different forces, economic and social and so on, pulling on how our computers work and that having this effect on using computers for productivity purposes. And the lab explores a wide range of research around that, and some of that research ended up turning into, or a subset of that was something we said, hey, we think there’s something commerciallizable here or something that could be turned into a product that could be not just a research project you read about and get inspired, but you can use in your daily life and you can experience what would it be like to live in this world that I can switch visions where computing is different from what it is today. So we took, yeah, all this advanced research on gestures and tablet devices, things like the canvas and canvas stuff, and obviously the local first sync, as well as many other ideas, and said, let’s take this, take a bunch of these weird ideas and see if we can put them together into this commercial product. And in some ways, maybe the simple answer there is the ambition of trying to do all of that, particularly in this emerging category, tools for thought thinking tools or infinite canvas. It just takes a lot. It takes a lot of time, it takes a lot of talented people, all of that means money, but we didn’t want to go down the venture capital road because we felt that might create some wrong incentives relative to the things we wanted to express about this next generation, creative or productive computing. And so we sought out this kind of unique blend, you might call it a middle ground between, you know, on one hand, we weren’t like an indie developer just building a one-off app, maybe consulting until they get to something sustainable, you know, pure bootstrapping, but we also didn’t want to go the venture backed thing, fast growth, etc. We tried to go this middle ground, we took a little bit of investment money, but we charged very early, we charge a premium price, we tried to be customer funded. And we hoped that there would be this middle ground. I think you see that reflected in the size of the team, right? We’re 7 today. It took us 4 years to grow to that size. You compare that to a venture backed company that might be at 30+ people or more at that age, or, you know, the other extreme, the sort of indie solo developer who might work for many, many years before even hiring the first person, so we’re in that middle ground. And I was hoping that would let us do what we wanted and kind of turned out it was just like a middle ground that didn’t work. And so essentially that leads to kind of why we’re doing what we’re doing now is we’re saying, look, we got to get out of that middle ground. And so one way to do that is raise a big venture round and we did explore that a little bit, but another way to do it is scale way down, make it into something kind of sustainable quickly and for the long term by essentially making the team down to exactly one person. So there’s tons to unpack there. I am looking forward to the opportunity first of all, to personally reflect in retrospect on this, but furthermore, I’d love to write an article for my personal site or maybe we explore it on this podcast or who knows, something like that where we can dig in a little bit more because I think we made a lot of really good moves and a lot of great bets. But also maybe there’s some things that didn’t work and particularly about the model of how we wanted to finance the company and the size of the team and our ambitions and whatever and so maybe there’s some learning there for either other companies that might come out of the research world later or just others that want to follow our model. So hopefully that’s a somewhat satisfying answer for now. 00:08:44 - Speaker 2: Yes, I think back at the 3 years that I’ve been with Muse and everything that we had set out to accomplish. It’s really amazing how much of that we have accomplished. There’s a new product segment now. Canvas tools and whiteboarding for thinking tools. There’s 1000 of these now today in in Muse’s footsteps, and we were really blazing the trail there as we started out 4 years ago coming out of In Switch. We have a local first strategy, all of the data is physically on your device. We built out local first sync, which is kind of unheard of and is still at the research level but is working in production as good as any other sync and faster in many ways. And then that last thing is the shape of the business itself, larger than a single solo developer but smaller than VC. And it’s such a difficult thing to do new things, and I’m incredibly impressed at the number of new things that we’ve done successfully. And it’s just kind of a shame that one of those new things that didn’t quite work out was the business side, was just the structure and shape of how we’re funding this business. 00:09:54 - Speaker 1: Alright, so that’s a little bit about the past, but let’s look forward to the future now. What does this mean for current new users and customers? And in particular, this is a very interesting one because you’re stepping up in a big way here to provide some continuity and some continuation for this product we all love. 00:10:13 - Speaker 2: I think there’s two questions in my mind. One is, what can customers expect today? And what can customers expect tomorrow? And today, everything keeps working. Ms 2 keeps working. We have the Muse 3 Beta, which is either released by the time this podcast comes out or it’s gonna be released very soon. That has a whole host of new features. Collaboration, so you can invite friends and family into your muse board, you can invite your teammates into your muse board. You have separate workspaces, so you can separate out the sharing parts of your thinking versus the private thought sanctuary of your thinking. So all of that stays the same and is even growing in the very, very near term, which is great. And then for tomorrow, looking ahead, what happens 6 months from now, what happens a year from now, I am eager and excited to continue Muse development, and that means continued bug fixes, of course, continued customer support and customer conversations. I’m gonna be talking with a lot of you. I know a lot of you are already in our Discord community, which is fantastic. And there’s gonna be lots of new features. Over the past years, we have had goals and visions, as every software product does, that are larger than you could build an eternity. And there’s just so, so much and so many exciting things that we’re looking forward to building, and I’m picking up that mantle, and I’m gonna keep building, so it’s more new things, more customer requests implemented, more bug fixes implemented. Everything you can expect from a continued software development will be happening. 00:11:54 - Speaker 1: And when we first started to explore, OK, we’re coming down to the wire here and you know the numbers aren’t quite working and what are we going to do and it’s important to us that this product continue to exist and we do right by users and customers and how can we best do that and you, to my surprise, stepped up and said, look, I think I can do it on my own and At first that seems counterintuitive, right? We have a big team working on it right now, but first of all, you are basically the only person on the team that has the broad base of skills. You essentially touch every part of the code, including the back end and the front end. You basically have led the whole kind of engineering effort around all the sync work we’ve been doing, including all the collaboration that we’ve done in the last year, but of course you’re also a very accomplished iOS client side developer. And you have a background in entrepreneurship and so forth. And so the more I thought about it, the more I said, yeah, actually I think this is possible, and importantly I think it’s that. The foundation we have built in this product and the kind of ideas that are embedded in it. I don’t say the hard stuff is done, but we tackled a bunch of things that would, I think, have been pretty impossible to do without a team like that Sinclair. But now that it exists, iterating on that and adding new features is something that’s in reach for, well, certainly not every developer, but someone with your exact skills, and that’s why I got excited about that possibility. So maybe that’s a chance for us to talk a little bit about your background and yeah, just help the listeners get to know a little bit, yeah, what led you here to this adventure. 00:13:23 - Speaker 2: Well, I always wanted to be an entrepreneur ever since I was a little kid and I always loved software in particular, so I knew going into college that that’s what I wanted to do. I graduated with a computer science degree as well as managerial studies, which is kind of like a pseudo business degree. It’s kind of as close to entrepreneurship as I could get at the time. And I jumped straight into my own company, so myself and a co-founder founded Jotlet.net, and that was an online calendar application launched just before Google Calendar, if you can believe it. That’s how far back that was, and we were really fortunate. We put a lot of time and effort and love and passion into building that company, and we had a successful exit and sold that and was acquired about 2 years later. And so that really fed the flames for me in entrepreneurship. I loved every second of it and knew that that’s what I wanted to do. And so ever since then I’ve been working for startups or starting my own companies. 00:14:25 - Speaker 1: Two that jumped out at me, I think when we first got in touch with you, which we actually contacted you because you have some open source inc engines for iOS, quite a unique thing that’s hard to find and obviously very relevant to what we were trying to do at the time. But then digging deeper in your background, some of the stuff you’ve worked on, including you made an app called Here File file, which was kind of a syncing-ish connecting to your home computer app as well as loose leaf, which in many ways feels to me like a proto muse. It was before the pencil. And that sort of thing, but you were making an iPad, digital analog paper, kind of sketching loose, I don’t know if you market it quite as a thinking tool, but you know, you look at that and you go, this has a lot of the qualities we’re trying to get in use, but was maybe too early in the sense that the hardware wasn’t there and hard to do as a single person, that sort of thing, so. I’m looking down this and other experience and just the UK, this fellow’s like worked on ink. He’s worked on iPad kind of loose sketching apps, you know, in the very early days, you’ve done sync oriented technologies of different kinds. These are like all things that are square and exactly what we need. So it was really quite the perfect match, I think. 00:15:39 - Speaker 2: Yeah, exactly. I think one really fun thing is in the era of here file file, which was, gosh, over 10 years ago now. This was even before or just as Dropbox was becoming a thing. The cloud was all brand new, which we all know is just somebody else’s computer. And so at the time, I was really, and I don’t want Dropbox, I don’t wanna put my files somewhere else, I don’t trust iCloud, I don’t want things local on my computer and the term local first had not yet been born. But in my heart, that’s what I wanted, and so that’s what your file file really was. It was a way for your phone to connect back to your home computer, and so that way your home computer was your cloud storage. All of your things were in your control on software you control, on hardware that you control. And what I loved about Muse when you all reached out to me was how closely it dovetailed with everything I’ve been doing until then. That local first intuition with your file file and then all of the ink work and loose leaf. And building tools for productivity and building tools to help people do better, and to help people be better and to think better and kind of reach their maximum. And that’s what I love about Muse is it keeps users in control of their own data, and it’s just a wonderful thinking tool that has helped me be much more productive and much more clear in my thinking, and I know it has for our customers and users too. 00:17:05 - Speaker 1: And you certainly do, along with Henry as well, some epic engineering architecture boards, you know, sort of flow charts and yeah, code screenshots and that sort of thing. So you become quite an accomplished user of the product as well. You’re often also the one who runs our team summit kind of planning decision section, figure out how to like slot all the time boxes and that sort of thing. So, also helps to be an avid user of the product, I’d imagine. 00:17:33 - Speaker 2: Absolutely, it is my go to tool, thinking through architecture problems and, you know, difficult coding problems and everything else, being able to diagram and Think efficiently is paramount when programming. It is the number one thing I do all day is just think that’s literally my job description and som is invaluable. 00:17:57 - Speaker 1: You know, it’s like that saying that there’s typing problems and thinking problems, and typing problems are kind of the easy one. That’s write the code, not to say that that’s, you know, it takes a lot of years to build skill as a good programmer, but once you have that, the typing problems are relatively straightforward. It’s the thinking problems, the knowing what you need to do before you’re starting to type the keyboard, and in the code, change the code, that’s maybe the hard part of the job in the long run. 00:18:25 - Speaker 2: Yeah, and I think it’ll be interesting because what I would love to do over the coming months and years with Muse is to bring even more of that thinking layer out into the public and out into the community. And so sharing boards that I’m using to think through problems and kind of really code in the open. What I’ve loved about working at Muse is how we’ve done that and how we’ve been so open in our progress and our process. Sharing small videos of features as they’re getting built, adding things to the backstage pass, making sure we get feedback from users and that we’re solving the problem we think we’re solving. And my goal is to continue in that same vein. I wanna be building this in the open with the community, not to the community. 00:19:13 - Speaker 1: I look forward to your Twitch live stream. 00:19:18 - Speaker 1: Don’t tempt me, mostly joking, but also kind of a suggestion. 00:19:20 - Speaker 2: It’s funny because that’s one of the things I did in Loose Leaf is I live streamed some coding and some, you know, who knows, I might end up doing that and Hey, let’s fix your bug life. Jump into the chat. 00:19:34 - Speaker 1: But yeah, for now, I think certainly our Discord community has been the place to be in touch and I hope everyone has sort of a sense, a little bit more of a sense of who you are and why you’re qualified for slash excited about this work, and yeah, I hope everyone will come in and say hi and they’ll probably be hearing a lot more from you through that channel and others. 00:19:56 - Speaker 2: Yeah, if you’re on the podcast and not in the Discord, please jump in the Discord, and I think we’ll have a link in the show notes, so definitely join and come say hi. 00:20:06 - Speaker 1: Alright, well, I think that brings us to the exciting part of talking about the future here, which is what we’re calling Muse 3. So we’ve hinted at this already, something we’re bringing into beta, but tell us exactly what is Muse 3 and how does it differ from the Muse 2 and Muse for Teams beta we have underway right now. 00:20:26 - Speaker 2: So Muse 3 brings together everything that’s in the current App Store version of Muse and everything that’s in the Muse Team’s beta. That includes new navigation, that includes colored cards and text formatting that were in the backstage pass, that includes collaboration is the biggest one. So now it’s not just you and your muse. But you can create a separate workspace and then invite family members, friends, teammates into that second workspace and collaborate live in real time together. 00:21:00 - Speaker 1: Well, I got access to an early build of what was going to become Muse 3. Let me migrate forward from my Muse2 personal, bring all my data forward, and as soon as I saw it, I said, this is the muse I’ve always envisioned. This is the muse I’ve always wanted. It brings together everything we’ve done for the last 4 years in a coherent and holistic way. And for me, one big part of that is this call it divide or Weaving together of the private thinking space, the private sanctuary, where you can explore ideas in relative, let’s call it safety, but also the shared space where I can collaborate with colleagues, brainstorm, plan, that sort of thing, and that those things weave together and things move between it, they may start in private and move to the shared space and maybe take some of it back to the private space and then having all that together in one app. Really makes this be, again, the vision that I always had from you and the workspace model, which we can explain a little bit, but that allows you to have any number of collaborative spaces or private spaces, so that you can have different work groups that you’re collaborating with. And of course we’ve had them use for Teams beta running for the last, I don’t know, 9 months, and that is a collaborative space and let us explore all this thing like live cursors and avatars and presents and comments and so on, but it’s one fixed shared space with one fixed group, and I don’t think that quite captures where we want it to go. So this Muse 3 combination, this unification of these two different tracks into one beautiful app for all your thinking is just really exciting for me. 00:22:37 - Speaker 2: Yeah, workspaces, I think, are the real jewel of Muse 3, because you can create a private workspace, you can create as many private workspaces as you want, maybe for different areas of thinking, and then you get the full M experience. All of your boards, all of your content, all of your thinking, all of your ink and drawing, and it’s just the same use that you know now, where it’s a private, safe, thinking, relaxing place to be, where you know that you have full control. We’ve mentioned on the podcast before that thinking is such a personal action, and you need room to make mistakes. You need room to just be messy and Think through difficult problems without worrying about what the thinking process looks like to co-workers. And so you have all that same privacy with workspaces, and you can create one to share. You know, we have one for the Muse team. I have one with me and my wife Christy with, you know, papers about our car and our house and our chores and our our to do lists and all sorts of different things, but I think the real risk, and the thing that we were most cautious about was making sure that it was very clear when you were looking at something that was shared, and when you were looking at something that was private. Because we did not ever want to get in a situation where, oops, I’m working on something in a shared space and I didn’t mean to, or oops, I thought this was private and it’s not. And so the way that we’ve built out workspaces in Muse 3, I think really respects the way that people work today and also gives everyone flexibility to expand out and share that work when it’s appropriate, or pull back and stay private when it’s appropriate. And that’s a real powerful thing. In a tool that is built for such deep in process thinking work. 00:24:31 - Speaker 1: Now workspaces are obviously the big banner feature here for ME 3, but even if you don’t care about workspaces or collaboration at all, we’ve been putting tons of improvements into what you might call the core app or Canvas features for the teamspa over the last almost a year it’s been now, so this includes things that were in the backstage pass before like headings and colored cards, but you also have connections between cards. We have board zooming that lets you fairly freely zoom in and out. We’ve got a whole redesigned UI including a Tonav bar that has bread crumbs, which is a really nice navigation feature, a sidebar, and in general it’s a much more discoverable and approachable interface, and I think everyone, if you haven’t had the chance to kick the tires on the team’s beta yet, you’re gonna enjoy using those. Oh, and by the way, search, one of the most requested features, and that will be in 3 as well. 00:25:22 - Speaker 2: I was gonna say, I think search is something I’m most excited about. I don’t think a day has gone by that somebody has not requested search, and now that it’s in the app, I’m using it all the time. I think everyone’s gonna love it. 00:25:36 - Speaker 1: So yeah, if you’re a member, you should be able to find a link to the migration guide to try out the test flight beta from U3 in your backstage pass, but this actually will probably be a shorter beta, you know, we’ll typically leave something in beta for 3456 months because we want to really make sure that we have time to develop it and thoroughly test it before we bring it out to the wider audience, but in this case, most of what’s here, we’ve tested pretty thoroughly in use for Teams. So the beta here can be a little bit shorter, but if you do want early access to that and help us give us some feedback before we go live slash just support the new business, we’d love it if you’d buy a membership. 00:26:18 - Speaker 2: And at the same time, like we said earlier, please jump into the Discord as well. I’d love to talk with you and hear questions and feature requests and feedback inside the community too. 00:26:30 - Speaker 1: Now, speaking of the muse for Teams beta, and how that relates to the personal app and this unification. It is the case that part of the story here, and again I’ll hope to get into more details in some future retrospective, but in the last year we have been testing a new market, right, which is essentially Teams or B2B or enterprise, sometimes is how those things are termed, and this contrasts to the original audience and to this day still the biggest user base and customer base. Of the Muse thinking tool, which is, I usually call those, you could say individual people, right? These are people who decide they want an app like this on their iPad or Mac, they download it, they try it, they go, actually, this is really good for me, I’m going to pay for it. But I usually would think of those as less consumers because it’s not really a mainstream or mass market product, but rather prosumers, that to say, they’re probably professionals, creative professionals of some kind, and they may be using it for personal life, but very likely they’re using it for their work in some way, you know, maybe they’re a freelancer and they’re. Using it to sketch out projects for clients, maybe you’re a startup founder and you’re using it to kind of put together strategy, or maybe you’re an engineer working at a bigger company and you’re using it to do, for example, architecture diagrams kind of for yourself, but you chose the product for yourself and you purchased it for yourself on your own, you know, App Store, Apple account. And that has different dynamics to a team says we need a product for shared whiteboarding or however they might think about it, for shared thinking, for planning and therefore we’re going to go and pick a product that we are all going to use and probably will be purchased together on some kind of SAS contract. And I believed then and still believe now that those two markets, if you call it that or two buyers are pretty complimentary, and we did see that quite a bit in the Muse for Teams beta in the sense that a lot of the people who were bringing news onto their teams were people who were already avid users of the personal product, but it also had some Split focus, maybe conflicting needs, you know, for example, making the app more approachable for or being on different platforms like Windows, for example, is something that if you want to get your whole team on there, you probably need that. If you’re purchasing a tool for yourself, the need to be multi-platform is less pressing. And so that’s part of what we’re doing over the last year and I think that was a worthy path to pursue, but at the same time, it did split our focus. So one detail of this is your plan, and I think part of what’s exciting about it is this, I think you’ve called it like a refocusing on the prosumers and essentially the individuals. And so even though you’re bringing all these same capabilities that we built for this team’s app into Muse 3, you can still make a workspace and use it with your team. The focus is less on serving that need specifically and more back to basics with the prosummers. Am I characterizing your plan correctly there? 00:29:29 - Speaker 2: That’s exactly right. Going forward, it’s gonna be a refocus on existing customers. And what this business model change lets me do is it takes a lot. Less growth to support one person, to support me as a solo entrepreneur, maybe a couple contractors, maybe a bit of extra, but it’s a much smaller revenue requirement. And what that means is that I can focus 100% of my time on existing customers, on our existing customer base, and growing to the same academics, designers, planners, managers. Teachers and students, creatives, all the people that came with us in Muse 1 and in Muse 2, and love the product, that’s the focus going forward, is build amazing tools for people that the people themselves are choosing. I think one thing that I think about with team tools, I think you’re right, I think there is a wonderful balance there, and I think it can work with both teams and businesses being a buyer and being a use case. What I love about building tools for individual people. is that they’re able to take their tools with them. And when you sell to a company, well, it’s the company’s tool, and you have to use it. And then when you go change companies, that tool is no longer there cause the company uses something else. But when you’re buying your own tools for your own thinking and for your own work, you can take them with you. In your personal life, you can take them with you to your job with everywhere that you’re doing, it’s You building up your own tools for your own garden, and I love that about uses, and I love that about the existing customers that we have, and so that’s really the big focus for me is How can I help all of our existing users and customers be even more enamored with new than they already are? I can’t, how can I help them see and use what I see, and how can I bring in new customers? And there’s so many thinkers and planners out there that might not know that music exists. It might just be still a bit niche, and that’s OK, but I think what’s wonderful about focusing on individuals as the target market, as the customer number one. is that all of these are customers that care deeply about the tools that they use, and they bring this tool to their job, but then when they change jobs, they’re gonna bring Muse with them to the new job, and they’re gonna use Muse in their personal life, and they’re gonna use Muse with their family, with their friends, with others. And building tools that people choose for their life is extremely rewarding. Invaluable. 00:32:18 - Speaker 1: You make a really interesting point there about the choosing your own tools or taking your tools with you when you leave a job and go to the next one. And I think that’s part of why you see a lot of the new customer base are people who are freelancers, for example, or yeah, founders, but people who are not sort of taking just what’s given to them but have opinions, want to choose for themselves. I think it’s something like, you know, In kitchens, chefs bring their own knives, right, because a knife is so personal, maybe there’s some knives in the kitchen, but like ultimately for your main knives that you use so frequently throughout the job, you bring it with you because you pick one that fits your hand. It’s a personal choice. And so I always liked that it was part of the reason why, even if we did see the possibility of moving into the team space later, I really wanted to start with individuals or prosumers, and I think it continues to be just the right market for this tool. It also fits together nicely with local first. And fits together with being a thinking tool because there I think, obviously there’s a case when you’re working for an employer, they own your output, that’s the deal you’ve made. You signed a contract, they give you some money and you give them creative output around a particular problem domain. But it always feels a little funny to me when you leave a job and you know, if you put the artifacts of your thinking into a, I don’t know what a Google Drive, a notion or whatever else, all of that you’re immediately cut off from as since as you leave. And I guess it sort of makes sense that like those kind of intermediate artifacts belong to the company, but I guess I just always feel like it almost feels like they were my thoughts. I feel like I should own my thoughts and that fits together with taking the tool that Sort of feels right in the hand and honing my data and I don’t know, there’s some nexus of things there that all fit together really well and I think that is the area where it’s called the early days idea of Muse, the 1 and 2 days. I think that really worked and why I think that getting back to that for Muse 3 was a great move. Well, maybe now we can take a little sidebar to talk about a more philosophical topic, but a pet one of mine, and I feel like a very relevant one here now which is leadership transitions. So we’ve been in the process of a handover from me to you, really from the whole team to you, but I guess me as the outgoing CEO and someone that had the overall picture in my mind, or at least hopefully did, and handing that over to you is something I’m familiar with because I’ve done it a few times over the years. One really successful example I can point to, or what I find to be very successful is ink and Switch, right? I ran that as the lab director for something like 4.5 years, and when I kind of had reached the end of what I had to say on it, or the end of the era, something like that, and I had the opportunity to hand over the reins as lab director to Peter Van Hardenberg, who’s been on the podcast before, and I’m sure we’ll hear from him again. And what he has been able to do, taking that and building on, I think, what I and the other early people created, but really expanding it a lot, taking it way further, making it way better, and creating a much larger impact on the world and a legacy that frankly reflects well on me. I could say that I worked on that for a long time, but then in the meantime, you know, Peter’s been at it for 3 or 4 years now and has accomplished great things again along with the rest of the team there. So I consider that to be a very successful handover in terms of the result, but it’s never easy to be honest. It’s kind of an emotion laden process. It can be confusing to try to dig out all this tacit knowledge that you have and of course it’s important that the new person coming in, the new leader coming in, be someone that has Their own vision, right? It would not be practical or effective for that person to just try to continue exactly what you’re doing. They need to have a new sense of what’s a vision for where this can go in the future, taking what was good about it before, but also bringing their own spin, their own take, their own vision into it and then you can switch example, for example, I think Peter really had this feeling that like Community that was starting to build up around this, this sort of research, HCI community, whatever you want to call that was really valuable. And I was less tuned into that. I was thinking more about essays and research projects, but he saw that this is an incredible asset, we should keep doing the research and the essays, but we should invest in this community piece and that’s been, I think, an incredible, incredible success. So. Here’s hoping that this transition will be as successful, but yeah, I’d be curious to hear from you about, yeah, how you think about this process so far, what it’s been like to shift gears mentally from owning, obviously a huge swath of the engineering, the application as well as thinking about the business somewhat to being just the overall owner of everything. 00:37:25 - Speaker 2: One thing I’ve loved over the past 3 years is Muse being such a small team, let’s all of us see and hear directly from the customers. Whether we’re in engineering or whether we’re working on the website, or branding or planning out future roadmaps, all of us have been very close to customer feedback and customer support requests. That said, of course, over my past 3 years, the overwhelming majority of my time was still code. It was the sync layer in particular. It was rebuilding the database layer, some of the UI problems or UI features that we’ve been tackling as well. So it’s been very, very engineering heavy, and so this transition to me has pulled me back into the entrepreneur hat, which I have worn before, and I love it. I’m so excited to Start spending more of my time thinking about marketing and talking directly with customers in the community, and planning roadmaps for the next 3 months and 6 months and everything else. But one big slice of this transition is just that brain shift, which takes time to think, what have I not been thinking about? For the past 3 years, because it’s not my job to think about it, and I know that somebody else on the team is thinking about it and is very capable, and suddenly I need to start unloading all of those thoughts into my brain too, and shifting my schedule around, which is exciting. But could also be overwhelming because it’s just a lot to feed into a single brain and over the previous month as we’re transitioning, it’s just a lot. Of data to move between biological brains without a Wi Fi or USB port. And so it’s all of those things that The intuition that you have, and the intuition that Yuli has, and the intuition that Leonard has, and All of the unspoken pieces of work that you do, because it’s, it’s your habit to do, and you’ve been doing it for so many years. The knowledge of the transition, I think is the easiest piece. It’s all of the unspoken parts of the transition that are the hardest, and that’s what’s so wonderful about this team is everyone is extremely experienced in their field. And so it’s been wonderful to learn from each of you how you’ve been doing your work, what’s important, what are the things I should focus on. I think I asked every single one of you, what do I not know that I don’t know? Cause I, I have a lot of questions and I’ve run marketing before. I’ve run, you know, very small entrepreneurial projects before, but every single business is different and every single process is different. So I’ve loved learning from each of you, yes, over the past 3 years, but especially during this transition. I’ve gotten a front row seat to see how incredible each of you are, and this team has been to work with. 00:40:30 - Speaker 1: One great trick you’ve been using on this is, uh, as you called the knowledge transfer boards, where you’ve essentially set up one board per person on the team, filled it with as many questions as you could think of about their domain and things they own and work on, and then we each in our own time, kind of fill that out, including, yeah, exactly as you said, that final question, what do I not know, which was an interesting. Thing to think about, you know, trying to like tease out this like tacit knowledge when you’ve just been doing a job for a while and yeah, it might not be obvious to someone outside that your role, even if they’re working closely with you on the team, and then getting on to one on one calls to sort of talk through in detail on that and certainly our knowledge transfer board was a really large one spanning the realm from, yeah, how memos are written and different marketing and growth channels we’ve tried and Many, many other details, but then also taking a quick glance at the knowledge transfer boards you’ve done with others, which are also completely dense with things from the area. So I can imagine that’s something that’s a little, gets your brain a little over full at times, but I guess this is also part of the fun of being an entrepreneur, which is that you do need to hold all of it in your mind somehow. So that’s a good trick you’ve used. 00:41:51 - Speaker 2: Part of me thinks about ancient historians. They’re writing out the history, they’re writing out the story, and they might mention, oh yeah, and then Jack and Jane, blah blah blah blah blah blah blah, right? Well, we have no idea who Jack and Jane are, but clearly they were famous at the time, and so there’s knowledge in the moment that seems completely obvious to the historian. Of course, everyone knows this. I don’t need to add any context. I’m just gonna mention the name real quick, and then everyone will understand exactly what I mean by metaphor. But then of course distance and time. Make that knowledge disappear. And so there’s some things that are completely obvious to each of you on the team, that for me, not being in your job and not being in your day to day and certainly 3 months or 6 months from now is essentially lost to me. And so the big piece of what I’m trying to do with these transfer boards and with this whole process is Find out as much of that local context that each of you has during your workday, that is otherwise invisible to me. That is perfectly obvious to you, so there’s no reason for you to mention it because, of course, but might be completely blind to me, and that kind of knowledge, I think is the most difficult to find during a transition like this. 00:43:11 - Speaker 1: Another piece of that that I think comes across partially through the knowledge transfer, but we’re also trying to do explicitly is just seeking to simplify everywhere that we can. So oftentimes you have just the infrastructure things, for example, that are legacies of something set up a long time ago and you just never got around to changing it, for example, our website has been in recent times, a mix of web flow, which we use to build some pages and NetLi HTML and coded pages, and we have a little Netify proxy that goes through the web flow. And part of the problem with that, it’s basically fine for our team that are doing things on the website because we’re sort of used to it or whatever, but in order to have like less stuff, you need to hold in your head, fewer moving parts, obviously fewer services to pay for we’re thinking, OK, how can we just get this down to one simple way that this gets built and deployed, that is easy for you to understand that is, Yeah, just sort of more call it futureproof or just, yeah, just less prone to breakage, more antifragile or something like that. And so that oftentimes feels a little bit like, you know, cleaning out your closets and you know, doing stuff you probably should have done a long time anyways and related as you did a pretty thorough audit of all of our monthly services that we’re paying for and trying to determine which one of them provide real value, where can we scale down, where can we switch to Less expensive stuff where maybe in some cases we’re just not getting that much value from it and maybe before, you know, relative to the cost of all these salaries, I don’t know, we just hadn’t thought about saving that small amount of money per month, but in the interest of being a really capital efficient, sustainable business, it’s worth your while to really take stock of that stuff and make sure everything it’s pulling its weight, and that’s all part of the process as well. 00:45:00 - Speaker 2: Yeah, I’ve really been looking at all of these different pieces as the foundation that I’ll be able to keep building Muse on for today it’s Muse 3, tomorrow Muse 4, Muse 5. And what I love about local first technology is that there’s a lot of complexity in our Sinclair, that’s fair, but compared to the complexity of a typical web application, web-based application, In my opinion, our architecture is so much simpler to manage and to reason about. And so, starting with a very simple conceptually simple technology layer. And then adding on a few of our most core services, like you said, the web, the Netify maybe the, I think Hugo is the template generator. 00:45:53 - Speaker 1: I can’t remember that content system, yeah. 00:45:55 - Speaker 2: So there’s a few of those on top, but the core of the foundation of Muse and the core technology is strong, and I’m so proud of what we’ve built over the past 3 years that It’s gonna be really exciting to continue to build on this very, very strong platform that we’ve built. 00:46:16 - Speaker 1: And then I guess as a footnote or perhaps citation here for the transition topic, I want to reference a book that I think I’ve referenced on the podcast before, actually, it’s just really quite a helpful conceptual framework for these sorts of things that come up, I think frequently in the business world. This book is called Managing Transitions, and the basic concept is that a transition is something that’s different from a change. A change is before it was red, now it’s blue, but a transition is how did it get blue? And I think some of the examples they use or whatever is more like, oh, you’re an executive at a multinational company and you need to close down a manufacturing plant and lay off 5000 people. How do you handle that? Situations that at least I don’t ever expect to find myself in and I think most people don’t, but for me, that kind of conceptual framework of there is a transition you need to go through that’s different from deciding to do the thing or deciding what the best thing is. in particular, there’s a concept of the timeline, essentially the process you go through, which is essentially a kind of mourning of what’s past and a sort of neutral zone, limbo state where you’re very creative, it’s kind of a confusing and uncertain time. But also it’s like a fertile territory for new interesting things. It’s a very creative time, right? Because you’ve sort of like broken down the old assumptions and new things can arise from that and then a new order can emerge, and maybe hopefully a better one. But you do need to go through that process. You don’t jump straight to things are better, you start with, OK, we’re sad about what we’re losing, and then a period of time of some uncertainty, and then you find your new reality. So, honestly, that’s applied to every Certainly leadership transition I’ve ever gone through every change in job, venture, etc. where there needs to be some time to say, OK, you know, this is something I’m sad about. We mourn it in some way, perhaps we have some little rituals or ways within a team or whoever’s affected by it to say we valued what we had before and we will miss that and it was special and it’s time and now it’s, we’re moving on to this new thing. So, recommended book and definitely in this case, I think it is something that’s applying well, which is we’ve kind of been doing our morning a little bit on the team, but we’ve also in this neutral zone creative time, come up with this new plan for the future and I hope it leads into what’s actually gonna be a new and very promising era. So maybe that leads us to what’s next. So, we’ve already talked about the Muse 3 beta and the unification of all this work we’ve been doing into the one beautiful thinking tool, but yeah, what comes next after that? What are your priorities? 00:49:07 - Speaker 2: So coming up next, M 3 brought so many new features, both the navigation, the sidebar, collaboration, workspaces, of course. The most immediate next step is gonna be to make sure that those features take root, to nurture those new plants, and to make sure that they grow strong. A big piece of that is with the new collaboration side. As I’ve mentioned, I have a workspace with my wife Christy. So, I would like to be able to stay up to date with things that she’s adding into the board, and she would like to stay up to date with the things that I’m adding into the board. There are a lot of tools you can think of the Slack or the email inbox or anything else that has the giant red blinking, you know, 7 updates, click here, click here, which is very antithetical to a nice quiet thinking tool. And so, one thing that I’m gonna be working on is how can I help people stay up to date in their collaborative spaces. Well, not making Muse yet another inbox, and yet another interrupter of deep work. The core purpose of Muse is deep thinking, and careful thinking, and deep work, and I don’t want to interrupt that with notifications, but of course, everyone needs to be updated. So that’s gonna be a very delicate balance, to make sure that that feature finds its correct home in the Muse universe. 00:50:36 - Speaker 1: I think that’s a really interesting area to explore. There’s obviously lots of precedent, like you said, the red dots, dust and such been updated, but I also think of things like see new changes on Google Docs. We’ve talked about things like heat maps before. I don’t know how radically you want to go on that, but in the ideal world, you should be excited to know that, yeah, you’re collaborating on a board with your wife and you’re doing some, I don’t know, home decor project, and she was up last night with some fresh ideas and you get up in the morning and it should be exciting to see, oh, there’s some new stuff in here, let me check that out. And to have it feel like something that is inspiring you, which I think has always been one of the key things we’ve sought in this product that it is about inspiration, rather than the feeling of, exactly like you said, an inbox to check or a to do list of things to check off, but rather a fresh influx of fresh ideas from your collaborator to get you inspired and for you to build on. 00:51:36 - Speaker 2: I think that’s exactly the right perspective. It’s about Letting that collaboration be a source of inspiration instead of a source of to do list, as, as so many kind of inbox shaped notification shaped applications end up feeling. And related to that, I think. In Muse 2, all of my content is created by me, and people have such strong memory with The spatial placement of their ideas and of their boards, and of their content. That’s what makes Navigating and use. So different than navigating in something like notion or Google Doc is use is spatial by definition, and that triggers that spatial portion of your memory. But working with other people, of course, that means they can move things or add things or change things and so suddenly where I put something might not be where it ends up. So similar to how can I see the inspiration from my collaborators? How can we work together efficiently so that way my spatial memory doesn’t interrupt theirs and their spatial memory doesn’t interrupt mine, as both of us are, of course, moving and organizing things in our space. So content organization and discovery is kind of what that box is in my brain. Some of that is search, some of that is linked cards. The new workspaces feature is, of course, part of that. There’s many new metaphors in Muse 3, and it’s gonna be important to make sure that they take root and grow into strong new features. 00:53:13 - Speaker 1: Yeah, another way to slice that would be. These major new capabilities, things like workspaces and collaboration, then have implications like, as you said, the spatial memory when you put everything down yourself is different than if someone else is there moving stuff around and putting in their own stuff or likewise that When you have new ideas that are being added to the boards that were not things you put there, you want a way to know about that. Those are all implications of these core features we’ve created. So I can imagine you could spend quite a lot of time exploring the implications and the follow-ons from those core new features. 00:53:53 - Speaker 2: That’s right, and then there’s of course just many optimizations and general improvements that I would like to make. Sometimes ink lag has been, you know, on again, off again problem in Muse, Muse one, really. So being able to spend time focusing on that, focusing on battery performance and making sure that Muse is not chewing through too much of your iPad or your laptop battery, just make sure everything is running at peak performance. Before starting on what will eventually become useful, or kind of the next round of interesting new features. 00:54:31 - Speaker 1: Yeah, that makes a lot of sense. We’ve been in various ways pushes to do big new things like sync layers or collaboration or Mac apps, new platforms for essentially the whole time you’ve been with us, and again, starting from the foundation of what’s there, it’s very solid and known product, a known purpose, a known audience, the infrastructure for the local first is all built out and works really well, that leaves room for both these kinds of quality of life improvements that you’re talking about. As well as exploring the implications of those big, big core features, which may be smaller features, but that can greatly expand the utility of the product. I like the idea of spending a lot of time on that, especially in response to the customer requests that undoubtedly you’ll be hearing a lot of now. 00:55:21 - Speaker 2: Yeah, a lot of the things on my plate are spring cleaning. Style issues that I see from an engineering perspective because I know the code, but might manifest in, you know, not obvious ways or not consistent ways to the user. So I definitely see these very first steps as cleaning up some of the things behind the curtain. You know, that we’ve necessarily needed to sweep under the rug. Let’s finally clean out under the rug. And of course, responding to customer requests and bugs and feedback and questions. The community and users, current customers are my number one source of direction for what needs to be improved, changed, cleaned up, tidied up, new features, that’s gonna be my backbone moving forward is What are the common patterns and what are the common requests that I’m seeing? Does that mean a new feature needs to be built? Does it mean an existing feature needs to be tweaked or adjusted? Does something just need to be tidied up, but all of it is gonna be at the service of That are thinking, and at the service of current customers and helping those current customers and current users. Think better individually and think better collaboratively with Muse 3. 00:56:47 - Speaker 1: Very nice. Well, as long as we’re talking about the future, I’ll do a little PS here, which is basically folks might wonder what’s gonna happen with the podcast, and I think it is a lot to ask for one person to run a product as sophisticated as Muse, but also being a podcast host would be, I think, a bit much and happily it’s something I enjoy doing. So we’re in discussions now. The future here is a little bit uncertain, but I’m happy to say that the good folks that you can switch has said, They think that this podcast has been really valuable to the tools for thought community, for the research community, and have offered to step up to essentially help with the show running, the funding. I could stay on as a host, but maybe we’ll find different topics and purposes that are uh more in the realm of the weird and wild research world of I and Switch, but obviously that’s very adjacent to a lot of the stuff we talked about in the past, so. Yeah, the idea is still evolving there, but I think there’s potential for some interesting things on the other side of a transition there. But at a minimum, you can look forward to uh me and Mark doing a little retrospective on the experience of podcasting and some of the things we’ve learned along the way working on this. Hopefully we’ll do that for the next episode and yeah, if you have ideas for what you think we should be doing with this, feel free to rate us. 00:58:11 - Speaker 2: I, for one, am excited to see where you take the podcast. 00:58:16 - Speaker 1: Alright, well, I think there’s a lot more we could say about the past, the future, and hopefully we will get a chance to do that, but I think we can wrap it up here. I will just say that I’m so happy that you are taking this forward and making sure this product not only continues to exist and be maintained, but indeed to grow because there really is nothing like it out there for unstructured thinking. When I began the process of my own thinking about OK, what’s going to happen in this transition? What do we do? And I was starting to think about, OK, in navigating a difficult question like this, why would use Muse for that? What can I do instead? And I tried other stuff. I tried some text files, I tried some sketchbooks, I tried some other tools for thought, and I was just Thinking, you know, none of it scratches the itch to really tackle a big complex, potentially very emotional, potentially very strategic thing, use as the right tool for that job, and I want to keep using this product for a long time, maybe ever so. I’m so happy you’re continuing. I suspect a lot of our users and customers will be as well, and certainly I’ll give a little plug here and just say, if you’re not a member already, buying a membership in the app either now or in the future to support Wulf and his efforts to make something sustainable for the long term would be much appreciated. 00:59:34 - Speaker 2: Yeah I need to send a thank you to you as well for even reaching out and finding me 3 years ago. This has been The most rewarding work that I’ve done in a very, very long time, and I am excited to continue it into the future and to make sure that MUS continues for many, many years down the line cause I agree it’s just the perfect thinking tool for me, for you, and for so many others. I’m humbled at the opportunity to keep this going. 01:00:05 - Speaker 1: Well, I think we’re absolutely lucky to find you, and it’s been an absolute pleasure working with you these last 3 years, and continuing to work with you going forward to the future. And yeah, I think that there is a silver lining to all this here, and you’re it. So let’s wrap there. Thanks everyone for listening. Join us in Discord to discuss this episode with me, Wulf, and our community, the links in the show notes. And Wulf, well, thanks for carrying the torch forward. 01:00:33 - Speaker 2: Yeah, thanks for giving me the opportunity.
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: I think it’s important to deliberately not decide too soon what you’re gonna do in that situation, cause you need time for the existing structure of your brain to basically disintegrate a little bit, like, let those pathways fade away, let the daily patterns of thinking and doing melt away, and create some space for new ideas and new ventures to enter. 00:00:28 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for deep work on iPad and Mac. This podcast isn’t about Muse the product, it’s about the small team and the big ideas behind it. I’m Adam Wiggins here with my colleague Mark McGranaghan. Hey, Adam. So by now, I think a lot of the listeners have heard the news that the Muse team is downsizing, talked extensively with Adam Wulf about that in the last episode since he’s the one carrying the torch forward here. But I felt like it would be really worthwhile for you and I to discuss, reflect on this podcast here, because I think it has in some ways its own life, that’s a little bit independent from use the product or the company, even though in many ways it’s also intertwined, which we’ll talk about, but one implication of this news, of course, as you and I both are not going to be doing news as our day job anymore, and I’ll ask you the same question I asked Wulf, which is feelings check, where are you at right now? 00:01:23 - Speaker 1: Well, I’m excited for Adam Wulf and the product to continue. I think Adam’s a great person to be carrying that torch and as a very heavy user of news still, I’m, I’m happy to see that for sure. You know, otherwise, it’s, it’s certainly a little bit saddening and disappointing. You work on this so hard for 4 or 5 years plus if you include the work at the lab, it doesn’t quite pan out the way that you’d hoped to. It’s a bummer for sure. But at the same time, it feels like the right move, it feels like the right time. There’s always a natural 4 or 5 year cadence I found where it makes sense to pick your head up and look at new stuff. 00:01:58 - Speaker 2: Yeah, the 4 or 5 year duration thing when I look back to my career as an entrepreneur and other projects I’ve been involved in that usually is kind of about the period of time that can kind of keep extended concentration on one. Particular topic, you know, you could certainly say the 4 or 5 years I spent on In and Switch were very closely related to the 4 or 5 years I spent on Muse, but in some senses like a resetting of the venue, a different, I don’t know, environment, a slightly different team, even if there’s overlap. Yeah, I don’t know, sometimes that can be a good thing, even if this isn’t quite the way I would have wanted to do it, but there is something about that timeline. Well, for this episode, I thought we could spend some time reviewing, retrospecting, and indeed, I think taking a bit of a victory lap for all we’ve done here on this podcast, which as I said, I think has had almost its own life and identity that is complementary to but also stands apart from you. Maybe it’s a little bit of a self-indulgent episode, but, you know, I don’t know, I think we’ve earned it. Yeah. So just to start us off, I took the liberty of doing a little lightweight data science here and just kind of dug in on our episode history. So, I don’t know, maybe some interesting insights to glean here. So not counting this episode, there’s 83 episodes currently in our back catalog, and they total 83 hours, 5 minutes and 52 seconds. With the shortest episode was episode 4, which was Partnership Freedom and responsibility at 37 minutes and 20 seconds, and the longest was actually a very recent one on spatial computing. That was an hour and 35 minutes, and the median ends up being almost exactly an hour, which I was surprised by. I actually thought it would be a little longer than that, but I’m also pleased because that’s kind of what I’m shooting for. We usually record for 1 hour and 15, maybe an hour and a half, and then trim it down and There’s various schools of thought around this, but for me, an hour is the right chunk of time. It allows you to go deep on something, but it’s not so long that, for example, if you listen to a podcast on a run or a commute or something that you’re going to need to listen to it in chunks. I thought that was interesting, but I’m glad we kind of landed there. 00:04:16 - Speaker 1: Yeah, I really like this length. I can even go longer. It’s interesting. I listen to a lot of podcasts that are 40 minutes, 30 minutes, even 20 minutes, nominal time, which by the way, that’s, you listen at 2x so it’s half that in real life. And so often they’re in a good conversation and I was just like, well, the time’s up, that’s it for today. bro, it’s your podcast. You can go as long as you want. How do you do? 00:04:38 - Speaker 2: Right, right, this is a network TV where you have a slot to hit, right? Yeah. Yeah, well, there’s very much something to be said for having time to really get into something. I’ve noticed, for example, with guests, I feel like the conversation usually starts to get really juicy around 30 to 40 minutes in, and there’s probably something there about you have the context, you’ve hit all the not quite service level things but basic questions, and then that’s a foundation upon which you can go a little deeper. And there’s one podcast I listened to for a while that would typically do like 3 hour interviews and they explicitly say, You know, we want to go deeper with our guests than, you know, if they’re interviewed on a talk show on TV or something, you probably are only going to get to those same talking points and those same questions that they get asked over and over. But if you do the longer conversation, you spend the first hour on that stuff and then you kind of go off script or you get a little deeper. So I see that, but I’m also a 1x listener and so for me, a 3 hour podcast, it basically never get to the end, no matter how interesting it is. So yeah, there’s pros and cons there and certainly we try to let the episodes be their natural length while at the same time, I guess respecting the listeners' time and trying to, you know, kind of make it information dense perhaps. Another piece of the podcast I have always, I guess, been proud of is our show notes, and so this is something where stuff we talk about, which is often weird obscure projects or articles or whatever, we try to link that so that you don’t need to just Google around for it. So we have a total of 1,943 notes, all of which are links, so that’s around 23 per episode. And then the other thing I thought was interesting was just the podcast format, the RSS format calls it A, which is a lot but basically the people who are on the podcast. And so I did a little breakdown there and it turns out that, well, not surprisingly, I am on 83 episodes, you are on 75, and then a few of our team members like Leonard and Adam Wulf and Julia were on a few each, and then we have a couple of guests like Jeffrey Lid and Max Schoening were on a couple of times, and then, of course, after that, it’s the one-offs. And the author thing points to what I would call almost a type breakdown, which is when we started the podcast, and we can tell the origin story here in a minute, but we didn’t necessarily envision it as a guest. Thing we kind of experimented with that early on. It worked well and we expanded that, but when I kind of did a breakdown, I discovered that episodes that are just me and you, which I think of as kind of our baseline or what have you, where the co-hosts, is actually only 28% of the total, whereas 57% are something with a guest. So when you look at it that way, it actually seems like this podcast is more about having guests than it is about you and I. But on the other hand, I think those kind of non-guest episodes are pretty often touch on pretty foundational topics. And then the last category, which actually might be my favorite and I almost wish we could have gotten more of is what I call the team episodes, and that’s where we bring on someone who is on the Muse team, so they’re not an external guest, but they are someone who you don’t normally hear from. And so that’s about 15% of our episodes, and as we’ll talk about some of our favorites, but I think that category is the one I in some ways like the best. 00:07:52 - Speaker 1: Yeah, and this makes sense to me because ultimately the podcast ended up being about ideas. So there are podcasts that are about the personalities of the hosts, and there are podcasts that are about the lives and activities of the guests, but ours end up being more about the ideas around computing and use and so on, and we have a lot of ideas, obviously, the team members have experience and things to contribute there too, and then all these different guests. It kind of makes sense to me in that respect. 00:08:18 - Speaker 2: Now the origin story here is that I’ve sort of always wanted to start a podcast about something. I just really like the audio format. I actually got a portable MP3 player, not an iPod, but some other product, a long time ago, just for that because I always liked, for example, like MR my mom listened to NPR, but for me, and I have the same problem with broadcast television, I just can’t do it on someone else’s schedule. I need to do it on my own time. And eventually when it became possible to get like audio format through again, MP3s or even in some cases like audio CDs, you have books on audiobooks, I just love that format. There’s something kind of, even though it’s slower or less efficient in some ways than reading. There’s also something intimate and you get to know the personality or character of the host in a certain way and it can be engaging and importantly, it’s something you can do while you’re doing something else. You’re driving, you’re running, you’re doing chores in the house, and that’s a really nice way to keep the intellect part of your brain stimulated while you’re doing something a little more rote. 00:09:25 - Speaker 1: Also, you gotta put that radio voice to work. I don’t know if we’ve ever mentioned this on the podcast, but I get comments constantly about Adam’s perfect radio voice. 00:09:35 - Speaker 2: Well, I’m glad I never would have guessed that. I mean, most people don’t like hearing their own voice recorded and I count myself among that, and I just kind of powered through it cause I felt it was a good format and it’s not that important how your voice sounds. But yeah, glad to hear the good feedback there. So yeah, I guess we’ve always both liked the podcast format and then I don’t know, inspiration struck, it was actually our very last in-person team summit right before COVID hit. This would have been, I think January 2020, we were in Sedona, Arizona, and I just pitched you this idea. We did a little test recording just using the memo, audio memo apps on our phones up in that freezing attic in that house we were staying in. It was only maybe 20 minutes long, but we sort of spliced it together and were able to listen to a little prototype basically. 00:10:22 - Speaker 1: Yeah, that was funny. I remember my teeth were almost chattering. It was so cold up there, and then I was really impressed cause you edited the whole episode on your iPad. I just can’t do any like production work on iPads, but you did it somehow. 00:10:34 - Speaker 2: Yeah, I can back reference you to our episode on iPad where we had differing ideas on that. But yeah, certainly at the time I was excited about the iPad as a place for productivity. There’s a nice bit of audio editing software there called Ferri that in a lot of ways I think with the stylus, it’s actually very natural and yeah, I managed to kind of put it together with some even through in some stock music at the start just to kind of give it that sense. Yeah, I had one of our colleagues listen to it and they said, yeah, I think there’s a spark here, you know, I think you and I have a natural dynamic. We’ve been working together so long, and obviously we have lots of ideas, and so, yeah, those two things kind of made us say, let’s give it a go at this. 00:11:12 - Speaker 1: Yeah, and you alluded to this when you mentioned in the origin story, how the idea was to capture the conversations that you were hearing in the team, but for me, that goes back, I don’t know what it is, 12 or 13 years. So we’ve been having these conversations for that long. I remember we went on those ski trips we worked together on Hioku, we were on the ski lift and we would talk about our schemes for making Hioku better and stuff and so we’ve been at it for a while, just formalizing with the podcast. 00:11:36 - Speaker 2: Yeah, absolutely. Now I think that in the original idea I had was that it would be something that was a little more spread out across the team. We would have different combinations of people and it wouldn’t be kind of one fixed host and ultimately kind of became my thing, I would say. I think even in the beginning, you and I traded off reading in the intro and stuff like that and in the end, I think that works fine. I’m the kind of organizer, showrunner, you know, kind of main host, and then we can have this rotating cast of characters, which indeed even extends out into the guests from the Tools for Thought community. One of my big influences from the podcast world is the genre I’ve heard described as two guys talking. You know, that sounds gendered. It’s not always two men, but there’s something about two that makes a really good, you know, assuming that people have good dynamic and and interesting topics, there’s something kind of nice about that number in the back and forth. One person looks a little too monotone, once you get to 3 and especially above, there’s a lot of voices, it’s hard to keep track of it all. And one of my favorites on that was a podcast called Hello Internet, which was not really about anything in particular, but just the hosts had interesting personalities that kind of contrasted each other, and there’s lots of others as well, like Gastropod is a great one. It’s kind of focused on food history and Lexicon Valley, which is a linguistics podcast back then had these two. Host, but one similarity across them, I think was that yeah, you have these two people in this kind of exchange, but then sometimes uh almost a contrast or something about the dynamic is you have the differing personalities maybe that play off each other. For example, I’ve often described you in talking about the format of the show as being the kind of contrarian philosopher, you know, so maybe I come in with the more direct perspective or something like that and you come in with the contrarian and philosophical perspective and something about that just works. 00:13:25 - Speaker 1: So you mentioned two guys talking. I think there’s kind of two dimensions there. There’s the 2. There’s also the just talking. So a lot of podcasts are heavily produced and they’re like they’re basically read, you know, you write scripts and then you read them, you might even have dramatic music going on in the background and everything, and, you know, there’s something to that, but I’ve always been a fan, both in podcasting and on YouTube of the just talking format. It’s less scripted, it’s more train of thought, thing of life, whatever it may be. I think there’s something really to that. Because importantly, there are a lot of ideas that you’re just never gonna get out of someone if they have to go through production, that write it down, get to produce it, especially with gas, you don’t know one has time for that, but everyone has time to sit down and talk in the microphone for an hour, so you get a lot of stuff out that you wouldn’t otherwise get. 00:14:09 - Speaker 2: The informality of it, the sense that you’re listening in on a conversation by, you know, practitioners in your field is certainly something I was always, always going for. I try to prep our guests actually and say, look, listen, I’m not, I’m not gonna treat this like an interview where it’s just like question and answer, hopefully. It’s the feeling a listener has is there’s sort of a fly on the wall at a hallway conversation at a conference where there’s two people that maybe are meeting for the first time but have this shared interest or this work in a shared domain and you’re sort of listening in on that. The highly produced. Style, which I can appreciate sometimes, as you said, like, This American Life, I think kind of pioneered that and there’s a gimlet Media has a whole series. I, I feel like that’s a style now, but yeah, it’s very much scripted, and that’s less compelling to me. Now, the other far extreme of that is just turn on a microphone and start talking, and we do do both prep work, which for me is helpful because you kind of have some notes we’re working from in a rough structure. But we also do editing, we’ll maybe talk about the production process a little bit, but you know, we remove false starts, we remove people talking over each other in some cases less often, but we’ll remove the whole sections that feel repetitious or boring, so a little bit of that editing to try to make it as listenable as possible and kind of respect the listener’s time and attention, but hopefully it still has Most of that kind of raw, unscripted, just real sense of, you know, people talking to each other. Well, over the years we’ve got so many nice emails, people tweeting about the podcast, reviews people leave on Apple Podcasts and other places, and I wanted to read a couple of those on air, again, partially for the indulgent victory lap, but partially because it’s so interesting to hear what people find valuable or interesting about what we’ve done, you know, it gives you a little bit of a mirror back onto your own work. So I’ll read a few here to you and we can react a bit live maybe. So maybe I’ll start with this one from Andy Dent Perth, who says this is the only tech slash design startup podcast I’ve been able to get my wife to listen to and not tune how well stuck in the car with me. And I like that one a lot because one of my goals generally with communications around the work I do, but certainly with the podcast specifically is to make it deep and specific to the feel. It’s obviously very much a niche, but at the same time, kind of try to make it approachable, it’s not like dripping with jargon or, or something like that, or if someone does use a term that maybe not everyone is likely to know right offhand that we try to stop and define that or you can, you know, it’s in the show notes, you can tap on it or click on it to get more information. So I’ve I’ve tried to sort of keep it accessible, but also for experts, I don’t know if that works, but I feel like that review kind of captured, yeah, maybe the accessible part has been at least somewhat successful. 00:17:12 - Speaker 1: Yeah, and it’s encouraging to hear. For me, if there’s one theme that ran through a lot of our episodes, it was software that reflects the way people actually think. And so, the, the software piece that can be more technical, but the way people think, everyone should be able to relate to that if we’re doing it right. So hopefully that provides some surface area for people to latch on to. 00:17:30 - Speaker 2: Another review here that touches on something that we’re trying to achieve and sounds like we did, which is when I first left a review saying, listening to the Meta Muse podcast is like eavesdropping on a conversation among friends. So certainly trying to create some of that warmth, create some of that. I mean, obviously this is, we’re talking about professional topics, we’re talking about the work we do, but I think for all of us and certainly for our guests, we are really passionate about it. It’s our life’s work. We put a lot of our heart and soul into it, even though in some cases it’s pretty abstract stuff, and obviously we’re doing it as a livelihood, but also, yeah, we’re trying to make it something we enjoy from a social perspective is right, the right way to put it. But yeah, we should be friends, we should be a certain kind of professional or business friends among all of us here on the team and with our guests and with people in this community or set of overlapping communities that we’re a part of. And speaking of community, we have a review from PPKN that’s titled Center of the tools for Thought Community, and I think it’s very generous to call the center, but I do think we have been a helpful gathering point for folks in this emerging space, and the review basically talks about guests from the thinking technology space and how tools shape the way we think, and so on. So, Yeah, a big part of it wasn’t necessarily our intention when we started, but I think you called it out from pretty early on that especially once we started bringing guests into the mix, this can be a form of community gathering, even though it’s not a forum where people can freely participate, it is something where we can bring folks who are working in the field, have again these fairly intimate and in-depth discussion, and then of course folks can discuss the ideas prompted by that on social media and so on. 00:19:18 - Speaker 1: Yeah, I agree it’s quite generous to call at the center, but it’s certainly been great to be a piece of that, you know, it’s a very special community. There’s a lot of cool work going on, and a lot of people who care deeply about software to help people think, so it’s been fun to be a part of that. 00:19:34 - Speaker 2: And the word community gets thrown around a lot, commercial companies use it to just describe people who use their product or something like that, which I don’t think is is quite right. But I think that a community, especially when you talk about a professional pursuit like this can be just a set of people who share values, but if they’re all out kind of scattered on the internet and you don’t know how to find them or where they are, you can sort of just feel isolated. I have these weird interests, no one around me understands or appreciates those things. And then when you do find a community, you know, I felt that way, for example, coming to Silicon Valley and discovering the entrepreneurial community there, where it was something that previously had only had known a few people, basically my business partners who cared about or thought about or worked on the kind of things that I spent my days on, and then suddenly here’s a whole group of people who are all in touch with each other and supporting each other, not only intellectually but also emotionally, to be honest. So I hope to some extent we’ve helped people discover and become part of the community and indeed inspire them to, well, realize you can make a career out of this stuff or at least some very passionate side projects. Another one I’ll highlight here is, this is a tweet actually, it’s from Arnav Gosain, and they say the Meta Muse podcast sets the bar so high for the time spent to knowledge gained ratio. Each episode leaves me with so much to research about. Again, I liked this one because, yeah, I strive to do this, right? I want it to be information dense to me, that’s respecting the listeners' time, as well as our guest time and so forth. And that that also loops around to the show notes a bit, which is a good episode. I think we’ll have some, you look at the show notes and you’re thinking, OK, all these obscure, interesting niche things, what possible conversation thread is going to tie them all together. So, that was a nice one to read. 00:21:26 - Speaker 1: Yeah, and I think this also reflects an important aspect of modern quote unquote, social media, which is that a lot of the value is in taste, not taste in the sense of what color is a logo, although that could be important too, but what is important to pay attention to, what’s important to look at and to learn about. And so a lot of the work that we end up doing on the podcast is just collecting and synthesizing and filtering down. That from our experience, from our colleagues' experience, from industry happenings, from prior art, from theory. And so on. 00:22:00 - Speaker 2: One of the personal journeys I went on in my career or life even is, I think when I was younger, I would kind of approach everything blank slate, oh, I need to price my product. I need to figure out how to roll out, you know, a major data migration, and in every case, I would just try to invent from first principles like no one’s ever done this before. And at some point I realized actually lots of people have done, maybe not the exact thing that I or my team is trying to do. you can benefit so much from experience and I feel like learning from wisdom of the elders is just not a thing that’s really a part of the tech world that tends to skew young and yeah, maybe startup culture tends to attract young founders who are sort of almost like take pride in their naivety. And that’s part of what allows you to do new things as you’re not constrained by the thinking of the past, but at the same time, it could be a weakness because well you’re actually naive. And so for me, each podcast episode is not only a chance to talk about my experience and what we’ve, for example, been working on it, use around a certain thing, whether it’s pricing or product launches or whatever else, but also a chance to go research a little bit in some cases look back at notes on books I’ve read or yeah, do a little web searching, talk to some people and try to expand my own knowledge and just sort of realize that anything you want to do, someone else has already done it, thought about it, probably written a book about it. You know, there’s knowledge out there if you want to go, take the time to find it. The last review I’ll mention here is from Metavi Bay. And this one’s titled Genuinely Curious, of course curious is a word we like a lot. We try to cultivate curiosity in our selves and in the product we’re working on, but this person writes, this podcast is an exploration of how we can work and think creatively with modern technology. The hosts approach each topic in an open and philosophical way. And again, that one caught my attention because I often even joke on it in this show, we can’t just talk about, hey, we’re launching this product and let’s talk about the details of that or we’re building a local first sync engine, so let’s talk about the details of that, but actually I always want to start with like really zoomed out, philosophical, explain like I’m 5. Whatever type of thing, like let’s try to really understand in a big picture way what this thing is and how what we’re trying to do now fits into that context. So, open and philosophical is quite what I’m going for, so I’m glad that comes through. Yeah. Let’s talk about some favorite episodes, and of course there’s so many, there’s no way we could touch on all the lovely moments we’ve had, especially with guests. And one thing I did, again, kind of in that data sciencey realm was just to dig into our analytics a little bit to see which episodes were most downloaded or kind of reflecting popularity, and that wasn’t that useful partially because podcast analytics are quite tricky. You have these downloads, but that by itself. may not tell you a lot, a given podcast player might download things multiple times or only once for multiple people, and then you can kind of filter by unique IP but that in any case, it wasn’t that revealing. I will say our most downloaded episode of all time, according to these analytics is episode 30 with Molly Milky, and that’s computers and Creativity. Which indeed is a great episode and also when I tend to point people to when they say, OK, what’s an episode I should start with just because I think that really does talk about certainly the tools for thought elements, but also the kind of creative tools and what’s happening in the field there. It’s just a very zoomed out, I think, look at a lot of things that we tend to circle around on this podcast. But then the number 2 was actually our sync episode, which you might be interested in. I think you mentioned that as one of your favorites, and that’s definitely a much more technical episode, but I think for helping the local first called community or movement get off the ground and reporting, you know, kind of our real world experience there. I think that’s been. A very helpful thing, and I’ve told gets passed around sometimes in more technical communities as kind of like a starting place for someone that wants to learn about this world. 00:26:11 - Speaker 1: Yeah, that’s certainly the one that I’ve blanked out the most myself. 00:26:15 - Speaker 2: And then the other one I’ll mention that’s from the most downloaded list is episode 12. Now, I think to some extent these tend to be sort of backloaded because of course they’ve had years to accumulate downloads, but our 4th most downloaded is Andy Mapschzek, Growing Ideas, and that one was kind of a breakout hit for us. In some ways that was our first high profile guest. We were still figuring out the guest format, but of course Andy is such a sparkling, you know, conversationalist wide mind that can go in so many different directions. And then, of course, he shared us with his audience and that in turn brought a lot of new listeners to the podcast. So, that’s in many ways quite a seminal one for us, I think. So Mark, I’ll turn it to you. Do you have some favorite episodes or even sort of themes of episodes that come to mind when you think back on these 80+ hours in front of the mic? 00:27:09 - Speaker 1: Yeah, so I did look through every episode, and I came up with about a dozen that are my favorite. I don’t know if I’ll go read through them all, but there were a few themes. So the first and biggest theme was this tools for thought, reflecting how people think. So things like having good ideas, growing ideas, those are right up that alley. You know, performance has been a big one for me. We did a few things on that. That’s one of the topics that I feel like I have much more to say about. Then we did a series of episodes on local first, so the sync episode, the local first episode, I think we had one sync revisited or something like that, or local first one year later. Those were some of my favorites. And then we also had a few, would seem like oddball episodes with the episode on cities. We had episodes on hiring and our corporate structure. And those reflects my interest in economics very broadly defined, and that’s something that, again, we touched on, but I have a lot more to say about that, but I was happy to have a few episodes sharing some thoughts on it. 00:28:06 - Speaker 2: Speaking as the showrunner or sort of editorial editor in chief, that needs to sort of guide what topics we explore, definitely some of these, as you call them, oddball ones, yeah, we had one on film production, we had one on progress studies, we had the one on cities, as you point out, and I guess I feel, especially since we’re all about ideas and curiosity, that being a little bit broad. In kind of not necessarily just tech world stuff or just running a company or tools for thought or something like that, you know, that that would sort of be too narrow and indeed we are curious people with wide range of interests, so that seemed natural to do. On the other hand, yeah, I think there’s probably points at which you go too far, you know, you got to have some uniting themes and topics and things that As an editor, you’re going to sort of draw, OK, this is clearly in, this is clearly out, there’s things I’m personally interested in and you’re personally interested in that wouldn’t be suitable for podcasts like that. So in some cases those were sort of taking risks and where we could, we also tried to relate it back, you know, the city’s episode, even though it was mostly about urban design. And urban planning, the guest there, Devin Sugle is, you know, from the tech world and product manager slash developer who could put things very much in terms that I think are familiar to what a lot of listeners of the podcast will resonate with them, even if it’s in this area that is something that maybe never even thought about before. So, yeah, those are some of the funnest to me, even if, yeah, there’s probably questions about where the edges should be, I guess. 00:29:41 - Speaker 1: And certainly it’s fair to have editorial ideas about where the edges would be, although I would say that both performance and economics, those are extremely related to software in my mind. Like the city’s discussion was basically about externalities, the economics of externalities and how they manifest in cities, but it’s also a huge deal in software and coordination problems again, a huge deal. So I have no problem justifying at least. 00:30:05 - Speaker 2: Hm. Yeah, looking back at a few of my favorites, looking across guests, and we’ve had so many great guests, but one that actually really stands out for me was this is episode 48, which is called Rich Text, that was with Slim, and Slim has worked with thinking and Switch, has worked at Notion, is now, I think, working in the academic world. But she is just so deep on this topic of kind of text as it is represented within computers, and indeed was even for me a mind expanding conversation because we went beyond just, OK, what you would think of, which is the text box in your messaging app or even the rich text editor inside your word processor, but we got into like equation editors and musical scoring and things like diagram tools, all these kind of like structured symbolic manipulation. And she’s been able to go both very deep and technical, but also we talk about why symbolic representation is just such an important and foundational technology for human knowledge. So that one was very memorable for me, both to record and to listen back to later. 00:31:10 - Speaker 1: It’s funny you mention that someone was just messaging me about rich text, and man, no one does not simply write a rich text editor. 00:31:18 - Speaker 2: Yes. On the team side, and I mentioned that sometimes these team episodes are some of my favorites, and yeah, it’s almost become a little bit of a joke on the team that, you know, I try to drag one of our colleagues in front of the microphone, who very often they prefer building stuff and you know, maybe English isn’t their first language and yeah, in general, just not super excited about being recorded, but they have so much amazing knowledge to. My perspective and I get to hear about that and be exposed to that through our our team discussions, but I think it’s really nice when we can to get that documented for the wider world and you know I really like the episode of MacA design, but one I think that I’ve heard folks come back to again and again is the one we did on Future of iPad, which obviously in many ways we bet our business on iPad as a platform. From the beginning as having this potential as a thinking tool, particularly with the pencil, and this was kind of coming back to that, like, what is the future of this device, what potential does it have a few years into it, and it was revealing because even though we’d had those some of those conversations internally, Having it for more of an external audience, I think revealed the way that me and you and Leonard, who is the other team member who was on with us, thought maybe about it a little bit differently and maybe even our ideas about it had evolved since we had started the company. It might be a little less timeless than some of our other stuff because we were talking about kind of the state of the iPad then, but I also kind of imagine that a lot of what we talked about then is still applicable. And then for episodes that are just you and I, I mean there’s so many. I love that episode 3 on manuals. I think it was one of the first ones where I got some, you know, private messages from people like, wow, you’re on to something here. Again, a great example of something we were developing the first manual for news that caused me to start reflecting on, OK, wait, actually, what do I want out of documentation, product documentation? And indeed this also I was able to find an old tweet here by Mel Parcola, who says, if you’re building a product, don’t skimp on the manual, it can be so much more than a boring description of your interface. I feel inspired to dream bigger by this episode of the MUA HQ podcast. And this to me again speaks to part of why we’re doing this is not just to kind of verbalize and vocalize our experience, but also hopefully to inspire others to see, for example, manuals as something of a product documentation is less of a like, oh, OK, I guess we have to do this before we ship the product, and more something that can be an important and integrated part of the product experience and indeed something good and inspiring just as much as any other part of what you’re building. I’ll also highlight the episodes on brand and product launches as being two that were really good for me personally to be able to kind of reflect on everything I had learned because a lot of the muse journey for me has been growing in the areas of storytelling, but also just kind of general marketing and that side of a business where I’ve traditionally been more on the product development side. So being able to in, you know, I’d read a bunch of books and talked to a bunch of people and then tried to do the work myself and not say that I’m an expert at it, but in many ways the best person to explain something to you is someone who’s just recently learned it. And so I think both of those episodes were for me, I had some light bulbs turned on around those topics, brand and product launches, and it was for me a chance to just kind of encapsulate that and talk through it all with you and in a way kind of lock in that knowledge for myself. 00:34:50 - Speaker 1: I see you also have the Learning from Games episode on your list, which I did as well. This is reminding me of something interesting. So there’s the extent to which I feel like we’ve said what we need or want to say about a topic, and then there’s the extent to which it, to my mind, has landed. So, for example, are like tools for thought, visual interfaces, infinite canvas stuff. I feel like we said a lot of what we had to say about that. It feels like it’s landed like people kind of understood what we were saying, and it’s percolated through the community, but some stuff like the local first thing stuff is sort of in between. We said quite a bit, it’s starting to percolate, but it’s still hitting some barriers, and for some reason it’s not fully out there. And then some stuff I feel like just hasn’t really landed. It’s like the performance stuff and the importance of The game industry and architectures is, I think it’s like a huge deal, and people just don’t seem to know about it or care or whatever, so I don’t know if our delivery has been unconvincing or I’m misreading the state of the community, but it’s a little bit frustrating and disappointing that some of that stuff hasn’t gotten out there, but I’m glad at least we gave it a shot. It’s in the record. 00:35:52 - Speaker 2: The learning from games episodes specifically, I think that was so perfect because we both come at it from different perspectives but also have drawn a lot of inspiration from video games and it felt like a non sequitur, but then in many ways I think it was, you know, quite perfect and we got very good feedback on that one. Yeah, now when it comes to software performance generally and why people are putting, you know, the struggles in the industry with computers keep getting faster, but our actual lived experience of them. Keeps being more and more spinners and delays and waiting on computers to do their thing. Yeah, it’s hard to say whether you know, is it a matter of timing, is it a matter of say it more, is it a matter of say it better, or is it a matter of, you know, we perceive something that others don’t like for me it’s just So clearly better when I use a piece of software that runs at 60 or more frames per second. It’s so superior to something where you’re staring at a spinner for seconds, but some other people maybe don’t experience it that way. It’s not a huge deal for them. They’re, I don’t know, more patient than I am or something. So it’s really hard to say to the extent we want to like, you know, illuminate this and get people to care and be excited and offer some positive directions you can go in terms of making software faster and more responsive to its users' needs versus our desires and interests and tastes just aren’t in step with what most of the rest of humanity and our industry wants. 00:37:15 - Speaker 1: Yeah, I mean there’s there’s a lot of factors there. My suspicion though is that people do in fact like fast software, but for systems reasons, it’s incredibly hard to deliver and candidly, we’ve seen that with views, you know, as much as I care about performance and you and I care about performance, just it’s hard to deliver. All things considered. And so I think the way that it happens is there needs to be some very deep systems thinking about what from a systems perspective, ends up making fast software. In addition to like, frankly, probably a lot of brute forcing in the form of very determined personalities. Yeah, but if there’s one kind of regret I have about the podcast, it’s that I didn’t spend more time on the systems ideas like around the economics of software and performance and stuff like that. So maybe that’s some topics for future episodes is either a guest or a transition host or something. 00:38:05 - Speaker 2: Indeed, I do want to talk about some episodes we want to do or haven’t gotten to or hope to do in the future or something like that, but I thought it would also be interesting here to take a little sidebar into the production process. Been in the position recently that a couple of folks who for various reasons are thinking about starting podcasts and ask us about our approach, which I don’t think it’s too wildly different from what folks in the rest of the What other podcasts folks do, but we do have a particular process and maybe be interesting to share with the audience. 00:38:39 - Speaker 1: Yeah, I think it would be worth just going through it, start to finish quickly. 00:38:42 - Speaker 2: Yeah, I guess there’s the what we call pre-production, and so this is largely coming up with topics and I guess I’ve developed a little radar for this in the form of, yeah, we’re having a discussion on the team about something we’re tackling again, we’re setting pricing, we’re working on the sync engine, we’re designing the Mac app, whatever, and then I go, oh, you know what, there’s a rich vein of discussion to be had here. But also there’s the guest side of it, which in some cases is driven by the topic. There’s a topic I want to talk about and I want to go find a guest, but in many cases it’s just there’s someone I follow on Twitter or someone whose work I admire or someone who’s working on a product that I think is interesting or has an interesting philosophy that’s relevant to our audience and you know basically just cold email them and say, what do you think, do you want to come do this and get a pretty good response rate. Now guests are a whole other thing because they need to be prepped, you know, maybe you do an initial call if you don’t know them that well and kind of talk through what kind of topics you might have, what the format of the show is. We do have a guest guide, maybe I’ll just make that into a public notion link and post that on the show notes for those who are interested, but yeah, we try to offer things like mic technique tips and things about, yeah, just kind of how we approach it. We’re also quite particular about having the right kind of mic. So we either get someone to borrow from a friend or most people are able to find or track down some kind of doesn’t need to be super high end, but a podcast quality mic, right, not just AirPods or whatever kind of Bluetooth headset you use and that doesn’t always work. Sometimes there’s background noise in the room they’re recording or you know, it’s actually difficult to configure these things to have the right pickup settings or whatever, but All of this is to say that actually quite a bit of work happens before we do come on air with guests, a little less for non-guest episodes there, it’s more like with the guests, I kind of count on them to say a bunch of smart things. All I need to do is kind of ask questions and keep the conversation going when it’s just us, I do a lot more prep work so that I feel like I have useful things to say for an hour. 00:40:44 - Speaker 1: Yeah, and for both topics and guests, I go back to this idea of growing or cultivating, like we talked about in our episode, Growing Ideas, I think it’s called. You don’t just sit down and decide, OK, we’re gonna talk about X today. It takes weeks or months, you start with a possible episode title, and then you say, OK, can I write 12 bullet points of interesting things about this? Maybe, maybe not, maybe try to find a guest, they actually want to talk about something different, so it’s an iterative organic process for sure. 00:41:08 - Speaker 2: Yeah, exactly, and discovering whether there’s enough depth to a topic to be sort of worth the recording time and the listeners listening time is largely a matter of, you know, for me, I make a blank board in muse and I start filling it out with stuff and trying to see and, you know, what are the connections here and what’s related and what’s not, and is this actually two episodes or actually is there not enough here to even fill one episode. So that’s the kind of open-ended ideation that of course Muse was exactly built for, and of course it’s especially nice now that we have the collaboration capability because you and I and whoever else is gonna work on the the episode can kind of pull our notes in this very loose freeform, messy format. How much time would you say you spend on prep in the cases where I send you a board and say basically, hey, here’s what I think we should talk about, can you add your ideas? 00:41:58 - Speaker 1: Well, if it’s a topic that I’ve already thought a lot about, the prep work per se is pretty brief. Maybe it’s a half hour of getting the bullet points down of things that I want to be sure to cover and collecting links and references. 00:42:11 - Speaker 2: Yeah, I think the citation is big because otherwise you’re stumbling on air. Oh, there was this book and it was that, was it called this thing and that, you know, this kind of thing versus you can just grab the link to the book’s website is right there on the m board, I could confidently read out the name of the book in the moment. 00:42:26 - Speaker 1: Yeah, but there have been some topics where they weren’t as much in my wheelhouse and I got to go think about it for a while, for sure. 00:42:32 - Speaker 2: And in terms of those ideas, what would you say is sort of the working material that goes into what eventually is gonna kind of pop out the other end on the recording? 00:42:42 - Speaker 1: Yeah, I think the working material is actually really important. If you go in there and just start talking based on just first principles, it’s actually not that compelling. So for me it’s our experience, not only in Muse, but in the decade plus in the industry. It’s specifically also the work in progress that we have, the stuff that we’re currently working through the challenges there, what’s working, what’s not. It’s everything that the guest has to offer. And then something that we’ve done kind of uniquely I think is we look a lot at the prior art, if we go into Google Scholar and type whatever, local first or whatever it is that we’re interested in, and relatedly the theory behind it, which can be, you know, computer science, design, human factors, economics, whatever it may be. And then a source of material that a lot of podcasts use, but we use pretty sparingly as current events. We tried to make these episodes pretty timeless. I think sometimes there’s something to be said for that, but that is certainly a source that you can draw on that’s very fruitful. 00:43:36 - Speaker 2: Yeah, that really describes well, not just kind of how we go about the ideas for the podcast episodes, but to me what makes good ideas generally, it’s really getting the whole picture, you need that tacit boots on the ground, real world knowledge. You need the prior art and the theory, the theoretical thinking, that kind of provides context and a balance to the more pragmatic aspects or practical knowledge, and the timelessness that that you mentioned is also interesting. It’s certainly something I have aimed for, and when I do occasionally hear people, they’ll tweet something like that they discovered the podcast and then went back to listen to every single episode or something like that, which is Certainly very nice to hear, but I hope at least most of them will sort of stand the test of time in the sense that, you know, obviously like a news podcast reacting to current events in the news, you know, be sort of maybe historical curiosity, but fairly boring to go back and listen to a podcast from two years ago, but here, hopefully, the vast majority of it that’s taking this bigger view, so therefore it should still be very relevant today. And also to your point about kind of having good ideas and sleeping mind and that sort of thing, what also helps me is I dump a lot of what I think we might talk about on the topic into a board, and then I’m thinking about what I might say when I’m just, I don’t know, walking my dog or doing something like that. Because important to me was I didn’t want it to be scripted. The whole point is that it’s an open-ended conversation and it can flow where it flows, but I wanted to just have those seeds, so you have the right place to start and you can make sure it’s a productive use of the time and the information dense and you don’t forget anything and that sort of thing. So then recording in some ways is the, we call it the easy part, but the fun part maybe you get to have a conversation with your friends and colleagues, and for that we started out originally using kind of like asking people to record into Garageband and we want to make sure we have the local lossless audio for all you kind of audio nerds out there, you know, just recording a Skype call, which is the way that some people did kind of like multi-person podcasts in the early days is, you know, the quality is bad if your internet has a hiccup, you don’t want. That unfortunately we did have a couple of instances of losing the audio file, it wasn’t properly recording or it was on the wrong whatever. Happily now there’s kind of a category of SAS tools. We use one called Riverside. It’s very good. It has the video chat and the audio chat, but it also does a clever trick with the browser where it’s essentially recording your audio in chunks in a lossless format, saving the browser’s local cache and then uploading those chunks as it goes. So it might be a little behind where you are in the conversation. But so far we’ve had very good luck in terms of not losing anything, and it’s really turnkey for our guests, which is nice, so I think an important tool like this is a good tool in the tool chain for podcasting. 00:46:27 - Speaker 1: Yeah, I’ve been very happy with Riverside. It makes a big difference, especially for guests, as you said. My only complaint is it only works in Chrome. So every time we do an episode, I click on the link, opens up Safari, you know, so I’m always 2 minutes late to these things. 00:46:41 - Speaker 2: And in terms of guiding it, you know, of course, again, kind of targeting that 11 hour and a half range, and I try to play host and kind of have a rough structure in mind and try to make sure we’re sort of moving through all those and we don’t miss anything, but for the most part, also again, let it be a conversation, let it flow, often it can just go places I never would have guessed or wasn’t really part of our prep work and those can often be the best moments in a lot of ways. So well that leads us to the post production side of things now in the very earliest episodes, I did the audio editing. And I didn’t do a ton on the call the audio quality in terms of like noise reduction or what have you. I focused more on really it’s called the editorial in the same way that you would edit a piece of writing by removing filler words or, you know, fixing the grammar, I would go in and essentially just kind of snip stuff out, which incidentally made me first of all incredibly aware of the filler words that I use because I’m in there having to manually select them as much as I can and delete them. Actually, you know, like, um, uh. And I think to some extent doing that process of audio editing has helped me use fewer filler words, at least in the recording setting. But yeah, this is a really natural thing that everyone does and you don’t notice it in normal conversation, but I think it can impact the listenability and the signal to noise ratio in a more kind of produced recorded format like this. And the other thing I did there was to just take advantage of that I’m in there listening to it and I think, OK, this part is boring. I’m just going to delete this whole minute, which more often than not was me. And so I would discover that I would start to talk on a topic. I would say something interesting, and be like, oh, that’s pretty good. And then I would keep talking after that and kind of say the same thing again, but worse, and I eventually learned, once you’ve made a point, just make the point, shut up. Now I did the first few episodes, you later took over and brought a more kind of professional tool and more levels balancing and noise reduction, and I’m not sure exactly what, but it seemed like you went a little bit down the audio editing rabbit hole for fun. 00:48:49 - Speaker 1: Oh yeah, I really went down that rabbit hole. I tried to teach myself audio editing from scratch with a focus on improving the audio quality. The modern audio editing software is kind of amazing. There’s All kinds of filters and stuff you can do to reduce noise and improve the quality and balance of the audio, but it’s kind of a dark art, so I watched a bunch of YouTube videos on how to do it, and I think I eventually got OK, but it’s a lot of work if you’re an amateur. It took me about 1 day to edit a podcast episode, and if you think it’s bad to listen to your own recorded voice, how about listening to it 10 times on a loop? 00:49:26 - Speaker 2: Yeah, I was amazed the results that you were able to get. Yeah, I think it was somewhere around episode 4 or 5 that you took it over, and the difference is really notable. And again, I appreciate that. I think it’s respecting the listener and making it listenable and yeah, it’s a good thing, especially when you have a guests who, yeah, their levels might be different or the way they speak might not even be something the audiences used to, and I think it was really valuable, also seemed to be a fun. Experience for you, but yes, so labor intensive, and I think that’s true for professionals as well. I think for every minute of recorded audio you hear, it’s several minutes at least of editing. It’s a big job. 00:50:05 - Speaker 1: Now most of that time is for editing all the, we need a word for this, but what’s it called you edit all the ahs and ums out, there should be like this line editing, content editing, what’s the equivalent for audio. 00:50:16 - Speaker 2: Yeah, I don’t know if there’s a we should ask our audio editor, but I just think of it as removing filler words. 00:50:21 - Speaker 1: Yeah. Anyways, that’s where most of the time was the baseline improving the audio quality. First of all, there’s these noise filters that basically work out of the box, and I hear a lot of podcasts these days that clearly don’t apply it, and that’s really leaving money on the table cause it’s really easy to do this. You run it through these filters, it sounds much better right away. And then there’s some basic balancing that you can do, and that you kind of gotta do it for each episode, at least for each new guest. And for each new room that you’re in, but once you do that, it’s pretty straightforward to do for every episode. So I think at least doing that is really worth it, and you can teach yourself to do that for sure. 00:50:55 - Speaker 2: But yeah, I think then somewhere around, I don’t know, maybe it was episode 10 or in that ballpark, you realizing that spending this huge amount of time on the audio editing was not maybe the best use of your time when we’re also trying to get a product off the ground, so you went hunting for a freelancer that could help us with that, and you found someone really amazing who has done every episode since then, so I have to give a big shout out to Mark Lum or Jay-Z. He is a really talented professional. He’s done audio work for major TV shows and that sort of thing. I have no idea how we were able to land him for our relatively small little corner of the internet here, but he just does amazing work. But the other place where Mark’s editing has made a huge difference is with guests. And so these are folks who, although we try to get them the right equipment and teach them some basics of how to keep your mouth the right distance from the mic and that sort of thing. They’re just probably new to podcasting. They don’t necessarily have the same kind of techniques and disciplines of all that we do. And in many cases there are folks who are non-native speakers, some of our really great guests, you know, you think of someone like Balant from Kraft. He’s not a native English speaker, he’s not someone who does a lot of public speaking from what I’ve seen, but that actually made him all the more someone that I wanted to hear from. Here’s a great operator and a great person building a great company. Who you don’t hear from that often, to me that makes him really high value to get in front of the mic, but he, like many of our other non-native speakers, it’s hard, it’s hard to sound articulate and intelligent in a language that’s not the one you grew up with. And this is a place where, first of all, giving folks the opportunity to know that they are struggling a little bit with an answer, they can stop and restart you and I do that, of course, all the time, and then we edit that out so that we always sound perfectly articulate. Furthermore, if someone has, yeah, the combination of background noise, mic technique, etc. non-native speaker, etc. and we can just kind of like make them sound as good as possible and in this sense not sound in the sense of what they’re saying because their words are their words, of course, but kind of elevate the audio quality that gives the best possible stage for their really worthy ideas. And so one of the places where I think Mark’s editing work I’m most happy about is when we have guests who come back and say, wow, you know, I was really nervous about getting in front of the mic, but this sounds amazing. You made me sound so smart, and then I’m thinking, well, you know, you are smart, it’s just that we kind of created the right audio environment for that to come through. 00:53:31 - Speaker 1: Another big deal about the editing work that Mark does is he does the content editing with, from what I can tell, little or no direction, and it comes out correct. Like this is something I was really worried about when we were initially trying to outsource the editing as part of the reason I wanted to do it myself first is to like convince myself I knew what really good looked like, but then people have to navigate, you know, these 2 or 3 people talking about this tech stuff and figuring out Where to start and stop and how to re-edit so the content makes sense. It’s quite hard to do without direction. And if you have to give someone a lot of direction, then it kind of defeats the purpose, you know, you want to be able to say, please make this episode good, and you get it back and it’s good. And I feel like, I mean correct me if I’m wrong, I feel like that’s basically how you operate with Mark. 00:54:11 - Speaker 2: Completely, yeah, no, we do have some back and forth, which is he wasn’t sure about should this section be in, it seems like a duplicate. Was this part of mistake, how should this part flow? So there is some back and forth there. I’ll also give a shout out to a more recent addition to our podcast team, which is Jenna Miller. I think she’s done the last 20 or 25 episodes, and she works closely with Mark on some of that content editing, making decisions about what should be in and out, things like description, show notes, she also makes the audiogram, which is that little kind of video preview thing that we can embed on Twitter, but she’s also just like another pair of ears to help. Figure out, yeah, what should be there or not. And that also includes things like I try to avoid, I don’t know, some kind of like veering off into like charged political topic, for example, or something like that, not because I’m afraid of talking about those, but just again coming back to that editor in chief trying to decide what’s in and out and I try to make it a kind of calm, and a safe space, quite the right word for it, but something that’s not going to be too triggering. And so sometimes it does happen the guests mention things and I go kind of I don’t know if that quite is should be in there or not, and yeah, so all those kinds of decisions are things that Jenna now can largely make with a little bit of input from me, finding links for things and so on. So that combination, the two of them are an incredible team and certainly I’ll link to their profiles if anyone wants to ask if they can help you out on your podcasting journey. It’s still a lot of work to come up with the topics and find the guests and do the prep, and so on, but having the whole postproduction thing be largely in the hands of a talented team of experts has made a huge difference. 00:55:54 - Speaker 1: And did we talk at all about hardware? 00:55:57 - Speaker 2: I don’t think we did. 00:55:59 - Speaker 1: Yeah, so I’ve been on quite a journey with hardware. When we first started the podcast, I looked up this site on Marco.org. He has this incredible podcasting microphones
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: Being able to do important and deep work in a world where information is not scarce, but abundant, not only abundant, but so abundant that it essentially becomes a problem. Hello and welcome to Meta Muse. Muse is a software for your iPad that helps you with ideation and problem solving. This podcast isn’t about Muse product, it’s about Muse the company and the small team behind it. My name is Adam Wiggins. I’m here today with my colleague Mark McGrenigan. How’s it going, Mark? Alright, Adam, how are you doing? Yeah, I’m doing well. Reading an interesting book about the life of Claude Shannon, the guy that invented information theory. So this was at Bell Labs circa I guess middle of the last century. Uh, for example, the, uh, that seminal paper coined the term bit, which I think I, I almost take for granted sometimes these fundamental inventions, you think, well, it’s just always, we’ve always known what a bit is, but in fact, boiling information down to a stream of ones and zeros and being able to reason about that mathematically is a uh an extremely significant breakthrough to put the, to put it mildly and surprisingly recent from my perspective. Yeah, interesting. So our topic today is the information age, and I usually put information age in caps. It’s in comparison to say the Iron Age or the industrial revolution. And I guess the the basic idea with this is that humanity or society has entered an era that’s defined by the I guess the massive availability and the free flow of information. This dates back to, I think the Wikipedia page talked about the invention of the transistor which kind of made possible things. Like global telephone networks and radio and TV, but obviously the computer as well came out of that. I think it’s become particularly cute or the information age and how different that is from what came before is really dramatic in the last 10 years or so, uh, with smartphones and the internet and social media. Uh, one statistic I read recently, I found a little Uh, mind blowing was that the essentially there’s total penetration of internet and smartphones, the stat I read was that there’s 5 or 5.5 billion people on Earth who are over the age of 15, so adults, and of those 5 billion of them have some kind of mobile phone and about 4 billion of them have smartphones. So for our purposes. Again, everyone’s connected, and now this new age is kind of defined by that. 00:02:35 - Speaker 2: Well, that’s a broad and weighty topic. What’s on your mind about the information age then? 00:02:39 - Speaker 1: Yeah, well, obviously connects to to muse here because we see it. As a tool that helps with this, which is particularly for creative professionals and being able to do important and deep work in a world where information is not scarce, but abundant, not only abundant, but so abundant that the it essentially becomes a problem. I read a nice article the other day called the Information Pathology. And they make this comparison to how in the 20th century, the abundance of food sort of slipped our widespread health problems from not enough nutrition, not enough calories, which essentially is a problem most humans had faced most of their lives or, you know, most of the existence of, uh, certainly civilization and flipped it over to now we’re worried about essentially having access to too much food, that the problems are obesity and uh diabetes and heart disease and so forth. And the author here makes a comparison to say, well, maybe in the 21st century, we have a similar thing with information, where we’re also hardwired in many ways to seek information, that new information is a way to be. Prepared for what the future might hold, assess our safety and do things to improve our lives when you know things about what’s going on in the world around you that can be extremely helpful to say the least. But then you add in this era of hyperconnectivity and the 24 hour news cycle and social media and newsletters and everything’s being pushed to you all the time and everything seems important. And that can quickly turn into more of a gambler at a slot machine getting the the dopamine hit from that next, um, that next piece of information rather than, yeah, rather than spending your life on things that are more meaningful to the point that we have people thinking about things like digital detox and Deleting social media from their apps and this is, this is quite a big topic now of how you actually manage this problem of information abundance. 00:04:38 - Speaker 2: Yeah, you had shared that article with me, and I found it very interesting and indeed alarming. The topic of food and nutrition is one that I’d studied for a while, and that’s an area where there’s something that’s incredibly important, but over the past 100 years. So we’ve really lost the plot and it’s caused an enormous amount of damage to us as individuals and as a society, and we haven’t fully confronted or even understood that 50 or 100 years in. So if you analogize that to the information age, it could very well be the case that we are, you know, victims of our own own abundance here in ways that we don’t and perhaps won’t understand for another decades or even. 10 years. And that’s a pretty alarming thought. 00:05:15 - Speaker 1: It’s hard to know whether it will be on that same scale, but I certainly feel that certainly the the change in our daily lives as humans and the changes to our society of the information age broadly is huge and dramatic. I, I do think it’s on par with the industrial revolution. We we don’t know yet because we’re not far enough to do it, but that’s, that’s my gut feel going from there to, well, such big changes in the world will bring both positive and negative. And there’s obviously many positives to having access to essentially unlimited information all the time, uh, but there’s also many negatives, and I don’t think we’re going to figure that out in the next few years. I think it’s going to be an ongoing process of society adapting and figuring out. Um, how to, how to manage this and try to get the good parts and leave behind the bad bits. 00:06:03 - Speaker 2: So how do you start to grapple with that? What’s good about the information age and what’s struggle? 00:06:08 - Speaker 1: Yeah, well, I think the, you know, what’s good in terms of access to all the world’s information at your fingertips is almost so obvious that it hardly needs stating, but You know, Wikipedia is amazing, Google is amazing, uh, Twitter is amazing. Uh, you can get access to information that could be relevant to your career. Certainly if you’re a person that does creative, you know, you’re creative professionally do knowledge work of some kind, which probably anyone listening to this podcast, it’s likely in that category, having access to so much is extremely powerful for your career. Uh, and also in your life, right, making decisions about Important life things like parenthood or adopting a pet or taking care of an aging parent or buying a home or any health things, and the abundance of information, you can get personal experiences, you can get academic information. You can download books, you can watch videos on YouTube, you can become, let’s say not become an expert, but you can completely absorb yourself in almost everything humanity knows about any subject at any time, from the comfort of your own home, uh, even just on your phone, if you choose to do that. One personal anecdote I give from my life about how kind of information and particularly broad, let’s say more like global news has an impact on your life. Uh, with the pandemic that of course we’re still in the midst of here in in 2020, but when that came along, I was alerted to it essentially by basically a lot of people being alarmed on Twitter, and that caused me to stop and think, yeah, let me look into this briefly and kind of do my own research, which, you know, for me was making a use board and pulling out a few relevant bits onto that so I could kind of poke them around and try to make, make sense of it. And I’m really glad I did because a few weeks later, someone that I live with basically had a close encounter where basically her school, her entire school was shut down due to someone there uh testing positive and then suddenly there’s all these, you got. quarantine, you got to do this, you got to do that. And I think that would have been really surprising and disorienting and upsetting if I hadn’t already been studying exactly what was going on with this. And instead, I said, oh, OK, I actually have my head around this. I know what to do and um that information being not just that I went out to seek, but actually being pushed to me through these, uh, through social media and through through news channels turned out to be very helpful in making good decisions and uh. Essentially it was, it was information that had an impact on my life. So how do you think about uh the information age? Do you, first of all, I guess do you agree with me, uh, we, we didn’t talk about it before, but do you agree with me that it does have, you know, an impact, such, such an outsized impact potentially, and, uh, where do you see the, the, the, you know, the, the benefits to you or humanity at large and likewise the Downsides. 00:09:05 - Speaker 2: Certainly I think there is a big impact from the information age. I think that’s hard to deny. An interesting insight I got from a book called The Rise and Fall of American Growth, though, is that as seemingly as important as the information age is, it’s, it still hasn’t kind of fully impacted the whole real economy and our, our entire physical world. Uh, this book makes a point that if you look at the, the economy of developed nations, it’s things like housing, healthcare, education, caring for children and elderly people, uh, things like this comprise much of the economy, and those have, you know, started to be affected by the information age around the edges for sure. You have like Zillow for real estate, for example, but the way that we build homes is basically the same. As it is 40 years ago, but you have a nest on the wall that connects to Google. Um, so in that sense, I think there’s potentially actually a lot more that could happen as computing and information pervades more of our real physical lives. Now, now that said, I think certainly it’s already been very impactful and and in my line of work, I enjoy a lot of those benefits, but potentially a lot more to go. And the other thing I would say is, I don’t think we understand the full impact and implications of all these new information flows. Again, I think the analogy to food and nutrition is very useful, where it took us decades to begin to unravel all the weird stuff we were doing to our bodies and our societies, um, with these new food pathways. I’m afraid we’re going to go through the same experience with all these information flows. 00:10:27 - Speaker 1: Well, to bring it back down to the personal level, I guess one question that I see a lot of people grapple with is how to have a healthy relationship with, they usually say technology or social media, but I think of it as the information fire hose being connected to the whole of humanity and everything that it is thinking about and it’s going on because it’s a powerful feeling, this feeling of being informed or in the loop or connected. And you know, whatever that may mean for you, it might be connected to your field or connected to a smaller community that has a private group, but it could also be connected to global news and what you do is you end up or what I often hear people talking about and and face myself a little bit, which is how do you, for example, spend less time on social media and more time reading books. So for example, um, the YouTuber and podcaster CGP Gray. Uh, did a pretty substantial, not quite a digital detox, but basically got off social media and all this sort of thing for some period of time with the justification of, I want us to take more walks in the wood and woods and read more books, and I hear a variation of that a lot, people. I don’t know, maybe in Silicon Valley, people go on their 10 day meditation retreat, they don’t speak and they don’t bring technology with them, and you even see things like software specifically made for this, uh, even as far back as when I was in Y Combinator, which is now 13 years ago, uh, one of the folks in our batch was rescue Time, which is still operating today. It’s basically a plug-in for your computer that monitors how you’re spending your time and helps direct you away from the You know, spending time on Reddit or whatever and towards things that you define as productive how you define those things, which of course is especially confusing for a knowledge worker, I think because you have stuff like Slack and email being connected to your company’s sphere and I think it can have kind of the same quality of being connected to the news cycle or uh sort of the global global news, which is always some new thing, you know, I open up, I don’t know, notion, I open up slack, I open up Figma, I’ve got, you know, a little notification thing. Someone left a comment and someone’s done a new thing and there’s, you know, there’s someone’s pushed a new thing to Github. There’s always, there’s always some some new thing to follow and that becomes even more true as company gets bigger and more mature and that has some of the same quality where you can easily lose a lot of time in your day to these more reactive type things rather than the deep work or the bigger projects or prioritizing your own time. And I think when Apple came along with screen time, that was also kind of an acknowledgement of that and I see people doing tricks there. But I kind of see all of that stuff as as really like mitigation strategies, um, it’s it’s our short term hack for OK, we’ve recognized that losing your whole day to being on Twitter or spending too much time answering email or slack versus focus projects, you don’t feel good about that, you don’t feel like you’ve spent your time in a good way, but the techniques we have for managing that feel less like we found a way to live in harmony with the nature of the world and our information. flows and more like we’ve just put these little blocks in place in various places to again to try to manage that. So I’d love to figure out and I’m still exploring this for myself, but how to, how to live in harmony with the information fire hose and get the most of that, get as much from that as I can for my work, for my life, uh, while at the same time kind of avoiding some of the worst, the qualities of it, the addictive qualities or the qualities that in retrospect I feel like I. Spent my time well. 00:13:59 - Speaker 2: Yeah, for sure. First of all, I think you’re seeing this emerging intuition that information flows have different quality. Also, we’re seeing that there’s opportunity cost to spending your time with these different flows. Any time that you spend checking Reddit, for example, is time that you can’t spend with your family or exercising or what have you. But then I think there’s in the last 5 or 10 years, this has all been amplified by the social networks and the feeds, and there I think the situation is getting more. Adversarial and intense because you have these companies that are motivated one way or another to engage you right with these, these feeds at the same time, the individuals like ourselves who are on the other end of this, we don’t have full-time people who are working to represent our side, you know, this harmonious engagement with information flows. So I think it’s not surprising to me that it feels like we’re kind of on our back foot, like we’re playing defense, like we’re trying to mitigate, like we’re trying to put our finger in the dam. Um, I think that’s a function of the structural situation that we’re in. 00:14:55 - Speaker 1: Again, that fits with the food metaphor where it’s easy to just put it all in the individual, and I think each of us can make healthy choices, but when you have a pretty serious, let’s call it infrastructural approach to making you want this thing, whether it’s fast food that’s designed to push all your primal buttons for sweet, savory and salty, and then on the information diet side of things, you’ve got. Some very, very smart people working for the Facebooks and Twitters and Instagrams of the world to get you to come back, re-engage, be involved in the feed. So as an individual trying to use willpower to manage that is, is a challenge for sure. One thing that my eyes on this quite a bit was I read this book Hooked back when I was working for a, for a company and at the time the book was circulating among the product people there saying, hey, there’s some interesting ideas here with, for example, using push notifications to help people re-engage with your app and for apps that are focused on active users and that sort of thing, that’s, that’s a desirable thing. And I remember reading this book and just having a sinking feeling in my stomach. This was, you know, I don’t know, 67 years ago. Having the sinking feeling in my stomach of a wait, we’re engineering things to sort of create these loops to bring you back according to not what’s most valuable to you or how you can get the most utility from whatever this product is, but just according to your, your natural desires of wanting to be connected or the orientation response or something like that. And actually the reading that book, which was not was not intended to be a cautionary tale at all as far as I know, uh, but that had a big impact on me and the next thing I did, which was, uh, start the ink and Switch research lab and one of our core ideas that we wanted to explore is OK, as technology and social media and the internet is taking on this new quality that’s going to be harder and harder to resist or hold at bay. How can makers and people who need to focus and get in the zone and do work, how can you manage that? How can we take back maybe some of the way that computing is made and the way that software uh works to better serve, I guess the user’s life goals or work goals rather than companies, let’s call them engagement goals. 00:17:20 - Speaker 2: Yeah, this is an insight from the ink and Switch lab that’s really grown on me over time. I’ve come to appreciate how important it was. There’s this world of call it consumer engagement based computing, which is really flourishing, like there’s a huge amount of investment and lots of great services, some of which I spend a bunch of time on like Twitter, um, and then there. The enterprise computing world like B2BASS, which again is, is great. I spent a lot of my career working in that and there’s natural economic funding for those two worlds, but we really needed to make a deliberate effort to support this world of computing for creators for having better ideas. So I’m glad we, we ended up working on that together at the lab. 00:17:53 - Speaker 1: One of the small areas there that I became aware of through the research that we did was the prevalence of notifications. I think I mentioned earlier, like even something like notion or FIMA tends to have some kind of a notification thing. Even VS code, which is a, you know, a programming editor, has a little, you know, has some little like indicators that sort of uh click here, there’s something happening, something you need to know about. The red dots, man. red dot. Sometimes if they’re they’ll make it a blue dot if they’re making it a little more chill, but yeah, the red dot badge put that on where we’re talking with Max recently about the no spinners thing and for me the no notifications basically respect the user’s attention and focus, don’t get in their way and Certainly don’t try to distract them or lure them away with that inbox feeling or there’s something I need to check. And it’s tricky because of course, there are times you do need to proactively let the user know something or maybe they they want to know, but certainly I hope news will never have anything resembling a notification segment. 00:18:52 - Speaker 2: Yeah, and speaking of notifications, this reminds me of another book in this in this genre, which is now a whole huge thing. There’s a bunch of books, you know, written along this vein, but this is digital minimalism, part of his thesis is that consumers are being constantly bombarded now by notifications and re-engagement loops and that you can, he argues should be more deliberate about how you engage with those platforms and do less of a notification based model and be more selective about how you engage in these information streams. Yeah. 00:19:18 - Speaker 1: Certainly, I put a lot of work into basically turning off almost all notifications on my devices. I have a couple of key things that go to my phone. Never want it from my desktop computer. I had everything turned off on my iPad for my phone, I do have a couple of things, messages, emails that I do want to be notified about. I think of that as my communicator device, that’s purpose, so it makes sense that I would be notified there, but certainly I never want push notifications for something like breaking news or Twitter mention. or anything like that. I want to be more deliberate and even email um is something where I, you know, I like the model of check it in the morning and again in the afternoon rather than something that’s more interrupt driven. But the nice thing about having the phone be the notification box uh is that I can turn off the ringer and put it face down someplace whenever I’m going to explicitly go into a work session and not be worried about, for example, being right in the middle of something and then suddenly my phone. Tablet and my computer are all chiming to get my attention for for a single thing. 00:20:16 - Speaker 2: And that perhaps seems like a small change, but I think managing my notifications has been really important, which is mostly turning them off, moving to a model where I choose if and when to engage with these different information streams. A similar one would be holding social media feeds. Again, the structural pattern there is that these sites really want you to go there and refresh all the time, which in some cases it’s, it’s hard to avoid because there’s no APIs, but wherever possible. I’ve I’ve moved to a model where these updates get batched, sent to me, and I can review them asynchronously. So for the Washington Post and Hacker News, for example, I get emails once a day for those, I check them at some point, but I’m not constantly refreshing. 00:20:50 - Speaker 1: Now, so far, most of these techniques we’ve mentioned here are things that let’s say are general, general purpose that basically social media and news and messages and emails is something essentially every human on the planet, more or less needs to needs to manage. But then bringing it to the realm specifically of the knowledge worker, the creative professional or someone that is doing something that requires deep focus and they want to create, either as an individual or in groups, uh, there I feel like it becomes less clear. There’s obviously those same techniques that individuals can use of managing your notifications or measuring screen time or something, but I was, I’ve also been struck by the number of techniques that I’ve seen seen emerge for let’s say more maker oriented activities. Which includes, for example, uh, pen and paper sketchbooks remain not only as popular as they ever were, but I almost feel like more so because it’s a place where you can go and write down your ideas and have information technology, which pen and paper certainly is at your disposal, there’s no risk of a notification popping up or being tempted to switch away and pop open Twitter or whatever. Then at the same time in groups, I’ve seen, for example, Sometimes it’s certainly it’s considered maybe a good habit to turn off your your ringer in a meeting, but I’ve also seen things like, OK, there’s a basket in the middle of the table, everyone put your phone there, and we do this just to enforce the discipline that we’ll all be here in presence in the moment and scribbling on the whiteboard and having the group discussion and not tempted to to switch away. And maybe I get a version of that as well with um using a Kindle hardware device to do my book reading, um, and there I like that I do get a lot of the benefits of digital, which is obviously I can have a lot of books in this one small device and I can highlight things and highlights go into a database and so forth, but it cannot do anything other than read books. So I stay really focused. Those were some techniques that struck me as kind of how you can do more, say, knowledge knowledge work type things in an information age, uh, that sort of holds the holds the fire hose at bay. Do you know of any uh techniques that you’ve seen or that you use for yourself in that nature? 00:22:52 - Speaker 2: techniques that I use tend to have that same flavor of pre-commitment, like you do. Something upfront such that you, you sort of commit yourself and your knowledge work to doing the thing that you want to be doing, and you’re not constantly having to make the decision of should I be doing the work that I want to do, or should I be checking Twitter. Uh, so a big one for me has actually been reading books on paper. For a long time, I read books on my phone or my iPad with the Kindle app, which is nice. Uh, you get a lot of flexibility. Obviously, you can carry a zillion books, but I’ve always had the temptation. of checking the other apps on the phone, or even like thinking about it and having to decide not to, it ends up getting wired very deeply into you. I think if you use these devices a lot that you can, you know, press the home button and see all these shiny icons and click on them and get stuff. Um, so I’ve moved to a model of I read books on paper, even try to go sit physically away from my devices, you know, put them somewhere else. So it becomes a session that’s about the reading and the thinking. 00:23:40 - Speaker 1: I’ve even seen different social, let’s say reactions from others when you are, yeah, reading a paper book with a pen and paper sketchbook, even with my Kindle hardware, I think there’s a version of this which is when I, I also read books on my phone just using the Kindle app for a few years and yeah, people just assumed that you’re on Facebook. Which is funny, and, and they, they respond differently. They treat you almost with more deference like this person is thinking deeply. So in the lab, we had a track of research around attention and focus and how that connects to getting into a state of flow and doing work, particularly difficult maker work. And one of the insights we had there was that the benefit of the information banquet, of course, is being able to go out and search Google Scholar and find every paper that’s ever been written on a subject or go on YouTube, or go down a Wikipedia rabbit trail and end up with 50 open tabs. That that’s a really powerful way to gather to collect information, but there’s sort of no bottom to that. At some point we found that people need to draw a line around or draw a fence around a set of information and say, OK, I’m not going to go further than this. Now I want to take this set of sources, whether they’re papers, whether they’re websites, whether they’re tweets, whether they are excerpts, whether they’re photos they’ve captured on their phone, whatever that material is, and I’m gonna take this set. And I’m gonna treat that as a fixed set, and now I’m gonna look through that, read it, ponder on it, look for connections, look for patterns, and often that or second phase, I think we, we call it in some of the, in one of the papers that sort of second phase of rumination is best done, a little disconnected, a little removed. In fact, the ideal thing would even be going offline, going along train ride or something, and there’s just there’s no Wi Fi or what have you, um, and being able to do that. But the thing is you’re either all on or all. There’s no middle ground. You’re either in digital detox mode, your phone’s in airplane mode, you’re not using your devices effectively, or you’re fully connected. You’re on the internet. Basically almost all software nowadays requires internet connection to work properly. And so the idea, for example, being able to look through a set of web pages, uh, without an internet connection isn’t really very viable. So one of the things that that research and those insights fed into use was this idea that you’d be able to ingest things into this. Private, safe, sanctuary like space, know that anything you put in there is not dependent on an internet connection and then be able to take that set of things and then go someplace whether or not you’re connected. In fact, maybe it’s even better if you’re offline and be able to go through all of it and think about it and draw your conclusions and potentially use those conclusions in whatever work you’re going to do. 00:26:25 - Speaker 2: Yeah, I think that character of where you’re doing this deep thinking and rumination is really important. Especially now because the public wild internet is this incredibly frenetic, almost combative information space, you know, likes, retweets, refreshes, ads, notifications, uh, and, and the prospect that any of those could change or you could open a new app. It’s almost like you’re in fight or flight mode, right, when you’re out there on the wild internet, and I think it’s just psychologically really hard to relax so that your mind can do the deep background processing that it needs to um accomplish this rumination. So I think crafting the space, well that’s physical. digital or perhaps both that supports that work is really important. 00:27:03 - Speaker 1: You mentioned the technique of reading paper books as one way to manage this. Uh, we’ve also seen in kind of the ethnographic studies that printing stuff out is a technique that people use for that, so it’s the same kind of ideas as the book, which is, OK, I’ve got these, I’ve got a couple of papers, I’ve got this one website, and I’ve got a couple of screenshots and I’m gonna print all those things out and then be able to go and work in a paper workspace just on a desk or something like that. Uh, with this fixed set of things. And of course it seems really funny to be printing out web pages and printing out screenshots, but in fact it is a good technique precisely because it is this fixed set because you’re not tempted to to go down the shiny objects path, tumble off that edge, and you can really stay focused on what’s in front of you. 00:27:49 - Speaker 2: Yeah, I think printing also relates to your physical space and posture. I know that some people print out stuff so they can read it at their desk, like the same place that they have their computer, but I know that when I like to do this rumination type work, I prefer to do it basically on a chair or a couch in a sort of semi reclined posture. When I’m quickly gathering information on the go, that’s the phone, when I’m ruminating, doing deep thinking. Developing ideas in something like Muse, I like to be sitting down in a soft chair, and when I’m doing like editing complex documents, I like to be sitting upright office chair at my computer and I found that those different physical postures are actually really important to encouraging the right type of creative thinking. 00:28:24 - Speaker 1: The other thing you get with printouts as well as the ability to put them in say 3D space, physical space. So often when you go to, I don’t know, an agency office or yeah, certainly an academic’s office or any anyone who does designers, for example, often pin up storyboards and screenshots, you know, annotated screenshots of an application that they’re working on. Obvious movie filmmaking folks tend to do kind of storyboards on the walls, but there’s something about not only being able to have that sort of tactile, uh. Experience and different posture like you said, but also the potential ability to put it around us in space and to have agency overdoing it. 00:29:02 - Speaker 2: I think this is another really important psychological state like you feel like you have agency over your information, your work, it’s really hard to invest your deepest creative energies when you feel like it could shift out from under you at any time or someone could take it away or could get, you know, refreshed or something, the physical printout or desktop style apps that are very stable. Give you that sense of agency over your work. 00:29:22 - Speaker 1: Yeah, I think that agency element is a big part of why I still like files. Uh mobile platforms have largely abstracted away files, and I think that’s basically for the best for certainly the the common case of the, yeah, consumer that has more limited needs in their computing life, but for the maker, for the creator that wants to build up their own personal archives over time. Maybe I shouldn’t speak for others, but I’ll speak for myself, which is files have this very simple quality. They seem very tangible, even though of course they’re they’re digital, but they’re, they have this, this timelessness and maybe it’s that they work across platforms, maybe it’s that they’ve they’ve been around a long time, but I feel like there’s more to it than that. They have a they have a feel where I feel like, OK, if I’ve got the file, I’ve got it. I’ve really got it. Nothing’s gonna take it from me. It’s not gonna change out from underneath me. There’s this, I guess there’s the ownership quality, but, but it really does feel like agency. If I want to have two copies of the file, I can. If I want to delete the file and know that it’s fully gone, I can also do that files for all their challenges they maybe create in the computing world for people needing to, I don’t know what manage their hard drives when they’re not prepared for that. They do have a lot of qualities that I think are really promising. 00:30:32 - Speaker 2: I think that’s really important. I think this is an example of a case where that we’re going to find out in the order of 1020, 30 years that the approach that we’re taking to information management today has some big downsides. Personal data, creative data that’s tied up with applications, especially applications that are like networked on the internet, uh, you can only load them remotely. This is very brittle. It works great, you know, now you get this web app that you can load anywhere, but it’s really unlikely that the Data is going to be readable and accessible in 30 years, for example, whereas if you had a text file from 30 years ago, there’s a very good chance that you could have preserved it, and that would, that would be in your agency to do so. And so I think this is a trade-off that’s only going to become apparent as we get a few decades of experience with these tools. And and my bet is that files and file like data that’s independent from applications is going to be the right side of that bet. 00:31:17 - Speaker 1: this reminds me of something we talked about previously, which was. and um command line and that sort of thing and that particular paradigm and that particular way of interacting with my computer fell out of being so central and important for me because as the phone became more uh bigger part of my computing life, plain text is a great example of something where I’ve I’ve relied on that for a very long time and I I do love plain text, but increasingly as I find it’s hard to embed a link, it’s hard to emoji in there. I kind of want an image and you know, I kind of want bullet points. Those are a hassle and like increasingly the capabilities it has are not quite enough or not quite keeping pace with the modern world and so yeah, it’s always a trade-off there where at some at some point I go, well, plain text just doesn’t quite cut it for me anymore, but then yeah, we are in in making choosing to, I don’t know, jump into some. Some app that has all the modern sleek features, uh, then I also lose some of these qualities of timelessness, agency, data ownership. 00:32:20 - Speaker 2: And perhaps we can do a whole podcast at some point about our thinking there and how we’re trying to bridge those two worlds with Muse, but I think as it relates to the information age just this idea of retaining your data is really important. I think an unresolved question for our current set of network-based apps. 00:32:34 - Speaker 1: And maybe another piece of that. That is your data, so the concept of what your data even is, which is maybe a little bit like the drawing the fence around things that I mentioned earlier, but yeah, if I, if I write a paper, that’s obviously my work, but if I reference a paper someone else has written, if I download that paper, go through it in detail, mark it up with a bunch of highlights, well, I tend to think of those highlights as being my. And certainly my Kindle highlights, I think that way, even though they’re an annotation on someone else’s work. I think there is this threshold you cross or there is this better way to put it is that I think it would actually be a good idea or it is potentially an approach to living in this information age that could be helpful, particularly for knowledge workers is to have an idea of what’s mine and what’s the rest of the world’s. So when I’m just scrolling through a Twitter feed, That’s the, the flow of the information world. It’s not mine in particular. I don’t even really want to keep it around. I would quickly my information systems would quickly get clogged if you try to track every single thing that you read, which by the way, is a is an idea that came up frequently when people were talking about this kind of Memex derived lines of research, which is why, why don’t I just save everything I’ve ever seen. And it turns out that people have written systems to do that and it quickly becomes unmanageable, not just in the sense of large data sets are unmanageable, but in the sense of it’s not useful to me when I do a search and I find what seems like a bunch of pretty irrelevant stuff because 98% of what you see, you don’t care about is not relevant, you’re just, you just keep on scrolling and having this moment where you decide to actively people use the word curate, but Draw something that’s that’s a little too, almost a little too high minded. It’s really just to say, I’m gonna take this paper and read it and that and and make a few highlights and that in a way makes it mine. Not the paper, but the the reading of it or the highlights of it or my personal understanding of it. Now it’s my And it should be in my information set, in my personal knowledge base, whatever that is, having a better concept of that. And yeah, I think the the nature of kind of cloud and web applications and most mobile applications work this way too is you don’t really have a concept of that. I guess you have your account, but the reality is that what’s in your account is very Can shift very significantly depending on what the people the service decide, right? 00:34:58 - Speaker 2: And so even things that you’ve seen with your own eyes can be taken away from you. A related situation here is how enterprise software is often managed. So again, I think a fundamental psychological thing for creative work is a sense of safety and privacy. It’s a very vulnerable act to create something new, especially when it’s risky or uncertain. I hypothesize that it’s harder to do that. When you feel like someone may immediately own or have control or be able to see that work, I think you need a private personal space. And I’ve always found that a little hard to do in classic enterprise software. So for example, on Google Docs, if you have a Google Docs or for your company and you go to make a new document that’s only quote unquote visible by you, well, sort of, right? So anyone Google can see the document and really anyone at your company can see it. You know, the administrators who own the company really own the document. It’s kind of your It’s like it’s your name on it, but not really yours. And I think some people, that’s fine, they’re able to do their creative work like that. But I think other people, either explicitly or implicitly, have a really hard time putting their full heart into their work when they know that it’s not really theirs and who can see it when it isn’t really under their control. I like the classic academic model. I come back to this analogy a lot, where you’re a professor and you’re doing creative work, and you have a personal private office, and the stuff that you write there on pen and paper is yours by default, um, but it’s still a very social thing. So you can elect to go out into the hallway and scribble some stuff on the whiteboard with colleagues or invite someone to come into your office and look at a work in progress, or you might have a big department meeting. But all of those actions are explicitly bringing your work into the group or taking the group into your work. It’s not that by default anything that you do is on a big, um, you know, whiteboard visible by everyone. 00:36:31 - Speaker 1: I think collaboration models is a huge area for potential innovation. We dipped just a even half a toe. of that in the the research lab. I know you worked on uh on some projects that explored some of the decentralized collaboration models, not just the technology, but also, you know, what does it actually look like to potentially improve on the Google Docs model or the FIMA model which Which really hasn’t changed much since since sort of Google Docs first introduced it 15 years ago or whatever, but it’s a very, uh, there’s these very discreet jumps, which is, yeah, you’re either in the org, you’re in the company’s Google Docs account, or you’re in maybe your personal account. And then once you’re there, there’s maybe very specific work groups. I think we’ve seen the real world collaboration is much fuzzier than that. GitHub does OK with this, I think to some degree with outside collaborators on repos, but it’s rarely that just you have a document or a set of project files or repo or whatever it is. In something like Figma, Google Docs notion that just everyone in your company should have full read and write access to. And at the same time, you’re often collaborating with people outside the company, right? So there’s a project you’re working for these two people in the company, but then you’ve got this outside contractor who’s doing a few things, and you, you get these sort of shifting work groups, you know, the enterprise, guess it’s the enterprise model of control, but I think it’s also just Just a very simplified version of what work groups and collaboration looks like in practice. And that’s an area I’d love to see much more innovation on come out the technology world. 00:38:05 - Speaker 2: Actually speaking of other people in collaboration, this leads me to another idea on the information age. We said at the beginning that there’s this incredible abundance of information out there, almost like everything is online, and I feel like in some ways that’s true. So you can see all of the I don’t know weather data from the US online presumably, but I think it’s important to realize that in a lot of cases, the stuff that’s online isn’t like proportional. The stuff that’s true or correct, for a lot of reasons, you know, in some cases, people are just confused, but in other cases, there’s there’s even perverse incentives for the wrong stuff to persist. Um, and I think something that becomes important in this inconsistent information age is deliberately and actively reading and processing the information and making decisions about who you’re going to follow on Twitter to get the better or right information and things like that. 00:38:48 - Speaker 1: Certainly, that makes me think about a lot of the recent discussions around social media platforms as arbiters of truth and the element of Perhaps once upon a time, or in the not too distant past, newspapers and journalists and other kinds of news outlets were in a way arbiters of truth. You have journalistic ethics, which are all about trying to represent things fairly and focus on finding truth and that sort of thing. And now, yeah, of course, the internet is this wild west where anyone can share an idea and that’s great in some ways, but it does mean that just because an idea is loud, uh, or because it’s it’s repeated often doesn’t necessarily make it true. That doesn’t give it weight. That’s another thing. Certainly our society is trying to grapple with is how to reckon with what is, what is truth and certainly what is a what is a shared understanding of our reality so that we can all make collective decisions together. One group I’ve enjoyed following on that front is the Center for Humane Technology, and they’ve looked a lot at um they have some interesting manifesto type stuff on their website that I’ll link to in the podcast where they they talk a lot about this, the interaction of technology. These kind of individual choices we make about our information diet and that sort of thing and how we get the truth as individuals and as society and how we can hopefully change the technology but also our own individual habits to again get the best results for this both as an individual and a societal level. 00:40:11 - Speaker 2: You mentioned this idea of shared truth. I’m afraid it might be even trickier than we realize. I’m reminded of the so-called Gal man amnesia effect. This is when you’re reading a newspaper. Article in a subject of your personal expertise and you realize that the author doesn’t really know what they’re talking about. They’re making a lot of mistakes and so on. But at the same time, you turn the newspaper page, you read the article on some other topic that you’re not an expert on, and you say, oh, that’s you know the newspaper, they must know what they’re talking about, right? So let’s assume it’s true. 00:40:37 - Speaker 1: Yeah, I’ve I’ve I’ve had that experience multiple times. It is uncanny how you can immediately switch back to feeling like the news source of the journalistic sources and authority once it’s writing about something you’re not. Knowledgeable about, right? 00:40:50 - Speaker 2: And so I would go back and say, before the modern information age, when we just had broadcast media like print papers and cable, we didn’t really have a shared source of truth per se. We had a shared source of like statements that we just didn’t have a better shared source to, you know, come to some agreement around, which is a sort of shelling point of quasi-truth that that’s the best we got, but with the modern information age, and especially social media, all of the individual citizens have the ability to analyze the different media that’s coming out, perhaps in their area of expertise and see the source. Details and then go back on social media and say what they’re seeing, which might be that, you know, for example, I’m an expert on this topic and this newspaper doesn’t know what they’re talking about. And this brings me back to a book called The Revolt of the Public, another one published by Straight Press, and the whole thesis here is that this is causing a big societal upheaval, because there’s no shared source of truth, especially around, you know, the classic political topics and the uh call them information elites, people like the newspaper editors are being revealed in this world to have less. Accuracy and authority than they might have been perceived to have previously and that’s causing all sorts of downstream issues and complications. And the way that I would tie that back to me in this podcast perhaps is that leaves individual citizens with a lot of responsibility for processing the information streams themselves and making their own decisions and conclusions. That’s a big thing that we try to support in the app is you bring this all this disparate information into your sanctuary, your information sanctuary, and then you have to make sense of that yourself. 00:42:11 - Speaker 1: Well, that strikes a chord with me because one thing that I strive to do in my life is be a good citizen, be a good member of society, be a good member of my neighborhood and communities that I’m part of. And a lot of that is, I guess knowing stuff, and it’s not just being informed in the sense of, I don’t know, reading the newspaper or reading your community bullet. It’s knowing the stuff that matters and is relevant to the society you’re living in. And so that means both subscribing to those feeds, whatever form they might. They might come in, but then be able to pick out the parts that matter and then think through the parts that matter. Yeah, so one thing that I try to do with my information tools is to have a space where I can pull in things that are relevant so that I can be informed so that I can think it through, so that I can understand the issues at hand for me and for my neighborhood and my society and hopefully be able to be a good citizen and there’s too much. Any one person to pay attention to or know uh in this information age, information banquet, fire hose, overload thing that we all face, but I think our information tools, if we chose them well and we use them in the right way, can be a big help there. 00:43:23 - Speaker 2: Well, that seems like a good place to wrap it. If any of our listeners out there have feedback, feel free to reach out to us at museA HQ on Twitter or hello at useapp.com via email. We always love to hear your comments and ideas for future episodes, and in this case, we’d love to hear if you have a way for managing your personal information stream. 00:43:43 - Speaker 1: Yeah, I’d love to hear folks' techniques, the tools they use, approaches, tricks, hacks, and general principles for having a healthy information diet, particularly how that connects to your work as a creative professional, because we’re really only at the start of this information age and I think we can all help and support each other as we try to make our way into this brave new world.
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: Maybe the past generation of programmers were sort of subjected to a really awful version of visual programming, but it would be really sad to let that frustration that other people have felt ruin what visual programming could be in a much better design format or just done in very different ways, done in ways that combine graphics and text. 00:00:24 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for thought on iPad. But this podcast isn’t about Muse the product, it’s about Muse the company and the small team behind it. I’m Adam Wiggins, joined by my colleague Mark McGranaghan. Hey, Adam, and our guest Maggie Appleton from Egghead. Hello. Thanks for joining us, Maggie. Now, listeners of the podcast will know that Mark and I are fans of computing history. We think sometimes the technology industry is a little unaware of its own history, and I understand you recently visited a museum on that topic in your area. 00:00:58 - Speaker 1: I did. I got last weekend to go up to Cambridge, which is about an hour away from London, and visited the Computer History Museum of Cambridge, which was mostly a warehouse that some people had put an old N64 in and an old Mac and got to play a bit of Pong and Space Invaders, which is terribly educational, but probably not a comprehensive history of computing. 00:01:20 - Speaker 2: Now, depending on what generation you grew up with, you know, so now I’m old enough that I go to a computer history museum or sometimes there’s, I don’t know, like the pinball museum in Alameda there in San Francisco or some of these arcade ones, and I remember this stuff when it was new, maybe. Kid, so in that case, it can be as much a sense of nostalgia or a comparison with your sort of adults perspective on something that loomed large as a child. Were there things there you recognized, or was this all like essentially stuff that predated your time? 00:01:52 - Speaker 1: I was definitely of the N64 generation and definitely the, I don’t know which version of the Mac it was, but I have a very clear memory of going into a friend’s house who had the Mac. Windows 95 was maybe what we had had at home. I mean, I was grew up sort of in the naughties, so I’m that generation. 00:02:08 - Speaker 2: Is that what we’re calling it now? I’ve heard the knots. 00:02:10 - Speaker 1: I know. There’s no good word for it. 00:02:15 - Speaker 2: I mean the century, maybe we could go with. So, before we get into our topic, I’d love to hear a little bit about your background, Maggie, as well as a little bit about what you do at Egghead. 00:02:26 - Speaker 1: Sure, so, yeah, Egghead is where I currently work and it’s a web development education platform, so we kind of will joke it’s Netflix for developers, it’s mostly video tutorials, teaching anything, mostly on JavaScript, lots of React, Angular view, that sort of thing. And I’m the art director, designer, illustrator there. So essentially I handle most of anything that is visual design, and I also do quite a bit of UX design there. It’s sort of a small company, so you get to be a bit of an all-rounder. And because it’s a very developer focused company, I also develop, mostly working in React. I like to call myself a mediocre developer, so I’m not intense, you know, I don’t really like dig into, you know, the deep code, but I know my way around, you know, front end database. So yeah, that’s kind of me. 00:03:11 - Speaker 2: And it seems like you came maybe from the, I don’t know, illustration or design side, and then that led you to kind of the development side, or was it the other way around? 00:03:20 - Speaker 1: Yes, it was definitely design and illustration first. So I had grown up in a very technological household. My parents were both programmers. I had a lot of access to technology quite young. So I learned, you know, HTML and CSS, but I wasn’t really introduced to proper programming young and you know, there wasn’t any like IT education in school. So I went more into design and illustration in my early twenties and then learned programming, mostly out of employment necessity, you know, I was, I was designing websites and, you know, starting to learn JavaScript a bit and figuring out how to get a model to work. And then, of course, once I started working at Egghead, got a lot more into programming and development. So I very much come at it from, I struggle to learn it. I’m maybe not. I don’t want to get into natural types of people, but of course some people have an affinity for being able to do abstract reasoning and they’re very good programmers because they can hold a ton of cognitive context in their head about what component is connected to our database, you know, where messages are being passed, and I am not strong on a lot of those fronts, so I do development. As someone who needs things visually displayed in front of me, I need a lot of explicit feedback from the machine telling me what’s happening and what things are connected. So my perspective, I kind of bring to programming is, I’m the person that struggles with it. So I really, really want tools that actually help you program if you’re not naturally inclined to abstract reasoning. 00:04:43 - Speaker 2: I think it’s interesting that you saw basic programming through HTML and JavaScript as being almost sounds like a table stakes for your career, and I think that’s the nature of the computing medium. You can imagine doing visual illustration, design work in print, for example, and there you probably need to learn some things about printers, but for the most part you’re fine just doing everything in pixels on the screen. You hand that over and There you go, and that’s probably true in other realms as well, but once you’re on the computer, now you’re working in a dynamic medium, and your ability to express things is very limited if you’re stuck with what’s static. I think that’s going to become more and more true here in the future. 00:05:22 - Speaker 1: Yeah, I think it was good. I was ignorant of the fact at the time that I was in the generation where people were designing websites in Photoshop, and I didn’t know that was an option. So I went and learned CSS and JavaScript because I couldn’t figure out any other way to build a website. I didn’t know I could just mock up pixels and hand it to a developer. So I’m very glad I was ignorant of that. 00:05:41 - Speaker 2: So our topic today is visual programming and also to some degree, its relationship to the learnability of programming. And since you suggested this one, Maggie, maybe you can explain a little bit for the audience what the basics is. What is visual programming, why is it interesting area? 00:05:59 - Speaker 1: Sure. So visual programming is sort of a catch-all name for a whole bunch of approaches to trying to do programming differently. I want to say I think the name itself is problematic, which we can get into a bit, but it’s essentially trying to explore graphical interfaces for programming in various ways and then There’s been a long history of people trying to do this, and a fair amount of pushback to versions of it that have gone quite badly, which we can also get into. But yes, it’s essentially trying to explore ways of doing programming that is not just based in text, you know, linear text in a text editor, which is kind of the default nowadays. 00:06:36 - Speaker 2: Yeah, certainly when people think of programming, they think of it as being synonymous with coding. Think of that Hollywood hacker view where they’re sitting in front of the terminal, the text is probably green on black, and it’s a bunch of text in this computer language. Now, is there a well-known example of what would count as visual programming? 00:06:58 - Speaker 1: The two that jumped to my mind. I’d say most famous is probably MIT has a programming language called Scratch that is technically designed for children in order to teach kids programming sort of as a first programming language. And I think this gets referenced a lot in visual programming, um, circles because it gets rid of needing to use sort of arbitrary syntax symbols to define things like objects and functions. Instead, it uses drag and drop blocks with colors that correlate to the type of each element. So it’s a very interesting example of how you can kind of lower the bar to people coming in and doing programming since it is designed for children. So that’s one that gets famous, but others that I would count as being some form of visual programming that will be very familiar to the audience are tools like Zappia, if this then that, Integrama now, the sort of the whole low code, no code movement where people are essentially building node-based logic flows where they’re saying, you know, if this happens, then do this, else. Do that, they’re doing, you know, programmatic logic, but they’re doing it in a very graphical interface. And I count that as visual programming, but I think there’s also a wide diversity of, we can talk about, you know, the amount of power each of these platforms might have, the amount of flexibility and control they give to the user. But yeah, those would count, I would say, as visual programming. 00:08:21 - Speaker 2: One that comes from my childhood, thinking of kids learning programming is there’s a game called Rocky’s Boots. It was like a 1980s, ran on the Apple II or something, and it showed you how to put together logic gates, the same kind that you use in electrical engineering, to make circuits and solve problems. And that was one of the things that maybe introduced me to this sort of form of logic that eventually led to my interest in programming. But one thing I think is interesting about that is In fact, electrical engineers designing circuits work with a form of visual programming. You make a diagram that shows where the resistors and the capacitors and the LEDs and whatever else go in this form that is very much, I guess it’s less of a flow diagram and more shows where the electricity flows, which may or may not exactly represent sort of the abstract logic, but I think that’s a professional context where there’s kind of a visual programming, at least representation. 00:09:16 - Speaker 3: And we can also talk about examples of visual augmentation. So with Scratch, kind of the whole environment is inherently very visual. Other examples we could look at the spreadsheets where you have the cells themselves are like text formulas, more like a typical programming language, but it has this visual element of layout and spatial based variable naming. Another example from when I was learning programming is the I think it was called Doctor Scheme. I think it has a new name now, or maybe it changed to that from something else, I forget, but it was the scheme development environment, which first of all was all in one, which is great. She’s got this like one executable you could run and do everything, but also when you hit errors, which is the dreaded case of a new programmer, it just drew lines to everything you needed to look at, which sounds so basic, but just connecting the dots between this is your call site and this is your function definition, and there’s something wrong, you know, check where these two lines terminate and see what’s up. We could talk about all kinds of examples of visual augmentation as well. 00:10:09 - Speaker 1: Yeah, and I know you guys are also familiar with a few maybe more powerful visual languages like origami, and I think X code is quite visual in the way that it allows people to program. So yeah, there are fully fledged IDs that have visual elements to them and might not be fully fledged visual programming environments, but the hybrid is actually much more interesting than this idea of pure visual programming, but we can get there. 00:10:32 - Speaker 2: Our colleague Leonard uses origami for some design prototyping. We even put some screenshots in one of the beta memos we did. I’ll link that, but It’s interesting because he’s doing design work and typically he can do that in a tool like BigMA and pretty static mockups and then we go from there working with U interface engineers. They connect the static screens to behavior, but there are certain things, for example, when we were working on this whole infinite canvas flex boards feature where just how it felt. and how it behaved was the whole design and you just couldn’t evaluate that by looking at a static screen and furthermore, just the standard click prototypes like you get in a lot of modern design tools just won’t cut it. And so he ended up doing some fairly complex programs that you could then in turn run on the iPad and really feel how it worked. It’s quite impressive. 00:11:25 - Speaker 3: You know, it’s gonna be very tempting to market this episode with a D&D style alignment chart for visual programming tools. It’s like lawful good is, you know, scratch and what’s the other corner? Chaotic evil is a meme generator as a programming tool or something like that. We’ll see if we can pull it off. 00:11:43 - Speaker 1: Yeah, I’m thinking of other ones I’ve seen. I think there’s a category of them that I think was very popular in the 90s, like I’m specifically thinking of Lab View gets a lot of negative press, I’ll say, as maybe not being chaotic evil, but it’s one of the infamous ones that I think was proprietary, so you kind of got locked into the system. And then there’s a whole Tumblr. We can put it in the show notes when I find the link to it, but I can’t remember the name now. That is just screenshots of awful literal spaghetti code because it’s a node-based visual programming language. So it would just be thousands of boxes and lines running between all of them, and literal, just a visual spaghetti that you can’t tell down from up. But yeah, that would be somewhere in the evil dimension. 00:12:22 - Speaker 2: Yeah, the boxes connected by lines also reminds me of another big category that I’ve come across in my, I guess not my day job would be the way to put it, but music production is something that’s been of great interest to me, particularly earlier in my life. And so I worked a lot with software like Logic Audio, for example, sequencers or something like Reason, which is a kind of an all in one synthesizer plus sequencer, and these typically have various ways to essentially wire stuff together, but I I think one reason that the visual thing works well there is you have this clear kind of input output flow. The output is always going to be an audio stream or in some cases there’s video tools as well where there’s a video stream, but it’s a single sort of time-based flow and so like a music track or something like that. You just got 7 minutes of music output and you can in logic, for example, To the quote unquote environment and there you can just string together, OK, I want to take the source material. I don’t know someone playing a guitar and I’m going to put it through these filters and I want to fork it off this way and then the end output just goes out through you know your master volume and obviously that is very much designed for professional very serious use cases, but these are non-programmers. 00:13:33 - Speaker 1: Yeah, I’ve had the visual effects industry has a lot of those same sort of interfaces, so the node model box and there I was just connecting different things together and really just showing data transformation over time, which is when a flow diagram actually comes in useful. 00:13:47 - Speaker 2: And then another one I think could be remiss not to mention is iOS has an automation system built in called Shortcuts, which was originally a very cool indie app that Apple acquired called Workflow, and this essentially gives you sort of a scratch style model but probably Even simpler in the sense that you don’t have a lot of nesting and what have you, you just sort of assemble these blocks top to bottom. You can do it on a phone, which actually is pretty interesting. It’s possible to do reasonable programming on a phone, and again, I think it does rely on a fairly linear input and output. You’re going to apply your shortcut to this image. You’re going to do some stuff to it. Something comes out the other side, maybe it’s a transformed image, maybe it’s something else, but that’s a good example of a place where Visual programming maybe is actually the mainstream in a way that a lot of folks don’t even acknowledge. 00:14:38 - Speaker 1: Yeah, it kind of transitions us into the idea that visual programming ends up being this really large umbrella that I think a lot of the debates around to get into people just not having an agreed definition of what we’re really talking about. And so I mentioned that we would come back to it being that it’s kind of a terrible name because to call something visual programming suggests that it is something visible with human eyes, which would most certainly include text or a screen. So that would include all programming. So when people say visual programming, I think what it’s really getting at is, this is my sort of opinion on it, I suppose, is it’s trying to take things that would otherwise be implicit in programming, so parts of the program we don’t see, so right, data transforming over time or a variable being passed through a function. And making it visible in some way. And this is kind of where it gets into the balance that visual programming platforms or languages have to kind of grapple with is how much do you make visible and in what context, because you can’t make everything visible because the point of programming is abstraction and working with higher level primitives and sort of taking away things we don’t want to always deal with, right? Like where memory is allocated, you don’t want that visible in a higher level programming language. So I always see it as how we take programming and we make different aspects of it visible in different contexts depending on what we’re trying to do. 00:16:03 - Speaker 2: Is there a better name, or if you were in charge of the rebrand on this somehow, what would you go for? 00:16:10 - Speaker 1: I feel like graphical programming would at least more accurately describe what a lot of these platforms are trying to do. I mean, a lot of them are simply just trying to apply better UX and interaction design to programming, right? They’re just trying to make it a more enjoyable experience that gives the user or in this case, you know, the developer what they need at the right time without overloading them with information, you know, really just being a good cognitive tool. For them to get their work done. So yeah, but graphical programming, I think would more accurately describe node-based interfaces or drag and drop, you know, ones like scratch, or even debuggers really, I think are a form of visual programming in a way, ones that really walk you through how the program is executing over time, although I think it’s kind of wild that you wait till something goes wrong until those tools come into the picture. Like, why isn’t there an inline debugger in every IDE, but you know. 00:17:06 - Speaker 2: Actually one of the first, sort of one of my mentors when I was getting started with the professional programming, he strongly felt that you would go and put break points at every interesting point in the code the first time you ran it, and you wouldn’t run it and just see what happens. You’re gonna step through, inspect the variables. Watch every single point, and only once you’ve been through it all and watched it all execute from the inside, and everything’s what you expect, then you can look and see what lands on the screen, if that’s what you expected or not, but that’s kind of the final step. That’s more your victory lap, not your first test of whether what you did worked. 00:17:40 - Speaker 1: I think you mentioned that console logs, right, are one method of sort of putting out or making the program more visible at certain points in time. I was trying to think of a good metaphor for what console logs are, right? It’s like the stream of the program and it’s like you’re shooting up a small bit of information at a point in time. 00:17:57 - Speaker 3: Yeah, it’s sort of like if you have a map of a territory and you take a journey along the territory that we go on loops and you cross back over your own path and you make jumps and stuff, kind of captures all of that in a linearized form, and I see it as a compliment to the map, you know, the map gives you the nature of the ter not people gonna get mad at me on the internet for saying that, but you know, that the map has some correlation to the territory hopefully, but also the linear view of everything that you encountered is also very useful. 00:18:26 - Speaker 2: One idea I would raise for the rebrand question I asked earlier was on the Ink & Switch piece we did on end user computing, and we can talk about the relationship of visual programming to end user computing, but we talked about this property of embodiment and it’s exactly what you said, the idea of taking something implicit and potentially very abstract and making it visible. And I think a lot of times in discussions I’ve seen about this, which are often among people who are already professional software engineers, and that includes both people who are very enthusiastic about end user programming or just increasing the accessibility of programming, but they themselves are still. Professional programmers, I have that background mark does as well, and whether or not they’re pro or con, they’re coming from that perspective of someone who, for whatever reason found it was drawn to or was good at holding all of that abstraction in their minds. And so in some ways, I wonder when I see the objection of, I don’t know, there’s so much visual spaghetti here, but that spaghetti all exists in symbolic code as well. You just can’t see it, and you have to mentally model it, and some people are unbelievably good at that, and a lot of those people are people who go on to be really great programmers. I’m probably kind of in the middle on that, my complexity threshold is Not that great, and I tend to always want to like factor my code in a way to make it more comprehensible and give myself more visibility and that sort of thing. So I wonder how much the needs of visual programming or this umbrella we’re calling visual programming, those serve sort of hypothetical people that today are not programmers but maybe would have that capability. Which I think is the other dimension of this, which is the learnability side of it. 00:20:10 - Speaker 1: Yeah, I definitely agree with that, that I do like to be the representative for, yeah, mediocre programmers or people who aren’t naturally inclined to it. And that I have heard a lot of the debates around it of people saying, Well, I love them, don’t take them away from me. You know, if you try to make it visual, I won’t be able to work in my crazy text editor with all my customized hot keys and I’ll say like, textual programming’s not going anywhere, you know, it’s like, this is all gonna be. Additional affordances built on top of a textual paradigm, you know, text is not leaving. But people say they can’t understand why we would ever need it. Whereas my perspective coming into programming, you know, starting when I was 20 or so, when I was first shown VS code and the JavaScript tool chain that I was supposed to work in an NPM and the command line, I just went, you can’t possibly be serious. Like this can’t possibly be the way that I’m going to do this. Pranking you. Yeah, what? My computer looks like it’s just stepped back into the 80s. Like, I don’t understand. You know, I’ve grown up in the rich graphical user interface that gives me what I need visually and it was just shocking. So I do think that people who are programmers or professional programmers are maybe ones that, I don’t know if they want to say they’re more willing to step into that world of invisible connections and implicit logic. And then it is everyone that maybe would shy away from that or would find that more stressful or just less intuitive, they end up being like oh OK well programming’s not for me. 00:21:36 - Speaker 3: That really resonates with my experience, and I think there’s a few things going on here. One is this issue of accidental complexity, where you have aspects of the experience that are just not really essential to doing the actual programming work. Basically, the tools are designed poorly and unnecessarily so. There’s too many things going on, some of them don’t work, they’re unnecessarily confusing. I had a similar experience when I first wanted to do. Web app at a time, the state of the art was like these Java serflet things. This is like full on enterprise Java wildness. And when I encountered that, I was like, there’s no way I’m gonna do this. Sorry. And so I went back to, you know, my doctor scheme where everything is in a nice little bubble. Eventually you got Ruby on rails and everything was fine and so forth. But there’s this other issue of communication and information theory. So by that I mean, A lesson that I learned from management is whenever you’re communicating something, something is said, and then something else is received on the other end. It’s like a lossy process, and I think the reason a lot of programmers like text based interfaces is that they have very low loss there. They kind of understand what all those symbols mean, and furthermore, they’re very dense, whereas a new programmer, and I was once one of these, basically it all gets lost. It just looks like a garble of like alien symbols. So one of the reasons that visual programming environments could be so appealing is they have lower underlying information density, but they’re constructed in a way such the optical clarity is higher, right? More information gets through to the other side, and I think ultimately that suggests that there’s this end game of you get both the very high bandwidth potential of textile interfaces with the augmentation that you can get from other visual aids. I don’t know exactly what that looks like, right, but I think there’s something there. 00:23:12 - Speaker 1: I definitely, I think, discovered that when, as part of my work for Egghead, a lot of my work is illustrating programming concepts, right? So it’s very much just educational material. We’re talking like articles or animations that kind of go along with video lessons, where, you know, I’m visually explaining things like, you know, how graphQL works or how React’s hooks work. So it’s just taking concepts. And what I believe I’m doing is making visible the mental models. I tend to use the word me. Metaphors, because I’m from more of a cultural anthropology background, and I’ve read a lot of thinkers like George Lakoff and Mark Johnson, who talk about embodied metaphors and sort of the fact that almost everything that we talk about in the abstract realm is based in our embodied experience of the world. So we have this inherent understanding that like, up is good and is more and is happy, we’ll see the stock market went up and the stock market didn’t physically move upwards, right? It, like, had more money, move into it. But we use the term up to think more, good, better, right? And we’ll say like, you know, I’m feeling down today, means I’m feeling sad. You’re not physically moving downwards. But the point is that we have these metaphors that are based in being humans with bodies that have like fronts and backs and ups and downs, and we map all our abstract reasoning on top of that. And when you have to draw like a programming function. You really have to look at the language we use around programming functions and really figure out like, OK, there is a physical metaphor baked in here because all things are based off physical understanding, um, and then drawing it, you know, you draw, OK, there’s a component that’s a higher order component in terms of a lower order component it’s passing data, so it’s, you know, mimicking this idea of physical objects moving through space. So it was very obvious to me in trying to draw programming concepts that it’s based in physical knowledge. And visual programming languages or visual interfaces, just make that explicit, right? They like actually draw a box that is above another box or it is to the right of another box, which suggests it’s in the future because we think the future is to the right and the past is to the left, at least in English, Western speaking countries. That’s how we map time. So I’ve always just been kind of fascinated by how We can sort of use these embodied metaphors to help people understand programming concepts because everyone has a body, so you get these things for free. Like we all get the concept of front and back, and we can use those in interfaces to communicate to people, you know, the relationship of these otherwise very abstract lines of code that are just encoded things on a hard drive that would otherwise be incomprehensible. 00:25:41 - Speaker 2: That’s super interesting and also it actually connects to our design ethos for Muse. A lot of our concept there is we want to tap more into, for example, your spatial reasoning, which is very strong for most humans, as well as things like the direct manipulation and touch and so on, basically taking advantage more of our bodies and our minds, natural, you might call them talents or just built in capabilities because of course so much of what we do with computers we are really Bringing ourselves into an abstract intellectual realm, and we can learn to do it, but it is very much a learned and a learned over a long period of time skill. 00:26:20 - Speaker 3: Yeah, and I think this idea of understanding, whether that’s through metaphors or physical embodiment or mental models is really important because ultimately most programming errors or failures are ones of understanding and not ones of like mistyping, and I think a lot of our tools, they focus on The mistyping issues, and it’s much harder, yet more important to get the ones of understanding. Like if you think about the most gnarly bugs you’ve dealt with, it’s usually because you misunderstood something about the world you’re modeling or how your program worked, not because you type out something. If you did something that kind of gets fixed quickly. So anything that can help us understand what actually is, is very powerful, which, by the way, is another reason why I’m a huge fan of logs because they are a sort of ground truth with very high information density of what actually happened in your program. 00:27:07 - Speaker 1: Yeah, I’ve actually recently been working on a project that really sort of emphasized to me how important this is, right, of the mismatch between the program creator’s mental model and the person trying to write the programming language. So, of course, I’ve mentioned JavaScript because that’s just kind of the world I work in. So this is a collaboration project that I worked on with a programmer named Dan Abramoff, who’s a really wonderful kind of well-known JavaScript developer who’s on the React core team. And so we’ve been collaborating to help create a course that visually, diagrams and a. Mas the underlying mental models of JavaScript, the way that it actually executes, which helps people get over a lot of the bugs that are written into JavaScript code simply because they don’t understand what happens when you say, let banana equals fruit or whatever. And then you reference that later, but if it’s been reassigned or it’s inside an object and it’s been passed through a function, they aren’t tracking in their head exactly where the variables gone and how it’s changed over time because it’s not visible in the program. So anyway, this project is all about showing people literal, explicit diagrams, showing them what happens when certain types of code executes in JavaScript and it corrects a lot of the mental models that are incorrectly taught in a lot of JavaScript textbooks. And this is where working with Dan and being able to help visualize this course, I completely reformed my understanding of how JavaScript code executes. But there’s no IDE that was going to show me that. So it was just one where I went, it’s great to make educational materials for this stuff, but it’s not built into the tool. Exactly. 00:28:35 - Speaker 3: It reminds me one of the earlier programming courses I took was in C and it was kind of notorious because there was this one point in the course where a lot of people hit a wall, which was when you introduce pointers. You know, it’s this incredibly important and fundamental thing that totally changes how the variable behaves, but just a little star, you know, in front of the variable name or whatever. And it kind of resonates with what you were saying about the mismatch between how people are thinking about what’s happening versus what is actually happening, the importance of correcting that. 00:29:04 - Speaker 2: How do you go about coming up with a metaphor when you’re working on something like the just JavaScript course or any of these egghead pieces? Presumably you need to develop your own understanding of it either from your own experience or from the course materials, but then you want to go to translate that to some kind of visual thinking or create a metaphor, hopefully when that’s correct and useful. How do you do that? Can you give us an example? 00:29:29 - Speaker 1: Sure. I’ll say there’s sort of a spectrum. I mean, I like spectrums anyway. There’s a spectrum of visual programming, and there’s a spectrum of metaphors, I’ll say. So the just JavaScript project with Dan probably leaned a lot more on very direct spatial metaphors. It was very much like what is connected to what, what is above what. So it’s sort of circles and our. in a very classic diagrammatic way. But a lot of the other work I’ve done for Egghead is illustrating programming concepts and what I would say is on more towards the poetic spectrum of metaphor, where it’s not technically, like, you know, the most accurate, it doesn’t exactly match to syntax showing what happens at each point. But I’ll make a lot of illustrations that will be metaphors that give you an understanding of like, oh, OK, if it’s a waterfall image, it’s like, OK, this is something about data flow, that sort of level of poetic metaphor that gives you more of the gist of an idea more than the literal syntax interpretation. I’m thinking of one of like, I did one for Redux, which is a state management system for React. And I use like a little joystick with space aliens, like shooting, cause it has actions, so it’s like you can like shoot out actions from redux from like a single state source. So that’s one way, it’s a bit more fun. Obviously, it’s a lot more visually interesting than just doing a box and arrow diagram, but it gets the concept across to people that you have a central place and it’s shooting actions out from it. And the the process I kind of do for that is whenever I’m given something to design a metaphor for, I will read docs, you know, I’ll read programming articles, I’ll go see what people are talking about on Twitter related to the thing, stack overflow questions, and sometimes if the community is already speaking about it in certain metaphors, I just use that because they clearly already understand it. If they’re trying to explain it to each other on Stack Overflow and they’re using these metaphors, that’s usually what I’ll base them on. But a lot of the time, I’m just kind of doing basic reasoning of going, OK, what are the functions of this thing, what are its qualities, and then you do a bit more creative lateral thinking to say, OK, what else in the world has those functions and those qualities. 00:31:26 - Speaker 2: Yeah, I think that that points to another reason to have this kind of illustration in learning materials, which is just to make it fun and break things up, and yeah, visuals to break up, for example, long streams of text, or, you know, if it’s more of a video format, long strings of speaking, or you’re just looking at a screen, that kind of looks the same the whole time, you know, it’s just a code editor window or something. I’m reminded a bit of Wi Poignant Guide to Ruby, which was a beloved introduction to programming for the Ruby language and had these adorable cartoon characters and kind of a web comic style, and, you know, a lot of it was not specifically helpful for helping you learn it. It just made the thing just more fun to consume and more memorable because you connect chunky bacon with, you know, some of these more practical concepts that are being taught to you. 00:32:17 - Speaker 3: Chunky bacon, that’s a throwback, man, wow. 00:32:21 - Speaker 2: Now, I can’t believe we got this far without mentioning Brett Victor’s seminal piece, Learnable programming, and maybe somewhat to the point you’ve both made in various ways, which is, it doesn’t have to be either or. The idea of creating embodiment or visualization or showing more of what’s happening, the abstract pieces, how things are connected, how things flow in time can also go. With symbolic code and this piece from some years back now, but I think has been influential in terms of, well, people lamenting we don’t have programming environments that are a bit more like this, but demonstrates lots of interesting and inspiring ways to potentially make, for example, control flow more visible. 00:33:04 - Speaker 1: Yeah, the Brett Victor piece has kind of been a seminal launching point for this whole visual programming industry. Of course, it was alive and thriving well before. I mean, you can kind of trace it back to, of course, Alan Kay and Xerox Park and Small Talk, and there’s a lot of precedents for this, but the learnable programming piece, I think, is the one I’ve seen referenced the most and has gotten the most people, you know, maybe in the last 5 to 10 years, more interested in it and to get them to go exploring and to go, OK, maybe the way we program now doesn’t have to be the way we’re always going to program. And the thing I really loved about Victor’s piece, I mean, of course, it’s a long article and there’s many aspects to it that we could kind of dive into. But this idea of just that because code when it comes down to it, it’s something being executed in full on machine code and bytecode, and with so many layers of abstraction up from there, it’s not like we only have to represent it in one way. When you get into the higher level programming languages, syntax is one way of displaying what that machine code is actually running. And right in the rendered UI is another way of displaying what that machine code is running. And I don’t know why there’s not a reason why we can’t flexibly display the same set of machine code in different ways and turn it on and off and, you know, say, OK, I want to look at it in visual data flow, set. Or I want to look at it in a way that shows me the component architecture, if it’s like a component tree kind of context. So just flexibly displaying it in different visual formats, rather than saying, OK, syntax is the only way I’m ever going to interact with this code until it becomes the final output. 00:34:39 - Speaker 3: Yeah, interesting. And now that you mentioned that, I feel like, as is often the case, the gamers are ahead of us, particularly the game designers, like I’m not an expert in this, but my understanding is that the game engine environments, like they’re very sophisticated. There’s like the code view, then there’s like the object graph view and you can like, you know, turn on different pieces of the visual environment and there’s all kinds of performance based views for looking at memory and CPU and GPU usage and so on. So there’s perhaps something to learn from that industry. 00:35:07 - Speaker 1: I also think the data visualization industry is one we could really draw a lot from, like I know Brett Victor had mentioned he had researched a lot in Edward Tufty’s work, who’s a information designer I suppose is the best term for him, but he’s written a number of books like visual explanations and beautiful Evidence that cover. Kind of the best practices for how you can represent data as visual charts in a way that it actually respects the original data and presents it in an accurate way that isn’t bending it or being too manipulative about the way that you’re presenting it. But he has, yeah, a wonderful set of sort of principles for how to do it well. And Victor had talked about how he read him before writing learnable programming. But the data this community in general has done a ton of work on thinking of different ways to visualize numbers, and they are fairly well known for it. Do you guys know on dashboards you can sort of turn on line chart or you can turn on bar chart, you can sort of jump through different modes of being able to look at the same numbers and that’s sort of in my head, what. We might be able to do with syntax in sort of maybe IDE plug-ins in the future. Of course, there’s plenty of IDE plugins that do help you look at your code in different ways. But more of that is kind of what I would love to see is like more plugins that just are like, I’m just gonna show you the architecture side of your code. I’m just gonna show you how this variable changes over time in your code. I’m like one of those where you’re kind of like, am I missing something? Like, why isn’t this happening? 00:36:32 - Speaker 3: Yeah, I totally love to see more of it, and I think it can come both from the IDE language plug-in layer, but also bottoms up from individual projects. I feel like I must have at some point done one of these things where you write a little script that like takes your code or your system and compiles a dot graph so you can visualize nodes and edges with one of these standard dot visualization tools. And I feel like there’s a lot of opportunity to do that in individual projects like you feel the need to have a different, more graphical view into your project. Well, you’re a programmer, you can make it so. 00:37:01 - Speaker 1: And it kind of to bring us back to what end user programming. I mean the the strange thing about programmers, right, is they are end user programming, like of all the industries, they’re the only ones where they are both the users who have the ability to actually build their own tools and to actually get in and change their own applications and no other, I guess, community that uses computational tools is able to do that. 00:37:22 - Speaker 2: Here you’re talking about a programmer writing their own VS code plugin, something like that. 00:37:26 - Speaker 1: Yeah, exactly. Or even if you use a certain language or a framework, you can build a library that adds on to that, right? Even if you’re not on the core team and you aren’t going to PR into the main repo of that framework or tool, you can build extensions off it, you know, it’s the beauty of being able to fork and change and collaborate on these things means that there’s so much flexibility in in developers having their own authorship power. 00:37:49 - Speaker 3: Maybe we need more culture of jig making and software as there is in woodworking. Woodworking is interesting, it’s one of the rare fields where maybe the only one I can think of where they have that ability to kind of build their own tools in wood, and there there’s this whole culture of making jigs to help you build the furniture. In fact, you might spend most of your time making the jigs and the furniture is kind of this final, you know, culminating step. Perhaps we need more of that in the software world. 00:38:12 - Speaker 2: Some of the ways to visualize your code or your program differently that you both have mentioned like in the game world maybe something like Unity where you tend to build stuff into the game that lets you look at the scene graph in different ways and I think we have that a little bit in the web world. Dev Tools is one that we tend to give a lot of love to. I think we talked about that a good bit with Jeffrey recently here on the podcast, but there it is an example of what you said. You see the output. But there’s also the kind of hover over elements and highlight which is where and what the extents are, and then there’s also the margins and padding stuff that kind of goes down in the lower right corner, but then you’ve also got an expanding hierarchical graph and you can see those all at the same time and even as you’re musing over its highlighting, you’re looking at exactly the same thing in three different ways, and you can spot different problems or understand by visualizing it in these different ways. And I would further argue that we see that a little bit in more the native development world with toolkits like Flutter and SwiftUI where there often is even a live side by side. Here’s your interface output, here’s the code, and often you can change things on both sides and it flows. Bidirectionally, but I think in all of those cases it’s already something where it’s a visual output and so you’re interacting with some of the under the hood stuff around that visual output. It feels very natural to visualize that. When you come back to the more abstract things like program flow over time, that’s where maybe it’s less obvious to do that, or maybe it’s just less clear how you would do it in the first place. But yeah, I think that visual debugging or visual understanding of something that is already a visual output to begin with, is actually a pretty rich place for the stuff. 00:39:55 - Speaker 1: And especially, I mean, you’d mentioned the two way or bidirectional aspect of it is super important. I mean, one thing I’m really liking is there’s kind of a new rise in state charts and state machines, but visual ones that are flow both ways. I’m specifically thinking of there’s a tool called X state that works for React where you can change either the diagram or the code and they’re side by side and they mirror each other. Whereas if I want to debug some CSS thing in the browser, it’s like, I’ll go test it out in the browser. But then I still need to go back to my ID and like actually change the actual code. And it’s just that like slight friction of you’re not actually changing the thing itself. You’re like mocking it up in one, and then you go back to the actual source. We’ll know and, you know, interaction design, any amount of friction you put into a tool or an interface is just causing that much more cognitive load on the user. 00:40:42 - Speaker 2: I’m looking at Xtate right now. I hadn’t seen this before. It is very cool, like, uh, code and flow chart diagram side by side. We’ve done a bit of research on the bidirectional editing capability as part of Incanwitch, and it can be very, very hard to do that well if you have something like maybe a tool like Apparatus would be a good example. I can link that in the show notes, but something where you have the ability to do direct manipulation with dragging something with the mouse or your finger in one kind of pain, and the other you have code that you can update. But having not one be the end state, the output, I don’t know the bad version of this is Dreamweaver, right? What the output it writes is just completely incomprehensible and you can’t kind of go back from there. So that bi-directional thing I think is sort of a holy grail in one way, but also it’s very hard to do technically, and I think it also depends a lot on the nature of the programming language itself and the tools you use to edit kind of the symbolic representation. 00:41:40 - Speaker 1: Yeah, I usually take the long stream of, maybe, I don’t want to say failures, but disappointments in the wuzzy wig world. You know, everyone that’s ever dreamed of, yeah, dream era, you draw the website and you can change the size of the div and the code, you know, reacts appropriately. The fact that no one solved it after this long and that many, probably billions of dollars, I’m not quite sure. It shows that it must be an incredibly hard problem, you know. 00:42:05 - Speaker 2: Yeah, indeed, and I know in the X code world where it ships with this interface builder, which is essentially a drag and drop GUI system for setting up your interface, but very often I’ve seen iOS developers, they prefer to say just don’t use InterfaceBuilder, write everything in code because Or or later you’re going to be basically working in code anyways and if you have some of your program is represented in this visual thing that’s edited one way, some of your program is represented in code, the two interact with each other in a bunch of complex ways, you’d rather have just the one medium that’s actually better long term. Now another great article that I came across by total coincidence, just as you and I, Maggie were talking about, possibly doing a podcast on this topic, is an article that is called Hackeroo’s Folk Wisdom on Visual Programming. And it essentially is a pretty large scale analysis of every single time something visual programming related has come up on Hacker News and sort of like distilling out the common themes and then starts with the really common and fairly shallow reactions and then goes into some much more nuanced and interesting discussion. So there’s lots of here including some we’ve already talked about, but is there any pieces of this article that are especially interesting to you, Maggie? 00:43:20 - Speaker 1: It’s funny, I had been following a lot of those same threads, and there’s a fair number of them, and they’re the sort of hack and news topics that go for hundreds of comments, right? People who just go deep on this stuff. I had been reading a lot of those same ones and passing through them right when that article was published, and I tweeted the author, I said, you know, thank you so much for doing the hard work of distilling that all for us. But I think the thing I found most interesting about it, and just from reading the threads is, I mean, the strong opinions people have on it, or you really get into people have very Emotional, I want to say, like reactions to visual programming and sort of the cultural anthropologist side of me just finds that quite an intriguing thing to look at, where many of them, I want to say, have almost been like emotionally scarred by past visual programming languages, like the stories they’re telling in the comments of the time they had to work on the most horrendous proprietary visual programming platform, and no one could find anything and the literal spaghetti code is just all over the Place and they just wanted to go back to text. So I think there’s some very legitimate critiques that should be acknowledged that maybe the past generation of programmers were sort of subjected to a really awful version of visual programming, but it would be really sad to let that frustration that other people have felt ruin what visual programming could be in a much better design format or just done in very different ways, done in ways that combine graphics and text. Yeah, so that was my main takeaway from it. It’s almost like you have to do some historical healing before you can kind of move forward with this concept. 00:44:47 - Speaker 2: It is interesting that it can be such an emotional topic because I think if we were to boil it down to a bit of a duality, you have both people like I think those of us here talking right now who really believe in some kind of end user programming future or programming being more accessible or just computing as a medium is so. Important for humanity’s future, and we need just more humans and a broader array of types of humans, different perspectives and different backgrounds to be able to access this medium. And so that’s maybe something we feel strongly about. Certainly I feel very passionately about. On the flip side is maybe as you said, first of all, the bad experiences that have scarred people, but also you do come back to this again, the hacker news comments are people who many and most are probably professional software engineers. There are people for whom the pure text model and classic text editors and IDEs and so on serve well, or maybe it’s less about being served well and more than they’ve had to go through the pain and suffering to get over that hump, to learn all those abstractions and manage a whole. All that stuff in their head, and then in a way, maybe they would feel robbed if someone else can just kind of skip over that. I actually had that feeling. I learned a little bit of electrical engineering many, many years ago doing Burning Man art projects. So I wanted to make stuff that lit up in cool patterns with LEDs and so on. And I had to go through the whole kind of classic electrical engineering process, and I found it very challenging. It didn’t really fit with how my brain worked. I thought it would be relatively easy because I’m a computer programmer, but circuits are a whole other thing. And just a few years later we had the raspberry Pi and the Arduino, an increasing number of these kits and Ada fruit and all these much more accessible things. I remember talking to a friend who said, Oh, you know, I’m going to set up my project that will have, you know, these LEDs or whatever. It’ll color cycle like this, and I’m like everything you’re describing there, that’s going to be a lot of work. I hope you’ve really budgeted some time. And he bought these kits. You know, I ate a fruit, and a week later he had this amazing thing working and I went in and asked him about it and I realized that he just didn’t need to learn all this stuff about debouncing with capacitors or whatever that I had to fight through because there are these just more accessible platforms. And there’s a knee jerk, I think I had that then, a knee jerk kind of like, wait, I had to walk uphill both ways in the snow to learn to do this. Other people should have to too, or I wasted my time or something like that. But of course, I think it’s much better that there are much more people that can now do things like make cool light up projects because these technologies are more accessible. I feel like there’s probably a version of that for today’s programmers versus people that might access it in the future if it was a little bit more learnable. 00:47:32 - Speaker 1: Definitely, there’s also another I suppose trend in people that are a bit anti-visual programming or I’ll say resistant to it or have some, you know, skepticism and reservation around it. Is this, I have found this sort of a duality where people lump themselves into going, OK, I’m a math logic person and art people are on the other side of campus, and I am not an art person, and everything visual is art. And this idea that they’re not visual thinkers, I hear that all the time from people who are in programming, and I can’t really fathom what that means in a lot of cases because I go, Well, visuals are about embodied when you have a body, and I think, you know, you could probably draw a box and an arrow and communicate some visual stuff if you And trying to draw some detailed drawing. But yeah, I think the, the, I’ll say yeah historical divide of art from science and visual from logic and this idea that math happens in textual syntax is a bit of a hangover that people just think, well, visuals don’t belong in math and programming. But I mean this is why I think cultural anthropology, one of the sort of points of it is to sort of show people the vast diversity of expressions that human. Life and culture can take and that everything we have was invented at one point in history, and we are one very specific narrow manifestation of possible human culture, and there are many others, and we could switch to them or move towards them and we don’t have to live in some world where math and art live on alternate sides of the dichotomy. 00:48:54 - Speaker 2: That’s a really powerful point, Maggie. I feel like we should wrap it up there, but for people who are wondering about examples, they want to see what this looks like because indeed it is a visual topic beyond the ones we’ve already mentioned. Are there some good resources you can name that allow someone to flip through and see the variety of different experiments folks have tried for visual programming? 00:49:15 - Speaker 1: Definitely, there’s some people who have done a lot of wonderful labor compiling screenshots of I think every possible visual programming language or platform that’s ever existed. And what I want to point to that we’ll put in the show notes is a visual programming codex that Ivan Rees put together. Which is a GitHub repo with just a wonderful array of examples. And there’s another one called Whole Code Catalog. So a nice play on the Whole Earth Catalog that has, again, a nice sort of categorized collection of different programming platforms and alternatives and the sort of the different qualities each of them has all nicely organized in a beautiful website. 00:49:52 - Speaker 2: Well, thanks everyone for listening. If you have feedback, you can write us on Twitter at museAppHQ or on email, hello at museapp.com. You can help us out by leaving a review on Apple Podcasts, and Maggie, I’m really glad you’re advocating for making programming more visual, more embodied, more learnable, and I’m especially inspired by the idea of having a less bifurcated world between the art thinkers and the math thinkers. I think we need that. That’s a beautiful vision for me. 00:50:21 - Speaker 1: Thank you so much for having me on. I really appreciated getting to come on the show, and I’ve mentioned to you I I adore the podcast, I think I’ve listened to every episode up until now, so it was really wonderful to get to finally come be a guest.
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: Rather than giving someone this hermetically sealed box, can we use an analogy like build a beautiful Lego set for them and hand it to them, where if they like it just as it is, that’s fine. And if they want to add one Lego right there, it’s not a big deal. They sort of see the composition of how this thing was made, they have a little bit of flexibility to tweak it because it’s made out of parts they understand. 00:00:24 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for thought on iPad. This podcast isn’t about Muse product, it’s about Muse the company and the small team behind it. I’m Adam Wiggins here with my colleague Mark McGranaghan. Hey, Adam. I’m joined by Jeffrey Litt. 00:00:40 - Speaker 1: Hello, hello. It’s good to be here. 00:00:41 - Speaker 2: So Jeffrey, one thing I’m thinking about these days in raising my young child is growing up in a multilingual household, since both of her parents are from two different countries and we’re living in a third country. I know you grew up in a multilingual household as an adult, what are your reflections on that experience? 00:00:59 - Speaker 1: Yeah, so my mom’s Japanese and I grew up sort of half my childhood in the US, half in Japan, and when I was a kid, my mom sort of forced me and my brother to learn Japanese when we were in the US and I was just thinking about how I’m so grateful now that she sort of overrode our preferences as children, and that now I have some proficiency in the language and so raising kids is complicated. 00:01:20 - Speaker 2: There is going to be, I can see this already at this young age, and I think if it gets only more so as children get more agency naturally with age, which is parents do know better. They’re just older and wiser and know how the world works and At the same time, a kid needs to find their own way, and authoritarian upbringing doesn’t sound particularly like a good way to blossom as a person. So finding that balance between what’s prescribed by parents, you’ll thank me when you’re older. In this case, literally so versus let a kid find their own path. I think that’s an ongoing philosophical moral dilemma. 00:01:57 - Speaker 1: Yeah, especially for something as difficult as learning a language. You know, I do think with whether it’s sports or music or these skills that take a lot of time to master, I’ve also been grateful that my parents helped me learn to love Japanese and build some of that motivation, whether that’s from visits to Japan to hang out there as a kid. I tend to believe that the goal of education at a young age isn’t primarily to transfer the skill. It’s to, as they say, light that fire that eventually keeps learning going, and to this day. I’m practicing my Japanese trying to keep it up, and so I think that’s an important balance this track too. 00:02:31 - Speaker 2: What’s that saying? If you want to set sail on a boat you’re building, you don’t teach someone to build a boat, you teach them to yearn for the ocean. 00:02:40 - Speaker 1: Yeah, exactly, I think there’s a lot of that at play. 00:02:43 - Speaker 2: So Jeffrey, I’ve been wanting to get you on the podcast for a while here. We got the chance to work together on the Cambria project at Ik and Switch last year, but I’d love to hear just a little bit about your background, how you came to be doing this work in the tools for Though and independent research space. 00:02:59 - Speaker 1: Yeah, so I’m currently doing a PhD at MIT in computer science. I’m in a lab called the Software Design Group, led by my advisor Daniel Jackson. And at the highest level, the questions I’m trying to explore are how do we empower more people to kind of take full advantage of the medium of computing? I think it’s very ironic that we’ve invented this infinitely flexible thing called software, and most of the way that we use it ends up being a small group of people, make some stuff and throw it over a wall, and everyone else uses it. And I’m just interested in new approaches to building software that changed that dynamic. But before coming into this academic side of things, a lot of my thinking on this area actually came from working in startups and shipping real software to people. If you had asked me 5 years ago, are you gonna be doing a PhD, I would have laughed at you and said, you know, no, I’m not that kind of academically minded person. But over my time in startups, I got really interested in these topics and I decided that Rather than go try to start a company or something, the academic environment offers a certain amount of freedom from the need to ship real software immediately, the need to make money immediately, that I thought would be really valuable for kind of thinking more deeply about what the problem actually is here, and maybe bigger picture ways to reorient the way that we build software. 00:04:19 - Speaker 2: Yeah, that makes sense. You have both industry background, as they might say, ship stuff fast, solve real customer problems, and kind of academic mindset, longer time horizons, more of a search for basic truths, trying to think bigger and more expansively and more philosophically, and that’s actually, I think, a place. That I and Switch kind of excels or part of its reason for existence is to kind of be in that middle space between those two worlds which I think is not well occupied and certainly for creative tools generally I feel like that at least right now is the space where we need the most minds and the most effort. 00:04:56 - Speaker 1: Yeah, that’s part of why I have really enjoyed following and can switch his work over the years and have gotten to collaborate a bit with the lab, and I think it fills this really important middle place between those two worlds. Too often I think startups are kind of not reflecting on the larger possibilities of what they could be doing if they had more than, you know, 3 months ahead to think about. And on the other side, you have academics who, I think sometimes It’s not really clear to me how idea transfer really happens from academic human computer interaction research to the real world sometimes. I don’t think it’s a smooth process where, you know, startups are devouring papers that are being written and trying to implement them in the real world. I think it’s a much messier process. If you look at even someone like Doug Engelbart, who I think is a hero for a lot of people in this community, it was really hard for him to get his ideas out into the world, ultimately succeeded, but through a pretty circuitous path. So I think it’s really valuable to have institutions that are thinking about both of those worlds simultaneously, with the ultimate goal of actually deploying in some form, their ideas, as opposed to just sort of just handling the ideas half of things. 00:06:07 - Speaker 2: Yeah, well, that’s why I think I really enjoy following your work so much, is that you do fit in that middle space and hopefully can be a role model for the rest of us on that. 00:06:17 - Speaker 1: Yeah, I’m trying to, it’s tricky. There are a lot of tensions to navigate as I’m sure that you guys have experienced. 00:06:23 - Speaker 2: And I also thank you for being one of the very early users of Muse during the beta as well as a customer. I hope you’ll consider renewing your subscription when that comes up again. You’ve both tweeted lots of screenshots about how you use it, which is, I think, really great for other people seeing how you use things and the every publication even wrote an article. of detailing your work and you talked about a lot of different tools in your flow, include some screenshots of use there so very much appreciate your business, but probably even more than that, the kind of very public moral support makes a big difference, especially in the early days of a product when you know you don’t have so many believers just yet. 00:07:00 - Speaker 1: Yeah, thanks for building such a great tool. I mean, I bought the big iPad Pro originally when I was starting to dip my toes into the academic waters and being confronted with a lot of 8.5 by 11 PDFs and decided I wanted a nicer way to read them, but something felt like it was missing there in terms of synthesizing across them. And when Muse appeared, I was like, this is it. This is maybe the early versions weren’t the perfect product yet, but I could tell the vision was exactly what I needed, and so it’s been a blast using it. 00:07:29 - Speaker 2: So our topic today is bring your own client, which is something you’ve written about, and of course I’ll link that article in our show notes here, but maybe you can tee up for the listeners a little bit what that’s all about. 00:07:42 - Speaker 1: Yeah, absolutely. So bring your own client means having the flexibility to pick what application you want to use when you’re working with some data, and for there to be some independence, especially I think between people who are collaborating on the same project, to pick the software that they want to bring to the table. So I think like to give a concrete example, right, back in the old days when we used to email each other files to work on a document, let’s say I could email you a Word doc. And then you might open that Word doc in Apple Pages or OpenOffice, whatever your preferred word processor is, and then you would send that doc back to me, and I don’t care what application you used on your end, as long as I get a file back, we can work together, right? And in fact, if we’re emailing files, I also don’t care what email client you’re using. There’s sort of this inherent point of flexibility built in where we get to make these individual choices about how we want to work. And broadly, the topic I’ve been thinking a lot about these days is how I think that we are starting to lose some of that flexibility with the way that computing is headed. So I’m very interested in this overall ethos of bringing our own clients and perhaps even building or customizing our own clients, um, to gain a little more control over our experience with software. 00:08:56 - Speaker 2: I think email is one of the best examples perhaps because it’s this really one of the oldest standards in some ways, sort of the first internet protocol in some ways, and the plethora of different clients that have existed over time. I don’t know, I used Pine and later mutt, this kind of terminal-based clients. At university in the 1990s and going forward to Gmail was this big revelation in terms of lots of great interface innovations as well as backend innovations, but it could just work right away. You didn’t need the person on the other end to be also a Gmail user, they could be with any email client. 00:09:36 - Speaker 1: Yeah, and I think email is one of those domains that really demonstrates how valuable it can be to have this flexibility. You know, I think sometimes it can be tempting to say, does this really matter? What’s the big deal? Can’t we just all agree on the same software to use? But if you look at something like email, I know a lot of people, some of them not that technical, who have really strong opinions about what email client they want to use because they’ve just found one that works well for them. I’ve had many moments of my favorite email clients sort of going out of business or being acquired and hopping from one to the next and searching for that elusive best client. And I think for anyone who’s sort of an email for like 8 hours a day at their job. You start to see why having this degree of flexibility genuinely matters for people, and it’s not just like a little convenience, it’s actually a big deal. 00:10:23 - Speaker 2: Right, and so you see this not only in the big example of Gmail that really revolutionized a lot of things about how email works, but even nowadays we have a plethora of new clients, superhuman, tempo is another cool up and coming one, or for example on the Muse team for our inbound support where you can just basically email hello at museapp.com that goes into a product called Front and so this is kind of a group inbox email thing that has quite different characteristics from what an individual might want. But it’s nice because the person on the other end, they don’t care what we’re using, they can just send us an email, maybe they include attachments, maybe they include whatever we reply back within that, so that gives each party in this back and forth can use what suits them and what’s gonna suit a team that’s going through a bunch of support requests is just dramatically different from what might suit an individual doing their own personal inbox. 00:11:13 - Speaker 1: Yeah, I actually personally use Tempo, and I think it’s a great example of a niche product. It’s really perfect for what I’m looking for. They have a really minimalist design. They have this concept of batching your emails so you don’t get distracted. And for me, as someone who’s at least trying to not check my email 100 times a day, it’s sort of aligned with what I want. I don’t think it’s necessarily the perfect product for everyone or even the majority of people, but I think it’s right for me, and it’s just great that because we have this shared protocol, I can make that choice to adopt this niche product that maybe only 1% of email users will ever use. Without convincing all this other 99% to join me in using this thing, we sort of take this for granted with email, but look at Slack. There’s not really a concept of a third party Slack client, right? And I think it’s easy to forget how monolithic that experience is. Every team that uses Slack is stuck with the exact same user interface with no ability for individuals or even teams to really meaningfully customize it. And I think that’s a tremendous design challenge to try to make something that works well for so many different people and so many different workforces. 00:12:21 - Speaker 2: Maybe there you illustrate the trade off though Slack because it is an integrated product where they control every part of it, the client, the API, the data storage, all of it, they can work on a very integrated and sleek experience. Twitter went through something similar in their early days. They were moving in this direction of being a platform. There was this initial explosion of clients that tried interesting things. Like TweetDeck and Tweety and so on, and ultimately they decided it was a product decision within their company. We don’t want to be a platform. We don’t want to be the next email. We want to provide an end to end curated experience where when we are going to add a new feature, whether it’s images and video in line or something else that we can fully control what that looks like for all the parties in the equation. And that’s a trade-off that I think you always have to make, an email is a good example. You do get weird stuff that happens when you email between two clients and they don’t quite agree about how to display the results, and also it’s very difficult to add new things. I say that speaking as someone who would really like to embed video into email newsletters and you just can’t do it. You got to use animated GIFs which are low quality and slow to download and so on, but it’s just not a standard that can quickly evolve. 00:13:39 - Speaker 1: Yeah, I think this is indeed one of the core tensions in this idea. How do we balance moving fast with a single decision being made about an ecosystem versus having this more distributed approach. One idea that I find interesting though is kind of this idea of partial compatibility. Can we find sort of middle points between these extremes of a single rigid standard that hasn’t evolved since the 80s versus a company that just decides whatever it wants and imposes it on everyone. I think we can potentially at least try to have app ecosystems where you might have two applications that share 80% of their functionality, and there might be parts around the edges that don’t work perfectly together, but that might be something you can manage as a team, especially if you’re working with people and you know what tools they’re using. I’m really interested in finding tools and sort of platform approaches to mediate this kind of fuzzier partial interoperability. 00:14:34 - Speaker 3: Yeah, I think there’s a really interesting spectrum here, or maybe even a whole world of different possibilities. I’m reminded, for example, of this idea of aftermarket support that you see in consumer durable goods like cameras, for example, and there through fiat or evolution, you have some standards, some connection points where people can. Plug in often literally and you might have the core the proprietary, but there’s all these extensions and accessories that you can put on it and because of that, you get an enormous ecosystem of tools and so on that you can build around the core, like a good example of this would be tractor attachments, where there’s the 3 point hitch, and you can basically put whatever you want on a. you know, a plow, a snow blower, whatever. And that’s really interesting because you enable profitable commercial entities and there’s only a few of them to build the extremely complex integrated tractor. And then you have this whole world of mom and pop metal fabrication shops building random implements for 200 bucks. It’s really interesting balance, and I don’t see that very often in software. 00:15:36 - Speaker 1: Yeah, I think it’s also interesting in software to look at domains where you often have a lot of tools that look pretty similar to each other if you squint. Take to do list software or like team issue tracker software, for example. Every time I see a landing page for a new project management tool, there’s a lot of concepts there that look pretty familiar. You have things to do, you assign them to people, you have some notion of projects. And yet every tool has a little bit of some unique spin on that problem. There’s perhaps new ideas that they bring for organizing stuff, and yet I think it’s reasonable to say that maybe 80% of the core ideas are shared. So something we actually worked on on the Cambria project that I worked on at I can Switch last summer was, let’s say, as one example, you have one to do list app that’s decided that you can assign something to multiple people to work together on. And another app says that a to do is assigned to a single person. And what if you want those apps to interoperate, you might just say this is impossible, but you could also say, well, if you assign something to multiple people, we’ll just show the first one on the other app that only allows a single assignee, and maybe that’s good enough for your use case to get by with that sort of partial little bit of bridging between those ideas. And I think if we can get creative about bridging between similar but not identical apps more, that opens up a lot more possibilities for how we can have tools work better together. 00:16:54 - Speaker 3: Yeah, exactly. Another thing that I’m reminded of here is the metadata that you can put at the top of HTML pages. I’m actually forgetting the name, what’s the right name for this? 00:17:02 - Speaker 1: The meta tags, the meta tags, I guess, yeah. 00:17:04 - Speaker 3: And there’s a whole world of emergent, somewhat adopted, partially adopted, somewhat conflicting standards for preview cards and Twitter preview cards and open network preview cards and, but it kind of works out, right, because there’s this basic platform entry point, which is the meta tags and then different platforms and users adopt different subsets of them, but in practice it tends to work pretty well. 00:17:28 - Speaker 2: I think the web obviously in many ways is a great example of an open and evolving standard that on one hand has innovated a lot and continues to over a pretty long period of time but also is not owned by any one vendor and browsers come and go and so on. But one principle that’s often used there is this idea of progressive enhancement. which maybe is kind of what you’re pointing to there, Mark, which is you can drop in something like if there’s some fancy new audio thing or some fancy new video thing or some fancy new interaction capability, you can either first of all just handle the degradation case of this browser doesn’t support that, so let me do something. Simpler, but in many cases just putting in, for example, those meta tags that produce, for example, a certain kind of unfurl card will just be ignored by older browsers that don’t know what that is. They just kind of skip over that and if you’re in that situation or You just don’t see that information and probably something similar happens with, yeah, you use an older browser to load a page that has, I don’t know, some fancy new video thing, you just see an empty box or whatever. That’s not great, but it still works for you, you can still get most of the content. 00:18:38 - Speaker 1: Yeah, I think we have a lot to learn from the web in terms of how to promote sort of a more flexible notion of what software can be. One really cool thing about the web, right, is that people don’t have to build plug-in APIs into their UIs for you to mess with them. So if you know a little bit of JavaScript hacking, or even, you know, how to open the DOM Inspector on a website, you can go in and delete ads, you can change stuff, you can install browser extensions that modify stuff and none of that is Using some official API, right? It’s just that the nature of the platform is that when you build a website, sort of by default, there’s a lot of hooks built in for people to reverse engineer how it was made and to pretty intrusively modify any part of it. And I think that’s a really interesting goal to aspire to and more software as opposed to a more traditional plug-in API like in a lot of platforms, if there’s no API for it, you’re stuck, you can’t customize that aspect of the software. Of course there are trade-offs, you know. The reverse engineering approach is harder, it tends to be less secure, and it’s a lot harder to maintain over time because things change out from under you. But on the other hand, I think there’s a certain beauty to being able to make changes that not only did the original authors of the software not anticipate and explicitly authorize you to make, but even sometimes ones that they actively don’t want you to make, right? So ad blocker being the prime example of that. And so I’m very excited about the potential for browser extensions as a mechanism for a more customizable kind of software, especially as the web just seems to keep growing and growing as where all software is going to end up living. 00:20:12 - Speaker 2: Yeah, one of my favorite party tricks is opening the Dev Tools console in someone’s browser and doing something like just changing a background color or some text on any website you want Facebook, CNN.com, whitehouse.gov and you know, it can blow people’s minds, wow, you’re an Uber hacker, but I actually also use that as an entry point for getting people interested in programming, letting them see without needing to install any new tools in their computer. Kind of how the web works a little bit under the hood and that they could do this too. 00:20:42 - Speaker 1: I love doing that too. If I’m trying to teach kids about HTML, I’ll always have them vandalize their school website and the Chrome deaf tools inspector and they just get such a thrill. I think it’s, you know, If you’re brought up in this world where software seems to be this immutable object that is just presented to you, and then someone shows you this little trick you can play, that all of a sudden makes it yours and something you can mess with, I think that’s just a really powerful ethos to instill in people. I think Alan Kay would call it. Popping open the hood and seeing something sensible inside and just a little bit of that ability to mess with the internals, I think can go a long way. Adults too, you know, I’ve shown like sales people how to fake a mockup in the browser, and I’ve seen people, adults scream with delight when they realize they can do this stuff. I do think there’s also a problem, which is that stepping from a little bit of dom hacking and depth tools to actually making a real browser extension, is this enormous leap. Like, if you think about it, you know, to publish a browser extension or even to save one for yourself, you go from messing around in depth tools to, OK, I’m going to learn. All these weird APIs and I’m gonna open up a code editor now, and I have to learn some JavaScript, and there’s just this huge chasm, and one of the things I’m interested in is finding ways to, I guess, bridge that gap, or just make it a smoother slope from that first hint of malleability to taking further steps down that path. I think, for example, spreadsheets do this really well, and this is one of my favorite things about the way spreadsheets are designed. There’s a lot of things that make spreadsheets magical for me, but one of them is that you can take your first step of just typing in some numbers, right? It’s just a data table, there’s nothing special. And then you want to add together some numbers, so you learn to use the sum function, let’s say. And then you just keep taking these little little steps. There’s not that much learning involved with any one of them. There’s not that many concepts involved. And fast forward 2 years and you’re like running a whole business on like a bunch of V lookups, right? And I’ve met so many people who don’t consider themselves that technically literate, who are in fact incredibly capable in this medium, and I think that a lot of it has to do with the fact that you can sort of accidentally end up becoming an expert, because no one of those steps was too big. Even though it is the case that, in fact, if you add up all the little steps, you did learn a lot. There was work invested, but it’s a much smoother path to mastery. 00:23:09 - Speaker 2: End user programming is something I think we’re all passionate about here and we’ve written about it in Switch and elsewhere, but this particular element of a gradual step by step rather than having this big jump from user of software to producer of software, I think is a really key part of it. We haven’t cracked the code on that yet as an industry, let’s say. One great discussion of this. Again, coming back to the web, there’s there’s a YouTube talk I’ll link in the show notes, but essentially someone talks about how they had first were using, I think it was LiveJournal, they quickly learned that you can customize the background color or something by pasting this little magic snippet of CSS and that leads you to doing more customizations, and then you go from there to kind of going to full HTML and CSS. There are some break points there if you’re gonna, you know, move off to your own home. Hosting or whatever. There’s a similar kind of path also with HTML that are just files that you FTP to a shared server, or shared host of some kind and then you’re just writing HTML but you can actually break out into PHP with these little codes. So all of these technologies, perhaps not even purposefully, I’m not even sure they were specifically designed to have that gradual ramp, but they do spreadsheets, HTML. PHP all have that kind of ramp, and that ramp is how you can avoid hitting some wall where you have to have some deep intrinsic motivation. I want to learn to be a software engineer or manipulate computers in this way. And instead you’re just on the way to solving your problem. You find some ways to do that by pasting some magic codes into your thing. Maybe you get a little curious and you follow where that leads, and pretty soon you’re an empowered computer user. 00:24:49 - Speaker 1: For me, this comes back to the bring your own client thing. One of the most frustrating experiences for me in software is when you’re in some sort of monolithic ecosystem, and you hit a wall of something you really want to do, but you can’t do, and depending on how the ecosystem around you is arranged, you might just have no choice. That’s sort of it. You can file a feedback request with the company that makes the software, and they will tell you, you know, we have put it on the backlog. Good luck with that. 00:25:13 - Speaker 2: Yeah, it’s on our roadmap. Honestly, I make that answer myself in a new support requests all the time and it’s genuinely true, but I’ve never. Worked on a software project that doesn’t have a roadmap backlog, whatever it is, that is just way longer than what you could ever hope to do in a lifetime. 00:25:28 - Speaker 1: Yeah, I’ve been on both sides of that too. Actually, a lot of how I got into this whole topic to begin with was from my experience being on the other side of that conversation. So before starting a PhD and doing research stuff, worked in startups, I spent a while at an education technology company, where we were building software for K through 12 schools and When we started, we were a very small team. I was fortunate enough to join early. We were like 6 people living in a house together. We only had a few customers, and so we had the ability to focus a lot of attention on any individual request that came in. But as we grew over time, starting to serve thousands of schools across the country, it just became harder and harder to manage all this feedback. And I think the default answer and what you’re supposed to do, given the way software is currently arranged, is to just get better at saying no. So, you sort of assume, well, we’re a resource constrained team, we are the only ones who can change the software. We don’t have the time to do everything everyone wants, and so we’re just going to do less. And I think that on the one hand, that can reflect sort of a wise style of design where you’re not just building a faster horse, you’re like digging deeper and really building something better than they could have asked for, but often in my experience, it was not that at all. It was just that only 5 people wanted something. And I agreed with them, you know, sure, that makes total sense for you. I can see why you want that. I wish I could build it for you, but there’s only 5 of you. And so I’m sorry, and that just really, I think, was a frustrating experience for me, and I found myself wondering, why does my team, you know, in this office in Boston have to be making these decisions for these teachers in like Idaho or whatever. One of the bright spots against that sort of philosophy though was coming back to spreadsheets. I remember this feedback call we had with a customer where We wanted to ask them, how did you like our data reports that we’re showing you, cause we were essentially building data dashboards for schools, and they told us, oh yeah, we don’t use your data reports at all. We use spreadsheets. Let me show you. And so they had exported the CSV and made their own thing. And on the one hand, it was sort of annoying for us having spent so much of our time trying to build this beautiful product experience for them. But on the other hand, it was so cool to see how they had built this really weird and ugly, but extremely functional spreadsheet that did exactly what they wanted for their school, and aggregated the data in a completely different way that had to do with how the teams worked within their school. And I thought what was neat about that was that spreadsheets were this flexible tool kit that they could use to build their own thing, even something as tiny as changing a single word of copy that might have been bothering them and causing friction in their whatever political environment in their school. There’s so many tiny things that I think people would change if they could, but it’s just that the way software is built requires everything to funnel through the original team building thing, which is who’s never gonna have the time. And so, I wish we could reorganize software to support more of that style of customization. 00:28:20 - Speaker 2: So we’ve already touched on some of your work here, Jeffrey. I’ll link your articles on bringing your own client as well as one about browser extensions being underrated, but then maybe you can also talk about some of the projects you’ve done that have to do with how you see solving this problem more broadly. 00:28:39 - Speaker 1: So on the topic of interoperability, one idea that I’m excited about is thinking about better ways to synchronize across existing cloud applications. So I think there’s a way in which, you know, if you’re using one app and I’m using a different app, and if we can establish a bridge between them, where let’s say I’m editing a doc in Google Docs and you’re using Dropbox Paper or your preferred editor, and imagine every single keystroke data is being transmitted live between them. That starts to create this more flexible feeling where the data is not locked in any individual app, and it more kind of lives between the apps. And so one new project that I’m sort of embarking on now is trying to create tools that mediate that kind of synchronization across tools. Some of the hardest part comes back to that partial compatibility issue we talked about earlier, where if there’s changes I’m making that are going to mess up your experience or that aren’t going to propagate to the app you’re using. How can we help users understand the relationship between these apps and feel comfortable with the overall user experience of stitching them together? And I think this gets at some of the toughest challenges in these sort of more flexible software ecosystems is that if we’re all using the same thing, it’s really easy for me to know what you see and what your experience looks like, and the more we diverge. I think it’s really important that I’m at least able to preserve a mental model of maybe there’s some data I’m putting in that you’re not able to see for some reason, and if I’m not aware of that, that’s gonna cause problems, right? And so, a lot of my thinking these days is about building these sorts of sync tools to mediate that gap. 00:30:05 - Speaker 2: I can think of a few examples of that, particularly in the enterprise world, for example, kind of Salesforce to SQL database stuff where your sales team wants to use their CRM because that’s got all these tools and things that suit them, and they’re typing stuff into a web dashboard and getting reminders about who they need to follow up on. But then your data team or your programmers, you know, they’re not going to go cook around in the Salesforce interface. They need to pull stuff into a proper database like a postres database and so syncing seamlessly between those is valuable. Do you have other concrete examples you mentioned the project management tool case. What are some other ones that you see as kind of like key use cases? 00:30:45 - Speaker 1: Yeah, it’s funny, sales data is one I’ve heard a lot about too from people and it’s sort of a more mundane use case. I’m not sure I would classify it in sort of the creative tool space, but I think it points to how this need just pops up a lot inside of companies. 00:30:57 - Speaker 2: I’ll go ahead and count sales as creative work. I actually have this discussion of fair fair bit, which is sort of I like to use the term creative professional when I talk about sort of the target audience for muse, but also maybe just the kind of person I’m interested in serving generally. And a lot of people do respond to that with, oh, well, I’m an attorney or I’m an accountant, is that really creative work? And I think it is, I think there is creativity that goes into, for example, financial modeling, and absolutely there can be creativity that goes into sales. It’s not traditional artist type stuff, so I would go ahead and count that. 00:31:30 - Speaker 1: That’s totally fair, and in fact, I think it points to why tools matter in any profession. Like, there’s a reason that people want to synchronize HubSpot with MailChimp. There’s something going on there about what individual tools are good at in the entire life cycle of how you want to run your process, and the need for sync emerges from the reality that no one tool can do everything perfectly. And so I think that’s totally valid. 00:31:53 - Speaker 2: I’m reminded of the phrase toolmaker humility, which came up in our podcast withalant from Kraft where he really tries to keep that in his heart as he designs the product of knowing you’re not only, not the only tool that people are using. but you’re probably a large collection of both process and over time your toolkit is changing and that sort of thing, and I just feel it’s so easy for toolmakers to want to make the everything tool. Don’t worry, we’ll just do everything and you can put everything in here and we’ll be all in one place and then it can all work together seamlessly and that has never been how the world has worked. It is never going to be how the world works. If you can design your tool to play as well as possible and be aware of that reality, I think everyone’s better off. 00:32:38 - Speaker 1: I think it’s tricky though, because you need not only the willingness of the tool makers to play with other tools, but you need a platform that supports that interoperability in the right way. So I think Kraft is the perfect specific example of this. I think they’ve done the best possible thing you could expect a writing tool to do today, which is that I think as Balant mentioned on this podcast, they let you save your documents either to their cloud, which gives you real-time collaboration, you can comment and things like that, or you can save it to a file, which gives you more control. It is sort of locally stored with you. You have the ability to save it wherever you want. Other people can potentially open those files in different applications, I think, is the ultimate goal of that teams, but it’s an either or. So if you want to collaborate in real time and have that flexibility to open those files in other applications, there’s no technological solution to that today that exists. There’s no platform that team can build on to support that, and to me that’s the key missing piece. There’s this ecosystem missing there, that means that even in this dream world where Google decides they want their party editors to exist for Google Docs or something, supporting that technically is very challenging, and so I think we need better platform support for that kind of thing, in addition to thinking about business incentives for people to even want to do in the first place. 00:33:55 - Speaker 3: Yeah, this is a great example to bring up. I agree there’s a huge technical challenge here. It’s one that I and many people around me and the Ink & Switch research lab have been working on for some years now. Yeah, so you would need to have that in place, something like files for the real-time collaborative internet. What is that abstraction. And then on top of that you do have this whole issue of business and incentives and dynamics and path dependence because let’s say conservatively that creating this technology takes 10 engineer years. a million dollars, who’s going to put that up and then how do you actually turn that into a public platform that’s optimized for the benefit of all the individual users and not the creator? It’s a tough problem. One of the things that I liked about this project that you mentioned, where you’re synchronizing data between cloud services, is that it does grapple with the reality of, here’s our initial condition of there are a bunch of proprietary. cloud services that do have important data and it’d be ideal if they had a perfect JSO API, but that’s not the reality that we live in. So we need to find a way to help our users get data back and forth between them. I feel like a lot of the conversations in this space, that is a space of open systems are of the form, we should X where X is design and build and use a perfect open system. That’s not gonna happen. In fact, it’s unreasonable for you to ask other people dedicate their moral lives to your pet projects, right? So you need to find a way to grapple with these dynamics and get out there in reality. 00:35:19 - Speaker 1: Yeah, this is a tension I think a lot about between sort of an incremental approach versus a first principles approach. I think you could frame it. For example, the solid project, which is led by Tim Berners-Lee and is pretty prominent in this space, is one attempt where their idea is, you know, we’re gonna essentially fundamentally rearchitect how web apps are built. We’re going to give users these little, they call them pods, where the users control their own data, and then web applications can connect to your pod to access and edit your data, but the applications themselves don’t store the data. And I think that’s a lovely vision. I would love to see something like that succeed, but as you’re saying, Mark, I think the biggest challenge is, how are we possibly going to get from the world we have today to that future? Are we really going to rebuild the web stack from scratch? And is the experience going to be better enough for both developers and users to incentivize such a massive shift? I tend to think that no amount of, you know, legislation or regulation, let’s say, is going to successfully push us to a solution if it’s not better for both developers and users. And so I think we need to think about making it incredibly easy and awesome for both of those groups in order to get from where we are today to that beautiful future. 00:36:34 - Speaker 3: Yeah, and to be clear, I do believe it’s possible to get to a future that looks very different from the present, a radically different future, but necessarily you are going to get there in incremental steps, which might be incremental steps from the status quo or incremental steps from zilch, basically where you’re building up a new system in the context of the current ecosystem. I think both of those are viable. I agree. I think what we need here is entrepreneurs in the broadest sense, not just of commercial ventures, but of ideas and nonprofits and politics and all these things to really work towards the future that they want to see. 00:37:04 - Speaker 1: I think another really important thing on the entrepreneurship theme there is being realistic about use cases. I think my favorite startup style thinkers are the people who can really focus on what is this technology actually useful for, and how can we focus in on that one killer app. And I’m not sure that we’ve necessarily found that killer app yet in this space. For me, I think collaborative writing might be the one personally, but I worry that you can make all the tech demos you want. But a lot of things take off in a particular niche. And I’m interested in finding where’s the place where people desperately are needing this real-time interoperability to the point that they would actually abandon their familiar tools. 00:37:43 - Speaker 3: Yeah, I feel like this actually afflicts quite a few projects in the space where, again, they’re thinking in terms of generalities and they don’t have a specific use case in mind. I actually called this the mark rule for product management, which is you need to have a single named human being like an email who specifically wants your projects. And that sounds like a low bar, but in a lot of cases, you ask people that and they’re like, oh, it’s salespeople. Well, do you have a specific one in mind that I can email? Well, not always, right? So it’s a good baseline. 00:38:11 - Speaker 1: Yeah, I think often, especially with this kind of customizable software, it’s tempting to get into wouldn’t it be cool if conversations that where it might be nice, but there’s no real pain. One use case that I think is really compelling to me is I read a paper recently by some researchers at Northwestern University on accessibility issues and collaborative writing. And they talk about how people with sight impairments have a really hard time using Google Docs with their teammates, because there are certain accessibility issues around how that platform works. And what they often end up doing is they’ll either convince their team to adopt a different workflow, or they’ll just give up and copy paste text out into a Word doc or something, edit it there, and then paste it back. And it’s very, very cumbersome. It’s not just a little inconvenience, it really limits their ability to be a true member of their team. And they have to make this incredibly uncomfortable choice where they talk about the social anxiety around trying to convince all of their coworkers to use a different tool, or just internalizing that friction and deciding to try to live with it. And I think that if you imagine a world of greater interoperability, could we have a text editor that is much more optimized for this specific group of people who have very different needs and still allow them to collaborate with their peers more effectively? The more that people’s needs differ, especially people with disabilities, I think often have fairly different kinds of needs and a lot of other people. I think that those are use cases I’m thinking a lot about in terms of where we really need better interoperability. 00:39:41 - Speaker 3: Yeah, it’s a great motivating factor. It’s easy to think of the what ifs in terms of cool conveniences and emojis and so on, but let’s not forget about that as well. 00:39:51 - Speaker 1: I also think as an antidote to cool conveniences, there’s sort of an interesting paradoxical way that software customization actually promotes very boring stability. So I think one of the special things about, let’s say, programmers and their text editors, which is a place where we have some of this file-based interoperability, is that if you talk to programmers, often they’ve invested like a decade plus in using a particular editor, right? And they’ve carried it with them from job to job, they’ve really made it their own. And they have successfully been able to avoid switching tools because of interoperability. It’s not this kind of tinkering, trying a bunch of new things mindset. It’s exactly the opposite of just getting to invest deeply in one tool and to keep using it. I think that’s an underrated benefit of interoperability is just. Yeah, being able to make that deep investment. 00:40:42 - Speaker 2: The revealed preferences of software engineers is that yeah, very standardized file formats, usually plain text, wide variety of source editors, wide variety of different kinds of plug-ins and liters and things like that. I guess you do have to agree on your version control system that needs to be at least somewhat standardized on your team. Terminal, even things like database clients, you know, SQL is pretty standardized, so software engineers seem to prefer software that changes less. And has more interoperability and it does have the problem of, as we mentioned previously with email or Twitter as a platform versus a product. Yes, it is hard. Someone says, you know, programming editors or source code would be really great if you could drop in an image. I could put in a little diagram of my Architecture or something like that in a comment that would make perfect sense. I think that would be a big improvement, but that would be very hard to do because the plain text format we’ve all been using a very long time and all the tools are built around that, but essentially software engineers prefer that versus something sort of newer and shinier and with more features. 00:41:50 - Speaker 3: Yeah, in fact, it’s the ecosystem that is extraordinarily susceptible to customization and extension because all the participants are able and in fact inclined to do that. So kind of competitively, it’s very hard to win without leveraging that. I think a good example of that is the editor wars which to my mind are now kind of coming to a close and BS code is one to a large extent I think because of the incredible platformization they have with extensions and language servers and so forth, and typically there’s going to be a bunch of editors. I use a different one. But they’ve been able to really pull ahead while accelerating the whole ecosystem for developers because they lean so heavily into the open platform angle. 00:42:28 - Speaker 1: I also think though that the diversity of text editors can teach us something about how to reconcile this partial compatibility thing we were talking about, because if you think about it, yes, the base format of the code being shared between people can be really stripped down into this text format, but some editors like VS code, do a lot with that format. They’ll run fancy analysis on top of it and do syntax highlighting and all these like autocomplete things, which are not inherently part of the data exchange format. They’re just Bells and whistles that each individual editor gets to add on top to that experience. But I’m not forced to opt into that. I can use a stripped down, I could use Microsoft notepad to edit code if I wanted to, right? There’s nothing stopping me from doing that. 00:43:08 - Speaker 2: Ed is the standard text editor. 00:43:09 - Speaker 1: Yeah. In fact, I think when I was like 12 years old, that’s probably when I started using to write code because I didn’t know any better. And I think That’s an interesting, for me lesson to reflect on is can we get more places where there’s this shared core and then more functionality built up as optional app specific extensions. 00:43:27 - Speaker 2: And then we touched briefly on, I guess, financial incentives, and we look at the interoperability problem writ large. Certainly it comes from the world of files, kind of classic desktop files, and yeah, there was problems with sort of format openness like Word docs. Files, for example, but ultimately files did seem to have a lot of that agency and interoperability, and it’s really both mobile and cloud that I think brought us these more closed up hermetically sealed systems, both for their own reasons. I think mobile is more around kind of safety and security and comprehensibility to end users, particularly very non-technical users. But on the maybe cloud web app side, particularly B2B software, now you get into this thing where data is considered to be where the value is. James Chen used this terminology data swamp. That that’s kind of like the aggregating a bunch of data together and that’s where the value is and you even see that in what people expect to pay for software. We run up against that with Muse, we talked to Balant from Kraft about that as well, which is people are in the mindset of, oh, if you’re going to host my data for me, then you need to run a server or whatever, then I can justify paying a subscription. But if I’m just buying the software, they feel like software isn’t valuable on its own, and of course that’s really restrictive for making truly great software and furthermore, it creates all these incentives around of course you want to lock up the data, of course, something like a two-way sync. Like you described, that’s hurting my business’s value. So trying to find a way to create financial incentives and paying for the software and the value that provides you versus the data, the data swamp, that’s a tough one. 00:45:12 - Speaker 3: Yeah, it’s tough. One angle that I like circling back to a previous podcast on games is, so to kind of recap the dynamic there is that there are some ecosystems that are so high powered because of their open platformized, scriptable, customizable, whatever nature that no amount of proprietary excellence can compete. And I don’t think we’ve quite found or charted that path in the world of creative tools. You think about, I don’t know, Photoshop. Could an open Photoshop be so much better such that it displaces Adobe Photoshop? I mean, maybe, right? I don’t yet see the path for that, but perhaps in the world of multi devices or multi users or other use cases, there is. So I think that’s one promising angle. There are other angles, but that to me seems perhaps the most interesting. 00:46:01 - Speaker 2: That’s an interesting one to think of the way that for example the web and its open standards and interoperability displaced and was clearly a huge improvement on the more closed up formats like Flash or maybe Java Servlets that came before. Clearly the web was just so much superior and it In addition to being open, hackable, you can pop open your DOM Inspector and do stuff to any web page. So what would be an equivalent of that that would make Photoshop or even something a beloved current piece of software like Sketch or FIMA? What would make those things feel like a Java servelet by comparison? 00:46:38 - Speaker 1: I think there’s a really tricky balance here to strike because it is very valuable to have someone think through an entire unified product experience and make it all fit together in a coherent way. I know this is something you’ve thought about a lot with when I use Muse, it feels like someone has taken care to design this whole environment and I don’t have to do much work to sort of put together a bunch of pieces. And 90% of people most of the time, don’t want to like assemble their own software from scratch, right? There’s a reason we pay designers. is to think through these problems for us. And I think that’s totally a good thing, and designers bring a lot of value in that way. But at the same time, I think that we can think about rather than giving someone this hermetically sealed box, can we use an analogy like build a beautiful Lego set for them and hand it to them, where if they like it just as it is, that’s fine. And if they want to add one Lego right there, it’s not a big deal. They sort of see the composition of how this thing was made. They have a little bit of flexibility to tweak it because it’s made out of parts they understand. I think that’s a design ethos that sometimes I feel like we’re in danger of moving away from. There’s this great story in one of my favorite books about end user programming, which is called Changing Minds by Andy Dessa, who’s sort of an education and computing researcher, and he talks about this nightmare he had where he’s riding a bike, and he looks down at the gears, and they are labeled not with numbers, but with words, like this is gravel mode, this is like uphill mode. And he has no idea how to use the thing, you know, if I’m going downhill on gravel, do I use gravel mode or downhill mode? And he talks about how like, because we’re used to riding bikes with number gears, this sounds sort of ridiculous, but you can imagine the product manager that had that conversation where they said, these numbers make no sense to people. People don’t want to like, see 1234, they want to understand the function. We need to give them an easier way to understand what this tool is for. But what you’re robbing them of is a structural sense of what’s going on underneath to provide that functionality. So that the moment you go off the expected use cases for the thing, you have nothing to lean on. You have no coherent understanding of the system, and so everything just falls apart. And what he contends is that people can actually learn sometimes more than I think we give them credit for. Like, it’s not actually that hard to learn a bike. Everyone learns how to ride a. Like, even though it takes some practice and you have to feel out the gears to understand how they work. Once you’ve put in that little bit of effort, you have this sort of generalizable understanding of the system that can go a long way and is much more generically applicable. And so I think it’d be nice to see a little bit more of that style reflected in how we build software for people. 00:49:09 - Speaker 2: Well said, yeah, I think the design ethos often is kind of polarized towards the edges, which are either making pure consumer stuff. It just has to be as simple as possible, no choices, no customization, just can’t have no chance of going off the rails. And getting confused or we have the full on I’m going to build my own PC from parts and put together my own Linux distribution and assemble my raspberry Pi and you put together all my special VS code plugins and there’s kind of nothing in between sometimes. 00:49:43 - Speaker 3: This reminds me of an important point about these platforms and ecosystems. If you look at the successful spaces, whether it’s software or protocols or hardware, it generally is not, you have some platform and then a bunch of individual users completely customizing their setup. What tends to happen is you have the platform, you have a small number of secondary market providers, if you will, who provide modules. Sanctions, implements, what have you, and a much bigger group that tries, by the way, but a lot of that stuff just kind of gets filtered out, doesn’t bubble up the top. But if you create an opportunity for people to have a business or some other sense of fulfillment from providing these things to the community, you only need a few of them. To really enhance the ecosystem. And yes, you’re gonna have some users who want to build their whole tractor from scratch or who want to go in and fiddle with the HTML and CSS that’s fine, but often the real main potatoes of these ecosystems is the secondary market of service module extension providers. And the somewhat sad consequence of that as someone who’s really into end user programming is that often it’s not the end user programming experience that matters the most. If you look at how hard it often is to build a module or extension or an add-on, often it’s frankly a huge pain, but people who are doing that as a small business, as a major hobby, they’re willing to get over that and then they can provide the service for all the other users in the ecosystem. So it often ends up being important is distribution, obviously platform access, and some ability to monetize or get the equivalent personal fulfillment. 00:51:20 - Speaker 1: I’m not sure I totally agree that it’s sad for end user programming. I think you’re totally right that there’s this collaborative dynamic, but for me, that’s sort of just one part of the picture to keep in mind when we’re designing tools for this. So like, for example, and I think there’s a similar dynamic in spreadsheet usage, where there’s been some great studies by Bonnie Nardi, who’s kind of like a hero in the end user programming community of how spreadsheets are used in offices and What it turns out being is that there’s like someone in the office who’s like the spreadsheet person, right? And when you have a really complicated formula, right, you go to them and they help you and they figure it out, and then you go back to your desk and keep working on it. But the key thing there is that there is a large part of that ecosystem that is available to you, even as a novice, and you don’t have to like, again, ask someone to ship you a hermetically sealed thing. Maybe you can sort of read the formula they wrote and start to learn a bit. And so I think Having fuzzier boundaries of expertise and enabling more collaboration is a thing to strive for. One project I’ve worked on that sort of embodies this goal a bit is this project called Wildcard, which is a tool kit for people to build their own browser extensions without programming. And the rough idea there is, like you were saying, Mark, it’s pretty hard to build a browser extension. Some browser extensions are extremely complicated. And when I install them, I have no idea how they work inside. If I want to tweak the extension, or maybe compose two extensions in a new way, that’s typically really hard to do. And the thesis of the Wildcard Project is that, yes, some extensions need to be really complicated like you said, but also there are some extensions that I think don’t need to be that complicated. I remember using for a while an extension that added a checkbox next to every transaction on a bank statement, so you could just remember whether you’d already written it down somewhere else. And this had like thousands of installs on the Chrome extension store, you know, that’s not a sophisticated thing. But again, it’s really hard to even build something that simple as a non-programmer. So the goal of Wildcard is, can we take that subset of extensions, which is not that complicated and make it accessible to normal people to build. And actually, as you can tell, you know, I’m sort of a spreadsheets fan. And so the paradigm we went with was, what if you could edit a website in a spreadsheet is the vision. You know, you open up a little pane, you see some data in a table that sort of represents what’s in the page, like on a news site, it might be a list of articles with their names and authors and whatever. And then, As you mess with the spreadsheet, whether that’s sorting and filtering or adding new columns with little formulas in them, all of that flows back into the page and modifies it. And the goal there is that if you’ve used a spreadsheet, you can maybe learn your way around this environment, you don’t need to like open a code editor, you’re just right there in the website and you can build and share these customizations with other people. Now, again, it might be the case that 90% of users of this thing eventually will just install pre-made things that others made, but if they’re not written in JavaScript, if they’re in this sort of more user friendly paradigm, maybe more people will end up popping the hood there and making little tweaks of their own. So I think it’s this delicate balance there. 00:54:15 - Speaker 2: Well, before we go, one question I think that can come up sometimes is this question of designing software for other people, and maybe you can imagine that product designers who their whole role in fact is doing that and software as this abstract hard to understand thing you actually need another person with that expertise to design it for you. But you could actually swing back the other way as well and say, how can anyone else know your needs? And in fact, this is why some of the startup advice is solve your own problem, build something for yourself because you know it in an intimate way that no one else can. Where do you stand on this? How can others design software? 00:54:53 - Speaker 1: Yeah, this may be a slightly extreme way to put it, but I think I’m pretty pessimistic that it’s possible to design truly great software for someone besides yourself. Especially if the person you’re designing for is operating in a complex environment, like, for example, I had experience designing for teachers, and I’ve never been a teacher in a classroom before.
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: That to me was the magic of the iPad, the direct manipulation of the iPad with my hands. It just felt so human in a way that the computers and even the phone never did. 00:00:19 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for thought on iPad, but this podcast isn’t about Muse the product, it’s about Muse the company and the small team behind it. I’m Adam Wiggins, joined today by my two colleagues, Mark McGranaghan. Hey. And Leonard Sversky. Hi. And I’m very excited to say that we have just booked our lodging and flights for our first in-person team summit in a year and a half, is it? The last time was Arizona in early 2020. So we’ve been doing all our summits, which is a very important way that we plan our work and just bond as humans get out of the day to day a little bit. We’ve been doing it all virtually, but that just is not the same. So we’re gonna be meeting soon in France for a nice get together and chance to really think some big thoughts. Look forward to seeing you both and our two other colleagues in person. 00:01:17 - Speaker 1: Yeah, it should be awesome. 00:01:18 - Speaker 3: I’m kind of proud of us for actually making it all this way basically, but yeah, it feels like we really need and would really benefit from seeing each other again. 00:01:27 - Speaker 2: For a team that scaled a lot, we had the benefit that the four of us already knew each other in many cases very well, because we’ve been working together for years, we already have those human connections. It’s easier to translate that to the virtual space. But I think if you had a team that was adding a lot of people swiftly, yeah, seems like a challenge to scale the culture, to keep the creativity and vision, and all the things that just tend to come from being able to not just see each other as moving squares on your screen, but as real full three dimensional human beings. So our topic today is the future of the iPad. So Muse is, at least at the moment, an iPad only app, so clearly we’ve bet our business on it, and we see big potential in the iPad as a creative tool, not just a consumption device, but something you can use to create, do work, be productive, and of course, for our purposes to think as a rumination space. But we’ve been at this a few years now, it’s interesting to look both at the history of how the iPad has evolved even as we’ve been on it. Then furthermore, at this moment, iPad OS 15 is in beta. It’s got some enhancements to the multitasking capabilities, which is sort of a power user capability, and all that just, I think, had me at least as I was using the beta, reflecting on how has this platform evolved. From our perspective as app developers as users that want to see it be a great creative tool. So I guess the first question that a lot of folks tend to ask. And I think it was last year the iPad had its 10 year anniversary, and there was a lot of articles about what does it mean or where are we at or how has this platform evolved in this time, and I think the tenor there was generally negative. I’ll link a few, but Strateteri, for example, has one called the Tragic iPad, and they basically say it’s a device that never found its purpose or never found its real role. It’s sort of too big to be mobile and fit in your pocket the way a phone does, but it’s not as powerful as a laptop. This thing doesn’t have a clear role in people’s lives, at least that’s the way that was presented then. How do you both see the role and who it’s for question with the iPad. 00:03:35 - Speaker 3: I think the fact that it doesn’t have a clearer role is both the appeal of the iPad for many people that it can be a lot of things and a lot of different things to everyone, but it’s also, especially for us, the developers, it’s also the problem, right? That we don’t really know what Apple has in mind for the iPad, but it wants the iPad to be who it markets the iPad for. And so it’s hard to really think about the future of the iPad and be certain what kind of app you should build for it. 00:04:03 - Speaker 1: Yeah, to my mind, the verdict is very mixed here. So I think the iPad has succeeded as this unique third form factor that’s somewhat mobile and critically has multi-touch input with a pencil and for apps that are designed for that hardware, things like Procreate and of course Muse, I think it’s uniquely good and it’s really special. The other thing that I think people envisioned for the iPad was this new general purpose computing platform that would basically replace a lot of the things that the Mac desktop has previously done, and I never saw that and I still don’t see it. I think it’s a future we could get to if we all really want to, but I don’t see it happening right now. I know some people kind of use the iPad in that way, but I don’t get that at all. So we could talk more about that, but that’s what I see as the split vers on the iPad right now. 00:04:54 - Speaker 2: Yeah, well, speaking as a user, I’ve done for quite a while the big kind of stationary workstation, big monitor, mouse, I’ve got my big podcasting mic that’s set up on a boom arm. I’ve got various recording equipment, I got a ring light. This thing is not a mobile workstation. At all, and I like that. It allows me to have all these multimedia pieces that I need, but it also allows a more powerful computer with a bigger monitor and bigger input devices and so forth, as opposed to a clamshell laptop. And then when I’m traveling or going someplace, even in town for a meeting, I bring my iPad. And this is just so much more portable, right? It’s not just the size, actually, it’s probably about the same in many ways as a standard MacBook, but in terms of battery life, instant on, I’ve got an LTE SIM card in there, which means it has always on internet, it’s really just truly remarkable as a portable device. Now you do hit the limits of what it can do, and I run into that when I’m taking a longer trip if I’m traveling for a week, for example, and then I want to do something heavier, certainly anything to do. With kind of web development, for example, but even editing a really long form essay or video editing, you can do all that, but you do run into limits. There’s just less software available. The software that’s there is a little less powerful, but for me that bifurcated thing actually works really well, and I feel like the laptop is actually a weird mix in a way because it’s not as portable as the iPad, but it’s not as powerful as the workstation. So that works for me. The idea of doing 100% of my work on the iPad seems untenable. 00:06:27 - Speaker 1: Adam, it’s so interesting that you and I have arrived at a totally different conclusions than this. I think that that’s been the case since day one. You were like, Mark, you should check out the iPad. It just feels magical. It feels like the future. And my response was basically no, except for the pencil, which is awesome. But you seem to really get along with it. I don’t know what to make of that. And I wonder kind of where the median or average user is. I do think a lot of people get away with the iPad as a sort of laptop light, but I also think a lot of people, it just doesn’t work. And I don’t know, maybe that’s more evidence for the mixed verdict. 00:06:58 - Speaker 3: Yeah, I think for a lot of people, it’s a mix of use cases and they basically find the ones that work for them and to discount all the ones that don’t work for them. And that kind of helps the iPad in that, yeah, it often isn’t great because of the software as a general purpose computing was that really does everything you needed to do. And so as long as you’re fine with that and stick to the things that you know you can get out of it, then it can really fill that specific hole that you want it from. 00:07:25 - Speaker 2: That’s true. It may be in some ways the market, especially more on the consumer side, was trained in that direction from mobile devices generally and the iPhone, which is, I know a lot of people who, especially a younger generation or in some cases older people who they just always struggled with computers. Like desktop computers, the difference between I don’t know, minimizing a window and closing an application was endlessly confusing, file management, all this junk that never made that much sense to them. They don’t find it fun. And so then along comes a mobile device where they can do 80% of what you can do in terms of sending emails and That kind of stuff and so they just try to do everything on the phone because the phone makes it easy, they understand everything. It’s hard to mess stuff up, you can’t get viruses, you don’t need to manage your files, and they just essentially decide to not do the things you need a computer for because it’s just they would rather be on the phone and then they can make the decision to. Cut out some of those use cases, whereas maybe a really uncompromising user that has really specific needs, either niche software or just wants a lot of power, a lot of control, something like that is not going to be satisfied with anything but sort of maximum computing capability, and the idea of cutting out a few of those things that they can’t do is just sort of like untenable. Yeah, that feels like the future point you mentioned there, Mark, is something that actually has come up a lot in our call user research, but basically just talking to people that use Muse or want to use Muse, which is they say something along the lines of the first time you use the iPad or when I open the iPad, it just feels like the future. It’s this magic device, it feels like they’re living in the future, and I certainly feel that as well, but in a way it’s sort of like a future that’s never quite coming true in the sense that you can do. A lot with it, but again, at least when it comes to those creative tool things, they haven’t really made the jump, and it doesn’t feel like there’s a fast and furious, Adobe porting all their products over and except far superior versions, or what if you want to use Figma or sketch, those seem like really natural things that a person who is also the sort of person that wants to use the iPad as a creative tool would want, but you really can’t use them at all, and it doesn’t really seem like that’s gonna happen anytime soon. So yeah, again, it leaves this conflicted or mixed verdict in some ways. 00:09:42 - Speaker 3: Yeah, I’m always reminded of that first slide that Steve Jobs showed when he introduced the first iPad and it kind of had the iPhone on the left, the Mac on the right, and then the iPad was introduced as that third device in the middle. And I think we’re still trying to figure out what exactly the role of that 3rd device is, even though we know, OK, it’s kind of supposed to be in between, but does that mean it takes things from the Mac and makes them simpler? Does it mean it takes what’s good about the iPhone and makes it better? What’s the actual use case that’s being solved by that 3rd device? Is it really only consumption based, which is kind of what a lot of people already use the iPhone for? or is there actually also a place for another productivity device or professional device that can do things that the Mac can’t do? 00:10:27 - Speaker 1: Yeah, I think this gets at the heart of the matter because I think once you put these 3 devices on one axis, the iPad’s already in a lot of trouble because the phone is already so pervasive and capable, people use it for a ton of stuff. It’s great for content consumption, and even some creation now, and the Mac desktop is uniquely powerful, and now, I would say that they’re very portable, almost as portable as an iPad. So you really don’t have a lot of space left for the iPad in that model. That’s where you get these like kind of marginal and incremental use cases like you have kids who use the iPad inside the desktops, it’s lighter and cheaper, and you have people who watch Netflix on the iPads as a bigger screen and like Adam types who take the iPad around so it’s a little bit lighter and more portable. Yes, but it’s not fundamentally different in the way that the Mac desktop and the iPhone were. Now I think there is a future where the iPad, it’s on its own axis, which is things like pencil, multi-touch, these things that are uniquely iPad. I just don’t see Apple really pressing on that front. I see that more from a few specific apps. 00:11:30 - Speaker 2: What might be good to talk about now our perspective as app developers in terms of a question that someone asked me recently that I thought was interesting to think about is what are the capabilities that you need from the platform to make your app better or more powerful or more professional. And there are some things that could be surfaced as maybe APIs that we as developers can use to make our app behave in a different way, but a lot of it really does come down to the operating system, and so for me at least, I’d be curious to hear how you both see this, but for me, I think the operating system is the weak point. The hardware is unbelievable, world class. I think it’s just the best computer we’ve ever made. 00:12:12 - Speaker 1: Oh yeah, the hardware is absolutely the best hardware that’s ever existed. It’s not even close, it’s definitely a software. 00:12:17 - Speaker 2: Right? And then the apps are weak, although I think a lot of that is Ato economics, and we inherited this whole iPhone consumer model and it makes it tricky to basically charge a reasonable prosumer price for your software, so that that’s holding it back as well a little bit. But I think the operating system itself is one of the biggest weak points. And I was really excited when, what was it 2 years ago, something like that when they forked off iOS into, so now there’s iPad OS as its own thing with its own version number and its own that sort of thing. So I was really hoping that maybe that meant I have no idea what things are like internally at Apple, but there’s a team whose job is To make this operating system, it can diverge a bit from the phone. They did that in the beginning with the dock and drag and drop, which were both things that are only available on the iPad, and then that would allow it to find that unique identity instead of constantly inheriting things from the phone, which I think are at this point more of a liability than an asset. It doesn’t seem like that’s quite happened. Yeah, and I’m curious, again, from the app developer’s perspective rather than say the user or just kind of market analysis perspective, how do we see our experience as an app developer and trying to make something for sort of professional use on this platform? 00:13:33 - Speaker 1: Yeah, well, let me give a quick list of what I see as the biggest features, and then I’ll build a little theory around that. So I would say it’s powerful multitasking, general purpose file management, payment structures and expectations, the whole payment situation, and more control over the run time in the form of basically downloading and running code things like scripting, extensions, plug-ins, and so forth. These are kind of the defining features of a desktop operating system. And I think that’s not coincidental. I think the fundamental tension here is pro use cases are almost by definition about taking multiple different pieces and recombining them in novel ways that weren’t anticipated by the original authors of those pieces, because if something was simple enough to do in a fully premeditated and pre-existing package, it kind of almost by definition wouldn’t be a pro use case, right? That’s kind of a casual thing that’s already been done before. So you need this ability to recombine pieces in ways that weren’t anticipated by the platform, but that’s kind of antithetical to how Apple thinks about the iOS ecosystem of they want everything to be curated and controlled and to be on the rails, which they have many good reasons for, but that’s what I see as the fundamental list and perhaps a theory for why they’re not making a ton of progress on it. One other thing I would add, I mean, I think you get very far with those things. I think if you want to realize the full vision of this third type of computer, you would need a lot of work on input. So an obvious thing is to have a bigger screen, more like a desktop size screen that you can put on your desk, multiple pencils, other physical input devices, and software that really took advantage of the 10 finger capabilities. Right now, most apps. Basically have one finger at a time. You have some apps like Muse where you can use multiple fingers, but you can imagine the muse approach to touch, which is use all 10 fingers being pervasive throughout the operating system in all apps and perhaps finding a way to replace the incredible speed and precision of a keyboard. That’s a hard problem. But I think you would need to tackle some of that if you want to really realize this third type of pro platform. 00:15:30 - Speaker 2: Yes, so from that list, it gets the programmability, the run time element, and that’s both individuals being able to write their own stuff, scripting or write their own little mini apps right on the device, that sort of thing, as well as something like plug-ins that basically are fairly strictly disallowed, and I do really see the tension there with essentially the security, you know, the App Store and the iOS and the mobile model Android has a version of this as well, maybe not as well done, but strict sandboxing, a little bit of a curation review process, and then just really kind of controlling what you can do. That is actually a lot of the reason the platform is good and is able to, yeah, your system isn’t bogged down by some weird ghost. Process malware is not a problem, which is partially the programmability. It’s also partially things like runaway background processes and stuff like that. So because the operating system controls all that so strictly, for example, a lot of that has to do with how the battery life can be better because the operating system has very, very strict guardrails for exactly what can run and when. And so I think a lot of that is good and some of them may need to be changed or relaxed if there is pro use cases, but even before getting into that, I really wonder if there isn’t lower hanging fruits in the form of some of the other stuff on your list, and to me, a huge one there would be multitasking, and I see that two forms. One is just the interface, and happy to say that iPad OS 15 does improve on that a bit, but it’s still could be a lot better. It’s pretty awkward, basically, to like get two documents or two. Apps side by side and copy paste between them, and there’s things with focus on the keyboard and all that sort of stuff that is just not very nice, it’s not very fluid, it’s not very memorable, it’s not very discoverable, either for, let’s say a less sophisticated user or for a pro user that’s really willing to invest, sort of it ends up being maybe a clumsy middle ground, I’m not sure exactly, but I think that can be improved on from the app developer perspective, the harder thing is something like, yeah, for example, this background process thing. So Muse we run into this a lot when we need to deal with a large data export or import or something like that. And so maybe if you want to export your entire Muse corpus, for example, in flat files, if you have a big one like I do, many, many gigabytes, that can take a few minutes. And I would just leave it running, except, of course, the device goes to sleep. If I switch away from the app, the process gets shut down after 5 seconds. Again, the operating system is very strict about how it controls that, which is part of what makes it good, but it’s also holds you back from these pro cases and we end up having to come up with all kinds of weird workarounds in order to do these things that we need to do. 00:18:13 - Speaker 1: I’m smiling over here cause I’ve long given the team a hard time about multitasking when Adam first said the iPad is the future. I’m like, is the future you can run one program at a time. Now, fortunately they’ve gotten a lot better about it, but yeah, that seems like an obvious one to get to improve. One related thing that we talked about in the podcast before, and then I’ll bring up again is this idea of kind of a technology frontier. So right now with our current sandboxing technology, you do have these sort of two choices of the wild west and viruses and out of control processes and all your battery and an app store where you can’t have plug-ins and extensions and everything is very controlled. Now, I think there’s a world where you have better sandboxing technology that allows you to get more. Of those benefits at the same time. You know, for example, if you had much more granular and accurate accounting of what bits we’re using, what pieces of power, you could finally control that or whatever, right, while still allowing good actors to do some work in the background and shutting off all the bad ones, right? Probably actually the easiest thing there would be on the payments front where all the things that we need to do with payments are well known. And I think people would be fine using Apple if like you could give refunds and stuff, right? And there’s a whole series of things that we could do to make that pretty good. And that’s the kind of work and research that I would like to see Apple doing if they’re serious about turning the iPad into a new pro platform. 00:19:32 - Speaker 2: And what’s your perspective as a designer of the app? Are there places where you’ve found either huge benefits from the platform compared to, say, designing for the web or for desktop computer or weak points in terms of things you can and can’t do? 00:19:47 - Speaker 3: Yeah, I think to me the most interesting part is actually not even iPadres, like it seems to me that, OK, they’re kind of trying to make it more like the Mac and they are borrowing features from the Mac, trying to come up with ways to make them work with touch and this whole iPad system. And eventually they’ll probably get there, like they’ll probably year after year, figure out more things to add and they’ll have more and more features. Developers will be able to make more and more powerful apps. But from a design standpoint, the more interesting question to me is what should these apps actually look like and what kinds of apps does Apple want us to build basically? And today, I really feel like it’s not enough for Apple to improve iPad OS. They kind of need to lead by example and build their own pro iPad apps and really have a shining light of an iPad app that shows everything that the iPad can do and shows the kind of interface that an iPad app should have in the minds of Apple designers. 00:20:47 - Speaker 2: Right, so one thing Apple could do if they really wanted to lead the way on the design front would be to take their first party apps, keynote, numbers, pages and use them to really demonstrate not just hey, here’s a reasonably good port of a Mac app to the iPad and it’s usable, but actually really go above and beyond and make it something where imagine Keynote seems actually like a pretty obvious example of something that’s fairly visual and tactile. Could you make it so that the keynote experience which so much better. People really preferred doing it on the iPad to the Mac or the spreadsheet actually is another interesting example where not only is that such a venerable and useful kind of staple productivity tool, but also to me it feels like pretty natural on the tablet form factor, and I often am poring over spreadsheets with I don’t know business financial models or something like that, and it’s nice to sit back in that more ruminating posture in the reading chair and what have you, but beyond just kind of. Assuming or very minor changes to a spreadsheet is no fun at all to do anything with a spreadsheet on a tablet. I feel like I could picture just maybe more emotionally, I can picture what it would be like to have a spreadsheet that’s really amazing and fun to manipulate on a tablet, even if it was not as powerful, but maybe for like the very most basic common operations that you do that it could really showcase that form factor’s capabilities, and yeah, no one’s led the way on that, not Apple. 00:22:15 - Speaker 3: Yeah, and I think there are a few layers to it, right? So one reason why I actually want Apple to build more of their own pro apps for the iPad is that I think that will make them see sort of the pain points or the gaps in the iOS iPad or interface. So I think a lot of the difficulties that we have with Pro iPad apps are actually because of gaps in the iPad OS. 00:22:39 - Speaker 2: So maybe if Apple was putting more effort into its first party apps less because they want to be successful with those apps and more as a showcase or an example of what this platform could do, then in turn they would be exposed to the weak points in the platform, things that the app developers need like background processes or more powerful gestures or other things they’ll discover those and then in turn the platform would get better. But that sort of begs the question also of What does make a great pro app or what does make a great pro app on the tablet? 00:23:12 - Speaker 3: Yeah, and one way is certainly to just look at the Mac and see what’s working there, try to bring that to the iPad. And I think sometimes that works and that’s what Apple has been doing. So for example, I think in one of the recent versions of iPad where they’ve tried to bring the right click from the Mac to the iPad. And so since the Mac has a mouse with two buttons, you can have a right click. The iPad doesn’t really have that. So instead, you have the long press on the iPad, basically. And then you get the same sort of context menu that you would get on the Mac, which works. It does sort of add another layer of more options that you can add like some hidden complexity that you didn’t have before. It’s basically the same thing as on the Mac, but it’s just a worse version of it. 00:23:55 - Speaker 1: Yeah, I agree there’s a lot of stuff that you can transliterate over from the Mac, and I’ve argued earlier that they basically should things like multitasking and a real file system and so on, but to your point, it’s only gonna get you kind of 80 to 90% there because a desktop will always have a bigger screen or will have a keyboard, which is an incredible input device. Again, I think if you want something really interesting here, you need to take advantage of the things that are unique about the iPad, which are the pencil and 10 finger input, and I just don’t see a lot of activity there outside of a few apps right now. 00:24:28 - Speaker 2: Now, since it seems like we’re falling a bit more on the negative side, let me balance that out with a bit of positivity. Also, since I’m the iPad feels like future guy, whether or not that feeling is correct or not. One example is the pointer stuff they introduced last year. So this is essentially if you have a trackpad or a Bluetooth mouse connected to your iPad, you get this little translucent circle that is your mouse cursor effectively, and it sort of morphs according to what it’s over. So, for example, if it’s over a button or if it’s over an app, it’ll turn into a rectangle shape that mirrors what it’s over, and this Sounds like a pretty minor thing, but once I used it, now going to a desktop and it’s mouse cursor feels very old fashioned, and it actually kind of boggles my mind a little bit that something so important and basic as your cursor, which you’re looking at all day, you need to spot it on the screen, you use it to do everything, basically hasn’t changed in, I don’t know, 25 years. And not to say that things need to change all the time, but generally that’s a good indicator in the technology world that we’re improving computers and they change and grow with time. And just seeing this in some ways kind of minor design tweaks on what the pointer can be, but it feels better, it looks better, it’s more functional, it’s more discoverable, and I just go, wow, this is great. Like, can we take more of these basic sort of. primitives and apply some new thinking to them and things you couldn’t do before, right, these smooth morphing animations, even something like a translucent cursor, was not possible at the time these black and white cursors that Windows and Mac and Linux use. Translucency was like a high powered graphics operation. No way it could be a part of your standard mouse cursor. Today, of course, that’s totally a trivial thing to do. Now, a counterpoint there might be people are disappointed that they are not applying this sort of innovation to the Mac and are investing it in the iPad and in fact, the Mac is the work and productivity platform. Why not improve something like pointing devices there instead? I find the contrast really interesting, especially for someone like me who goes back and forth between a Mac and an iPad in my daily work. 00:26:43 - Speaker 3: It seems to me like one of the most exciting parts of the whole iPad platform, or at least the iPad system, is that Apple does have teams like that that like they probably spent years just designing and developing this cursor system and getting all the details right and really going back to the start and not trying to just take what’s on the Mac and kind of apply it to the iPad and make it work somehow, but really think deeply about what its place on the iPad should be. 00:27:11 - Speaker 2: Yeah, I see that as the positive version of transliteration. I feel like this happens in personal life. For example, you move to a new house or a new office, or maybe if you’re changing your productivity tools, it sort of forces you to take stock of all the stuff that’s there. You had weird stuff hiding in your closets or you hadn’t really rethought how your kitchen was arranged because, you know, you just had what you had and it worked fine, but when you’re changing it. Everything, then you stop and you go, wait a minute. I’ve actually changed my cooking habits. Let me change my kitchen to match that, and you actually can end up with something much better. And so I think there is a version of this where we’re translating things like keyboard shortcuts or right click context menus or mouse cursors to this new platform, and they think, OK, well while we’re here, let’s rethink it. Let’s take the things that are really great about it. And actually even keyboard shortcuts is a good example of this to me, like this kind of system-wide default capability affordance on the iPad, which is when you hold down the command key, you get a nice pop up that shows you all the currently available keyboard shortcuts in the current context in a format that’s really standardized. You know, most Mac apps have some kind of keyboard shortcut help sheet, but it’s hard to find, not everyone has it, and it’s just always right there, and it’s incredibly discoverable because if you hold down the command key and you’re like, hmm, wait, what do I want? And you kind of pause there for a little bit, then it pops up because you’re sort of being indecisive. I think it’s like a really nice example of bringing across keyboard shortcuts are amazing, including modifier key-based shortcuts, but bringing them to this new platform was a chance to improve and enhance. And so I see that as a lot of the ways in which there’s big potential in the iPad, and what we just don’t know is whether that potential will be fulfilled. 00:28:53 - Speaker 3: And notably both of those innovations are about inputs to the iPad and accessories to the iPad, the, the trackpad and the keyboard. And to me, that’s really what’s most interesting about the iPad and when you compare to like the Mac or the iPhone. We say the Mac has a keyboard and it has some sort of mouse, and you can kind of guarantee that every Mac has that, and that’s not really going to change. Windows has some touch stuff, but that’s more added on top like no app really makes that great of a use of it. And the iPhone just has touch and they aren’t showing signs of trying to add a pencil or external BlackBerry like keyboard to it, right? Versus the iPad has really this flexible system of inputs, by default, it is touch and that’s sort of the basis, but then every user adds their own input devices to it. Some add an external keyboard to it, some have a keyboard case where it’s semi permanently attached, and then you have different kinds of pencils. 00:29:51 - Speaker 1: Now I’m realizing as you two describe all the different ways that you use the iPad, it’s kind of alarming because unlike the phone, And the desktop, where there’s basically one way to use them and the phone it’s the thumb or the pointer finger, and the desktop it’s a keyboard and mouse. It sounds like people are using the iPad in all kinds of different ways. I could come up with at least 4. There’s the muse style, 10 fingers, there’s the you’re holding it with one hand and using a 1 pointer finger. There’s the Adam Wiggins style keyboard with the iPad propped up. And there’s maybe it’s lying on a desk it’s a 4th way, right, with a pointer or a mouse like device, and it’s a benefit because there’s always different ways that you can engage with the device, then as an app designer, you kind of don’t know how they’re approaching the app, and I guess in use cases we’ve kind of had to say we’re gonna embrace this one or two styles of using it where, you know, for example, we kind of assume that you have a pencil, but I don’t know, maybe if the different input modes proliferate that becomes a sort of bigger problem. 00:30:47 - Speaker 2: Multimodal input is, I think, one of the things that makes the iPad, or maybe just the tablet form factor generally, the most exciting to me. I agree it’s a huge design problem as well as just user research problem. You can’t necessarily support every possible combination that people have, but I think that that Reflects how computing is changing for humanity overall. I mean, it wasn’t that long ago when you wanted to use a computer, you would go into the room where the computer was, you would turn it on and wait for it to boot up, which took a couple of minutes, and you sit down and you start your computing session and you do that for some length of time, 20 minutes, an hour, whatever it is. When you’re done, you power the whole thing down, you stand up and you walk away, right? And then mobile brought this thing where it was so integrated to our daily lives. You pull out your phone, you look something up really quick on the map, or answer a text message or something, pocket your phone again, and now comes, I think I read somewhere, some statistics of people look at their phone 100 to 200 times a day, pretty commonly, and some of that maybe is social media engagement loops sending you breaking news, notifications. really need to be looking at your phone and you can talk about all the ways that that’s interrupting, I don’t know, more human conversations and whatever, but putting that whole discussion aside, I think that this thing where computing is woven into our daily lives, where if I just want to Google something quickly or look up the hours in a restaurant or pull up a note on something, I can do that quickly and return to what I’m doing in context. I use that all the time from everything from looking up something with one hand while I’ve got my baby in the other hand, you know, when you’re out in the world, all that sort of thing, and I really like that, and the mobile platforms powered that. And so I think the iPad and thinking of the iPad in again more of a work productivity setting, it’s less about just whip it out and do something quickly in 5 seconds and put it back in your bag, and more than I’m here in my office, and I’ve got the iPad with the touch capability, but it’s also got this really nice hardware keyboard. I’ve got the trackpad, I’ve got the stylus, I’ve got voice input. I use the dictation. Not hugely, but sometimes I’ve got my AirPods and I can listen to things. So basically there’s all these different ways I can interact with it. I’m moving around the room, I may carry it into another room if I’m in a meeting with someone, and the laptop, I think, kind of for all its mobility, it inherited that desktop. You sit down and you’re in one posture, and that’s sort of the position you’re in, and it’s this integrated to life. And that’s sort of related to or overlapping with the multimodal input. For me, it’s just a much more creative, comfortable, fun, I don’t know, it’s just like, once you’re there, you can’t go back, but then you have to go back because you can actually do most of the things you wanna do on this platform. 00:33:36 - Speaker 1: No, totally, that to me was the magic of the iPad. It wasn’t the cursors for me, Adam, but it was the direct manipulation of the iPad with my hands. It just felt so human in a way that the computers and even the phone never did. So yeah, plus one on leaning into that for the future of the iPad. 00:33:58 - Speaker 3: I think this is another case where the iPad software lags behind the iPad hard, where you have all these different input devices. You have touched on the iPad, the pencil, the keyboard, draws a trackpad things, and you can really mix and match them. You can use the pencil in one second and switch to the keyboard in another, and it all works great. But then on the software side, they still kind of feel like different modes. When you use the keyboard, you are probably editing a text field somewhere. When you use the pencil, you’re on some sort of canvas sketching area. And as soon as you go outside of that, the pencil only emulates touch, basically, like it doesn’t add anything to the experience. So that’s why I would hope that Apple advances iPad OS in a way that you can really combine these and say, press a key on your keyboard while touching something or while doing something with a pencil. And that’s also why I think it’s important that they start building their own pro iPad apps because in the end, that doesn’t only need to be reflected in the system software, but also in every app and you just kind of need to come. To expect how these different devices that you can use with the iPad really interoperate and not just uh stand for different modes. 00:35:08 - Speaker 1: Yeah, I think this is an incredibly rich area. I really hope we see more work in this, and I would emphasize that it’s a lot of work. Like we have a multi-year research program going through ink and Switch, and now Muse, like, how do you use more than one finger at a time, right? Just that alone is a huge deal and doing it in a way that’s responsive and accurate and so on. And so I could imagine teams working on this for years to really bring that vision to life. 00:35:34 - Speaker 2: The one thing that often comes up when folks are talking about the future of the iPad is whether it will or whether it should merge with Mac OS. So there’s something that happened a little bit in the Windows world, for example, the Microsoft Surface hardware, which is one of my favorite tablet stylus form factor hardware pieces. But of course it runs Windows with all the baggage that entails, and they have found ways to merge the touch and the stylus and the mouse cursor that I think are not entirely successful, but you see where they sort of brought together those platforms and those paradigms in their way. And many have argued that Apple is doing something similar. They’re on a long, slow progression whereby, for example, adding things like trackpad support to the iPad or you look at something like the control center in Mac OS Big Sur and has these very big kind of touchable chunky things that look like you should touch them with your finger, but In fact, of course you can’t because the Mac doesn’t have a touch screen, but at the same time, I think Apple’s been publicly on record saying no, we’re not planning to merge those together, so I’ll put the question to both of you, do you expect that as a thing that will happen? And then separately from that is the thing you would like to happen or that you think it’s a good idea? 00:36:50 - Speaker 3: So to me, it kind of comes back to the question of what Apple wants the iPad to be and what really is the core of the iPad. And there are sort of a few possibilities there and it kind of worries me that we still don’t know what it is. So one possibility is that it’s really about the simplicity of the US as we talked about that it just has more restrictions and it’s just something that is a simpler version of what the Mac does. And in that case, I don’t think it can replace the Mac. Then they are clearly positioning the iPad as something that is more approachable and less complex as the Mac, so the Mac has to stay where it is. Although then I would also argue that Apple could invest into the Mac a lot more and actually go into the opposite direction with the Mac and make it a lot more complex and say if you don’t like that, you can always go to the iPad. 00:37:37 - Speaker 1: Yeah, I see it similarly, I would break this into two questions, which is, does the iPad grow to support pro use cases, which means things like really powerful multitasking, powerful file system, run your own code, things like that, as well as all the input stuff that we talked about. That’s question one. And question two is, does Apple want to continue to support pro users? So there’s a world where the iPad continues to not support pro use cases, and then kind of part B of that is Apple could continue to support pro users through the Mac, or it could basically sunset the Mac and say, you know, those folks are cool, but it’s a relatively small piece of the market. We’ll let Windows and Linux deal with the weird like audio editors and stuff and other normal people can use iPads and iPhones. My bet for the first piece is that I would love to see them turn the iPad into a Pro Tool, as we’ve talked about, that’s a huge amount of work, it’s a long path, so it’s kind of hard to predict that they will do that. It’s kind of hard to imagine them giving up on. The Mac because those users are such a keystone piece of the ecosystem, among other things, it’s all software developers. That would seem to be a mistake to me, but who knows, maybe there’s just so much money in the iPhone, the iPad that they can get away with it. But I don’t think that they will do is they won’t get pro users to use a non-pro tool. Just won’t happen. People use our platform as they have in the past. To be clear, the future that I want to see for the iPad here is that they make a 24 to 30 inch version that has all of these powerful features and that can replace or appear to the Mac desktop. I think they could do that if they want to. It’s just given how things are going, it’s hard to predict they will do that at this time. 00:39:10 - Speaker 3: Yeah, I think that’s a really important bridge basically that Apple could cost. Right now, yeah, iPad is the super mobile device and everything about it, including the different inputs you can use with it. I kind of built towards. OK, you can hold it in your hand, you can have it at your desk, you can have it on your couch, and you can switch between those within seconds. And I think that’s part of the really big difference that right now iPad is a really mobile first device and I could very well see Apple deciding, OK, that is what iPad is about and we don’t want to make it a 24 inch or even like a 20 inch, 16 inch device because then you can’t really hold it in your hand anymore. And that’s really like the line we draw between the iPad and the Mac. 00:39:50 - Speaker 1: I also think, by the way, if this gets a little bit beyond the iPad, but I think if Apple chooses not to pursue this future of a pro tool for the touch surface class of devices that someone else could do it. So, you know, someone could go buy a 30 inch touch screen. Those are becoming increasingly available and write the software and plug it into Windows or something. I guess we’ve kind of seen Microsoft try that a little bit with their line of what’s that called the Surface hub, surface, yeah. I think it would be a real shame if that future wasn’t pursued somehow, so if Apple chooses not to do it, hopefully we’ll find another way. 00:40:25 - Speaker 3: And certainly I think it would help Apple embrace sort of the general purpose nature of the operating system, because it doesn’t make sense on a 24 inch screen to have a single device, and it doesn’t make sense anymore to use it on the couch. So you want to have it on a desk and you want to do things on it that you do on your desk, which are naturally more complex interactions. So in that way, I think it would be really exciting for Apple to build a larger iPad, even for the people that don’t want a larger iPad, like they would probably still benefit from the development that the iPad gets out of it. 00:40:59 - Speaker 1: There’s an incredible endgame here where what was originally iOS becomes adaptable from the phone to the iPad to a Pro desktop class tool, and if you were able to figure that out, if you were able to succeed in that research project, you could have this incredible fluidity between the devices, maybe even using the devices together, for example, your iPhone is on your desk as a little sidecar with some extra controls while you’re working on your main iPad plus. 00:41:27 - Speaker 2: Yeah, I love that. Maybe that’s extending the multimodal input even a little further, as sort of a multi-device world, which I think we already kind of live in, you know, you’ve got your Kindle, you’ve got your fitness watch, you’ve got your computer, there’s other kind of devices that float around in your home or your office. And I always like this kind of Hollywood thing with uh Tony Stark on his lab where he’s got his like robot assistant he talks to, but he usually has multiple screens and this is basically just a Hollywood thing, but in some ways it also is compelling that the room is the computer and the screens and the different devices, whether they’re touch screens or holographic displays or voice interfaces, they’re all just different affordances into that same computing medium. And I think in a way, we kind of have a version of that now, in the sense that we do have lots of devices floating around on our desks and in our homes and so on, but they don’t coordinate that well with each other, so yeah, you can imagine that there is a version of iOS that flows across all of those different size screens and different form factors, and they work seamlessly together, that could be pretty cool. 00:42:35 - Speaker 1: It’s so rare that when it does happen, it’s such a shock. I remember the first time I experienced the Wi Fi flow where you try to log on on one device and it like another device that has the login, sends it to the other device. Oh my god, that’s so cool, right? But you can imagine that for everything. Yeah. 00:42:52 - Speaker 3: Yeah, and I feel like the fact that Apple is putting that many resources and making the devices, the Mac, the iPad, and the iPhone work together really points to me more to the fact that, yeah, they aren’t trying to replace the Mac with the iPad. Like they are seeing the iPad as a 3rd device and they want you to use it even right next to your Mac and like they showed, I think with the iPad OS 15 and the next Mac OS version, you can kind of use your MacBook trackpad and actually move the cursor over to the iPad and then control your iPad with it and also use your MacBook keyboard. And it really, at least from the demo, it really seemed seamless. And to me, that’s really the exciting part of what Apple is doing, where if the iPad is a 3rd device that I’m supposed to use next to my Mac, then they can actually figure out these specific use cases that the iPad is good for, and they aren’t forced to bring down everything that the Mac does to the iPad, but they can say, OK, you you have the Mac, you also have an iPad. And we can figure out exactly what interface works best for each of those and maybe even more importantly, which use cases are best for each of those. 00:43:53 - Speaker 2: Now obviously here we’ve spent plenty of time speculating about what Apple will do, what they should do, what their opportunities are, and that’s, I think a lot of folks in the industry because they are such a powerful player, and certainly anyone who is an app developer, you’re necessarily very much playing their game, and so what Apple, who never, you know, announces ahead of time their roadmap or their intentions, where they’re going, becomes a source of maybe endless speculation. But I think it’s useful sometimes to stop and just think, OK, separately from what Apple will or won’t do, what is the computing future that we want? We got to this a little bit with Rasmus Sanderson and that episode talking about some of his vision for Playbit, but notably here at Ink and Switch, Mark, you and I worked together along with a bunch of other great folks on various research projects, and in a way, we saw them circling potentially a larger vision. I think at the time we called it the programmable personal knowledge manipulator, not that catchy, I suppose, but, you know, you gotta start somewhere. And we envisioned something that had a form factor similar to an iPad or a surface, where you have the tablet and the stylus and the 10 fingers for touch, but potentially other kinds of input had maybe, you know, local first storage, so you have a powerful file management like you do on the desktop, and more suitable for collaboration in this sort of cloud world, and that furthermore, it’s fully programmable, and then maybe the base device doesn’t. Do a lot. It doesn’t come with a lot of apps, it doesn’t have a lot of features, but you could sort of write your own apps and browse the web and sketch, and that something like that could be a very fun and powerful new kind of pro platform. Again, not necessarily trying to replace the desktop, but a way to take these computing capabilities that we have with modern hardware and everything that’s been pushed forward by the mobile revolution and bring that to the creative tools space. And we even put some work into trying to bring those pieces together into a prototype, but we actually determined it was just too early, too hard, probably too big for any one company to do. So that’s part of where we kind of split out the different pieces, and one of those was Muse. We said, look, the best way to explore this kind of multimedia canvas side of things is on an existing platform and that platform was the iPad. But I still have that shining vision floating in the back of my head, and I think it both leads me to, I’m doing the mental diff between where the iPad seems to be going and that vision that I have for that programmable knowledge manipulator that I want. And the ways in which the iPad is changing to be more on that trajectory versus not, makes me happier or less happy with the iPad, but then maybe separately, like you said earlier, Mark, maybe someone else needs to build that, and it’s a huge undertaking, but maybe Apple isn’t the right company. Maybe they’re a consumer company now, not a creative tools company, and maybe something, another company or another team or a set of companies or open source project, I don’t even know, that could really be focused on that audience and that sort of set of use cases could do something pretty special. 00:47:00 - Speaker 1: Yeah, and I think it’s interesting because there don’t seem to be a lot of people really working on this. This is problems like the multimodal input problem, including with 10 fingers, the sandboxing and security problem while maintaining power and flexibility. There is not a ton of work on this that I know of. And so the flip side of that is that if you do get a small group together and work on it for a few years, you can pierce the frontier, you know, you can make a contribution to the field. So I’d love to see more people try that. 00:47:28 - Speaker 3: Yeah, and I think it’s kind of where change needs to come from. I think Apple does have like a ton of really good research groups that do this kind of research, but it all stays within Apple and they’re famously secretive. They certainly don’t show it, but a lot of it also either takes like 10 years to develop. I think a lot of stuff like even the MacBook Touchar that nobody really likes took like 10 years to develop from like the first research stuff. But like 90% of what they come up with will never see the light of the world simply because. Apple with the iPad and especially because it’s based on the iPhone, it’s now at a point where it is such a popular and widely used device that they can’t really change anything fundamental. The only thing they can do even with the iPad is to add stuff on top of it, which might improve things somewhat, but they will never really be able to change the game. And so what I would really hope for is, yeah, we basically need some sort of newcomer that doesn’t have any legacy to worry about. And can really just start fresh, but that gets more difficult with every year basically because there’s so many more things you need to do and the ecosystem that Apple and Microsoft and Google have just grows bigger and you can’t really compete with it. 00:48:42 - Speaker 1: Yeah, it is tough. It’s why I think this idea of research prototypes was so important out of the lab. You need something that’s higher fidelity and more information than just like theorizing about something and drawing some sketches, but to turn it into a production product that’s integrated with an existing platform is an enormous amount of work we’ve seen with Ms even to do a tiny slice of it, as many years, right? But these research prototypes, they’re real software, they’re working, you can play with them, but they focus on one or two dimensions. And so that’s perhaps a way to tackle that. 00:49:14 - Speaker 2: Well, before we go, coming back to the iPad, if you had a wish list item, a genie that could grant one wish for something that could be added, some major change to the iPad as a platform, say, 3 years out, what would that be? My answer to that would be developer tools. There was a great terminal and the ability to write your own apps directly on the iPad and run your own apps and possibly even give them to your friends. And finding some way to resolve that problem of you want that sandbox security, and you want the app Store curation that protects against the wild world of difficult malware, but at the same time gives you the freedom and flexibility to program your own computer, and I think that that in turn would kind of solve. A lot of the other problems, because then the developers could start to do more of the innovation and discover more weird interesting use cases. If they could do that and the thing that is not constrained by Apple review because it’s just for yourself and a couple of friends, then I think some very interesting things might emerge from that that could then solve a lot of the other problems. 00:50:21 - Speaker 3: For me, I think it would be text selection. It’s sort of the underlying cause of so many small frustrations that I have when using the iPad. And basically, whenever you work with text, you kind of need to select things and move the curse and it naturally doesn’t really work with touch. And so either Apple needs to figure out a way to just make it work more precisely with Touch, or maybe even leverage all the input devices they have and make better use of the pencil and the keyboard and just let me use those in combination with touch to accurately select text. 00:50:52 - Speaker 2: Yeah, probably that area of things might even be bad enough that just declaring bankruptcy just completely remove everything with the current touch base text selection, which is just doesn’t work well, has never worked well, and instead start over from scratch, and maybe that’s, you can’t even select text at all with touch and you need some other input device, or maybe they just have some wild new idea for how to do that. But yeah, what’s there now is not good. 00:51:19 - Speaker 1: Well, it’s tough for me to pick just one, but a very practical item is multitasking, and there’s a very simple test here, which is the multitasking needs to be good enough for me not to be so mad that I agitate for us to write our own in-app multitasking in use. We’re still not there yet, but I believe we can do it and thereby avoid a bunch of work on our part. 00:51:43 - Speaker 2: Well, let’s wrap it there. Thanks everyone for listening. If you have feedback, write us on Twitter at @museapphq. You can reach us on email at hello@museapp.com, and you can help us by leaving a review on Apple Podcasts. And while we’ve had our gripes and concerns about what the iPad is today, where it might be going, I think clearly the fact that we’ve all chosen to devote our careers here in the moment to building exclusively for this platform means we see its potential, that it’s one of the most interesting. Fast evolving places in computing right now and certainly for building thinking tools it offers new capabilities that I think are not available anywhere else. So I hope you both still feel positively about the potential for the iPad because well, you’re betting your day job on it. 00:52:32 - Speaker 1: Absolutely we criticized because we care and we love the platform.
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: Curious is interesting because of course you can describe your mindset as a user of Muse, but it could also apply to the software itself. And I do think there’s an element of Muse is a little bit weird. It’s a little bit different, it’s a newcomer, and it takes an approach that no other app has really taken before. 00:00:22 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for thought on iPad, but this podcast isn’t about Muse the product, it’s about Muse the company and the small team behind it. I’m Adam Wiggins, joined today by Mark McGrenigan. Hey, Mark. 00:00:36 - Speaker 1: Adam, so exciting times for you? 00:00:39 - Speaker 2: It is. I’m expecting a baby very soon. 00:00:42 - Speaker 1: Congrats. 00:00:43 - Speaker 2: And while there’s many things that make pregnancy its own journey both emotional and physical, I will say that one of the big challenges and one that’s emotionally fraught is picking a name. And I was familiar with this from picking names for products, companies, I don’t know, software libraries, but something that is going to affect another human whose opinion you cannot consult on it for literally the rest of their life. Oh, it feels like a lot of responsibility. 00:01:10 - Speaker 1: Yeah, I bet. 00:01:11 - Speaker 2: And maybe that also connects to our topic today, which is brand. 00:01:15 - Speaker 1: Yeah, brand is not necessarily the native territory for you and me. We grew up in the engineering and product areas mostly, but we’ve been, especially you have been getting into this, I think more as we’ve gone to start this business. So where are you at in your journey on brands? 00:01:31 - Speaker 2: Yeah, I think it’s been a long journey. I definitely started from maybe a place of assuming brand was, I don’t know, a logo or something and not the hard or important part of a business. And one of the things that turned me around a bit on that or opened my eyes, I guess, to the importance and potential power of brand was reading history, as always, that’s something that gives a lot of context for me. There’s a book here called Brand New and it essentially walks through some historical examples, including the company that was the first real department store in the United States, or some more recent history like Dell. The story that really struck me, I think was Heinz, which nowadays has a very strong brand for ketchup. They got started at the time when, and hopefully I can remember the story correctly, it’s been a number of years since I read the book, but basically they got started at a time when mass produced foods were first starting to become a thing that was possible thanks to the US being connected by rail transit for the first time. And apparently what had happened was Heinz was originally a pickled foods company, and apparently this was a big problem to solve because this was something that American families and traditionally the women would end up being in a position where they would do a bunch of essentially pickling of foods for the winter, and it was hugely labor intensive and not a lot of fun and whatever, and at some point someone figured out that, OK, you can send traveling salesmen around to sell pickled foods. But the problem with that is you’re buying a product that you won’t use for many months later, and so it would turn out that a lot of times these were shady and they would open it up in the wintertime and discover like sawdust inside. And so this was essentially a problem to solve if you want to take advantage of this potential at scale food business. But how do you build some trust in the same way that you would have trust with your local merchant where if they sell you something bad, you can go back and complain to them. And I guess Heinz was one of the pioneers here of thinking, well, I’m just going to literally put my name on the label in a very not only a name that’s always kind of the same, but a very recognizable typeface or logo or logo mark, and I’ll put that on there and I’ll work really hard to make sure the quality is high and build a reputation and connect that to the name and the logo and even the shape of the jar, and that was immensely successful and built the food empire that exists today, and now of course that’s totally standard practice, but at the time that was a huge innovation. And so thinking of brand as a technology, you use the term social technology sometimes. I don’t know if this would fall into that category, but that was an unlocking thing. And of course mass produced food, while we have some negative associations with that health wise nowadays, it was a huge unlocker for basically low cost food and more people being able to have full and healthy diets, um, which is, you know, for most of human history, getting enough food has been one of the primary concerns for most humans. So yeah, that historical context helped me think, oh, OK, maybe it’s not just kind of a logo. 00:04:30 - Speaker 1: Right, there are actually a lot of good and important reasons to have strong brands that ultimately will benefit the users and consumers. 00:04:37 - Speaker 2: Yeah, now, of course, I like to dig in on the kind of what’s that core thing, what is a brand ultimately? Is it a logo, is it a name, would be more like a reputation, like we’re describing with Heinz, how do you think about that? 00:04:50 - Speaker 1: I guess I tended to come at it from the reputation, character, voice, personality, angle, in part because I’m partial to these small giant type businesses where they often lean on that aspect of it a lot. But I understand there’s also the aspect of color and fonts and logos and names, and I’m just not as familiar with that, so I have more to learn there, but I’ve always been fascinated by the character side of it. 00:05:11 - Speaker 2: Hm. Yeah, I think for me at least that is the heart of it looking past the surface, you know, saying that a brand is a logo is kind of like saying writing software is typing on a keyboard. It’s like there’s some literal sense in which that is true, but it really misses the essence or what’s at the heart of it. Yeah, I think it was one of Richard Branson’s books. So this is a fellow that’s very good at his own personal brand, kind of flamboyant Playboy style personal brand, as well as his sort of business conglomerate, which is Virgin, and he talks about brands as being a communication on what a person can expect from your product or service. Hm, yeah, I like that. And one example he uses, that’s obviously a very strong brand is Pixar. Pixar makes a certain kind of movie, and I think that brand is so strong and so well known that if I say to you, hey Mark, there’s a new Pixar movie out, you want to catch it with me, you don’t need to know anything about the movie, even what it’s called, but you instantly have a picture in your mind of what you can expect, and maybe that thing is something you’re in the mood for, not in the mood for, but you know what you can expect, and that’s the power of brand. 00:06:20 - Speaker 1: Yeah, and you can see how that would help both in the classic marketing sense of it gets people excited or interested or aware of what you’re doing, but also in the more tactical sense of addressing the information asymmetry, you’re going to buy some ketchup, like you need to know that it’s going to be actually be there and be of high quality and not going to make you sick. And that’s something that people encounter all the time, especially with our very global and distributed commerce now, like you need to buy a pair of running shorts. You can expect that if you buy it from Nike, it probably has some property, it’s probably pretty well made and it’s gonna fit well and things like that, where it’s not necessarily the case for the default pair of shorts that you buy online. 00:06:54 - Speaker 2: And Nike is an interesting example and certainly often listed as, you know, textbook case of extremely strong and well executed brand over the course of many decades, and part of that is that Nike swoop and the name, which are both good and somehow seem to capture some things about being a runner or an athlete or, you know, who their target customer is. But more than that, I think it’s also what they stand for, so. Yes, Nike presumably stands for quality athletic goods, but it’s really that just do it message and the imagery that they have used consistently over the years that says it’s about celebrating human athleticism and that individuals can strive. be their best self physically. So for a certain kind of person, say you’re a runner and you enjoy that process of pushing yourself to achieve more physically and that incredible feeling of pushing past your own boundaries and what that can mean for you personally, and you see this imagery that resonates with you and you think, OK, this company stands for something that I personally believe in or has been meaningful in my life. 00:08:01 - Speaker 1: Yeah, this comes back to the idea of aspirational marketing, which I think we’ve talked about before and it’s actually pretty, I think, effective and resonant in the tools for thought space. People want a combination of permission, vision, architecture, name around how you think better and have better thoughts, and the tools for thought movement, I think, has successfully tapped into that. So it kind of seems like it shouldn’t be that big of a deal just to say you can do it, but actually it is a big deal, and there’s a lot that goes around that to make it effective for people in their minds. 00:08:28 - Speaker 2: Yeah, well, coming to digital products, do you think there’s particular products that have a brand that either speaks to you or just is really effective at communicating what people can expect or a particular vibe? 00:08:41 - Speaker 1: Yeah, so I can give you a few examples. There’s perhaps the most obvious suspect of the high-end premium brands, stuff like Apple, and I don’t think we need to elaborate on that too much, but I think that is an effective brand for me. Another one would be, again, the small giants, so I think 37 Signals would be the classic in that space, company that’s very vocal and frankly kind of loud, but they’re also very clear and they stand for something. And if that’s something that you also believe in, that’s a very effective brand for you. And if you’re not, it kind of correctly repels you away. And you shouldn’t partake in their products. 00:09:13 - Speaker 2: Yeah, maybe being a bit polarizing is a desirable quality in a brand because it lets you know it’s a beacon for those who are drawn to that message or that set of values or that character, and it repels those who are not interested in that, and that’s actually what you want for business. 00:09:28 - Speaker 1: Yeah. Another category might be these brands that are extremely direct. So Duck Duck Go, I would put in that bucket. It’s like search that’s private. Tar snap is another one that I love in that space. I think their tagline is backups for the truly paranoid. And unless you fit in a very specific niche, that product doesn’t make any sense to you, but if you are in the niche, it makes total sense and it’s very appealing. 00:09:50 - Speaker 2: Yeah, that’s the ideal thing is that the brand conveys either on your first encounter of it or more just anything that you come across if you have consistency in the materials that you’re presenting, that should, for the target prospect for the right kind of person, they say this resonates with me. I want to learn more. Yeah. 00:10:08 - Speaker 1: What about you? What brands come to mind? 00:10:10 - Speaker 2: Yeah, when I was thinking about this question, one that came to mind was slack, and I think one of the places they managed to be really effective is in projecting a playfulness. And that is really what maybe sets it apart from all the group chat that came before and in general from work and productivity products. Maybe this has actually become more commonplace since they have come on the scene. Maybe Mailchimp has a similar thing, a little bit of reverence and fun, but for something as practical as an enterprise communication product. And you just associate with that, OK, you need it, but it’s not really gonna be particularly fun, and slack really turns out on its head and makes your work communication into something fun, a little silly at times, playful, taps into some of those consumer social media dopamine hits, which, you know, you can debate the merit of that, but again, it presents a very differentiated and strong character relative to other products that solve the same problem. And I was contrasting that to there’s plenty of other products that I think do not have a particular strong brand in the sense we’re talking about. One that comes to mind for me is Trello, and I really like Trello. I think it’s a great product, it’s fast, it’s reliable. I’ve been using it for many, many years for all kinds of business ventures and personal projects, but even so, if you ask me, and I don’t know, they’ve got a pretty good name and they’ve got like a cute mascot, but if you ask me what does Trello stand for, I would just kind of think, I don’t know, being organized, I guess. So it’s just a product that solves a problem, and that’s fine. I don’t think every single company and every single product needs to have some strong mission or some strong character, but it’s interesting to contrast those two. So then coming to the muse brand, vibe, character, whatever you want to call that, I was reminded of when you and I were first brainstorming this a bit along with our other colleagues back when we were getting started with the business, and we sort of looked through some different products that we thought had good brands, and in particular characters that maybe fit a little bit or were similar to what we wanted. One that stuck in my mind is a Go player. Sort of a Go program slash assistant just for desktop computers called Sabaki and their website is very simple. It just says, you know, it’s an elegant Go board and an SGF editor, which I guess if you’re a Go player, maybe you know what that means for a more civilized age, right? So they’re telling you practically what it is that it’s this editor and, you know, game board, but they have a couple of words in there like elegant and civilized. There’s a Star Wars reference in there as well. And then visually, you know, they show a screenshot of the product, that’s the main thing you see. But there’s sort of this mood imagery on the side, which they have a wood table with some, I guess these little clay or wood jars that contain go pieces. So it’s obviously relevant to the product, but it’s also something that just gives a vibe, right? It’s a little bit relaxed and elegant. And there’s a little bit of humanity to it, and it’s a small thing, but to me that really makes a big difference from the, you can imagine a version of this that was slightly more practical. You take away those little mood images and you just have the screenshot, you take away some of the adjectives there, like elegant and civilized, and you can see what it is, and maybe people would still want to buy it, but it doesn’t really convey a character, right? If you had to characterize the muse character and the brand vibe based on either what we thought we were gonna make it back then, or maybe what you think it has evolved into today, what are some words that come to mind? 00:13:44 - Speaker 1: I think thoughtful is a big one. You people are spending a lot of time in use thinking and striving to come up with better ideas. I think high quality as well, in the sense of it’s a tool that you spend a lot of time with, and your hands are on it constantly, and you want the sense that it feels good while you’re working with it. 00:14:03 - Speaker 2: Yeah, those two are on my list. Two others that I often reach for, one is serene, and we sometimes use calm or something like that, but to me this is in contrast with the, I would call it franticness of a lot of digital products of the digital age, maybe, you know, social media is a good punching bag there, but In general, I feel like software products, even productivity tools are very often trying to grab your attention and being pretty demanding with what they want you to do and calls to action, and there’s a million things and pop up dialogues and do this, do that, and one thing I think we always try to do is be more relaxed, calm, serene, and we try to convey. That through websites, through any materials we do, but then in the product, right, that’s something like we actually had this come up on the team just today. There’s a situation, a rare situation where there’s a certain circumstance that an easy thing to do or an obvious thing to do would be to pop up a dialogue, but that feels very kind of demanding and I don’t know. That’s the sort of thing, at least I’m against, and I wanna see how far we can get at the moment. There is nothing you can do inside music that will pop up a dialogue that demands your attention, if you don’t specifically ask for it, and I wanna see how long we can keep it that way. Nice, yeah. Now the one that’s on my list is Curious, and probably it helps, you know, I think there’s some degree to which the character of your company comes from the character of the people who started it. You know, we are all curious people, so some of that is just who we are. But I think it also fits with, you know, you have this tool that is designed to help you learn about the world, solve problems. To explore, to understand something and curiosity, I think we even mentioned this on the last episode there talking about how to spot good ideas and how to have good ideas. The curiosity is upstream of having good ideas, and so that naturally fits with kind of the purpose of our product, and additionally, we try to, through other means, live that. A good example of this is that we have our product newsletter that goes out once a month, and it’s mostly stuff about what we’ve been working on and what’s new in the product, but I always try to include at least one or two small sections. It’s an interesting book we’ve read recently, or a podcast that we like or an interesting new tool, and that just kind of fits with this sense that it’s about more than a laser focus on the thing that’s right in front of you. It’s a willingness to see the wider world and just be open to possibility and have an open mindset. 00:16:30 - Speaker 1: Curious is interesting because of course you can describe your mindset as a user of Muse, but it could also apply to the software itself. And I do think there’s an element of Muse is a little bit weird. It’s a little bit different. It’s a newcomer, and it takes an approach that no other app has really taken before. And I think that kind of pervades the product, the marketing, like we don’t quite do stuff exactly like other people do, and a lot of our users, I think, appreciate that. 00:16:55 - Speaker 2: Hm, yeah, exactly. Maybe the product itself walks its own path, and that in turn, maybe attracts people who are also willing to take that on the road, take the road less traveled, you might say. Yeah. Now when it comes to the practical elements of what is a brand, I’ve talked about the vibe or the character, but what in practice are the pieces that make a brand. Once I discovered or read about this history and started to look closer and realized that a lot of the products that I like or companies I respect the most are ones also with strong brands, and then that leads into, OK, what actually is a brand, not in the sense of character, but in the sense of what are the pieces. And we touched briefly on the kind of the visual element there, and we can speak to that a little bit, but I think the really big one, or even a almost the starting place of everything else is name. Hm yeah, names are so tough. Names are important and challenge to get right and not something you want to change too often if you didn’t get it right. The one place I found, once I got curious enough about what makes a brand, I wanted to dig in a little bit on the practicalities of it, looked around for books to learn more about that. And there’s a few different ones, but I think one of the seminal ones for me is, I think it’s a pretty old book, might be from the 70s or 80s, called the 22 Immutable Laws of Branding. And here it’s talking about pretty old school stuff, but they make this list right from the start of what the author believes are great brands, and that’s Coca-Cola, Kleenex, Jello, Band-Aid, Rolex, BMW, FedEx, Nintendo, Tide, Heinz is in there, Visa. And it’s notable that for many of these examples, I’m not a customer and never have been, but I instantly know the company, I know what they sell, I know what it’s going to look and feel like, and in many cases I have a sense already of character, what kind of person would buy products from this company, for example. 00:18:46 - Speaker 1: Yeah, and apparently those have stood for several decades anyways. 00:18:50 - Speaker 2: Yeah, exactly so. And this book kind of rattles off a lot of the, it’s called the practical mechanics, which include the name side of it. And for example, the author makes the point that you want something short and punchy, it’s memorable, and it needs to be in this kind of middle ground between not too generic, but also not too weird. So he gives some good bad examples. So a good name from his point of view for laundry detergent is tied. A bad name would be the Procter and Gamble home laundry detergent. Now, of course, you can make a brand on maybe not a great name. I think a good name makes it easier for people to remember you, makes it easier to brand things, but ultimately you can attach a company reputation and a vibe and a character to any name you choose, but certainly something like an abbreviation is not great. Some other points this book makes is that the brand is not the name of the company, it’s the name of the product, and it’s really important, and the only one that really cares about the name of your company is your team, and that’s fine, and you know, you do want your team to be motivated, but ultimately you should be really thinking about customers and how your brand is filling a space in their mind, and a test for this almost linguistically is People use it as a noun or a verb, he says, basically it’s what’s in the box. You say, I’ll have a Coke. You don’t say, I’ll have a flavored beverage from the Coke company, right? You say, I’m going to drive a BMW. I say, let’s play a Nintendo, or you can do the Verb version, which I think maybe is more common a little bit in the tech world, which is, yeah, I’m going to Google it or FedEx me that document. So that’s a brand. 00:20:28 - Speaker 1: So what would be some examples of getting this wrong and confusing the product of the company? 00:20:32 - Speaker 2: Yeah, so there’s a few examples of this. One of the most notable ones that unfortunately is pretty prevalent in the tech world, I think, is something where you put the company name and then the product name after. So in the Microsoft suite you’ve got Microsoft Word, and this is actually a clumsy name because you can say Word with a capital W by itself, and many people will know what that means, but it’s a Little too generic, so you kind of need to prefix it. Well, it’s MS Word or Microsoft Word, but now you sort of have two things because there’s Microsoft, a company which has its own identity, and then there’s this piece of software. And the interesting thing there is a contrast to another product in the same exact suite, which is Excel. Excel is a great brand name because Excel is what you buy in the box back in the days when you bought software in boxes. Now it’s, I don’t know what you download or whatever, and you say I’m going to use Excel, or let me put that in Excel, or let me check my Excel spreadsheet, so that does not have any of that confusion. I think Google’s also quite an offender here. Google Docs is one of the most awkward product names of all time. In my point of view, it’s hard to use in a, let me put that in my Google Doc, I guess, my Google Docs doc. It’s just, yeah, it’s terrible. But Google, as the search, let me Google that and I’ll look up a Google search, that works great. Yeah. And notably also Gmail, Gmail’s a perfectly good brand, and yes, Google is in there, that G is in there, but it sort of is, you don’t have that confusion of like pasting these two things together. Gmail is its own brand that stands essentially alone. 00:22:10 - Speaker 1: OK, that’s interesting. So naming the thing that’s in the box and not the company. What are some of the other things in this book that were most surprising or interesting to you? 00:22:19 - Speaker 2: Yeah, another point that this book makes is talking about how you want to think of owning a piece of mental real estate with your brand, and that you stand for one thing, and that that thing should be pretty simple. So, it gives the example of FedEx. So FedEx stands for overnight. And apparently this was actually kind of a pivot for them. They used to be more of a general purpose mail provider, they competed with UPS and the post office and so on, on that basis, and their big breakthrough was, and actually there’s a great book, I have to look up the name of that for the show notes, which is kind of an autobiography by one of the FedEx founders of the early days of that. They basically made a kind of pivot into overnight as their focus and something where when you think of FedEx, you think of getting something to someone reliably really fast, like the next day. Yep. And that’s connected to their logo and their colors, and even that distinctive. The envelope that you buy to put stuff in and then you even get the reverse of that which is when something comes in a FedEx envelope they oh this is important so that shows you right there a powerful brand because they don’t just stand for male or male that’s efficient or something like that. They stand for something really specific and differentiated. And this points to a mistake that’s easy to make once you have a strong brand as you think, well, great, let’s put that brand name on a similar product, essentially expand into a new space and we can use the reputation on that new product, but you can actually destroy your reputation. If you move into a space that doesn’t feel related, and you can find yourself putting a name that owns, for example, in the case of FedEx, owns overnight, and you put it on something else that just confuses it and now you’ve essentially destroyed that real estate in the customer’s mind. 00:24:07 - Speaker 1: Yeah, the FedEx example is interesting because I think that brand has been very effective and it’s premium, it’s super fast, it’s reliable, it’s high value, and the flip side of that is you expect as a sender to really pay for it. So whenever I think, you know, I got a mail, uh, I don’t know, you know, t-shirt, if I’m gonna send a FedEx, it’s gonna be like $72 or something, you know, and so I’m always hesitant to do that, whereas if I’m sending a really important piece of paperwork, OK, sure, I’d be willing to pay something like that. But then they have now it’s like FedEx Ground and FedEx 2 day air and 3 day air and FedEx fast, you know, it’s kind of a whole thing, so it’s a little bit confusing to me. 00:24:38 - Speaker 2: So that’s names, and that can bring us to the visual or aesthetic side of the brand, and there’s a bunch of elements to that. The logo, of course, is a big one, and so here that can be your name, typeset in a particular way, is a good way to go, may also be a little mark that could be either paired with the name or use standalone. And then we’re in the iOS world where your app icon is essentially your most important logo, and that has some slightly different properties from a logo that you would put on a sticker or a t-shirt or a business card, but it is extremely important in terms of it’s the first thing people see every single time they run your software. 00:25:16 - Speaker 1: Yeah, and this area reminds me a lot of this branding stuff is a combination of memetic and emotive. So by that I mean, emotive is like how it makes you feel, of course, a big part of the brand is people aspire to or want to feel a certain way and a well executed brand can do that. But also, especially these days, the memetic aspect is very important, you know, how does it help you remember, cut through the noise, share with your friends, get transmitted, go viral, the name, the image, the fun, they all play a big role in that. 00:25:44 - Speaker 2: Exactly, and I was thinking of some examples from the tech world and notion comes to mind in terms of they have this kind of black and white illustration style that they use throughout and even their team members will often have a, I don’t know if they have an illustrator on staff whose job is just to draw people in this particular style, but it’s a very notable style. It’s not a logo. a name, but it is this visual style that you come to associate with and the black and white, it invokes kind of, yeah, printed paper or maybe a notebook or something like that and fits with their generally pretty kind of pragmatic but chill, but you know, nicely designed but not overdone, very different from the highly richly saturated colors of slack, for example. And then maybe to take a third example, which is quite different from those two would be Craigslist, which I would describe as brutalist HTML. And some of it may evolved organically in the sense of it’s just an old site, and when it was originally made, it was not put through the kind of let’s do a classic visual design past, but now it’s very much part of their brand. It says to you, this site is no nonsense, it’s practical, it’s just the basics, it doesn’t try to be something fancy or impress you needlessly, it just really is focused on this very simple way to list and look up classifieds. 00:27:04 - Speaker 1: Yeah, and I think a flip side of that, perhaps the other end of the spectrum is brands that do a lot of proof of work around some quality that they want to show. So this would be very well designed websites that gives the viewer a sense that there’s basically a higher probability that the product itself is going to be well designed if you have a well designed website. Of course, the correlation isn’t perfect, but if you come to a very well executed website, you have more confidence via this proof of work mechanism that what’s underneath is going to be good too. 00:27:31 - Speaker 2: Yeah, what’s the old saying, you can judge a book by its cover. Yeah, yeah, so that’s logo and illustration and name, but also something like the typefaces you use throughout all your material on your website and your product and your advertising, you may have a single font family or a set of font families that hang. and if you use those consistently over time, I think something like the typeface Apple has used for many years in its advertising, you don’t even need to see that little apple with the bite taken out of it. You can just see the typeset text and you already know it’s an apple. It’s something Apple related. And certainly for physical products, packaging is absolutely huge, and there’s a lot of folks who are very skilled at packaging design. I actually quite enjoy going through, for example, packaging design on Drribble or 99 designs or whatever. You can scroll through the portfolios of these folks in there, they need to work within the constraints of the physical world, you know, if it’s a can for a Beer or soda or something, they need to work with that cylinder shape and there’s practical things that need to be put on the can, but people get very, very creative with that and conveying these ideas and having a visual brand where all the elements hang together across something like a physical package, a website, a digital product that work within their medium and what’s needed for each of these different settings, but also all hang together, all identifiably part of the same universe of stuff. And for me, a great visual brand is one where in the end, it feels a bit like a flag to rally behind. Or sometimes I think of it as sort of a peg to hang your feelings about the brand on. So if the visual brand is strong, then that means that love it or hate it, it’s easy to attach those feelings and recognize right away, particularly when there’s a new product or even something like something coming out of their Twitter account or any communication that you know right away who it’s coming from and what their character is, and you draw up those feelings you may have about the brand. So I think in the end with these elements together, the right name, strong visual brand that’s conveyed throughout a set of values or a vibe that it stands for that makes sense within the product and the mission of the company and the product but also has maybe something a little more expansive, something like curiosity in relation to a tool for Thought as an example. And in the end, I think all of that can add up to hopefully if you do a right kind of almost a tribal affiliation because I think for many people when they make product purchases, they’re thinking not just does this solve my problem, but they are also thinking, what does this product say about me as a person? Are the people who make it, and the other people who buy it, are they part of my tribe? Do they share values with me, and then what will people think when I purchase this? So, in the Nike example we were using earlier, maybe if you feel like, OK, the people that purchase these products are people who care about personal athleticism and trying to push yourself to reach higher heights, and I want to be seen as a person like that as well. So, therefore, I wanna purchase these products. 00:30:32 - Speaker 1: Yeah, I think it’s a big one. It’s such a powerful force, a desire for tribal affiliation. I think both be affirming in the sense of, OK, I am an athlete, so I do want to buy from this brand, but it can also be aspirational. OK, New Year’s resolution, getting off the couch, let’s make sure I have the right vibe around me in terms of my clothing. 00:30:51 - Speaker 2: Yeah, absolutely. One of the examples, I think that was from one of the earlier books I mentioned that I found quite remarkable was Harley Davidson, I guess they’re a motorcycle company. Although again, another good example of something where I’ve never ridden a motorcycle, I’ve certainly never purchased one, and nevertheless, that name, Harley Davidson, evokes a pretty strong vibe in my mind. I feel like I know what that stands for, for sure, which says a lot about their effectiveness as a brand. Part of what they’re saying, the tribal affiliation or the what kind of person does this make me or as you were just saying, what do I aspire to be, and for them it’s very much I think about a kind of masculine but independent, a little bit rebellious, you’re out on your own, you’re taking some risks, you’re kind of dangerous. And so it may be that you’re drawn to that because, in fact, you are those things, but it could be that you want to be those things. You want to push yourself to be those things or you aspire to be those things, or you see something laudable in that, and buying, maybe not the motorcycle, but maybe the jacket or the shirt, or whatever other product that the company is selling will somehow help you make that come true or grow into that person you want to be. Yep. So we said that Muse today stands for thoughtfulness and maybe it’s a little serene and a little curious. What do you think in the future would be an expansion or an addition to that set of values? 00:32:13 - Speaker 1: Well, there’s a lot more that I want us to do around developing and articulating the character of Muse, this personality small giants idea, and we’ve, I think, done some of that with the podcast, but there’s a lot more to do with writing and video. But I think an interesting fulcrum for us over the next year or so is going to be the question of privacy. We came into Muse with this hypothesis that privacy is really important and perhaps we would even elevate it in terms of our brand. And that’s kind of the path we’re pursuing now because right now it’s a single player app, it’s a single device app and so all of your data is private. But as we go to expand Muse to sync across multiple devices and perhaps even collaborate across users, that becomes a much bigger question. There’s a question of can we implement something like that in the end encrypted way. There’s a question of do users value that if we had this as part of our brand, would actually resonate? Would that be something that people aspire to participate in? And there’s a question of is that even legal to do anymore at some point. So that’s a big question mark, I think for us in our brand. I could see us going quite deliberately in that direction, perhaps not as much as that duck.go, but making it a big piece of what we’re about. And I can also see us going more in the standard enterpriseas direction where our data is in the cloud. So I think that’s a big question mark for us. 00:33:27 - Speaker 2: From the tone of your voice there, we can see which uh outcome you would be happiest with. Yeah, absolutely it is. I think it’s something we personally value privacy and particularly in connection with creativity and tool for thought because your thoughts are such an early raw, intimate thing. It’s something we want to just see more of in the technology world is greater attention paid to privacy and protecting the user’s content. And yet, there are huge technology challenges here. We don’t even know, as you said, what’s actually going to be possible, and if that comes into conflict with other more important things that are just more important to our customers, we need to listen to that and we can sit here and say, well, we value this thing as people, but if that is just not achievable in a practical way with the business, then we can’t say that’s part of our brand. So that’s part of what makes it an open question to generally hard and challenging problem. I think one I would be inclined to list is one of my, I guess, goals for the company generally is to help people be more thoughtful, so it’s not just that our brand or vibe or the product’s vibe or the product’s character is one of thoughtfulness, but then in fact it will help those that are already thoughtful or aspire to be to move more in that direction or to embrace that fully. And so one maybe expansion or future direction I might see that as We do go to say more like team collaboration features, that that’s something that we could bring along for the ride that I think thoughtfulness for an individual and bringing thoughtfulness to a team kind of collectively is bringing that into say a team culture of let’s make decisions and considered and thoughtful ways. I think that sort of value or approach is fairly common among designers. Maybe also among certain categories of more leadership and managerial people, but maybe is not a kind of necessarily as broad across a given team. And so, is there a future where somehow bringing news into your team’s work flows when it’s some future time, when we have some as yet undefined features around that, is there a way that it actually allows your team collectively to be more thoughtful or move in that direction? I think that’s a big challenge, but that’s all the more reason to build a strong brand around it first in the easier single player space. 00:35:47 - Speaker 1: Yeah, and this is actually giving me another idea, maybe this is too diffuse, but I think there’s this sense of agency that we could really emphasize and use. So it’s traditional software, especially these days, it’s like all your data is locked up, yet the company’s hosting it can see all of it. You have no ability to really manipulate or control your software and you’re part of a big org, you know, you’re part of this enterprise software org and you’re just a data point in that. The model that I’m interested from use is more of the. Individual agency network of collaborators model where you have your stuff, it’s your stuff. Also you have some elective collaborations with other individuals, other groups, and perhaps other organizations, but the individual is kind of the primary node, and I think that’s too abstract and diffuse to bring that into a brand as is, but I feel like there’s something there around software that brings the power back, the agency back to the individual creative user. 00:36:36 - Speaker 2: Mm. It reminds me a bit of the, maybe the consumers. of IT or they talk about bringing your own device, which was in the, I don’t know what ancient times, 15 years ago, 20 years ago, whatever, particularly in the larger the company was, the more you were issued equipment to use, you know, your laptop came from the company, certainly your BlackBerry company issued and very locked down, right? There’s all these IT administrator controls, you know, there’s a VPN you have to log in just to get access to anything. And what that meant was that these products were good from the perspective of the administrative legibility side of things. But they really weren’t kind of optimized for call user experience, but just the happiness and productivity of the individuals use them, and then on comes things like the iPhone and Gmail, whatever really raises the bar on what people can expect, and then suddenly by comparison, their clunky kind of company issued stuff is just so far below, and they just don’t want to do that, and eventually there’s have to be This adaptation, and now it’s even to the point where, at least for me, like a company issued phone, that seems crazy. The phone is such a personal device and each person has strong feelings about which one exactly that they want, and certainly the idea of not having total control over my device to set the preferences as I like feels very weird to me, and I think that’s become quite common. So yeah, is there a version of that for productivity and collaboration tools where there’s less of the IT administrator decides exactly what’s best for the user, and more that you have the creators who are part of this collective, that is the company or the project team, they can bring their tools and their practices and make their own choices to this larger whole rather than the top down process. Yeah, nice. But yeah, you’re right, how that gets boiled down to a, you know, one or two word brand character thing, well, I guess that’s an evolution that happens over time. Yeah. Well, certainly I think brand development is like product development, as much discovery over time, not a sitting down upfront and figuring it all out, but a process of developing that. It’s a combination of your personal characters on the team, it’s a combination of what the product is today and what you aspire for it to be, and then it’s Also the users, the customers, and the people, particularly early on, who come in with their own set of values and ideas and affiliations, and that’s something that evolves, develops, grows over time. So looking back on this discussion maybe in a couple of years and seeing how the Muse brand has grown and developed in that time. Right on. If any of our listeners out there have feedback, please feel free to reach out to us at @museapphq on Twitter, or you can send an email to hello@museapp.com. We always love to hear your comments and ideas for future episodes. Thanks for the chat, Mark. See you next time. Thanks, Adam.
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: There just really doesn’t seem to be an effective concrete practice for taking like day to day insights and accumulating them, like rolling them up into a snowball of novel ideas. 00:00:16 - Speaker 2: Hello and welcome to Meta Muse. Muse is software for your iPad that helps you with ideation and problem solving. This podcast isn’t about Muse product, it’s about Muse the company and the small team behind it. My name is Adam Wiggins. I’m here today with my colleague Mark McGranaghan. Adam, and a guest today, Andy Matuschek. Hello, thanks for joining us today, Andy. I think you’re about as close as there is to Rockstar and the tools for thought space. 00:00:39 - Speaker 1: That’s a really distressing statement. 00:00:42 - Speaker 2: Yeah, we’ll, we’ll talk more about why this space is so small a little later on, but for those that might not know you that are listening, maybe you can briefly give us your background. 00:00:51 - Speaker 1: Sure, I’ve kind of a meandering background. It begins in technology. When I was a kid, I was constantly developing video game engines and kind of these tools for creative people. I, um, with a couple of roommates, I worked on the, the first native Mac OS 10 graphics app and did that for a bunch of years and then made some open source software for developing. I was always really into tools for others. Went off to Caltech and kind of got introduced to science, serious science. And uh kind of got my, my very pragmatic engineer perspective salted uh with all that. But unlike all of my peers who who went off to get a PhD, I, I went off to Apple and got a different kind of, it kind of felt like a graduate program of studying at the, the heels of all of these people with like jeweler’s loops that they were using to to look at individual pixels of devices and There, there my work became much less about just programming and much more about kind of the intersection between technology and design. I, I got myself involved in in all these projects that it kind of the through line was that they, they were about what was central to dynamic media, uh, as opposed to just pictures on screens. So things like, you know, interactive gestures and like the 3D parallax effect and, you know, crazy page curls and And all this stuff we’ve talked before about. 00:02:07 - Speaker 2: Uh, the way that Apple’s environment maybe has less of that distinction between design and engineering or there were a lot of people that sat really on the intersection of those two things and it was part of what allowed them to do and continues to allow them to do really innovative things on interface and and maybe you’re a person that sits in that place as well, right? 00:02:26 - Speaker 1: Sure, yeah, yeah, it’s it’s interesting because like from an org chart perspective, there’s really heavy boundaries between engineering and design, and like I was on the engineering side of the house, like I sat with the engineers, but uh for several years, I, I would like Spend much of my day sitting in the human interface lab, like next to a designer, and we’re just kind of like tossing prototypes back and forth all day. And so it became this kind of mind meld thing where those people could tweak values in the prototypes I built and you know, I would end up tweaking design elements as I was building prototypes and it kind of just the titles fell away. But over time, I kind of, I began to feel that these experiments we were doing with the dynamic medium, I would love to see them applied to things which had More, more meaning, more impact in the world. And so I, I got really interested in, in education research. I started writing about that. And uh the folks at Khan Academy reached out and asked whether I’d like to do that kind of work with them. Um, so I joined Khan Academy and and took along, uh, one of my Apple colleagues, Mei Li Ku, who is a wonderful designer and, and together we started this like R&D lab, uh, at Khan Academy where we explored all kinds of uh novel educational environments from that perspective of like trying to trying to look at what the dynamic medium alone can do. Trying to make these active learning environments and I did that for about 5 years and um I started getting a little disillusioned with institutional education and um I started getting really interested in the kind of knowledge work that people like you and me do every day, where you’re reading information, writing information, creating new things, pursuing uh novel ideas every day, and I’m wondering how we could augment some of that. Uh, so now I have this kind of independent research practice where I’m pursuing oddball questions like what comes after the book? Can we make something that does the job of a book but better? Uh, it’s just been sort of a delightful experience. 00:04:12 - Speaker 2: And I think one of the uh pieces you’ve written in all your writing is delightful, and I certainly recommend everyone uh read it, but uh uh read as much of it as they care to. But when I’ll link to because I think it particularly illustrates maybe the place where you and our team kind of overlap and thinking is the transformational tools for thought article, which both describes sort of your current work around the the learning and the space repetition, which you can tell us about, uh, but also the kind of the meta elements of how do we develop these kinds of tools in the first place. 00:04:43 - Speaker 1: Yeah, that that was a project with uh my wonderful colleague Michael Nielsen, who’s also been investigating the space which we might label tools for thought. And people have defined this in different ways that the term stretches back some decades, but uh I like to think of it as tools or environments which expand what people can think and do. And you know, a great example of this is writing. Another great example is numerals. So there’s a tendency to, to think about, you know, kind of computer implementations of these things and of course there are instances which are very interesting. Um, I find it very powerful to reach back to you know, these, these cultural. 00:05:16 - Speaker 2: Uh, ancestry tools for thought. Absolutely. Another great example of that is, I think Brett Victor has a piece about this, which is essentially the chart, is the charting numbers, you know, on an X Y axis or, you know, line graph or that sort of thing that we we take for granted nowadays where it’s easy to crank that out in a spreadsheet or whatever, but that was an invention that happened not even all that long ago. It’s, you know, a couple 100 years back or something like that and the existence of this new. Um, tool, or actually, I think as you argue in that piece, medium, you would even call it a medium for thought, might even be more accurate, basically allows you to have new ideas or see the world in a different way. So the tools shape the kinds of thoughts you’re able to have and the kinds of works that you’re able to create. 00:05:58 - Speaker 1: That’s right. If all you have is Roman numerals, Roman numerals, uh, then it’s very difficult to multiply. Suddenly, if you have Arabic numerals, it becomes quite easy by comparison. So kind of in the what comes after the book space, one of the things that my colleague Michael and I had been exploring is just this observation that most people seem to forget almost everything that they read, uh, and sometimes that’s, that’s fine. The thing that really matters in a book is, is the way that it kind of changes the way that you view the world for many books that really is the impact that matters. Uh, but for other books, for instance, if you’re trying to learn about quantum computation or some advanced technical topic, uh, it really is kind of a problem, uh, that, that you forget. Uh, most of what you read because these topics build on each other as the book continues. And so you end up starting reading a book in English, say, and then halfway through the chapter, uh, you start to see there’s like a word of Spanish and, and then by the end of the chapter, there’s like whole sentences of Spanish and then then like the whole second chapter is in Spanish and say that you don’t know Spanish as a language, you read this book and you’re like, well, I thought I was reading an English book. It’s like, no, it’s actually written in this other language that you have to. Learn, just as you would have to, you know, learn vocabulary, if you were trying to speak a foreign language, you need to like learn the vocabulary, both conceptual and declarative of this domain that you’re seeking to enter. Uh and so, and so the experiment is kind of been, well, can we make that easier? A project that that paper describes is this textbook called Quantum Country, which tries to make it effortless for readers to remember what they read. Um sounds like kind of a crazy thing, but It takes advantage of really a fairly well understood idea from cognitive science, about how it is that that we form memories. It’s reasonably well understood. There’s sort of a closed set of things that you need to do in order to form a memory reliably. Uh, it’s just that like logistically, it’s kind of onerous to do those things, and it requires a lot of coordination and management. And so most people don’t do it or it’s kind of difficult to do it. Uh, but it’s pretty easy to have a computerized system assist these things. And so, basically, as you’re reading this book, every 10 minutes or so of reading, there’s this really quick interaction where, you know, say you just read about the definition of a qubit, after a few minutes of reading, there would be this little prompt interface where it’s like, hey, so how many dimensions? Does a qubit have? And you try to remember like, uh, how, OK, it’s two dimensional. So you think yourself 2 and then you reveal the answer and it’s like, oh yes, it was 2, and so you say, cool, like I remembered that. And then we say like, OK, so a qubit is really a two dimensional what space? Like, how do we think about representing this? And say you don’t remember that, it’s this linear algebra concept. OK, it’s a vector space. That’s fine. Like you reveal it back, you didn’t remember that. See market is like, I like, I didn’t remember that detail. And um this is already doing something for you because it’s kind of signaling like, hey, maybe you weren’t quite reading closely enough or just seeing that answer that you missed, like as you read the next section, if that topic comes up. Maybe you’re more likely to remember because you were just uh corrected and you saw that correct answer. But somewhat more importantly, 10 or 15 minutes later when you’re looking at this, this next set of prompts, and you, you see kind of the new things from this section, that prompts about the two dimensional vector spaces that you failed to remember, that one will appear there. And so you’ll, you’ll kind of get another chance. And then once you remember it there, the idea is a few days later, we will send you an email and you’ll say like, hey, uh, let’s let’s remember these things about quantum computing that you were working on, let’s work towards long-term memory, and you’ll you’ll open up that review session and linked in the email, and you you’ll kind of do this interaction again, just, just a couple seconds per question. It takes about 10 minutes to go through the material. And that 5 days later will kind of reinforce your memory of that material about as well as the 10 minutes later prompts did, not, not exactly, but, but just roughly you get the idea. And then if you remember things after 5 days, then, you know, maybe you will next practice them after 2 weeks and after a month, after 2 months, after 4 months, and so it initially seems like this kind of onerous thing, like, oh, I’m gonna like be working on these like memory flashcards for this thing I’m learning, but Because the way human memory works is that it’s stabilized in this kind of exponential fashion where you can have successive exposures that are further and further apart. Uh, it only takes a few exposures before a particular idea can be remembered durably for many, many months at a time. 00:10:11 - Speaker 2: And this is a space repetition systems you’re talking about, um, which I had some exposure to through Onki, which is this little kind of I don’t know, uh, it’s definitely a tool for thought, but it is, uh, very nichey, I would say more than a little clunky to use. You have to be really motivated to do it. And so you can use a tool like this to increase your retention or understanding of something you’re reading a science paper, a book. Something you you do want to get a deep grasp of, but you got to really work hard at it, right? The tools are very taping it all together yourself in a way that requires pretty big commitment and investment. And one of the things I think is really interesting about the work you’re doing is whether you can take that and build it in a way that’s fun, relatively low effort by comparison, maybe even you know, sleekly designed and just more, more enjoyable overall. 00:11:06 - Speaker 1: Yeah, one thing that characterizes, I think a lot of opportunity in this space is that there are many exciting ideas which have been explored by technologists or by academics, which are promising at some foundational level. The underlying mechanic of Aki is fundamentally the same as the underlying mechanic of quantum country if you look at it from a certain angle, but there’s this core design piece missing, that’s kind of keeping that idea from really having the transformative impact it could have. By that, I don’t mean the fact that Aki is like hideous. I mean, it is, and, and it will kind of like turn off basically everybody who looks at it for that reason. But there are deeper issues to your point, it’s really hard to write good prompts. Uh, both in the sense that people start by being bad at it, and so they’ll write prompts that don’t work very well and that are boring and onerous to review, and they mostly won’t realize that that’s what’s happening. They’ll just think like that’s what this is. And then also in the sense that even if you do know how to write prompts well, it’s quite taxing. It takes a lot of effort. It’s a context switch from the experience of reading and it’s valuable insofar as kind of reflecting on material that you’re studying and synthesizing it, distilling it and turning it into a question actually does. go quite a long way to enforcing your your understanding of the material, but maybe you’re only going to do that for like the most important things in your life. And it’s pretty interesting to wonder like, OK, maybe you do that for the top 10% of the stuff that you ever read, but what if it was like really pretty easy and low effort for you to remember the top 70% of the things that you could read. You could save that special effort for the stuff that really, really matters. Um, that’s kind of what quantum Country is pursuing. One of the main things it’s wondering is, can we make this something. That it basically everybody who’s reading it and is serious about the topic can take advantage of and really see the benefit of. 00:12:49 - Speaker 3: I think this thread also reflects one of the challenges in developing new tools for thought, which is you actually need a lot of different skill sets. It’s not just a matter of engineering or computer programming, you need engineering, products, design, writing, marketing, community, often you need at least all of those things. And I see a lot of people approach the domain as basically pure engineers and they they. Tend to kind of bounce off or the products don’t stick because they’re missing a lot of those aspects. 00:13:15 - Speaker 1: That’s right. And I’ll add one more actually, that that’s kind of Michael’s in my hobby horse here, which is that you probably also need some kind of domain expertise. So many of the, the projects in this domain, even if they do actually have the design skills and the technical skills involved as well as some of the other peripheral skills, they’ll be doing things like trying to make a tool to do math better or something like that, but no one on the team is a serious mathematician. And so they’ll make something that seems really cool and it makes for a really good like product presentation, but no mathematicians really going to use it to do serious work. Maybe it works in an educational perspective, but it’s fundamentally limited. It’s it’s like a toy in some fundamental fashion. And so to that list, I would add, you need some kind of deep domain expertise too for a product like Muse, maybe that is somewhat diffuse. So anybody working on a product, the domain expertise that’s relevant there might be like, you know, the visual design of a product or like doing this kind of conception stages of a product. 00:14:11 - Speaker 2: Well, our domain is thinking. So luckily we have a domain expert on that, and that’s Mark, right? 00:14:15 - Speaker 3: Yeah, I feel like a sort of secret that we have, we had with the lab and now we have with use this understanding of the creative process and thinking and a lot of it actually comes. From the study of how this stuff happened historically. And you mentioned reaching back in history and learning from that something we’ve done a lot of. 00:14:29 - Speaker 1: Yeah, it’s fantastic. I think it’s just really attractive to build tools. It is built into my DNA like I grew up that way, and it’s actually a liability for me. My tendency when I see an opportunity or I see a problem space, is like, oh, wow, like I’m going to make a tool to like help with that. And that’s like a useful tendency, it’s a cool tendency. But often, I’m not like really solving a burning problem, or I’m solving an abstract problem that isn’t connected to something that is like concrete and intrinsically meaningful and that like actually is about doing the work. So like the analog and muse would be if maybe I’ve done like one serious creative process that was about like a concrete thing, and then I. Like, wow, like I’m really interested in the creative process. Like I’m going to devote, you know, the rest of my days to working on building tools for the creative process, which I like, I’m never really using to do any subsequent serious creative process. Like I’m I’m doing it in order to make the tool because I’m fascinated by tools. That’s a tendency that I have that I have to actively combat. 00:15:24 - Speaker 2: The other thing that comes with it, if you come into building a tool with the domain knowledge. Is that over time you get focused on building the tool and maybe you actually know the domain less well. So there’s there’s quite a parallel for me personally between uh Hiroku and Muse in that both are some kind of creative process. Hiokku’s web development, um, which is one kind of one kind of creativity, one kind of creation, act of creation with Muse’s, it’s thinking and reading and making decisions. In both cases, there is a process where a thoughtful professional sits down and they start in one place and they end with a solution or a result or or an output. And studying and understanding that process both it’s fun for me to introspect for myself, but then the the ethnographic research aspect of going out talking to in the lab and in the build up to Muse, we talked to hundreds of creative professionals about their process, which was always an interesting thing because of course it’s this very private and intimate thing and also I would say 98% of the time people are vaguely embarrassed because they feel like it should be better. It’s like, oh, my notes are really messy, or yeah. Yeah, you know, don’t look at my office. It’s, you know, things are, I, I should have some, I don’t know, some they have some idealized version of what it would what it would look like the reality I think is the creative process is messy and that was something we we fed into Muse was sort of embracing that a little bit. 00:16:46 - Speaker 1: I think it’s critical that you all not only experience that ethnographically but also personally that you have this deep personal experience of that process. Otherwise I fear it’s too detached. The insight from the last year that I’m most excited about is is kind of this nugget in the middle of the the paper you you referenced, Adam. I call it like that the parable of the Hindu Arabic numerals. I hope you don’t mind if if I kind of recap it here because it just seems to bear. It’s this observation that if you are the Roman royal accountant and you’re just struggling through these tables of numbers and you find it very onerous and it’s kind of taxing and it’s error prone, imagine if There was like Roman IDEO and you could go to them and say like, hey, please help me like with my accounting process, please redesign this. You know, IDEO’s process is pretty amazing in a lot of ways. They’ve helped make a lot of really powerful products, and they have this process that is really interesting where they go and they they embed, they will like sit with the accounting departments and like interview extensively as you talked about interviewing people about their creative process and like really try to internalize it, they’ll do all this like synthesis and diagramming. And they’ll come up with words to describe what people are doing, and it’s all great, but I think there’s just no way that Hindu-Arabic numerals would be the result of of that process if, if what you’re starting with is Roman numerals, because the transition requires the deep insights of a mathematician and also deep insights of a designer. So just for instance, place value, this notion that like if I have a 6 and it appears in the right moment. Spot, then it’s like a one digit, but if it appears in the second or rightmost spot, that 6 is still 60 in certain fundamental ways, and you can still perform the same fundamental operations on it, like with addition and so on. It still works the same, but it has this alternate interpretation of being like 60, it’s in the tens place. That is a profound mathematical insight that depends on deep intuition of like commutivity, the laws of distributivity. Uh, it’s not something that somebody just like doing some ethnographic research in the field is going to come up with, yet simultaneously, it’s also not something that most mathematicians are going to come up with. And so it’s a great example of how you like, you really have to have the same, the people on the same team. 00:18:57 - Speaker 2: That is a great example of the domain knowledge, and I wonder if that connects to something. I feel like I see the trend of people with design as a skill set. I feel like are more often drawn to what I would call consumer or sort of end user things. So they’re more interested in working on social media, you know, let me get a job at Instagram or Facebook or something like that. And I wonder if that’s because then they only need to be an expert in the design domain, and if they’re working on something that’s more um for an end user that’s not really a specific domain, you don’t need that knowledge or the things that you need. To understand the problem space of Instagram is not deep specialized professional knowledge. It’s just being a person with a smartphone that likes to take photos and post them on the internet. 00:19:40 - Speaker 1: They can certainly be a lot more successful in that way. People are sometimes surprised that Apple doesn’t really engage in anything that looks like design research, and here I use that word to to kind of mean that the ethnography that you’re describing user interviews, the walls full of sticky notes where you’re trying to like describe user behavior. And summarizes your quotes. The Apple designers don’t really do that. But they’re primarily designing products that solve problems in their lives. Like I use email, like, let me make this email a little nicer, and so like they can do that. But I think as soon as you leave that domain, things start getting hard, like Apple iBooks, there aren’t a lot of like really serious readers on the design team. I think that’s part of why Apple iBooks is not good. The various attempts at social music platforms, that’s something that requires like a set of ideas that have been pursued by various products. It requires like, you know, kind of a landscape review, understanding people’s social interactions really deeply, that’s also not part of the process. The Instagram designers, I think they are doing something that the Apple designers aren’t, they’re talking to users a lot about how they feel when they’re interacting socially, and that’s a piece that has always been missing from Apple’s process, but to your point, they’re not this like goal of of taking and sharing photos. That’s something they already like. 00:20:52 - Speaker 2: Well, we’re already pretty far into it here, but I feel like I should um stick to our format, which is introducing the topic. Maybe I’ll do that here and Andy, you, you suggested this one, which is uh environments for idea development, particularly idea of development over time. I thought it might be interesting to compare what that phrase brings to mind for each of us. 00:21:12 - Speaker 1: Sure. So one of the hobby horses I’ve been thinking about recently is, I’ve been reading this literature on deliberate practice. Eriksson is maybe the prominent individual there and there’s this, this extensive research on the practices of dancers, musicians, athletes who have these very formal and intense. Hence preparation and practice structures that stretch from youth into eminence. So touring international pianist is still working on these like fundamental skills and activities. And I think it’s fascinating that by contrast, knowledge workers really don’t seem to take their fundamental skills all that seriously insofar as kind of like improving them in a deliberate daily ongoing way. 00:21:51 - Speaker 2: Yeah, I’d be curious to even just enumerate what we think are some of the foundational or some of the core skills for a knowledge worker. 00:21:59 - Speaker 1: I was about to try to do that because I think it actually connects to this to this phrase. I’m sure that y’all could add some more, but I think reading effectively is is one of them, writing, communicating effectively is one of them. But taking an inkling and developing it over time effectively seems like another just really important idea of creative work. And so that that’s what made me suggest the topic that if I speak to people and ask them like, hey, so you know, this kind of interesting notion comes out of a conversation, and you think like it might be worth pursuing, then what? People’s answers are uh. They’re not good, you know, and like people do come up with things, they managed to develop ideas in spite of this, but it’s clear that this is very haphazard, and it doesn’t always feel like haphazard in a good way. People will say things like, well, you know, maybe I write it down in my notebook. It’s like, well, and then what? Well, uh, maybe later I’ll like flip back through and see it, like, no, no you won’t, uh, or, you know, you can like you can schedule time, you can like put aside time to like think about that idea, and maybe if it’s like a really important idea you’ll do that. But you won’t for like, you know, something cool that comes out of a conversation that seems like it might connect to something later. There just really doesn’t seem to be an effective concrete practice for taking like day to day insights and accumulating them, like rolling them up into a snowball of novel ideas over time, except insofar as, you know, they kind of happen to accumulate in your awareness. 00:23:17 - Speaker 2: Yeah, that makes sense and obviously connects very well to the To the Muse story for me, it’s become because of this product that I now obviously have been using in the process of our team developing it. Because it for me represents the place I go to do my deepest thinking. There’s almost not quite a ritual, but let’s say when I, when I go to make a muse board for something that I feel like is something I need to do a deep dive on, I know I’m really getting into it. That signals it to myself. Almost to the point that sometimes I’m, it’s an idea I’m excited to explore exactly what you described, like the team is having a conversation, something serendipitously comes up. I think I should really dig in on that. I think there’s something there. I put it in my notes to do that. So that can be like. A fun, exciting opening a new door, opening a fun Pandora’s box kind of thing. But it can actually also be the other way around, which is I know it’s maybe more of um something important to insult to research or understand deeply that maybe has is a problem in in my personal life or like a government paperwork thing or some other something like that. And I just know, OK, I’m going to really get into it. This is not shrugging it off. This is not quickly jotting down a couple of quick notes in my notebook and moving on by creating this board. I’m kind of mental. Making myself a commitment to follow this rabbit hole as deep as it goes until I feel like I have my head around the problem or or I’ve solved it, which is sort of an interesting effect, mental effect that the product seems to have on me. 00:24:36 - Speaker 1: It’s really interesting. Can I ask the and then what? Like something comes up in a team meeting and so like you add it to the muse board. What’s the and then what? How does that idea grow? 00:24:45 - Speaker 2: Yeah. Well, importantly, I wouldn’t add it straight to muse from the meeting. I would put it more into my kind of like inbox GTD style. Like just stop it’s the same it’s the same list where I put down, um, you know, we’re out of we’re out of milk, you know, get more, it’s just like little notes here. Another way I’ll think of it sometimes uh in team meetings is realizing we need kind of an internal memo to pull together diverse thoughts on the topic and like really articulating what the problem is, um, and really trying to lay it all out so that not just for my own thinking but so we can all sort of be on the same literal page about. Something, particularly maybe something that’s a long time ongoing problem and there’s people that weren’t on the team before and they don’t have some of the past contexts you want to put it all together. Yes, so then what for me is deciding I want to devote a chunk of time to this, you know, maybe it’s 20 minutes, maybe it’s an hour, maybe it’s more to really dig in, to really just face whatever this is head on and see where it leads me. And you know, maybe it’s something like an idea for a new product feature, for example, which again tends to be more on the fun. Uh, the fun side of things. And so then, then there’s this whole process around, you know, let me assemble prior art and get together some ideas and sketch some things and all this kind of stuff. The output varies, but sometimes there’s just a clear insight of like, oh we should do X, it’s a decision basically, and then I will go and take action on that, but other times it’s realizing, wow, this is a really much deeper hole than I thought and You know, it needs more thought or it needs more whatever. And then maybe I want to, for example, it’s a team activity, maybe I want to bring it back to the team and say, we thought we could, I thought I could think about this briefly, have a solution, and then do it. But actually it’s a lot deeper than that. What do we want to do? So I think it’s, I think it’s just like understanding or not quite enlightenment, but getting to this new place of understanding about whatever the thing is, and then that in turn implies a next action. 00:26:38 - Speaker 1: One of the questions I’ve been exploring in this space is what to do when it’s not really possible to make a lot of progress in one session. So talking with people about their practices, one common approach that I hear relates to what I just heard you articulate, and that’s that something kind of reaches a threshold of interestingness or apparent importance. And at that point, you’re going to like carve out some time and sit down and really think about the thing. That’s cool. And sometimes that is enough. I noticed that for a lot of the most interesting ideas that I explore, one session doesn’t often really doesn’t yield all that much. In fact, often it doesn’t necessarily feel like that session really produced a significant increment at all. Uh. You’re just kind of like manipulating the terms of the equation, so to speak, getting a better handle on it. And so one element that I noticed often really seems to be lacking from people’s processes, because it’s kind of it’s hard to orchestrate is marination, where it seems like sometimes what ideas need is just kind of consistently returning to them over time and asking like what do I have that’s new to say about this difficult question? OK, I can say a few sentences about it that seem kind of new, like it’s interesting, but it’s still not. Something. So I’m going to leave this for 2 weeks and I’m going to come back and like, what do I have that’s new to say about this? And maybe if you do that, you know, 6 times, something starts to emerge. That seems really difficult to orchestrate. 00:27:58 - Speaker 2: It makes me think of a great article called Solitude and Leadership, which basically is describing how you need to carve off this. You basically need to disconnect from the opinions and influence of others in order to have original thoughts. One way that the author talks about it is in that first session, like you described, at the end, everything that you’ve come up with a written. Down is really in a way just the thoughts of others that you’re echoing back. And that’s fine. That’s a starting place, but to truly get to something original or new or potentially breakthrough, you need to push past that. Yes, he claims that he can sense when he’s sort of like sort of cross from the more mundane thinking and into the more excuse visionary for lack of a better, better word or just original, uh, when the thoughts start to not just be an echo of what he’s read or seen or heard someplace else. And that always requires multiple sessions. 00:28:49 - Speaker 3: I think this also points to the idea that you can’t always expect to sit down in a series of sessions and then kind of one step after another, produce an idea all kind of in the forefront of your mind. When we think about thinking and ideas and tools for thought, we have this very conscious perception of it. It’s like I’m sitting down, I’m going to come up with something that’s better than Roman numerals. At the end of the session, I’ll have, you know, Arabic numerals. I think that’s just not how it works. Usually, sometimes you can get away with that, but often it’s more of your, like you said, marinating on stuff. That’s becoming this fodder for your mind and then in the background, you’re having an unconscious process of ideas, connection forming, inspiration, and then when you come into a later session, you might be better prepared to have a new idea. So I think it’s like you said, it’s really important to find ways for the tool to support that marination, chewing, ruminating, going over, rearranging without the expectation that you’re going to be explicitly building up your new idea. 00:29:39 - Speaker 1: It’s really easy for tools to accidentally build walls for that. One of my favorite novel reading tools is this. liquid text, totally fascinating set of interactions for manipulating PDFs, excerpts, things like that. One very interesting design decision is that by default documents are kind of a workspace and so you extract excerpts into like this canvas and you can manipulate them, but documents are kind of separate from each other in that sense. So you can have a set of insights about a document, but if you’re going to have inter-document insights, that’ll depend on your memory. Now there’s a fix for that, which is that you can create multi-document workspaces. You can say like, well, this is like my thinking about the this. Problem, you can kind of like bring several PDFs into it and kind of like make your notes and make your excerpts and whatever. And that’s cool because then you can have insights between them, but it still requires this intentionality of saying like, cool, I’m gonna like bring that PDF into this workspace and then like the notes and excerpts and whatever like they live there. But if you’re working on several interesting questions and ideas at once, it’s not at all clear that you’re going to have interactions between those workspaces that are necessary. 00:30:40 - Speaker 2: Yeah, liquid liquid text is great, but I think as a coming back to the environments for idea development. That creating room for serendipity without just total chaos is maybe a subtle and tricky thing. 00:30:53 - Speaker 3: I’ve thought about ways, by the way, to do this not subtly. One notion I have for an experiment is the idea collider. So you have something like your, your notes or your wiki pages, and every morning it just gives you two random pages and it’s like write a third page, which is the synthesis of these two things. Oh cool. I’d love for someone to do that experiment. Have you tried it? No, no, it’s kind of a it’s open. Request for research. So if anyone listening wants to develop it, let us know. That’s great. 00:31:14 - Speaker 1: It connects to a set of ideas that I’ve been exploring for the last year or so. I’ll share it, maybe that’ll generate some more. I’ve been doing this kind of strange note taking practice that really came out of trying to solve this problem of like, how, how can I make marination effective? How can I, how can I make a process where I can like do something every morning and cause there to be increments on my understanding. of some ideas or some problems I’m trying to solve. And so I have something that’s kind of like a personal wiki basically. The technology is not really important. It’s more about the practice that’s important and the practice is that I try to write these notes that are densely linked to each other where each note is about a particular atomic idea. Sometimes the note is a question like what are the most important design considerations when writing prompts for the mnemonic medium like one country and sometimes for Since the children of that note are declarative statements like space repetition memory prompts should focus on one idea, and then that note will kind of accumulate not just in one session, but over many sessions, all of the things that I have to say about that. And sometimes I’ll learn that the title was wrong. It’s like, oh, actually they shouldn’t always focus on one idea because sometimes it’s really good for, you know, these memory prompts to like synthesize multiple ideas and these things kind of evolve over time, a term that some have used is is gardening. Uh, I call these like evergreen notes because they’re trying not to be fleeting notes, like notes from a meeting that you’ll never really return to, but rather uh notes that you water and which grow over time. And just to get back to your idea, Mark, one of the practices that I found most rewarding here is this notion of a writing inbox, where when something seems interesting or juicy, I have a place for it to go, and I start my writing most mornings by looking at that writing inbox and and training. those as a set of provocations or prompts and asking like, which of these things do I feel like writing about this morning. In this way, ideas which seem promising, even if there’s already a lot written about them, I can kind of throw them back in the inbox and then it’ll like it’ll appear for consideration on upcoming mornings. But I think that inbox gets even more powerful if you start to introduce fancier orchestration methodologies into it. So one possible orchestration methodology is like the one that you just mentioned where like maybe the inbox this morning. contains these like pairs of notes. Uh, so it’s going to kind of combinatorically like walk my tree here. But another thing that seems pretty interesting and that I’ve been playing with is this idea that I had this interesting idea in a conversation with someone. I don’t really know what to do with it yet. It still feels promising, like, I don’t want to lose it, but I also don’t really have anything more to say about it right now. So I can like kind of snooze it for a while. It’s like, OK, I can go out of my, my writing inbox for a while, and it’s familiar from Gmail. And then It’ll like come back in a while, but in a modification on the snoozing functionality that I’ve been finding very interesting is the parameterless snooze. Normally you have to say like come back in a week. I think that kind of overhead is unhelpful and is often counterproductive and it’s better to just say like, no, not today. And to say like, well, if I’ve said that 10 times, then like, probably this should just go away a long time. 00:33:57 - Speaker 3: Yeah, does it like exponentially back off and reminding you. I think by the way, that snoozing or moving things out of you is really important. It’s actually a big difference in just having a big pile of to dos because there’s a limit to how many things you can have in your head at one time. And often we have new ideas that we want to bring in, but there’s no space. And the only way to do that is to actually kick stuff out from your working memory, and something like a snooze can help with that. 00:34:21 - Speaker 1: Muse is really Interesting in this regard because the the constraint of the screen as a surface, it encourages users to keep stuff to the quantity which they can see at a reasonable zoom scale on a screen at a particular time. I like part of the design? 00:34:36 - Speaker 2: Yeah, well, certainly constraints are potentially great for creativity. Post-it notes. One that I reliably come back to both in my own work, but also just as just this kind of very workhorse tool for thought analog world thing and part of it is you just can only fit so much you can also use index cards for this as well, yeah, maybe with an index card and a Sharpie and that sort of limited amount that can be on each card. Of course you can have any number of cards. So yeah, obviously with Muse, you’ve got the, you’ve got the expanding boards and you’ve got the sort of the 3D nesting, but certainly there’s I feel a desire to make what’s on the screen at the time kind of fit together as a collection of things that feed each other and when I start to have a section. Of the board that starts to feel like a rabbit trail, then I want to make a subboard that and so it feels like you’re going deeper down the rabbit hole or something like that. 00:35:30 - Speaker 1: One of the things I wanted to ask you about is kind of muse relates to this note writing practice I’ve been doing is the practices of refactoring or revision, polishing, gardening. Uh, something that’s been very useful in my practice is kind of having ways to think about writing at different levels of fidelity. So I’ll kind of have a place where daily notes go that are quite fleeting and kind of scraps will start there. And when something is titalable, there’s some, some atomic unit that I can point to and say like, OK, that’s that’s the thing. Now it can get its own notes and it can be linked to from places. But almost, it’s almost like the goal over time is for these things to adhere and Crete into larger elements. So a a note that’s a single claim is like not that useful. It’s kind of this ross, but eventually some number of notes that make a claim will become like a, like a theory or like a noun phrase, a coinage or something. And that larger note that, you know, contains references to all these constituents, it feels like an increment that’s meaningful. And so the pressure in the system to like over time refine, refract. To create ever higher order abstractions is very helpful in my writing practice and I’m curious how you think about that. 00:36:38 - Speaker 3: I would say that Muse supports that, but doesn’t require it. So you can certainly use Muse as a persistent corpus that you’re accumulating over time and building up to these pristine and complete notes that are basically publishable. But you can also use it in complement with other tools. So maybe you’re doing it in your head, maybe you’re writing stuff out in notion, maybe you’re using an authoring tool like Final Cut Pro, it’s more flexible on multi-purpose maybe. It’s very important. It was a very explicit design decision that boards and cards in general do not require titles. I think that one of the kind of original sins of of file systems is in order something to exist, it has to have a name, but a lot of things just aren’t named yet. 00:37:11 - Speaker 2: That was one of our design goals with Hiroku was that you’d be able to put an application online without giving it a name. 00:37:17 - Speaker 1: Oh, that’s great. I didn’t know that. 00:37:19 - Speaker 2: That’s wonderful. The original implementation was Apps by default were untitled some long. 00:37:25 - Speaker 1: They have cute names. 00:37:26 - Speaker 2: I recall. This was, I think one of the, one of the really lovely pieces of work my partner there, James Lindenbob did, which is what we now call haiku names, which I think have been fairly widely adopted, which is sort of taking an adjective and a noun that were carefully selected so that they go together and they convey a certain vibe that kind of connected to our brand or whatever, plus we eventually had to add some numbers on the end just because there was enough of them. Um, but the idea is something that looks nice. It doesn’t look unfinished, it doesn’t look like untitled, but it doesn’t also require you to figure out, wait, do I want to call this my wiki or is it the team wiki or is it Team Wiki 2 or is it the, cause it’s like an idea I wanna pursue an unfinished thing and I don’t quite know what it’s gonna be yet. I have this hunch that I’m exploring and then yeah, you get all hung up on the name, um, and yeah, for for sure I see the file system. Uh, world of things having kind of that same problem where you use his names are important when we know that we sense that and so if you have to give it a name to even get started on whatever it is you’re creating, that can be a bit of a, a bit of a hold up. Now it’s nice, it might be nice to title something or label it later. Muse has labels for that reason, obviously rename your Hiroku app. There’s lots of other examples of that, but being able to just start with, it doesn’t have a name and eventually actually the act of naming it is you’re sort of upgrading it from Random tidbit of of random idea, random tidbit of knowledge may not amount to anything to, OK, this is a thing now. 00:38:47 - Speaker 1: Yeah, I really like this word upgrade. It accesses a design direction or a design space that I’m curious about with this taxonomy of notes, taxonomy of creative work. Taxonomy is too too rigid a word. It’s obviously much more fluid than that. Almost the ceremony of giving something a name, giving some. A coinage, and that that feels that the object feels more complete when it has a name, almost like it wants to like it wants to have a name. It’s OK with not having a name, but it’s in a happier state when it has a name. 00:39:19 - Speaker 3: This is a feeling that resonates very strongly with me. When I’m doing a project, a huge milestone is when I come up with a good name. And I don’t know why it is just, it feels so much more. Real when that happens. 00:39:29 - Speaker 1: In designing tools for thought in general, I think this is a powerful practice to avoid the tyranny of formality by saying like, OK, there are 6 types of notes. There’s the fleeting note, there’s the claim note, like, that’s terrible, screw that. But you can still have an opinion about process. People ask me like, what software do you use for your note taking? and it’s like totally the wrong question. What matters is kind of the methodology, but having the methodology and Mind, I can’t readily like communicate it or install it into others' minds except by having them read like thousands of words of notes. And one of the things that Tools for Thought can do is to encourage a particular methodology, not by imposing formal structure, but by implying certain kinds of structure, by making, for instance, objects on a canvas feel somehow more complete when they have a title. You’re not imposing the necessity of a title, but you, you’re suggesting that one’s work should perhaps culminate in a title. 00:40:24 - Speaker 2: My creative process is always heavily oriented around finding patterns, which is why it’s important for me to have a lot of I guess raw material and input. Uh, you can call it data, but it might be something like user interviews or it might be something like looking at some other products in the space that I want to compete with or improve upon or something like that. Um, it might be a series of bug reports, and I’m trying to get to the root of what this is in some kind of complex system in order to do that. I want to, you know, it’s been very difficult to track down, but if I could somehow kind of look at all of it together and extract out what’s the, what’s the pattern here? That’s, that’s the place where insights come from me. I, I glean that’s not necessarily the case for everyone, but for me it is this process and if I can somehow get everything together, I can get all the relevant stuff in one place, that’s half the battle. 00:41:12 - Speaker 3: Uh, one last idea and tools for thought before we transition into the meta, and the, the mummonic medium can be thought of as a way to optimally position you to remember things. There’s this point where if you’re at as a learner, you’re, you’re best position to recall vocabulary phrases. It’s like just as you’re about to forget, basically, you get prompted again and as that happens more and more, those times become longer and with a system like space repetition, you get this software-based support to help you remember things. I’m curious if you think that technique can be applied to Skills. Uh, this is an idea that I’m really intrigued by because yes there’s a lot of interesting things that are like facts and figures, but there’s also a lot of things that are our skills and abilities, and I wonder if we could apply the same technique to learning how to play chess or how to use a video editing program or something like that. 00:41:57 - Speaker 1: I do think that’s possible. I’ve spent a few years experimenting with it now, and so is my colleague Michael, and it begins with this observation that it’s possible to use spaced repetition memory systems for more than just recall. So the the typical way to use them is like, OK, what’s this term? What’s this definition? And that’s cool. I mean, that’s useful. But you can also use them for, for instance, applying an idea. And in fact, in quantum country in the final chapter, we have these questions that look a little bit more like lightweight exercises from a textbook or something like that, that share the property of the recall prompts that you can kind of, you can do them in your head, they’re quite rapid. They’re semi fungible, they’re lightweight, but they’re things like what would the output of this circuit be? And these are different from the recall prompts and that they’re not the same. Every time you see them. So you’re actively not trying to remember the answer, but you’re trying to like go through the work of producing the answer. You can also write conceptual prompts, concepts distinguish themselves from declarative knowledge by focusing on how things relate to each other and kind of systems and structures. You can ask questions like for instance, when I was studying the history of philosophy, contrast positivism and existentialism. Now we’re making a connection, but in terms of developing a skill, like maybe you want to like learn to think in a Danological fashion or something. So you can also write a prompt that says, take a decision that you made this morning and it could be as simple as like deciding not to exercise when you normally would have and justify it or condemn it from a dentological perspective. And so this is like a task. So zooming out, I think space repetition becomes most powerful when we think about the items, not as flashcards, but as micro tasks and what the system is doing is batching. The transaction costs, which would normally be associated with orchestrating all of these tiny micro tasks that you could use to practice a skill or develop a worldview or self-author in some way, and putting them together so you can say like I’m going to do 10 minutes of like my self betterment session very broadly construed, and that’s going to involve remembering certain chess moves and also practicing this line of force motion in chess and also reflecting on logical positivism in a certain way. Uh, and so on and so forth. 00:44:06 - Speaker 3: Yeah, that’s really interesting, and I’m, I’m wondering if you can extend it even further. So I think one element of space repetition is it’s kind of helping you with the mechanics of, OK, you commit to spending 10 minutes a day on this problem and we’re going to use the software system to make that really productive. You’re gonna see a lot of cards, for example. But I think another element is basically identifying what you need to get better at. In the case of memory, it’s pretty straightforward. It’s like the, the question. that you answered incorrectly last time or something like that, are the ones that you need to see now. But in the case of chess, for example, it might be that your endgame is weak, or you don’t know how to handle attacking knights or something, and that is potentially much harder to identify programmatically. But it seems like it’s also within reach. And so I’m curious about systems that both um help you mechanically, but also in kind of the same system, identify your weaknesses and where you can improve. 00:44:48 - Speaker 1: There’s a lengthy history. of people trying to solve that particular problem, going back, I think now almost 5 decades. For me, the most promising kind of subfield or sub approach is called intelligent tutoring systems. There are a few systems in the wild that have been commercially successful. The most notable is called Alex ALEKS. It’s an algebra tutor which has some fairly clever mechanics for identifying your weak points and then focusing practice time on on those. I would say that none of these systems has been wildly successful and the field as a whole has not been wildly successful. I don’t fully understand why. I’d like to spend some time studying that because it seems like a somewhat obvious progression once you kind of get into the space repetition space of trying to schedule stuff more efficiently, choose construct cards more effectively, perhaps dynamically. I have read some papers about people in the fields theories about why it hasn’t worked very well. They center on things like the non-regularity of topics. So an intelligent tutoring system on algebra will often share very little in common in its implementation with an intelligent tutoring system on geometry. They can share, you know, some kind of fundamental like modeling, the learner primitive type stuff, but the representation of the ontology is first off very difficult to construct and second off very. difficult to like systematize and encode in a consistent way across fields. My like personal hunch, and again, I haven’t read deeply into this, but my hunch is that part of why these systems have not been more effective in my practice is that they’re universally incredibly dreary. They, they have this intense feeling of being in a skinner box, like you’re a rat in a wheel, you are being fed. These like morsels of problem, and you like swallow, and then, OK, true, like, here’s another morsel, like, do this one next, and I think it may be possible to like, to recuperate the underlying conceptual ideas without the the interaction framework that they all employ. 00:46:39 - Speaker 3: Yeah, very interesting. I check out that literature. 00:46:40 - Speaker 2: So if we come to the meta side Of how tools for thought get developed. We all have some familiarity with the human-computer interaction academic field and dabbled in that in various ways, even if none of us are career academics. Then Andy, you ran a corporate R&D lab, which is sort of a one commercial approach to tackling innovation. We, uh Mark and I were part of An independent research lab, which was an experiment in that, uh, and then all of us in various ways have been part of either classic Silicon Valley startups or bigger innovative companies like Apple. And despite all of these, I feel like we still don’t have the level of attention, funding, and just people who are passionate about. Yeah, computers and more broadly information tools that can help us be smarter, more thoughtful, make better decisions, be self-actualized, all of that bicycle for the mind stuff. I’m still trying to figure it out why that is. What’s the, what’s the gap there? 00:47:41 - Speaker 1: This is an ongoing mystery and a topic for discovery and discussion because in my mind, the wind condition for my work is not creating a particular tool for thought that that’s really powerful, but causing this to be a field. I view it as not a field right now. It’s kind of like this proto fields like some people doing stuff. We don’t have the Maxwell’s equations. We don’t have a powerful practice, but it kind of wants to be a field. I would really like it to be a field. 00:48:04 - Speaker 2: And in order to get there, no one graduates from design school and says I’m going to go into Tools for Though. 00:48:08 - Speaker 1: Well, I mean, some people have that intention, but they mostly don’t, and they mostly can’t. 00:48:11 - Speaker 2: Yeah, can’t is a really good point. I we got a lot of emails that can switch with people saying, hey, I’m about to graduate from this design school or I’m working in a startup over here. How can I get into To this field, I kind of said, well, what field? I didn’t have, I didn’t have anything like an answer for them. 00:48:27 - Speaker 1: I don’t think there is a good answer. Almost everybody who’s been successful, it’s difficult actually to say that anybody’s been terribly successful recently in this space, but anybody who’s had even moderate success has something weird going on. They’re like independently wealthy or they have some cash cow that they’re like milking in order to let them do this essentially economically unproductive activity, or they have like a whole bunch of connections that they’re using. I have been helped in my thinking on this recently by reading uh Nadia Eggbal’s new book Making in Public, which analyzes the economics of open source production, and there are some connections between the the challenges of trying to provision tools for thought, work and also the challenges of trying to provision work on. Open source. They both seem from an outside view to be kind of economically unproductive activities. Nadia’s insight that really helped me and that seems to have some analogs and tools for thought is that it makes sense to separate the way that we think about the economic model of consumption of open source from the economic model of production of open source. So when one consumes open source software, that is a non-excludable resource, so the code is just, you know, it’s available online, you can’t readily charge tolls for it. Uh, it’s also non-rival risk. So you downloading the code doesn’t really like make it more costly for me downloading the code. There’s very near zero marginal costs. The analog and tools for thought is once I like publish that paper. On the great idea I had in Muse. This is a non-excludable resource out there, and it’s also mostly non-rivals, you know, the 100th person consuming that paper and consuming those ideas. It doesn’t really cost any different from the 100th person. But the production looks pretty different. It’s a it’s a small country of people. It’s perhaps excludable, and there are some rivals elements in open source, for instance, Nadia characterizes it as being about attention. The scarce resource for the open source maintainer is their attention, they’re being bombarded by these like requests and like well-meaning people trying to contribute code and so on and so forth and it’s very draining and this actually makes the resource rival risk because the 1,000th contributor to the repository doesn’t cost 0 additionally relative to the 100th contributor. And so one way to think about this that she suggests for open source that I think applies a bit for tools for thought and relates sort of the strategy that I’m pursuing now is we should think about funding production. Than funding consumption. Normally with media goods, we think about funding consumption. Like you go to the store and you buy the shrink wrapped package of software, and see like you’re buying a good, you’re buying an artifact. And when we think about commercializing or monetizing software, likewise, we think about the good or the artifact, or perhaps the services associated with it in the modern world, like I’m going to sell support services if I’m red hat or something, modern models might sell cloud services, but a different way to think about all this is to think about kind of verb instead of noun, funding the process of production rather than funding the The output of the production. This is more common in the arts, somewhat more familiar in the arts. Like if there’s a musician you really like, your contribution to buying their albums or whatever, like it’s probably not earning them very much money, but increasingly it’s a popular thing to like be part of their their fan club or sponsor them or something like this. And when you do that, when you sponsor the musician
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: So we think a lot about how do you give agency back to people, but we think about if this is your web browser, this is your operating system, this is your home on the internet, how do you feel agency over Hello and welcome to Meta Muse. 00:00:16 - Speaker 2: Muse is a tool for thought on the iPad. This isn’t about Muse the product, it’s about Muse the company and the small team behind it. My name is Adam Wiggins, and I’m here today with my colleague Mark McGranaghan. Hey, Adam, and a guest, Josh Miller. Hello. Thanks for being with us here today, Josh. You’re an accomplished entrepreneur and also have a background in both the startup world with Branch, which I think later became part of Facebook, but also you’ve done a stint in government with the White House, if I’m not mistaken, and nowadays you’re working Obama White House just want to clarify that. 00:00:51 - Speaker 2: Fair enough. And now you’re working on the browser company, which is super interesting. Why don’t you tell us what you’re doing there? 00:00:59 - Speaker 1: Sher, thank you so much for having me. Honestly, I feel like I’m at Whole Foods right now doing my grocery shopping routine, listening to this podcast. So, uh, really awesome to hear that intro live and grateful to be talking to you both. My name is Josh, uh, working on the browser company. As the name might imply, we’re oddly fascinated by web browsers. We feel like we spend a ton of time in web browsers in 2020, too much time, maybe, and as we were looking at the kind of arc of web browser technology, it felt like the interface of the web browser and the jobs it did for you. It was fairly stagnant and honestly was just curious about why and what else it may look like. So there’s a group of about 10 of us, uh, in a room together, well, I guess a metaphorical room together experimenting pretty widely about what a web browser reimagined for 2020 might look like. So figuring it out as we go along and really happy to be here. So thank you for having me. 00:01:54 - Speaker 2: We’ve had a lot of informal chats through Twitter and other kind of conversations, but where maybe I really felt like I got my head around what you were doing was when your colleague Nate Parrott came and did a little workshop for the ink and Switch crew to show us the experiments you’re working on, and that was very. Interesting partially, you know, just to see inside the machine and what you’re doing, but also because it seems to me like you’re really taking what I would call a research approach. I think you are a startup or a venture funded startup. Is that the correct characterization? 00:02:23 - Speaker 1: Yes, that’s a correct characterization. I agree with that statement. 00:02:28 - Speaker 2: But even so, it seems like this approach you’re taking these very throwaway experiments while you figure out what your initial product is going to be as opposed to the maybe the more classic mode that I’m used to, which is you start with an idea that you love, you build that until it’s clear that it’s totally unviable and then you pivot to something else when you’re forced to. That’s a different approach. So when Nate demoed to the switch crew and it was really interesting to see those experiments, but he said something. In particular, that gave me an idea for a topic here, which is, he said, OK, we’re not innovating on the browser engine. Things like JavaScript run times and how the HTML is rendered and all that sort of thing. There’s been incredible technology developed on that in recent years. You’re innovating on the interface, all the stuff that goes around that core engine. Can you expand on that for us a little bit? 00:03:17 - Speaker 1: Sure, of course. First, worth noting. I am one of many people on the team, so I appreciate being the representative, but you know, everything I say, I’m trying my best to speak for everyone else doing the real work back in the office. In terms of innovating on the interface, I think the thing I want to touch on first was your comment about the R&D and experimental approach, because in some ways, that’s the core of our product philosophy. Whether or not it’s correct or not for us or others. I think with our first company, Branch, we’re 20 years old. Didn’t know what we were doing. We still don’t quite know what we’re doing, but we know a little bit more. And in our first company much more focused on let’s whiteboard everything, and then let’s mock up three directions, and let’s narrow it down to the best answer, and that will be the best answer and let’s go build that. And I think from our experience and maybe just our dispositions as creative folks, very much believe in that no one has any idea of what they’re doing. And in many ways, some of the most interesting innovations may sound like a dramatic word, but the most interesting progressions of interfaces and software products we’ve loved and we’ve built have sort of been accidental or if not accidental, we never intended them to be that big of a deal or that part of the product or that part of an idea to be that interesting. So from a philosophical perspective, our view on product iteration is bias towards experiments, quick experiments, hacking. Experiments, be intentional about what you’re trying and why, but be open-minded and succumbed to the fact that you don’t really have any idea what’s going to be meaningful and what’s not. So I think that’s generally our orientation, which I should note, we think is great for our specific prompt and our specific team. I don’t think is the only way to do things. And so for I just want to represent that as one viewpoint and one lens which we take to the product problem. 00:05:02 - Speaker 2: I was just gonna support your sort of we don’t know what we’re doing and that’s fundamental to innovation. I like the Einstein quote, which is, if we knew what we were doing, we wouldn’t call it research. So I think of it as a discovery process that doing something new that no one has done before fundamentally means no one can know what they’re doing and you kind of have to embrace that a little bit, have this beginner’s mind, this humility, and just realize that it’s, it’s more of a treasure hunt than a Engineering project. 00:05:32 - Speaker 1: Yeah, I have one story on that note from a mentor of mine when I was 20 maybe. I really looked up to Evan Williams. He was the co-creator of Blogger, you know, really the publishing platform that in many ways popularized what we know is the concept of blogging. Then he went on to co-create Twitter. Obviously we know the impact that Twitter had on publishing in the world, and then went on to work on Medium, and I idolized him in a way when I was 19 or 20 because what passion for a single problem and what from afar looks like he had it all figured out. It was just over the arc of time, he was gonna come up with all the good ideas and just came out of him effortlessly and when we were 19 or 20, I had the lucky fortune of Getting a meeting with him and convinced him to kind of mentor us and invest in our first company branch and invited us to come work out of his office in San Francisco after he left Twitter and was sort of in R&D mode. And we viewed this as this aha moment. We were working on this new publishing platform. It was gonna be a different thing, and we had the Godfather, the genius, the expert that was just gonna tell us how to make it the next big thing, cause here’s the person that knew everything about publishing. And in our first meeting together after we moved to San Francisco, I laid out this 6 month plan with a bunch of questions for him of is it the right plan. And he stopped me, he said, Josh, I hope I didn’t get your hopes up. I have no idea what the right answer to these questions are. And actually, quite frankly, let me give you some advice. I’d be aware of anyone in Silicon Valley that purports to have the answers to questions like these, we’re all just making it up as we go along. We’re all just trying our best. So, let’s keep talking about this. I’m really excited. But I don’t have the answers and no one does. It’s obviously one worldview, but it was a very humbling, informative experience to hear the co-creator of blogger Twitter and Medium say, I’m just trying my best to making it up as I go along. And I’ve continued to subscribe to that worldview and philosophy as I’ve had a little more experience building software. It’s not the only one, but it’s definitely the one that I believe in. 00:07:31 - Speaker 2: Yeah, I can see why that would be really powerful, and there is clearly a skill, a talent, a whole world of capabilities for effectively searching for something new or a better way of doing things, improved technology and improved design, what we’re kind of broadly calling innovation here. So it can be tricky when I do describe this kind of process to others or you hear someone really successful like Kevin. Williams talk like in the story you just told that it seems like, well, we’re just making it up as we’re going along. It doesn’t mean that there isn’t a skill there and a structured way to go about this and discipline that’s needed and that there’s, you know, certain teams that can be really great at doing that and others that struggle more, but it’s a different mindset than this visionary top down. I just woke up one morning with the future in my mind and now I’ll spend the next 10 years building it according to that plan. It’s a very different mindset. 00:08:25 - Speaker 1: I think that’s totally right, and I think I describe it as a spectrum, and either end of the spectrum, in my opinion, is too far, and so one end of the spectrum, as you described, top down, we know the answer, we just have to build it. Other side is, we’re just aloof floating through the world, hoping to stumble across the next thing. I think every team that I’ve known that is extremely effective at interface innovation and Development has their own part of the spectrum, but I think in my experience, I’m curious to hear from you, Mark and Adam, is our teams that are very principled in what they are building for and why they’re building it and opinionated at that highest level motivating factor. So as an example of the browser company, I’ll share two hypotheses that end up becoming thematic buckets for experiment. One is our view is that if you look at the browser in 2020, it’s actually more like an operating system, not in the technical sense of the word operating system, but it’s no longer one of many applications on your computer that you go to momentarily to surf the World Wide Web and track down information. You’re doing all of your work in the browser, all of your apps, all of your documents. And so that’s a hypothesis and a principle, which suggests a certain type of opinionated experimentation and exploration, even if the exact implementation is something that we believe we don’t know and we’re gonna have to find out. I think another one is we think a lot about digital spaces as being analogous to physical spaces, and you think about a living room or a bedroom or an office, and those rooms are supposed to make you feel a certain way, and they may look different, even if they, from a utility or features perspective, all have chairs, you sit in them, you can exist in them. Generally speaking, they make you feel a certain way. That’s not as low level as we have a feature idea that we know is gonna work, but it’s not so vague that we could just build anything and count it as progress. How do you think about this Muse? I’m curious what your principles are. So I mean, first off, it’s worth stating, I know you invited me on this podcast. I’m on this podcast right now cause I am obsessed. With everything that you’re building at Muse, and ink and Switch as well. And I’m inspired by the way you do product development and interface innovation. It sounds like directionally, we’re pretty aligned in the way that we build things, but how do you think about somehow narrowing down the scope of what you experiment on while also leaving open the possibility that you actually have no idea what’s gonna work? 00:10:54 - Speaker 3: Yeah, well, first of all, thanks, Josh. I do think what you’ve described reflects the attitude that we have at Muse and ink and Switch. This kind of goes back to the previous episode where we talked about principled products where I do think you can’t expect to get there with pure brownian motion, you know, just randomly bouncing around. You need some sort of principle, vision, direction, valence, something that kind of tends to pull you and the team together in a unified way in some direction. I think that can take different forms. It could be principles, it could be this kind of postulates, it could be hypotheses, it can be an end goal that’s important to everyone. You just need something that’s kind of pulling people together. Another comment I would make is this idea of balance between theory and practice is also reflected in the literature on technological development in general. If you look at how things have improved in our material world, this is a point that’s made on the Roots of Progress blog by Jason. I’m sorry, I forget his last name, but Jason Crawford. Jason Crawford, there you go. Thanks, Adam. He makes this point that if you look at an empirical matter, innovations that have happened, they tend to be from groups that have been kind of bouncing between the realm of theory and practice, and both of those inform each other. And so I think that is reflected in how we work on software at Mu and Inc and Switch where we have some theories that are developing over time, and we have some experiments, some tests, some engineering, you know, field work, and Those kind of go back and forth, and you can’t expect to get very far just on one of those two legs. 00:12:14 - Speaker 1: One thing I’m curious about that we’ve thought a lot about, and I’m not sure we have the right answer, is I’ve seen some teams where the principal or guiding light is a hypothesis about what’s possible with software, or what’s possible from a product. Some people call it jobs to be done. I think other teams articulated in terms of a target demographic. Uh, elementary school teacher, a back end developer in Silicon Valley. I’m curious as you think about Muse, what I find so inspiring about the product is the tool for thought aspect that can be melded to my own instantiation of tools for thought and what I want to think about. I can imagine that direction is also difficult at times to know who you’re building for. How do you think about that balance between what and why, who, and I’m, there are other vectors I’m not covering. How do you think about that? 00:13:07 - Speaker 3: So there are some direct answers I can get to that. Maybe I’ll actually give Adam the chance to kind of articulate the specific things that we think about there. But I would also point out that I don’t think we can actually always expect to be able to articulate what’s drawing us in a particular direction. This is a kind of Hayekian idea where you Yeah, the hunch thing is a big part of it. 00:13:26 - Speaker 3: Yeah, just because something can’t be written out in words or articulate doesn’t mean it’s not there in people’s implicit knowledge. And so that points to another. The thing we very often use to draw us in directions, which is the energy that an individual person has for some idea. And that often just ends up being a quite good predictor of promising areas. 00:13:43 - Speaker 1: I’m so happy to hear that because I wasn’t sure if I was going to share that part of our process, because it’s true to us, but I don’t know how quote unquote good it is, is we are so motivated by the energy and emotion of the team, maybe to a fault, but I think, you know, I previously worked at Facebook and I think that a lot of large organizations, they’ve codified their approach to product development. This often may look like a design document that has a goal, problem statements, set of assumptions, input data, and you almost have to justify what you work on in a relatively formulaic way, which I think is extremely effective. Again, I think there are many ways to build products. We find ourselves a lot, oftentimes all of us are the plurality of us coalescing around a single idea or direction. And oftentimes, as you point out, it’s hard to justify it empirically, and it’s just something feels right, or we’re energized by it. In the early days of the browser company, we’ve definitely been driven a lot by that. It’s felt great so far, but it’s definitely a different posture that I’m sure has pros and cons, but I’m excited to hear that Muse works that way as well, because we found it to be really fun and fulfilling. 00:14:48 - Speaker 3: Yeah, and to be clear, you often have this raw data that’s influencing these opinions. So we have some use cases that we have in mind. We have some archetypal people that we’re working for, we have some technology theories, and those end up influencing the directions that we’re personally excited about pursuing. It’s just that you can’t always expect to be able to formulaically in close form, describe, given these inputs, here’s the function that determines where you should go next. Totally. 00:15:13 - Speaker 2: Mark and I might have talked about this before, but I think of the active entrepreneurship and product creation, which to me the building the company that builds the thing and building the thing is one unified whole, but there to me it’s about half and half or for me to be satisfied with the result. I think it has to be this balance of practical business needs to have customers and solve a problem they have in a way that’s useful and fits into their life for. Price that they find fair and that you have a reasonable distribution channel and all those business fundamentals, you have to have that, but then it’s also an act of expression, artistic expression. There’s something inside me that I want to express, something meaningful that I have to say, or me and my colleagues, part of the reason we’ve banded together is we think we have a thing to say together, we share some values or some sense, this hunch, this drive to make something that doesn’t exist in the. and I think that part of it, it really is like an art project, like painting a painting or writing a book or or something like that. You just have a thing you want to express, but part of the fun, intellectual challenge, satisfaction, but also hard part is actually balancing those two things together. And so it does mean on one hand, for example, following that energy that you’re both describing that feeling of like this seems right, there’s something here, let’s pursue this. That that building what’s in your heart is the way that my colleague Ryan sometimes put it. I think you have to do that, but you can’t do that at the expense of building a business that has those fundamentals, or you can, but you know, that works until the VC money is gone and then you won’t get more of it. So I think it’s that balance between the two that’s what makes this act such an interesting act of creation. 00:16:53 - Speaker 1: I think the discipline that balances this very well at their best are architects. So for example, we’re working on collaborating with the architect David Adjay. He designed the Museum of African American History in Washington DC and if you look at the building, it is very much an artistic expression. There’s a story behind it. You feel Adjay’s personality in the building, you feel his heritage and the heritage of. People he’s commemorating in the building. And you better believe in Washington DC at a publicly funded museum, there are some budget constraints, and there are some ADA rules to comply with, and there are bathrooms to build, and so I don’t yet know, and I don’t know if I’ll ever know how they do it, but I think architecture, not only for the analogies between digital spaces and physical spaces, but I also think for the mixture of practical realities. Jobs to be done, combined with artistic expression and emotion and personality. I’ve always admired how the greatest architects seem to tread those very, very well. 00:17:55 - Speaker 2: I see a lot of parallel there as well. I’ve read a number of architecture books less because I want to ever design or build a building and more that I see these really strong parallels and on one hand, yeah, you’re trying to express something beautiful that is art or can be, but at the same time, your building has to stand up. It can’t go down when the earthquake hits. People need to move through it. People have physical dimensions that need to be accommodated. Air needs to flow through, light needs to come in. Right? 00:18:19 - Speaker 1: You need HVAC. HVAC’s not pretty. 00:18:22 - Speaker 2: Yeah, exactly. That brings to mind. I’m looking at some images here of the museum you mentioned of course I’ll link that in the show notes. It also brings to mind. I saw this fellow, Danish fellow Jark Ingalls, I think. The name speaks some years ago and the Netflix show Abstract had featured him in an episode, and he’s a really good example of almost avant-garde, very kind of forward thinking to the point of being quite weird sometimes with his designs, but also really Sort of challenging the status quo and again, same thing listening to him talk about each building and sort of what he was trying to express through that and how that fit into the time and the cultural moments and whatever else felt very close to some of my motivations when I start companies and build software. 00:19:05 - Speaker 3: Yeah, and also to connect this architecture topic a bit to interfaces, it reminds me of the book A Pattern Language by Christopher Alexander. So this is a book that basically catalogs patterns and architecture from the very small to the very large that Alexander had observed as being successful over decades and hundreds of years of people interacting with buildings. So the very small scale it might be that people really like to have shelving at waist heights. That’s kind of where you conveniently put stuff. At the very large scale, it’s like your city should have greenery accessible to people within, I don’t know 10 minute drive or something. And the patterns in the book are very interesting, but also the way that he arrived at these understandings, which are basically about interfaces between people and buildings, is observing, it’s kind of this like archaeology of what has actually worked over the many years that people have interacted with buildings. And I think it’s interesting that with software, we’re now getting enough data where we can do that, and instead of having to invent things from first principles, we can say whenever people use software. They really want to like cut out stuff and like put it somewhere temporarily and hold it. And that’s something that it’s really important that software does. And you don’t need to invent that idea from first principles. You can just observe that people want to do that all the time. I think there’s a lot of opportunity in there that can draw on this kind of pattern language type thinking. 00:20:15 - Speaker 1: I think that’s a great connection and making the connection back to interfaces again, a thing we and I have struggled with is When do you reinvent the wheel? When is it worth questioning the interface, given that there are these patterns in the physical and digital world that over some number of years, decades, we have proved work extremely well and evoke a certain type of feeling or action. When do you question them and when do you accept them? So in our first company Branch, you know, being 20 reinvent all the things. You have a follow button, we have a watch button. You have vertical comments, our comments branch to the side. And it felt like, because it can be so exciting and tempting to question and reimagine interfaces because they are spaces and touch points that we encounter so much in our day to day life. There is an excitement to the novel, and there’s an excitement to the new. But as I learned, and you’ve probably learned, I think the more advanced or accomplished product designers are the ones that know what to focus on, and they know what are the highest points of leverage in the interface, or what are the parts of the interface that are. broken and deserve reinventing. And so one thing common conversation we have at the browser company is, should we be reinventing the wheel here? Is this the right place to focus on pushing the boundaries? Again, I cannot purport that we have a good answer to those questions yet, or that we’re experts on this topic. But I do think it’s a temptation and a talent to know when do you rely on Christopher Alexander’s-esque observations about patterns that are wonderfully human, and when do you question whether or not we’re doing things the right way. 00:21:58 - Speaker 2: To even ask the question, when do we reinvent and when do we go with the known pattern is the right place to be. I think there’s a natural tendency certainly goes with youth. I was there as well at age 20 which is you just want to blow up the status quo because that’s like in your spirit at the time. That’s what young people want to do. And definitely entrepreneurs, I think, are by their nature, people that like change, novelty, new things, shake it up, try something new, blow it all up, and then you have others who Maybe you’re more stasis oriented, like to conserve, protect, go with what’s working, tradition, that sort of thing. And I think the art is to learn to step back from either of those tendencies wherever you may naturally fall and instead try to analyze where is there opportunity, where is there something that society can really benefit or individuals could benefit from a reinvention and a rethinking versus we have a known pattern that works and, you know, stick with that. 00:22:55 - Speaker 1: On that note, earlier in my career personally, I think I fancied myself more of an artist. I’m giving myself a little hard time and being a little self-deprecating, but I think I viewed things like revenue strategy and business model and market structure as being things that corrupted the creative process and the innovation on interfaces process. And I spent two years working at an investment fund. Observing the sort of startup technology landscape from a venture capital perspective. And one of the things that struck me is that some of my favorite products from uh innovation on interface’s perspective actually fundamentally took advantage of business model innovation and misplaced incentives in generating the product experiences that I, from an emotional perspective, fell in love with and changed my experience. We’re actually driven from looking at where companies Incumbents were making money saying, wait, that seems a little flawed or perverse, and extrapolating from there. And so I think even that’s interesting to say, even if you care about feelings and emotion and the way buildings hit the street, sometimes to know where to focus can come from something that could be as boring to some as, well, how’s the incumbent making its money? What incentives does that cause? One example from Facebook, Snapchat, one of its core innovations, was opening to the camera. And, you know, it’s hard to imagine that. That was a huge deal. Talk about interface innovation. It broke every rule in the playbook of social networks. 00:24:27 - Speaker 2: I was actually going to cite that exact one, which is in the Snap S one, they actually articulate this pretty well, which is they consider the camera in the phone to be the most important interface, and they lead with that on absolutely everything from their little snap codes to the fact that the apps open straight into that. And it’s more obvious now we live in a world where smartphone cameras really are this cruel. crucial input device alongside touch screens and keyboards and whatever else, but probably at the time you’re talking about, that was quite a shocking idea. 00:24:58 - Speaker 1: Yeah, and I don’t purport to suggest that Evan Spiegel was motivated to put the camera first from a business perspective, but if you have an incumbent like Facebook who monetizes through showing ad units in a news feed right when you open the screen, structurally, they are not incentivized and it will be difficult for them to compete on that vector. We think about this at the browser company. As you mentioned earlier in the podcast, Chrome and the Chromium team specifically is responsible for insane technological progress on the browser front, and we’re building on the backs of that and grateful for that. From a business perspective, Chrome is useful to Google because it’s lead generation for search ads. The more you use their web browser, the more you use the internet, the more you’re gonna do searches on Google. The more searches you do on Google, the more ads they can show you. And if you talk to their the Chrome team members, they’ll even explain the genesis of the Chrome team was not that they wanted to go into the browser market. They just thought Internet Explorer was so shitty with all of its IE toolbars, that it was making the internet experience poor. And if the internet experience was poor, you’re gonna do far less Google searches. And so that’s interesting and at the time that was novel. Flash forward to today, Google and Chrome are not incentivized to make a more feature rich. Powerful web browser that stretches the definition of what a web browser is, not because they’re not capable, not because they’re not creative, but their incentive structure from a business model perspective is one in which they just want you to type little searches in that URL bar as much as possible. So if you open 40 tabs, that’s 40 potential Google searches, and so it’s not that clean as anyone that’s listening to this podcast that has worked at a large organization like Google. I’m dramatizing a bit, but again coming back to interface innovation. And where do you know where to focus? I agree that often that comes from energy, often that comes from principle and product hypotheses, and oftentimes it might come from looking at the market structure you’re competing and say, where is everyone else weak, where are they incentivized, and what sort of perverse side effects does that lead to? 00:27:04 - Speaker 3: Yeah, this is actually a big part of the ink and switch and muse origin story where we had observed the economics of the industry were very heavily rotated towards a social slash advertising and be enterprise sass, and those were the most obvious things to make. economical and so the lion’s share of work in the industry was being put behind those to the exclusion to our mind of classic creative computing for individuals. And so we saw an opportunity product wise that was like you said, kind of created by the economic dynamics. 00:27:34 - Speaker 2: I think it’d be interesting to return to the item you brought up earlier there, Josh, about the kind of operating system, the web or the web browser is kind of a set of operating system primitives that sort of exists separately from the host computing operating system. I strongly agree with your characterization there that the web is kind of its own OS and in fact OS. It has a really specific meaning in terms of kernels and. Vice drivers and things like that, but I think of it more as the operating environment or the way in which the mental models and the set of primitives that you interact with. So on classic desktop computers, that’s things like copy paste, files, mouse cursor, maybe on Mac OS you have the menu bar at the top or on Windows, you have the start menu in the lower left, and then the web and the web browser has its own set of those core primitives that includes URL. includes something like the back and forward button, maybe something like tabs was a major interface innovation that came from the sort of Mozilla Firefox early days, and I see a similar thing for Muse as well, which is for Muse I see something similar, which is I in many ways envision Muse as kind of being a reinvention of the file browser, something like the Mac OSinder or even. stretching back to the DAS days, something like Norton Commander, the files, I think are this cornerstone primitive in how we interact with computers, particularly how professionals interact with computers, but in many ways they’ve kind of aged to the point and become very static in a way that they haven’t really made this jump to, for example, the mobile world very well. And a lot of the way we think about Muse, or at least I do, is as taking this set. Of things that typically are part of the operating system, essentially how you manage your digital stuff which is expressed as files on a file system, but bring that into a mobile touch, you know, more visual interface. What can we bring forward that works really well about files and then what are things that maybe we want to leave behind and embrace more modern elements that have been brought to us from, for example, the touch environment. So I’d love to hear what you see as being the areas your team is either currently working on or just most excited to innovate on in terms of the browser as a set of operating system primitives. 00:29:51 - Speaker 1: Sure. So we think about the answer to that question really is a series of observations, and really the observations that guided us wanting to start this company. Some of those observations include, if we looked at our Mac OS docs and we looked at the quote unquote local applications we use the most, obviously they were all internet-based, but they were also all built on Electron, which meant they were secretly just Chrome, which means we were running 7 versions of Chrome on our computer instead of just a single browser. So that was interesting. 00:30:20 - Speaker 2: And just for listeners that might not know it, Electron is kind of a container that lets you run a web application as if it was something native to Mac OS or Windows. 00:30:31 - Speaker 1: And it’s an incredible technology in the sense that as a budding group of developers, you get a ship a cross-platform application that feels native to the operating system without writing native code. And so grateful for Electron, we’ve prototyped an Electron. It’s a great technology. But as you’re pointing out, we actually ran this early experiment where we launched the Notion app. We use Notion. I love Notion. The company runs on Notion, so this isn’t a criticism, but we launched the Notion Electron app, the local quote unquote Mac app, and then we built a prototype of our browser which was just the pure internet. There was zero browser Chrome, and we loaded Notion in that, and you put it side by side, and it’s almost indistinguishable which one is the Mac app and which one is the local app. That doesn’t suggest what we’re building, that doesn’t suggest how to make a better browser, but it just struck us as an observation as, huh, hmm, that doesn’t seem like it makes a ton of sense. Another one is, if you think about Mac OS, you talk about the file system. A large reason operating systems exist is to help us manage our files, and that files mean more and more things, but all of our stuff. I observed again. Just for me, I feel like I live in a post upload world. My files are all permalinks, random strings of characters that I enter in my web browser. I have Figma URLs, I’ve notion URLs, and so on and so forth. And so even from a file and folder perspective, I’m looking at my desktop right now. I got nothing but a conglomeration of screenshots that I wish would go away and I didn’t intend to be there. All of my files are in the browser. And so on and so forth. So I think, you know, I was a sociology major in college. I’m inspired to work on technology and software and interfaces, not because of the technology, but because of the people. And so I think as we just observed how people are already using their desktop computers and how they’re already using web browsers, it just invoked a series of questions and observations that, again, we’re trying to answer, we don’t have answers to yet. We may never answers to, but just struck us as almost cultural shifts in how we use technology that may just maybe may warrant a new browser interface that could look more like an operating system. But at the end of the day, my wife, my mom, my niece, I don’t think they care at all about the word operating system. And so we also think a lot about what are the metaphors or what’s the right way to talk about the scope of our work that is not just geared towards people on this podcast. 00:32:58 - Speaker 2: Could you give us a hint of some of the stuff you’re working on? I noted here on your recent tweet of comparing kind of a browser to a figma canvas. Obviously things of spatial zooming interfaces are of particular interest to me. I think again your colleague Nate there tweeted some short videos that he used at that. You want to speak to that or give us another example of what sort of things your team is doing to try to push the boundaries or to try to improve what a browser experiences for a power. 00:33:27 - Speaker 1: Sure, I think first and foremost, I’ll plug Nate Parrott, a designer on our team who, one of the things he does, which I love, is we share, I don’t want to call them failed experiments, but past experiments that we learned a lot from, but weren’t quite right. 00:33:42 - Speaker 2: The primary output was learning. Yes, exactly. 00:33:45 - Speaker 1: That’s what we talk about those. Exactly. So if you’re curious, I think better than my terrible radio voice, I check out Nate’s Twitter account and he shared a series of these, and we’ll continue to share more. I think that just building off of the canvas prototype that you reference, what Adam’s talking about is we prototyped a view of a web browser, which is, imagine all of your web pages or tabs, lay down, if you spread out a big white sheet of paper on the table or desk in front of you, and each 8.5 and 11 piece of paper that you plop down on it was a web page, what if that was your interface for navigating and interacting with the internet and your web browser? Because it was tweeted, it did not quite work, but I think, you know, one of the themes that that touches upon is an observation we made about the way we use web browsers is when the concept of a web browser was originally popularized 25 years ago. The internet was a document network. It primarily revolved around retrieving and finding and reading information. 00:34:45 - Speaker 2: Sure, well, I mean, it was invented by a physicist working at CERN that wanted a way to share his research with other researchers, right? 00:34:52 - Speaker 1: And it was wonderful. And however, in 2020, I’m doing everything in my personal life in the web browser. I’m doing everything in my professional life in the web browser. In my professional life, for example, that can mean focusing on a specific task and writing a long document and not wanting to be interrupted. It could be going on a rabbit hole late at night. Probably some of the topics we’re talking about today. I’m gonna go Google them later, and 8 hours later, I’m gonna end up in some random Wikipedia link. And given the breadth of parts of our Life we turned to the web browser for. And given even within those parts, the different modes or moments that we rely on the browser, it just seems silly that every incumbent browser was a one size fits all. The window never changes, the tab bar never changes. It’s all the same all the time, completely consistent and unchanging. Which could be correct, you know, the counterargument to this perspective is that there’s some solace or comfort in the fact that you know what it’s gonna look like. Our view is, if you take the analogy to the real world, sometimes you want to read in your bedroom, sometimes you want to read in the living room, sometimes you wanna host a party in the dining room, depending on what You’re doing and what part of your life and the time of day and how you’re feeling, you might want different spaces. And so what would that look like in the web browser if there was no Chrome whatsoever? What if there was nothing? It was just a pure web page. What if you had 28 web pages tossed onto a table and you could move them around and see them spatially? What if there was a view to, you know, manipulate 13 at a time and take bulk actions and move things around and export them and I’m kind of making this up as I go along. I’m not suggesting that our final product or current product has all these things, but that’s an example of starting at the top level principle, how we end up going down, down, down to prototype that might be, what would FIMA look like if it was a web browser, for example. But what about a use? I think you are tackling an equally broad and large surface area. So how are you? in recent days prioritizing what you work on. 00:36:51 - Speaker 2: It’s hard. My experience has always been if you’re working in a company you’re on a product that has a lot of possibility, it’s very fertile territory, and the biggest problem you have is in fact being pulled so many directions because there’s so many great things you could make, or as I think there’s a quote somewhere that’s great startups die of indigestion, not starvation. We definitely feel that in MS, there’s so many directions we want to go from new kinds of content type, video and tweets and lots of other things we have on our list, but there’s a whole other track that has to do with kind of collaboration and sharing, whole other track that maybe has to do with kind of programmability, whole other track that has to do with much more powerful kind of spatial manipulation and non-spatial manipulation, and it’s all really good and all potentially really valuable and You know, that’s even combined with the small things that users are asking for, at least once you, you know, are to the stage that we’ve been at for a little while now, if you have a pretty solid user base and they’re using it for real things in their daily life and there’s a steady stream of bug reports and small feature requests and things like that. So it’s tough to find the right thing and keep your focus, but you really do, especially with a small team, you know, we’re 5 people and don’t really plan to expand beyond that foreseeable future. It’s so critical. To come together, consider all the options, but then pick a thing and say, we’re gonna do this for a little while because we think this is a really compelling space. We like to kind of time box that. We’re gonna spend 2 months going really deep on one theme, see how far we can get on that, and then step back and, and see what we’ve learned. 00:38:20 - Speaker 1: Yeah, and it’s worth noting for us at least, as much as it’s fun to talk about these heady directions and observations, and it’s earnest and genuine. At the same time, if my team was here, they would point out that some of our favorite features and honestly favorite themes of directions have come from very quote unquote uninspiring simple couple hour feature development that actually turned out to feel a lot better than we thought. I’ll give you one tangible example. We multitask a lot in our browser, as I’m sure everyone on this podcast does, and we prototype the ability to click a tab and drag it and drop it on another tab and automatically create a split screen mode that you can move the dividing bar left and right and kind of adjust the view of the split screen. Drag and drop for split screen, not inspiring, no one’s gonna come work for us because of that. And it was fucking fantastic, and one of our most used features, cause guess what? What do people do today or some people do? They open a second window, they resize both windows and do this dance where you pull that corner up and that corner up and so it may not be part of a connection to architecture or anything that gets us really excited, but turns out it’s damn useful and the fact that it was that useful, even if it was that small, suggested a kind of direction to keep exploring. So I think it, it would be honest, most honest to also mention that it doesn’t always come top down from themes. Actually, I found more successfully it comes from tiny little features and extrapolating, like, why did that feel as good as it did? What does it suggest and you go that way? 00:39:57 - Speaker 2: Yeah, well, I think the bottom up extraction of the pattern and that there is a bigger theme there that points to an underlying need that maybe you could double down on. It’s not, hey, we just made a small random thing and it happened to work, maybe sometimes that’s it, but probably someone on the team followed a hunch or did something according to what they saw from user behavior. It worked out way better than expected, and then you can stop and reflect on why. Why did this work so well? Why is a side by side of two tabs? Why is that? Key to how people use the web and what can we learn from that and maybe there is a bigger theme we can work up to from there. 00:40:30 - Speaker 3: It’s funny that you mentioned fluid multitasking. This is something that we’ve studied a lot in ink and Switch and Muse because our user research has shown that’s very important for the creative process. It is an overwhelmingly common thing that you do. You have a few documents open, you want to read them and put them at the same time. But notably, it’s still an unsolved problem on iOS. You basically can’t really do good multitasking on the platform, even on the big i. Ads. You can sort of get these sort of split screens, but they’re not fluid and they’re really hard to bring in, and they kind of go away when you’re changing them and they come back. That’s also interesting because it, uh, it’s, it’s very much dictated by the platform. So on the web, or web-based platforms, it’s quite straightforward to add a horizontal split and to fluidly move it. It’s kind of built into the engine, whereas an iOS, as it is kind of a platform thing, and if you want to do it in a way that would incorporate multiple apps you need, basically the platform’s help. So it’s a different beasts. 00:41:16 - Speaker 1: Operating systems rearing in their head. Yeah. One thing I’d love to get your guys' advice on, uh, since I have you here, is we had an experience recently where we prototyped direction that we were super excited about, didn’t work, clearly didn’t work. There’s some things about it that we liked, but all in all, considered it uh let’s move on. Couple months later came back and had this inkling that maybe some things had changed in our product that might suggest this feature would work again. Tried it again, and I think specifically took it to a much higher fidelity than we had previously, and all of a sudden, I think it’s the coolest thing we’ve built so far, not to tease too much, but the larger question is, as a team that experiments widely and quickly and iteratively and is not afraid to take the research process, which means tossing stuff out. Any tips for how do you know when it didn’t work because it’s not gonna work, and it didn’t work because you didn’t take it far enough to master the fine details that as we know from our favorite software products truly matter. It’s just this experience, which was an accident, and again, I don’t think we did well. Makes me wonder what else we’ve missed just because we didn’t take the extra week to do that extra design polish or animation or rev on a slightly different iteration that we were so close, but we gave up because we took the wrong conclusion. I know these are very broad questions and so, you know, maybe there’s a specific example that comes to mind, but I think that’s the risk of being a team that doesn’t take to high fidelity and to user ready production code with every iteration is that some really great ideas need that in order to work. 00:42:56 - Speaker 2: Also a really tough one. I think it is largely an act of judgment or even taste, probably something you develop with experience over time, but yeah, I’ve been in that exact position many, many times and Yeah, maybe people point to that. I can think of high profile examples on that. This is more the product level than the prototyping level, but maybe it’s a larger scale version of the same thing. Why is it that Slack was this breakout success when we already had hip chat and campfire, and most people would just say Slack was just nicer, it was just better executed. They just took it a bit further and Really put that extra polish on it. And you could point to some features or whatever, but it just had this higher degree of craftspersonship, maybe more love put into it, more attention to the user experience. It turned out group chat is this incredibly useful and central thing for many and most teams. Yeah, Slack just kind of broke through that boundary. Another one for me that’s like that is back when I was first living in San Francisco and realized pretty quickly that a car, private car ownership was not the way to get around, but public transit was weak and whatever else, and I eventually realized taxis are a pretty good way to go when you need to get across town, but it was really hard to call one and I thought, why doesn’t someone have an app to do this? Why can’t I just press a button and summon a car to my house and I can use the GPS on my phone to know where I am. And then I was delighted when I came across someone actually in the Ruby community who was building this exact thing. I think it was called Taxi Magic, and they hooked into the dispatch system and they would summon a taxi for you. And they even had a little map that tracked where it was. And I used it for a good while because I really wanted this product to exist, and I really believed in it and they did pretty well, but ultimately it was just kind of not a great experience and the taxi would get lost and it would take a long time or the address wouldn’t be right. And so I tried to stick with it. Then Uber comes along and they just nailed the experience completely, partially because they weren’t using the dispatch system. And that was for me and clearly lots of other people, this revelatory moment of like, wow, it turns out calling a ride from your phone is really, really great, but they didn’t execute far enough or they didn’t take it far enough to find that out. 00:45:03 - Speaker 1: One example for me that I’ve been thinking about recently is I had this moment with superhuman. I’m not sure what listeners think about superhuman, but I have found it to be a better email experience for me, putting aside the cost. I work in email in an unfortunate amount, so I probably am more attuned to the little details and bells and whistles, but I was just floored by how fast I felt, how productive I felt using it, and my colleague turned to me and enumerated how every feature I was describing has been in Gmail for like a decade or something. And somehow superhuman tied it together in a way, I don’t know if this was marketing, if this was design polish, if it was interaction design, if it was, I mean, who knows, but I think it’s another great example I’ve been thinking about of it’s not just about building the correct features, it’s tying them together in a way and with a level of polish that I don’t know, has that special quality to it. And so it’s one thing to think about a production email client that you’re charging $30 a month for, but how do you know which need that extra level of polish in order to kind of break through and which things like there’s some features we’ve built where it’s, this is just so damn broken that it could be ugly, and People would flock to it. And I think those are some of our most favorite beloved products were ones where you see V1, you’re like, that was the first version of Acme Co. but it turned out itself such an acute need that we didn’t need that last mile. But I think superhuman relative to Gmail is an example of where, like, wow, Gmail had it. I guess they’re doing fine. We shouldn’t feel too bad for Gmail, but at least at a personal level was a snooze is not new, it turns out. 00:46:45 - Speaker 2: Another piece of your anecdote about building something, not working, setting it down and coming back later, and then finding it does work. That’s something I’ve experienced a lot in my career. 00:46:57 - Speaker 3: Adam, isn’t this one of your Hiroku rules? 00:46:59 - Speaker 2: Uh, could be. I have to look it up. Yeah, certainly we talked there about throwing things away and that sort of thing, but timings, timings. That’s what it is. 00:47:09 - Speaker 1: Speaking of timing matters, yeah, I’ve been really curious at a personal level, and I think this applies to you, Mark. How the both of you ended up trying to innovate on interfaces when previously working on a company like Hiroku or I believe Mark, you were at Stripe previously among other jobs. Not that those products did not have great interfaces, but I assume the podcast about why Hiroku worked or Stripe worked would probably be a different number of topics than the ones we’re discussing today. So I find it really fascinating and interesting that both of you have gravitated towards Muse and the interface challenges you’re working on. Curious to hear what, if anything changed, if I’m thinking about it the wrong way, if, you know, how did you two get here from where you were before? 00:47:52 - Speaker 3: Well, there is more in common than you might think. So those are all basically tools, and there’s a lot of generalized tool thinking that goes into all three of those companies, I think, as well as obviously, you know, building software companies. But yeah, then in terms of timing for me, I mean, a lot of it was, I had fully experienced the world of enterprise, and there’s a lot of great stuff there. And obviously it was how I started my career. To be really honest, I just wasn’t thrilled about looking at Gmail and Google Docs for the rest of my professional career. I just couldn’t see myself being really excited. About it. And at the same time, Adam and team were working on ink and Switch, where they had kind of the other piece of that puzzle. They saw this opportunity for developing software that’s about enabling people’s creative potential. And that really resonated with where I was at the time. And then of course, I loved working with Adam before at Hooku and I definitely want to do it again. 00:48:39 - Speaker 2: Yeah, I feel like there is a pretty strong connection to, yeah, work you did at Stripe around say APIs as well as at Hiroku. Speaking for myself, I certainly have gotten from a lot of folks that it feels like a non sequitur to go from cloud developer tools to call a productivity iPad app. And there is obviously some big jumps to make there. There was a lot of education I had to give myself. In order to learn about building apps on a mobile platform by comparison to the web stack that I spent a lot of my life on. But to me, there is a really a through line and a connection, which is it is about tools and enable people’s creativity and productivity, and that just gives me a thrill. And I would say at Hiroku, a huge part of that was the interface. We had to build a lot of infrastructure. Make the interface that we wanted, but I knew that I wanted this idea of servers and configuration files as being the main way that I get my software in front of my users and needing to go fucks with those every single time I want to ship a change to them didn’t feel like the right interface anymore. So I think of Haruku as primarily a whole other interface, and that of course also led us down this path of command line tool. And this kind of term developer experience, which I don’t know if we invented that, but I think we had a lot to do with popularizing it, which is the idea of, OK, just because you’re building an API or a command line, those things are very technical tools and very technical interfaces, but you can still bring the user experience design ethos that I think at the time, now we’re talking 15 years. Back was kind of on the rise with maybe more consumer products, but then you can take that same thing and say, well, developers are people too. They like nice experiences. They like tools that are easy to understand and use that serve their needs well, and they like different kinds of experiences, text-based experiences and keyboard-based experiences, and they’re comfortable learning technical things that maybe a lot of more non-engineer users would not be comfortable learning, but You can bring those same principles to bear there. So I think of Haruku very much as an innovating on interfaces and the tools for Creative people company, and then Inkot Switch was a research lab that worked on those things as well, and now Muse is, it happens to be on this other platform and have this other kind of business model, maybe even a different kind of target user, but fundamentally there is that through line that ties it all together. 00:51:03 - Speaker 3: Yeah, and back to timing. I didn’t understand this when I first started working with Adam and team at the lab, but it was definitely a big influence in deciding to go off and do Muse. Muse is really riding a particular technology curve. So if you look at what has happened and especially consumer and gaming, which drives a lot of the individual level of technology that we see today, you could basically plot the size, density, refresh rate, and responsiveness of touch screens over time. And if you Kind of draw those dots out a few years, you see something like, we should have a kind of small desk size touch screen that exists, and it’s quite good. And in that world, what is the software that powers it? And it definitely wasn’t a big phone. It wasn’t a desktop transliterated onto that thing. And I wasn’t convinced it was the iPad is currently existed then several years ago. I felt like you needed something quite different, and we saw a particular timing opportunity with Muse to go and try to build that. 00:51:59 - Speaker 1: I think there’s also something interesting about, I love the way you talk about both of your stories is actually there being a through line, and they’re not so different as portrayed. And I also think there’s something interesting about the merging of worlds and perspectives. It’s one thing we’ve thought a lot about because if you had told me I was going to work on a desktop web browser in 2020, 5 years ago, I would have laughed at you. And actually, quite frankly, the origin story was the browser company was supposed to be a web browser for work specifically and an enterpriseas tool, and I actually gave the idea to my now co-founder and former co-founder Hirsch, and I said, I think it’s really boring, but I think it’s a great idea. You should go work on it. I’ll fund you. And that was the original intention. And then as I started collaborating with him from that original relationship, I realized that the web browser was one of the only pieces of software that is in the middle of the Venn diagram of tools and apps that my mom uses, my little niece uses, I use. The web browser is. Almost the most consumer tool out there. And I hadn’t really thought about it that way before. And, you know, we’ve hired people from Instagram and Snapchat and take a very consumer lens. So I think what you would say, our desktop web browser, we probably rely on more for work and getting things done than fun time on a Sunday these days. So anyways, I just think there’s something interesting in both of your stories and how you arrived at Muse and what you did before, as well as kind of how we think about the browser company, which maybe some of the more interesting interfaces we’ll find out, arrived from multidisciplinary teams that bring the intersection of different experiences that others may see as not compatible or different, but actually there’s an interesting through line, as you said, Mark, that ties them together in some way. 00:53:42 - Speaker 2: Josh, do you feel like there’s a theme or a narrative arc in your career, you know, going from social media space to government to now reinventing the browser? 00:53:54 - Speaker 1: It’s definitely the sociology major in me. I was a pretty poor student, so I wouldn’t say I’m a good sociology major, but I’m a people person. I literally was sitting back 90 seconds ago thinking, man, the internet is so fucking cool that I met you guys through the internet, reached out cold. We’re now having a podcast, having a topic about something that I would love to geek out more, but I don’t feel like I have an outlet to do it. And so what drew me to technology is like this podcast is happening right now and how cool is that? And I think I am driven by people and what we do and what we do together, and That’s what drew me to, you know, I also did urban studies and urban planning in college. I just like the meeting places of people and the ways in which we come together, and I think the internet’s one example of that. Public policy and our government’s one example of that, and the civic Commons, a web browser is one of those things, and so I think that’s the through line for me personally. I mean, I’ll tell you a quick story about the way I even got into technology. I was interning for my senator. I did random internships. Definitely never thought about technology. And then a professor from Harvard came to guest lecturer named Robert Putnam, and he wrote a book called Bowling Alone. And Bowling Alone is about social capital, and the decline of social capital and these kind of meeting points in the real world where you bump into your neighbors and fellow citizens, and what that is doing for society. And I was just floored by it. And I went up to him after and I said, Hey, Professor Put. I’m Josh. What should I do with my life? And he sort of said, I don’t know you and I have no idea, but if you liked my book in this lecture, there’s this entrepreneur in New York who started a company after he read my book and he was inspired too, so you could go work for him. And that company was Meetup and that entrepreneur was Scott Heiferman, and I went to intern at Meet Up, and the first day at Meetupp, I went to an all hands, and Scott got up on stage and gave this impassioned lecture about the internet was bringing us together and we were turning away from banks with Kickstarter and it was bringing us together and we were turning away from universities and it was a little idealistic, and
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: I cannot overemphasize the first run experience, that’s when you have the most energy and the most enthusiasm and momentum coming from the user. 00:00:14 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for thought on iPad. This podcast isn’t about Muse the product, it’s about Muse, the company and the small team behind it. My name is Adam Wiggins, and I’m here today with my colleague Julia Rogats. 00:00:28 - Speaker 3: Hi, Adam, nice to be back. 00:00:30 - Speaker 2: And a guest, Jane Portman of User List. 00:00:33 - Speaker 1: Hi, Adam. Hi Julia. 00:00:34 - Speaker 2: And Jane, maybe you can tell us a little bit about your background and what you’re working on at user list. 00:00:39 - Speaker 1: Well, thanks for having me today. My pleasure to share a little story. User list is a tool for sending activation on boarding, life cycle, email and other kinds of messages to Sassy. Users, so we work specifically with SASS founders and provide great tools for them to run their SAS companies. And uh user onboarding that we have as a topic today is so hard for us because that’s like the primary application for our tools. So we’re sort of on a mission to try and help founders establish their better onboarding practices. 00:01:13 - Speaker 2: And just because I always like to unpack abbreviation, SAS stands for software as a service, so this typically would be web applications, often ones that are sold to businesses rather than either consumer applications or mobile apps or iOS apps such as Ms. Yes, that’s correct. What was your journey? What brought you to be passionate about this area or be working on this particular company? 00:01:38 - Speaker 1: So if we go back in time a little bit, this is my 2nd SAS product and I’m running this one together with my amazing technical co-founder, Benedict Die. He’s a real engineering wizard, like I would never pursue this conflict of a product without him. When I was doing my first product, which was a little productivity app that didn’t go anywhere because it was not as crucial to the business, it didn’t like have a major mission, it didn’t have a good audience, and also while I was running it, there was no great tool that I could use for life cycle messaging, for user onboarding, etc. except for Intercom. Which back then wasn’t even pretty, to be honest, so it was super expensive, not very attractive, and it was not targeting small founders like myself. So a couple years later, It was pretty obvious what to build because I was very sure that Sa founders need help in that area and I recruited two more people, Benedict and we had a marketing co-founder, Claire Suentrop. She later on decided to stay as an advisor. She works on a popular marketing project, Forget the Funnel and Elevate these days. So that’s the story of fuselist and before that, I’m a UIUX consultant by trade. For the last 8 years, I’ve been working online with international clients and running my personal brand, UI Breakfast, and I also do UI Breakfast podcast, which is a nice design show. So that’s been out for a while as well. 00:03:08 - Speaker 2: And notably, we’ll have a crossover episode there. Mark, Mark’s going on with you at some point. 00:03:14 - Speaker 1: Yeah, I’m so excited to have him soon. So that show is sort of catering to my design interest and user list is something that we’re all passionate about is helping fellow founders pursuing that like bootstrapper dreams, slow and steady, kind of not funded, but self-funded growth. 00:03:33 - Speaker 2: Yeah, well, having the pain yourself, that is having previously done a business and see where this is needed, that’s certainly one of the best ways to drive you to create a great product, I think. And you already kind of teed up our topic here, which is on boarding. You actually suggested this one, but it ended up being serendipitously apropos because Yuli was actually deep in the project at the time. We’ve, we’ve since released it, but deep in the project of redoing our onboarding, which we’ve done several times and is a challenge for various reasons we’ll get into later on. But before we do that, let’s start with the fundamentals. Can you tell us what is on boarding and why does it matter? 00:04:11 - Speaker 1: Well, firsthand congrats on your recent launch. That’s a big one. Also very exciting. Well, going back to user onboarding, that’s the process that software people use to receiving value from their product. And this can mean different things in people’s heads because we often associate this with like tool tips or guided tours, so very like specific interventions, but it should. be perceived as a more abstract thing, sort of a larger situation in life that the person is in and how you can help them using different kinds of tools, interventions and no little things to achieve value using your product and your product plays a little role there because they usually don’t strive to be good users of your product, but they’re striving for achieving something else which is much, much bigger and important for them. 00:05:00 - Speaker 2: You wrote this piece that we referenced a little bit titled Inspire, not Instruct that focuses more on the helping people understand what I usually talk about the aha moment or the understanding how something can fit into their life or help them in some way or solve their problem rather than the nuts and bolts minutia of how exactly do I use this. 00:05:19 - Speaker 1: Yeah, it’s kind of meta because user list is a tool for user on boarding, but it’s also quite a big challenge for us to onboard our own users. Once one of our users uh wrote back and said that they loved what they saw inside the app on the first run experience, and basically what we have is a single welcome video that does have not a single instructions inside it. And our goal is to sort of set up the tone and then we just rely on their own skills to continue with the journey, because different software applications have different levels of complexity and ours is definitely not on the easier side of the spectrum. It has a lot of elements for the user to become successful, they have to complete the integration, they have to actually write the emails. Of course we do have like templates and everything else we can, but. You can take the horse to water, but you can’t make them drink if they’re not inspired, so we really strive for this inspiration component more than trying to like instruct them, um, towards performing certain steps. 00:06:23 - Speaker 2: And I suspect there’s particular challenges when you get into B2B, as they call it business to business stuff, as well as very technical products. We ran into that with Hiroku and it’d be interesting to compare that to the maybe the mobile app world a little bit later on, but you know I was curious to get your take on onboarding here. And again, this has some nice historical touch points for us. And that we met at a company called Clue, a reproductive health tracker, and while we were both there, you were leading a project to build the out of box experience or the UI, it’s kind of the cute acronym there, which you said maybe UB and onboarding aren’t quite the same thing, but in any case, I’d love to hear how you think about this now being a veteran of having built multiple first run experiences for apps. 00:07:08 - Speaker 3: Yeah, for sure. The way that I understand the UBI or the out of box experience is basically The way that the user sets up a piece of software, in many cases, this is, you know, if you’re installing something first, this would be part of the UBI. If we remember like for Windows users, I think this is still a thing where you have to double click on a thing and then you get the dialogue, where do you want to install the tool. So this would all be part of an Ubi. Obviously, in the app world, you just download an app from the app store and then you open it, and then what happens in those first couple of minutes, I would say, is the out of box experience. And so in the example of clue, there was actually different guided steps to make you see the app with some initial data, so it would ask you how old you were. If you remember when your last period was, if you know roughly how long your period is, and based on the data that you input there, you will then end up at basically the app’s main screen that already has a little bit of data filled in. So this was both a way to kind of get to know the user and get information from them that are relevant for the app to work correctly and also avoid then bringing them to an empty start screen, basically, because if you have an app that’s fundamentally about data input, The first thing that you see being an empty screen is kind of uninspiring, of course. And so to compare this with the new experience, I think what we’re trying to do with the onboarding here is to both inspire them to realize what the product is about and how it could fit into their lives, but then obviously also teach them how the app works and Muse, as we all know, is kind of a, a pro tool that does things quite differently from other apps. So some of the gestures are fairly hard to discover on their own, which is I think why it is important to teach the user a little bit on how to use the app without overwhelming them with too many things all at once. But at the same time also show them a little bit of content, motivate them to get some of their own content in. And so based on all of these incentives, we we’ve tried to put together a little on boarding, which I think we will get into this later. That hopefully brings all of these components together. 00:09:23 - Speaker 1: I’m super curious to hear what you decided on that because you have so many hidden things in news and um that really requires some instructions. So what is the form and shape that you decided to go with? 00:09:36 - Speaker 3: Well, we’ve historically been through a couple different steps here. I think the very first version when we were still in beta was basically just an empty board with 2 or 3 cards on them, and one of them, I think was a pretty long text describing what news is about. And obviously that was neither teaching the user anything nor being particularly inspiring because the last thing that people want to do. When they first opened an app is read a huge block of text. So that was discarded fairly soon. 00:10:03 - Speaker 2: In our defense, I’ll jump in and say that the earliest onboarding was actually that we didn’t let anyone try the app unless one of us was sitting right there to help them. Onboarding was what you might call white glove or high touch, which often goes with, yeah, high-end kind of enterprise sales type products, but also I don’t know, maybe someone like superhuman has kind of popularized this a little bit, at least in the tech world’s imagination. But yeah, we would just sit there either in person in some cases or over video chat and either first give them a demo, try to show them what they can do with it once they get better at it, but then once they’re in it, kind of direct them around a little bit and then, you know, that obviously wasn’t very scalable, but it was a good place to start where we combined the usability test with a user interview with an onboarding was kind of all one thing that was just done completely outside the software. 00:10:55 - Speaker 3: Yeah, that’s right. So I think the thing that we did after this was to focus more on the inspiring part, so to really show people what you could do with Muse, what a muse board looks like when it’s filled with rich types of content. So we actually had a fairly extensive bundle of like pre-made onboarding content. I think it was one main board and then maybe 5 other different boards and different topics inside there. With some, you know, hand drawings or sketches on there, different types of links, PDFs, basically every content type that’s supported in use was in there, but there was no instruction at all on how to use the app. So people were kind of left to just explore on their own, which I think worked well in some regards, but I think one thing we also learned there is to just throw a bunch of random content at the user. Without any context on why this is important or why they would care about it seemed a little bit weird to users as well. Like they come in wanting to do a certain thing and if they then find a board that outlines, you know, notes on a book that someone wants to write that maybe doesn’t align at all with what they’re interested in. And so where we went from there, I think it was to try a little bit more of a learning the muse interactions based on a stack of cards that was in your inbox, like right when you launched the app, that was basically just a blank board and I think something like 12 or 15 cards that are arranged in a little stack in your inbox. This is where your content lands when you bring anything into Muse. And that definitely had a little bit of a threshold for users in terms of figuring out what to do with that stack of cards. I think for some people, and even if I remember correctly during one of the app reviews, this was actually reported as a bug, like there’s a bunch of cards or like a bunch of little things hanging off the side of the screen, and we don’t know what to do with it. 00:12:55 - Speaker 2: Yeah, in the ideal world it was sort of. And they would tempt the user to grab it and drag it out and it’s a way to kind of draw you into that interaction without explicitly saying it. And I think that did work in a lot of cases. I ran some usability tests where I saw people be kind of puzzled what’s going on with these things on the side, and when they pull it out, they have kind of an aha moment and a sense of delight at having kind of figured something out, but just as often as not, it was uh what’s going on here, this app looks broken. 00:13:21 - Speaker 3: Yeah, exactly. Yeah, and I, I definitely think the moment of like when you do figure out what to do with it and then you realize, OK, you can drag these things around. There are a couple, just, you know, I, I think it was like a gardening project, so we had like a set of cards that had some inspiring images, and then a little bit of text explaining what Muse is and what you can do with it. It also pointed you to a little panel that you can open from the main menu that we call it, I think just a learn panel. That had some of the main interactions of the app explained just with some icons, and it seems like most people figured out how to use that and then notably a while later we actually introduced our handbook, I think there was an entire podcast episode on this, but we really went through lengths of recording videos of basically every interaction and everything that you can do inside the app. And put it on a website. So linking to this also from the main app helps. So if people really get stuck or they’re curious to learn more or to figure out how everything works, they can go and look at the handbook. Basically, the new onboarding that we designed based on the pain points that we saw with the random stack of cards in the inbox is a bit of a combination of everything we did before, combined with like a quest-based system. So our main incentive here was to motivate users to figure out the app while Using the app without necessarily forcing them to do something in a certain order, or I think we all know these types of onboarding tutorials where you first open an app and they, they really don’t let you do anything but click on the thing where the error points and you feel a little bit like a child that is taken through like an obstacle course and There’s basically no freedom to just explore on your own. 00:15:08 - Speaker 2: Jane, I think your article talks about this, right, like the tool tips and the guided tours and basically says that stuff doesn’t work. 00:15:15 - Speaker 1: Yeah, and also there is this famous person in the industry of user and boarding, Samuel Heli, and he wrote a book that I’ve read like ages ago, that was kind of laid the foundations for my own thinking and we recently had a conversation with Samuel and yes, he confirms like up to date. This does not really produce great results because everybody wants to have an autonomous experience. They want to explore things on their own at their own pace, while tool tips like enforce working within the UI at some predefined scenario, and this is just not a great practice. 00:15:50 - Speaker 2: Just as an aside, it must be fun to to read a book that had a big impact on your career and what you’re working on and then get to interview the author later on. 00:15:59 - Speaker 1: Yeah, and we’ve been friends with Samuel for many years as well, so we have this kind of multifaceted relationship, uh, him influencing my thinking because he’s the UX consultant who only does onboarding for the last decade or so. It’s interesting how life has unfolded that these days we’re also establishing ourselves as an authority and user on boarding because we have a tool for it. And like, I don’t want to personally compete with Samuel’s thinking by any means, and neither do I want to reproduce his ideas, but it’s so amazing to be thinking in the same direction, sort of. 00:16:33 - Speaker 2: Nice. Yeah, well, give me the link to that book, as well as the episode after and I’ll put it in the show notes for the. 00:16:38 - Speaker 1: Yeah, he’s been super famous for these onboarding tear downs, and he has plenty of mobile experiences as well. So we just do web apps and he does all those consumer apps that have interesting first run experiences for end users. 00:16:55 - Speaker 2: Now Yuli, I think you’re about to start talking about how we landed on the onboarding we have now, maybe called the quest style. I’ll use this opportunity to tell a little anecdote from my own history, which is that many years ago I worked on this kind of a side project, some online multiplayer games. It kind of early days of the internet in the 90s and ended up doing an onboarding. I wouldn’t have called it that then. I didn’t know that term, but that first run experience to help someone learn the game. And the one I was inspired by was, or there was another game similar kind of one of these kind of D&D style online multiplayer games. And in this particular game, you had a magic sword that you started out with when you began the game. And I thought it was very clever because the sword would just talk to you and tell you what it thought you should do. So it would say, OK, maybe you should go over here now, maybe you should try talking to this person. Maybe you should pick up this object and we kind of take you through a bit of a, of a sort of a step by step tutorial. But the great thing was it was just saying that you could do whatever you wanted and you could just ignore it. And in fact, if you got annoyed and tired of it talking, you could just drop the sword and walk off. and basically just throw it away. So it was a really nice way to both give that guidance for someone that wants it, but then not. Take away in any way the user’s sense of agency or freedom. 00:18:13 - Speaker 3: Nice. I think that reminds me a little bit of the little animated paperclip character in early versions of Microsoft Word. I don’t know if they still do this, but I have a very strong memories of like my young teenage years having this little paper clip set off to the side and telling me things that in most cases, I didn’t really want to know. But sometimes also just helpful tool tips, but I think you also could, if you get an out, you could just remove it completely from your view, I think. 00:18:40 - Speaker 2: Well, notably there, I believe this fellow’s name is Clippy and has become a punching bag for sort of dumbing down professional products in the software industry. So while on one hand, I think maybe had some good intentions in many ways represents for a lot of people what’s actually wrong with tutorials and software on boarding. 00:19:02 - Speaker 3: Yeah, I agree. 00:19:03 - Speaker 1: It could also take forms of different animals in addition to the paper clip. I recall. 00:19:11 - Speaker 3: Yeah, the amount of work they put into making that thing be really distracting was quite outstanding, I have to say. 00:19:19 - Speaker 1: We’ve just talked about how important it is to keep the user autonomous in their journey, but on the other hand, as a UIUX person, I cannot overemphasize that the first run experience, that’s when you have the most energy and the most enthusiasm and momentum coming from the user, so. Those like first few steps that you make really mandatory, yes, sure, you have to make them shorter so that they can then autonomously explore the app. But on the other hand, you shouldn’t really neglect that energy that’s coming with it, and if those steps are pretty fine that you might still want to take advantage of that momentum that the user has that very moment. So it’s not always that you just leave them hanging. Sometimes you really have to enforce something. 00:20:04 - Speaker 3: Yeah, and I think we struck a fairly good balance with the new onboarding and new. So what happens now when you open the app for the first time and you made it past authenticating yourself, you get onto basically a root board that has a couple cards on it. One is another empty board, one is a text card, and then there’s another little text card on the side that just gives you a very brief intro about what news is and why you should care about it. And then the other text card is basically already a mini tutorial or suggestion. It just says take this card and zoom into the empty board next to it and then drop the card there. And notably, this is one of our, I would say, most complex or surprising interactions. We often get people to write in feedback that they can’t figure out how to move a card between a board and Based on this, it actually seemed like a lot of users really couldn’t figure this out, so we decided to make this sort of key interaction to be the first thing that we’re trying to teach users. In a way, also because we think that it gives users a good idea about how new is different from other tools. It immediately teaches you this, you know, you can use both hands. It’s not all just use your finger to do something. You can use one hand to pick up a card and then you can use the other hand to do something else. So teaching people how we’re doing things a little bit differently from other apps was quite key to us here. And then once you completed this first task, basically, We guide you to open a little panel that then has a list of other interactions that you can do in Muse, and they’re laid out as a sort of checklist, but you’re also free to just close that panel and explore on your own. And the next time you come back, you can come back to it and open it again. So it’s not like it forces you to do these things and do them in a particular In order, but it does sort of give you a rough set of what basic interactions are possible in the app, and it entices you to explore them a little bit. And if you get stuck on any of them, you can actually, and this is where we’re making use of the handbook and all those video content that we created to really teach you in a visual way how the app works. If you get stuck anywhere, you can tap a little button for each of the tasks, and it actually drops some cards into your inbox. When you drag them out, you’ll see that they’re like a little instructional card that explains how a certain thing works. And then also a card that plays the video. So a video of demonstrating, basically, you see two hands on an iPad actually doing the thing. So this way, we’re really trying to explain to people the things that are possible in the app. And then also motivating them to add a little bit of content of their own and to basically start exploring how the app feels when they use it for a real project. 00:22:50 - Speaker 2: I’ll say that the use of the two-handed card carrier that put a card into a board as the very first thing was a really great insight by you in terms of it’s this thing that not a lot of people figure out how to do because it is different. They expect that, oh, maybe I should be able to drag a card with one finger and kind of drop it on a board and it’ll go inside there, but that’s Muse has a. Different model and using both hands to do this complex gesture is not what they expect. But we also see that when we show that to people in many cases just through our support channels they write in and ask how to do this and we explain it somehow or send a video or something and then they have this, oh, that’s amazing. I love this. It feels interesting. It turns on a light bulb a little bit. So maybe to Jane’s earlier point of they have this energy right at that moment to try to kind of challenge themselves a little bit or try something a little different. And it’s something that’s hard to figure out on your own, but if we guide them to doing it, and then maybe you have a not only a little light bulb about here’s how I do this specific thing, but a light bulb of, like you said, this app works differently. I can use both my hands. I should be prepared for a slightly different experience. 00:23:56 - Speaker 1: Um, buckle in. For a different experience. I’m curious, you have such amazing videos with this over the desk camera and the hands using the iPad and everything. How did you produce those? Are there any secrets because like you can’t really do that on your own, to have some magnificent video editor hand or any other secrets? 00:24:19 - Speaker 2: Yeah, that’s our colleague Mark. So he set up a little home recording studio, which is not too fancy. I think it’s sort of a boom arm that holds everything’s recorded with an iPhone camera, which of course are amazing these days. They do, you know, 4K 60 frames per second. And then the lighting turns out to be a really key thing so getting some lights on all sides so the shadows aren’t too heavy. We talked about this a little bit in another podcast episode that I can link back to, but basically kind of came down to a combination of these a few pieces of equipment using the iPhone. Camera and then what for me was a surprise, which is filming a screen seems weird to me, but actually it works really well because the high quality of cameras these days combined with the brightness and pixel density of the iPad screen means basically looks great. 00:25:08 - Speaker 1: So it’s an actual screen recording, that’s quite amazing. I thought it’s a combination of some magic editing. As they do. 00:25:16 - Speaker 2: Right. I’ve seen, um, I read a post somewhere someone doing this for I think an iPhone demo video where they essentially did like a green screen or a chroma key on the phone screen, and then they record the hands doing the motions and then they record a screen recording and composite them, and that would be nuts for us to do. I mean, even aside from that we’re a small team and just don’t have the resources for that kind of thing. It’s also that we have these really complex interactions and trying to replicate them twice once for screen recording and once for like recording the hands would be tricky, but yeah, weirdly enough, just filming an iPad screen works fine and actually I’m pretty sure that’s what Apple does for a lot of their videos too, so I guess it works. 00:25:51 - Speaker 1: Do you have any other tips for the video content during onboarding, like from my experience, keeping those short is very useful, but also a big challenge because the shorter you want to be that the harder it is to record a good one. Because I’m the one on the team who does all of this stuff and it’s amazing how much infrastructure there is in a software application that does not relate to software that’s got to be done, like the docs, the videos and everything. 00:26:17 - Speaker 2: That is a really great point. 00:26:18 - Speaker 1: So what are your tips for the videos? 00:26:20 - Speaker 2: Well, we, you know, maybe we did it easy because we’re in some ways, it’s a very simple format, right, just hands and an iPad on. and these things are often 5 seconds long or something. What do you do in your videos and actually maybe that’s a lead in. I was going to ask you more about this whole other world of B2B apps and the fact that I think onboarding is not just what’s in the software, but it’s also email exchanges, maybe there’s a sales component or demos, obviously videos, which could be on your YouTube channel or whatever. I’d love to hear the larger picture of what that whole experience is for your customers. 00:26:54 - Speaker 1: I think experience for our customers is one thing, is what we offer, but there is this whole spectrum of different interventions that you can apply to try and affect people’s behavior to some success or maybe to no success. It really depends. We only cover as a tool, we only offer email as the most classic and powerful way of getting in touch with the people, and we also offer. In app notifications, which are like a little chat bubbles, but without the chat that appear in the corner of the app that you can use to supply some helpful information. But there is also such a wide range of tools, and I don’t mean tools like autopilot or chameleon or a dozen other tools that offer guide through tours and things like that, but you can also offer demo calls such as white glove on boarding, as you mentioned before. You can invite people to. book with you at certain stages of the app, you can, you can make fun of a little bit. 00:28:01 - Speaker 2: Yeah, super cheesy, but it actually does work, you know, it’s a little more scalable than a one on one thing, but you get on a video call and you can kind of walk through. Some script, but then you can also answer people’s questions, that sort of thing can work really well for the right kind of product. 00:28:16 - Speaker 1: You can do office hours, you can do an online community where people try and even help each other, but I would never recommend that at a small scale because it takes so much energy to support that. But if you have that, there’s this people out there who seem to be, you know, revived by communications with others like we’re not among those, so. Having multiple customer conversations in a forum that would like drain our productivity to zero and we’ll never get things done, so maybe later when we have like a community manager or someone, and also the docs, videos, everything that’s in this materials ecosystem that you can produce and help the people. There’s this delicate play of the formats and different calls to actions that are all around the place in the emails and inside the app. For example, in Muse, if you have a handbook, how do you help people open it? How do you leverage this uh different experience, you have the app and you have the browser, how do you not lose attraction? It can be really, really different for multiple products. So you put together this delicate play, and then it’s usually traditional to have email as sort of the main thread. where you pile up those interventions and offer different kinds of help along the cycle. And, uh, there might be opinions. For example, there’s this wonderful email expert called Val Geisler, and she’s amazing. She has wonderful email on boarding tear downs, but she says that whatever you undertake that makes you send less email is not great. Well, we might be missing out on that, but we do think that less stuff is actually better. And the best email is that the one that’s not sent, so we highly encourage our customers to use behavior data to actually filter out some of the communications that are already irrelevant, like if the future is used, there is no need to promote it anymore. In the ideal world, the user will just like figure out themselves and not have to do anything. So yeah, it’s so interesting, it’s so specific to a particular product. 00:30:21 - Speaker 2: The email one is, I think, worth drilling in on a little bit there. I mean, you mentioned it as being kind of the standard or the center point for the back and forth. I think that’s really true in B2B enterprise stuff, which is where I spent a lot of. My career, it is unusual, perhaps even non-existent for consumer applications. In fact, we’re in an age now where I know younger people that just don’t have email, right? That’s just not part of their world. And in any case, the way that for example, the App Store and so forth is set up really doesn’t encourage that sort of thing. We discovered that same you discovered pretty early on that this was a really important Channel for our target audience because our target audience tends to be kind of thoughtful reader types. They like reading and writing long form things and so we made the perhaps controversial choice to ask for an email right off the bat. We don’t ask for a name or anything else like that, but we want to be able to have that direct communication channel and if you send feedback from the app, that comes from your email address so we can reply to it. And we don’t use it for a lot. We don’t do any kind of like drip campaigns and stuff like that. I know that sort of thing is very standard when you sign up for Notion, you get a series of emails saying, here’s some information for, you know, your next step in using the app or whatever. But yeah, it seems to me like email, at least certainly for us, and definitely the more B2B world is a key piece. How do you think about or or how do you approach this whole world of, I don’t know, drip campaigns and follow-ups and that sort of stuff. 00:31:46 - Speaker 1: Your app is really at that price point when you’ve got to have a more serious relationship with the people about their billing, about their content, and you really have to use email, at least a little bit to make sure that this relationship and that this content is intact if they lose like their device or something like that, isn’t that true? 00:32:08 - Speaker 2: Absolutely. Even aside from the practicalities of the reset, I think. Being kind of a spectrum where on one far extreme you have consumer products which are big scale, you download from the app store. There’s not really much of a relationship. It wouldn’t be practical for an application maker that has millions or tens of millions or hundreds of millions of users to have personal relationships with their users. They just can’t do that and the users probably don’t want that either. And then on the other extreme, you might have the classic, you know, multimillion dollar top of the market enterprise sales where it’s, you know, you have a personal relationship with your salesperson, you go out for steak dinners, they come to your, you know, your wedding or whatever, that like really, really deep long term. And then of course there’s a bunch of stuff in the middle. I think for Muse we kind of discovered that we ended up maybe kind of in the middle, little closer to the lightweight side, but having that email so we can build a personal connection when you send a message with a question, you get an answer from some me or you there or someone else on the team. You build up that relationship over time and it builds trust in the product and maybe makes you more inclined to part with money or believe in the product both now and in the future. 00:33:18 - Speaker 1: That reminds me of a phrase that I really like and there’s high touch, there is low touch, and there is tech touch. Which means that you can imitate the high touch relationship, but it’s scale, because you have like thousands of downloads and you can’t really honestly offer your hand to everyone, but you can offer your help using automated means and then some of the people will use it to generate genuine relationships. 00:33:44 - Speaker 2: I’m a little bit, and again, I’m curious to hear what you think about sort of the drip campaign method. I’m a little skeptical of some of that myself when I get those follow-up emails from a product I just signed up for. I don’t really tend to read them that much, but maybe a version of the tech touch or at scale thing is something like our email newsletter, which now goes out to thousands of people, and I write this in my voice. It comes from my email address, and when you reply, that reply comes to me, and depending on the the issue, we get more or less responses, but I respond to every single one of them. And I really enjoy making that connection with our audience and with our users. We’ll see how that scales over time already with this recent launch, we found ourselves pretty buried under the communication, but that’s important to us is to feel connected to the folks that we’re helping or trying to help our product. 00:34:31 - Speaker 1: Yeah, as makers of the tool that does that, we’re under no false impression that this is a magic bullet to nudge people with email, but it’s still the most reliable channel, so you can use this to make super personable. And then maybe that will result in some real life communication and that’s as much as you can do. If you don’t have any other channels, you can’t really call them well, unless you ask for a phone number, which also is an option, but that’s as much as you can do as a founder to get in touch with them. 00:35:04 - Speaker 2: Julie, I know you’ve done a lot of kind of usability tests and in particular kind of there’s the ad hoc form of usability test with, you know, grab a person that’s nearby, a romantic partner, a roommate, a family member, as well as maybe the slightly more structured, try to reach out to people you know are in your target audience, but you don’t know personally. How do you think about that as fitting in with and and particularly for this recent Muse on boarding? And we’re a little bit restricted in the in-person usability test these days, but what’s your approach there? 00:35:35 - Speaker 3: Yeah, I think the sort of ad hocability tests where you actually watch a person use the app for the first time. are super helpful and super insightful because I think you often tend to have the user stumble over certain things and then eventually they’ll figure it out, which is probably fine, but to actually identify those initial hurdles, it’s quite hard to do that just by looking at maybe, you know, aggregate analytics data or something like this. So actually physically watching someone use your app, get really stuck or frustrated with something, then figure something out, having the aha moment. is always super insightful and it’s also always a little bit painful because of course, you know, if this is a piece of software that you look at every day because you’re developing it, you develop a certain blindness to certain things. So seeing someone get confused by something that you just take for granted is, yeah, is obviously always a little bit surprising. But it is super important to do these tests and to take your learnings from there. So we did this a little bit with the current onboarding and definitely restructured a few things that some of the wording wasn’t quite understandable to people, but where we were maybe using some internal words that for us is super clear what they. but the user who sees the app for the first time is not quite clear on that terminology. So this is always a good sort of feedback check if people actually understand the way you communicate. And then on the bigger scale, I think what we’re trying with this new on boarding as well is to actually try to measure. The success of how well users are onboarded, and I think that the task list that we came up with basically lends itself really well to this. So whenever the user completes a task in the list, we send like an event to our servers and based on that can calculate a sort of onboarding score that each user has. So how many of the basic interactions have they performed at least once. And then based on this, you could imagine doing some IB tests, maybe you reshuffle things, you slightly change the wording on a couple of items, and then you can compare the score of that version versus the other version and see if, you know, those small tweaks really make a difference in the long run. 00:37:49 - Speaker 1: Were there any surprising discoveries that you’ve learned using these AB tests? 00:37:54 - Speaker 3: I think one of them is still the basic interaction of picking up a card and then dropping it into a board after you zoomed into it is still not clicking with quite everyone, even though we feel like we’re explaining it the best that we can. And maybe that means that it’s still just too weird and people just aren’t used to doing these things, or maybe it means that we have to think about explaining it better again. Or maybe it also means that the interaction just should be changed and maybe we should come up with a different way of doing this. So definitely by looking at the data we have now, there’s quite a few things that we want to try to tweak and potentially do differently. So it’s quite helpful to have that information. 00:38:32 - Speaker 2: Also noted on the split test front, I think we, you, I should say ran the initially ran the previous onboarding, which was this deck of cards garden thing kind of alongside the new on boarding and so then we could just compare how far looked at those aggregate analytics to just see in general the people that in this group got this far and the people in this group got this far, and I think that’s a, we don’t have a necessarily a lot of split test work on. Our team, we’ve done a little on the website here and there just to try some small ideas, but this is a practice that I know a lot of Silicon Valley firms speaking to a product manager from Pinterest some time back that said they had a really good practice that they never rolled anything out without kind of a 90/10 split test, that even the new thing would be up alongside the old thing for a week, and they could look at some of their core metrics and just sort of, first of all, make sure nothing regressed, but also have a pretty specific idea of well. is we’re rolling out this new thing. It’s not just that we like it better, or it looks better or it feels better to us intuitively, but that we can actually show the way that it affects our core business and it’s probably not quite the way that Muse would go about things, but that approach of trying to be a little bit rigorous in, OK, we want to help people be more successful. Does this help people be more successful and that that’s not just based on our intuition or even these anecdotal reports, but it can be based on data to some extent. 00:39:58 - Speaker 1: You just touched upon a pretty important topic that how do you transform like one-off efforts on improving your onboarding into some organizational practices that help you be consistent at improving that. And two things that are super easy to do is one assigning a. On boarding champion in your company who will take care of this thing in your app, and they would vote for it in the internal meetings and things like that. Another one is regularly, maybe once a month or once every quarter, going through the entire boarding experience of your app, including the payment. The sign up and everything and everything changes so fast, you just gonna have absolutely fresh mind every time and you’re gonna have some surprising discoveries. 00:40:46 - Speaker 3: Yeah, definitely. I think you feel like you designed a good onboarding experience and now you can go off, develop new features for your app, but you have to continuously keep in mind as you’re adding new features or as you’re changing things that that might affect how the user goes through the. the first time, like maybe you need to promote those new features, you need to make it part of the onboarding. I think for us now is the case that every time we add a new interaction or a new feature into the app, we basically have to record a new video for the handbook, which made it extra important to make the lighting situation and the videos cropping and everything easily reproducible because we don’t want then the new video to look completely different from the old one. But yeah, I definitely agree to what you’re saying, to always keep this in mind and to regularly revisit it and see if it needs to be adapted to how your app evolved since. 00:41:33 - Speaker 1: I once interviewed Max Zillemann of Ulysses, and I know you’ve mentioned Ulysses a bit on the show, and they have so much of this infrastructure in different languages that introducing new features and producing materials to support that in like dozens of languages. It’s an enormous part of what they do as a company, like you can’t overlook that by any means. 00:41:55 - Speaker 2: And once you start to localize, you make the cost of every change higher, and you’re adding on to your earlier point, I think, which is that the onboarding tends to get less tension just because it’s naturally in front of not only your team members, but also your longtime users. Because of course, they go through it at the beginning and not so even if you’re in good touch with, you know, we tend to have the best relationships and the most ongoing communication with our customers, those are sort of by definition, people have already not only successfully onboarded but found value for the app in their lives enough that they’re going to pay for it. And so as a result, the onboarding experience is something that we just personally see less of, and you can go back to run through it. And and realize ways that it’s come out of date or there’s rough edges or something’s changed in a new version of the operating system that makes something funny about, you know, the screen where you type in your access code or what have you. So creating some kind of organizational practice to make sure that stuff gets attention because that is your first impression and that is the place that’s the sort of the moment you can convert someone into a Someone that’s gonna use and love the product, or they kind of shrug their shoulders and say, huh, I don’t see what the big deal is and never come back. 00:43:10 - Speaker 1: And it’s so much economically viable to invest in that because sales and marketing costs are enormous compared to the cost of these little interventions that you can add to like dramatically increase the activation rate and just make better use of your marketing money. It’s scale with every single user, virtually any improvement is a great improvement. 00:43:33 - Speaker 3: Yeah, definitely, I think that’s one thing we were kind of trying to achieve with this new onboarding is that we have lots of users coming into the app and of course, naturally people will always turn for one reason or the other, like maybe they just realized the product isn’t for them. But we really wanted to eliminate the risk of using someone just because they can’t figure out how the product works. So once you kind of went through the app a little bit, you tried out a few things and you then realized, yeah, I don’t really know what to do with this. That just maybe means that the product is not a good fit for you. But if you actually do have the motivation and that there is a way that it fits into your life, but you can’t figure out the most basic things, and we saw this by users emailing into support by like, how do I delete something or how do I erase something. And so really putting some focus on teaching them the basics so that they then based on that can decide whether or not this product is a good product for them was quite important to us. 00:44:27 - Speaker 2: Looking forward to the future a little bit, we’re seeing lots changing, including, for example, the importance of video content, but Jane, with your eye on and your specialization on the onboarding space, what do you see as potentially being improvements through technology or practices to onboarding for the future? 00:44:47 - Speaker 1: Well, we’ve been pretty mature in terms of the tool set that people can use, but it’s great that organizations in general are starting to realize the importance of user onboarding and just investing resources in that more and more, and even smaller founders can now afford certain tools that were previously just for enterprise companies. And that’s an amazing trend because previously it felt like this ecosystem of marketing and growth hacking and everything, it was really mature, but what happened after I sign up was a little bit kind of vague and not touched upon. And these days we can observe a wonderful trend of this product led trend word, product led growth and things like that, which essentially means just looking at what’s inside your product and what’s better for the user. So that’s definitely a wonderful trend. 00:45:35 - Speaker 2: Yeah, it’s a great point. The cultural awareness, whether that’s within a particular company or in the whole industry, you know, we saw that happen in this huge way with design, for example, it’s not that design didn’t exist before, but it came to be something that probably originally pioneered by Apple, but now it’s in the zeitgeist where people say, OK, we should be thinking about design as a first class thing and I think onboarding is not something that has that same. Awareness as this is a critical piece of any product that you’ve ever build. It’s a huge opportunity both for your product and for your marketing, and it deserves its own attention and name and people to think about it like you said earlier, like the assigning an owner on your team, so that aside from any technological improvements, the culture shift seems likely to only produce better onboarding experiences in the future. 00:46:26 - Speaker 1: And I think that 2020 has already taught us a lot is thinking about sensitive moments about how that intervention that you’re applying can be relevant to the user at this particular moment, uh, because a lot of things have been going on and your drip campaign is definitely not at the top of their priority list, like reading through that. And it feels like there is no hack of just sending more email. Now you have to be really thoughtful and considerate and maybe send less but be more personal and sensitive to all these things and we’ve had a lot of big lessons this year about that. 00:47:03 - Speaker 2: Excellent. Well, yeah, thoughtful, considerate and personal, those head on 3 of our values here on the Muse team and I think that. And I think that furthermore, you’re right, in 2020 specifically just because of the state of the world and society and so forth, those things are perhaps especially important, but I think they’re important all the time and if we can get more in the habit of our products and our companies and the way that we engage with customers and potential customers as being a little more personal, a little more tuned in, I think that’s a win across the board. Absolutely. Well, with that, I’ll just say that if any of our listeners out there have feedback, feel free to reach out to us at @museapphq on Twitter or hello at museApp.com by email. We’d love to hear your comments and of course ideas for future episodes. Jane, thanks for coming on, for pioneering slash advocating for better onboarding through your work at user list and where can folks find you online? 00:48:00 - Speaker 1: It’s definitely user list.com as our primary internet touch point, and we are at the moment working on a comprehensive on boarding guide, which puts together all the resources and what we want our customers and our audience to know for the right mindset about user onboarding and that’s gonna be up very shortly, should be live by the time this is out, and it’s available at userless.com/user onboarding. 00:48:27 - Speaker 2: You heard it here first, folks, breaking news. Alright, thank you both for taking the time today. 00:48:33 - Speaker 1: Great pleasure. 00:48:34 - Speaker 3: Thank you. Yeah, thanks for having us, pleasure. 00:48:36 - Speaker 2: And we’ll see you around. Bye.
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: I really thrive off of urban energy, but I also I’m at a point where I want a little more green, a little more quiet, a little more space, and can I get those two things together. Hello and welcome to Meta Muse. Muse is a tool for thought on iPad. This podcast isn’t about Muse the product, it’s about Muse, the company and the small team behind it. My name is Adam Wiggins, and I’m here with my colleague Mark McGranaghan. Mark, what’s the air quality like in Seattle right now? 00:00:33 - Speaker 2: It’s much improved. We got hit really bad by that smoke, but we got some proper Seattle rains, and now it’s really clean out here. 00:00:40 - Speaker 1: I love the uh smell of the air after a good rain, and I can only imagine how different it must be in the wake of the wildfire smoke. Our colleague Julia found it a little funny because actually in the demo video that’s on our website that you recorded, there’s some content related to Seattle and there’s actually a whole board about natural disaster risk and wildfires explicitly called out there, and I think it’s pretty low, mostly in the Pacific Northwest, I assume because it’s raining or whatever, but apparently not in that calculation is what happens if wildfires hundreds of miles away happen and then the smoke drifts. 00:01:15 - Speaker 2: Yeah, exactly. The immediate area here is safe cause it’s very wet, so it’s hard to catch fire, but we definitely can get smoke as we were reminded the past few weeks. 00:01:23 - Speaker 1: So our topic today is leaving San Francisco, and we both have a personal story on this. You moved to Seattle a few years back, leaving the Bay Area, and I moved to Berlin 7 years ago now, after 7 years in San Francisco. And there’s a little in the zeitgeist in the discussion here, the pandemic has led a lot more companies to remote work, and in turn has made people who work for those companies have more sort of flexibility where they can work from wildfires are probably a piece of that as well, but in general, I feel like I’ve seen in my Social networks and colleagues, people considering leaving the Bay Area or in some cases they’ve done so. There’s a great article by Kevin Lana who speaks about that, that I’ll link in the show notes. And we’ve also got tech companies like Stripe and Zapier being willing to essentially pay you to move someplace cheaper, which is sort of interesting. But the topic here isn’t to debate the merits of the Bay Area, but I thought it would be really interesting to reflect on not just our personal stories, but how you make a decision like this. Because it feels like an unprecedented social shift in some ways, which is most people, and me included, most of my early life, I went to where I needed to go for school, you know, university, where can I get a good education that will have me, and then later on to pursue employment. And I didn’t make any kind of calculus of where do I want to live. I made the calculus of where can I get the best job for myself, and then that naturally dictated where I was going to live. And it’s something I feel like I’m seeing a lot of lately. I had a bunch of conversations with folks where people are going through the same process that I went through some years back when I embraced remote work, maybe you did as well, which is to realize that you have the opportunity, the privilege to just pick where you want to live and have that be based on some criteria that’s not coupled to your employment. But also realizing maybe the weight of that responsibility or it’s not the right way to put it, maybe that it’s a great opportunity, but how do you decide if you can do more or less anywhere in the world or within some time zone band, what criteria do you use? Where do you even start? So that’s why I thought it would be an interesting topic for us today. So Mark, I know you moved to the Bay Area, kind of at the start of your professional career. That’s when we got the chance to work together and I think for you it was like me, an incredible opportunity to build your early career and then just a couple of years back, you moved to Seattle. I’d love to hear a little bit of that story. 00:03:51 - Speaker 2: Yeah, so I moved to San Francisco originally. It was 10 or 11 years ago, I think. And at the time, I knew I wanted to be in startups and San Francisco was basically the place that you went for that. Another possible option would have been New York City, but it was definitely second place as compared to San Francisco, and actually at the time, San Francisco was much cheaper than New York. Jokes kind of on me there eventually, but that was a factor at the time. And yeah, I was there for maybe 7 or 8 years or something like that. And an incredible experience, you know, learned a lot, met a lot of interesting people, including obviously you, but a couple years ago, I was ready for something different and moved up to Seattle after a bit of a process thinking about that. 00:04:29 - Speaker 1: Yes, so I had a similar story. I moved to the Bay Area in 2007 because our company got into Y Combinator, and yeah, accessing the networks there, certainly the venture capital, but also just the wider world of tech was absolutely fantastic for our business and for my career. But then when I set down my work with that venture 6 years later, I found myself a little more flexibility. I realized that some of the day to day life there wasn’t quite what I wanted, and that led me to starting to think about where to go next and went through kind of a pretty detailed process by which I made the somewhat surprising decision to not only relocate from San Francisco, but actually move to another country, but that I think worked out really well for me. So you mentioned going through a process and I had one of my own as well and I guess this is what I’ve been talking to folks about recently is when you have this capability to choose a place, how do you actually do that? It struck me how that’s similar in a lot of ways to the two-step creative process we’ve talked about in the context of Muse before and we can get on to that a little bit, but I’d be curious just to know even setting aside process criteria, what makes one place or another better for the stage of life that you’re in or what it is that you seek. 00:05:42 - Speaker 2: Yeah, I had an interesting angle on this. So the original impetus for looking to leave San Francisco was mostly the usual reasons, which I don’t think we need to go into too much here, you know, it’s extremely expensive, it’s overregulated, and so on. But a more subtle thing that I think is really important is what was happening to my cohort. So I’m in my early 30s now, and what was happening was all of my friends and peers who are mostly a similar age, were hitting that period. Where they want to start a family, they want to have a bit more space, maybe they have other hobbies, just kind of entering that phase of adulthood, and they were all really hitting a wall in San Francisco. A few people were able to make it work, having one or a few kids, for example, but most people, when they hit that point in their life, they just couldn’t make it work in San Francisco anymore. So they had to leave. Some of them went to the East Bay or the North Bay, but a lot of them just completely left. They went to Texas or To Portland, for example, or to Seattle, where it was possible for them to pursue that phase of their life. So a lot of my peers were basically leaving all around me, which is a problem from a personal perspective, of course. But also, I was starting to sense that the magic of Silicon Valley and of San Francisco was starting to break down. And here’s what I mean. The reason San Francisco has been so special for tech is that you have people who have been there for 5, 10. 15 years who are helping to bring up the next generation, right? You get that mentorship, that experience, that network. And what was happening was the amount of time that people tended to stay in San Francisco, I felt like it was getting less and less to the point where it was starting to knock on that threshold of being there long enough to kind of fully contribute to that cycle. People were jumping out after they’ve been there for 5678 years. And as that amount was coming down, I was feeling like there was a bit of a collapse in the San Francisco magic. And on the flip side of that, I had this intuition that the future is on the internet, right? It’s not going to be limited to one city. We’ve been developing these social technologies for people collaborating and forming communities across physical locations, and it was very nascent at the time, but I figured it’s only gonna get bigger. And so what I want to bet on is that it’s not being tied to one physical place, it’s having a network that actually spans more of an area. So when I was looking for a place, it wasn’t as much finding everyone being in that one city. Like it’s not that everyone who I want to collaborate with and be with is in Seattle. But for me, that’s a very good home base, and it kind of personally is a very good fit for me, and I can talk about that if you’re curious, but also it’s a great jumping off point. It’s in the right time zone for collaborating with a lot of people in San Francisco and also the East Coast has an amazing international airport, in my opinion, like basically one of the best you can get. So it’s a good place to start a business. It’s of course, where we’ve HQ use. So that’s kind of how I was thinking about moving from San Francisco to Seattle. 00:08:31 - Speaker 1: Yeah, when I was thinking about or you know, enumerate a little bit, maybe my criteria for or what I discovered was my criteria for a place I like to live, but I was thinking more in terms of greenery and transportation and architecture. But here you’re talking about networks, which obviously is much as people I think like a lot of the history and architecture and nature in San Francisco and rightly so, the networks is obviously the real reason or is the big reason, the overshadowing reason for someone that’s in technology. I note that the places that we both chose. I wanted actually to be, if anything, in less a completely saturated place where I love being around these people that are in the same field as me and being connected to that, and that was very powerful at first, but then at some point I started to feel saturation where I can never get away from it. Totally. I was, you know, going to a coffee shop, every single conversation you overhear is about someone’s funding around, driving down the, what’s the main freeway there, every single billboard is a recruiting thing for some tech company and I’m not saying that’s good or bad, it’s just for me, what’s right is I want a mix. I want to be around some people who are in the same field and share this passion with me about computers and technology and the internet, but I also want to be around a diversity of people, young people, people, kids, people that do other kinds of work, artistic people, people in different professions. So trying to find a mix of those in Berlin was a good one. I feel like in 2014, there were some really fun up and coming. Companies and even now has a small but vibrant startup scene so I can be around people to do that stuff. There’s some great co-working spaces and companies I can connect with and all that sort of thing, but it’s not everything, it’s not everywhere. And I feel like Seattle has something similar. There’s obviously the legacy of both Microsoft nearby and then Amazon in the city and other smaller companies. So there’s plenty of tech around. It’s just not the defining characteristic of the city. 00:10:21 - Speaker 2: Yeah, exactly. That was definitely a factor for me. And to be clear, there was a whole series of kind of personal factors on why I chose Seattle as this home base instead of, for example, Austin, Texas. And yeah, one of them was getting this better balance between being plugged into the community but not being overwhelmed by it. I actually like Seattle in that respect because Well, first of all, I think people underestimate how big of a tech hub Seattle is. You know, two of the three biggest tech companies in America are based in Seattle, not the Bay Area, for example. Also, it is really the hub of like cloud back end services, even maybe enterprise, it’s very strong in those areas, games, whereas San Francisco is more. Startup and consumer focused, I would say. And the Seattle flavor is more of my expertise. So that was a good fit. And yeah, I did want to be in a place where I still had 1 ft in the world so I could go down to downtown Seattle and talk to people about tech stuff and you know, even have that option career-wise in the future, but not be so overwhelmed with it as you are in San Francisco. Also, I would say, I was betting that Seattle was just going to keep riding that curve up while San Francisco struggled. You know, it’s really hard for people to build an office in San Francisco and expand it somewhat notoriously. The Bay Area recently had this proposal to like, basically ban commuting for most of your Employees for large employers, it’s really wild. I’ll link it in the show notes. But on the flip side, the offices in Seattle are just growing big time. I was really impressed with how quickly Stripe, for example, was able to stand up a really solid and thriving office here in Seattle. And so I just figured there’s going to be more tech in the future here. 00:11:51 - Speaker 1: And you’re quite good at or quite connected to, let’s say local governance and being aware of and evaluating how well a city or state government is making an environment for infrastructure projects and certainly businesses, which is something I quite like and respect. Because I think there’s a tendency to focus on national politics and election horse races, and those things are important, but many times, especially for something like your business, it’s actually the local level stuff that probably matters a lot more. It’s like a little less dramatic and a little more long term important in some ways. So I’d be curious to hear, I know you’ve looked in quite a bit in Seattle, maybe done some of that in San Francisco around things like ease of starting a business, tax rates, that sort of thing. And again, this comes back to this making a decision about where you’re going to live, if you’re someone who’s an entrepreneur or an investor or a mix of those or a freelancer, which is that it may actually be not just, hey, I like. This place because the schools are good or I like the public transit, or I like the sports team, but actually may have impact for your work life if you’re more of a solopreneur, freelancer, entrepreneur type person. So it is both a professional and a personal decision. 00:13:06 - Speaker 2: Yeah, I think that local and state politics are a really big deal. Maybe this is an American thing, but at least here in the US it’s really important. I think people underestimate that. I certainly fell into that bucket when I first moved to San Francisco. I didn’t really understand any of the California or San Francisco stuff when I got there. So for example, somewhat to my embarrassment, I was not aware of the rent control laws in San Francisco, which is a huge deal. And I kind of lucked out and ended up being fine, but I think understanding those dynamics is really important. You know, it’s funny, this was actually one of the things that really pushed me over the edge on San Francisco. I was getting more interested and involved in local governance, especially around land use and housing and transportation and taxation. And the more I understood what was going on there, the more alarmed and dismayed I felt about. Situation. And it also seemed like it was quite structural, like it’s not something that was just a little bit more organizing and a little bit more democracy, you know, you can push through and fix this thing. It’s very deeply structural in California and San Francisco. And I just didn’t see it getting fixed anytime soon. Whereas on the flip side, I was looking into the governance of other cities and states around the US. I think Seattle actually does relatively well and Washington State compared. to the other big coastal piers. So if you look at, for example, LA, San Francisco, Seattle, New York, Boston, Washington, DC, Chicago, I would put in that bucket. They’re all to varying degrees troubled, but I think Seattle and Washington is probably the best run of all of those cities. And so that was nice for me. And also there’s good structural reasons why Seattle and Washington are going to be, I think in much better position than those others. 00:14:39 - Speaker 1: And I wonder what effect this greater freedom and flexibility for so many knowledge workers will have in the longer term on city governments, and I’ve come to think a bit of government generally, but especially local government as maybe there’s just my bias because I’m a product guy. A city is a product of sorts. It’s a very all around you, all encompassing product, but nevertheless, it offers a series of things and. Requires a series of things as a citizen, and I wonder how much people, I guess it’s already the case that cities competed for or do compete for employers. For example, you saw this when Amazon was considering their second headquarters and they essentially put out like an RFC to cities around the United States and said, you know, make us a good offer, and I think that boils down to some pitch that mostly in the end is tax breaks or something, but if individuals again these People who have a little more agency now in their own careers and they’re deciding, I wonder how that will change if governments, city governments are thinking in terms of how to attract these sorts of people and provide them a good product, essentially a lovely city to live and work in. I don’t know how that will change things, but for me, that helps the mindset you’re describing, which is not thinking of as well, the government’s just given, it’s a natural monopoly. I don’t know, either complaining it doesn’t work well or Satisfied or whatever it is, but treating it as an unmovable force versus, well, actually I can choose. I can go here, I can go there, different cities are governed in different ways and some of those produced places that I find more amenable to living a good life, to running a business, and so I want to go give my business, so to speak, or give my citizenship or my residence to a place that is doing a good job at making a good home for its residents. 00:16:24 - Speaker 2: Yeah, I think it’s going to be very interesting to watch this reshuffle play out over the next few decades. I do think it’s going to be challenging for some cities who see their tax bases realize they’re less captive perhaps than they were in the past. And I think for a lot of it’s going to be a huge boon because people have the flexibility to move there and take advantage of the quality of life and other benefits. So I think it’ll be interesting for sure. 00:16:44 - Speaker 1: Well, maybe now we can talk about the process element here. You mentioned that and I have one of my own. This is the Muse tie in to me, which is, I think of one of the key purposes or one of the reasons this product exists or why I’m motivated to be pushing it forward is that I think of making decisions as a thing we could all use help with, making thoughtful decisions. I often think of the Muse mission as being to help individuals and maybe someday even the society as a whole to be more thoughtful. We live in this age of hot takes and the next outrage wave and sometimes it seems like we just lack space for contemplation and of course one version of that is, you know, build a log cabin and disconnect, but I don’t think that’s throwing out the baby with the bathwater kind of thing and this is a place where I think There’s potential for it to help and something like deciding where you’re going to live and work, if you have that flexibility is a great example of this really deep important decision that involves both facts and research, but also just a lot of thinking and a lot of reflection on what’s important to you or what factors are in your life. So I’m curious when you were in the position of considering moving and considering options, what did that process look like for you? 00:17:56 - Speaker 2: Yeah, there were a few angles. A big one for me is just spending a lot of time in the actual cities. So for several years before I ended up moving, I actually had a habit of spending time visiting different cities, often long weekends or working remotely from a week for different cities in the US and around the world. And I’ve always found that you get very different energies, just being in different cities, being on the street. I always feel very different depending on where I am. And the only way you can know is to go there and do the actual. So I Did some more of that with cities that I was thinking about more seriously, including Seattle. Come here during different times of the season, which by the way, is something people always warn you about in Seattle. You know, you visit in the summer, people like, oh, this is amazing. Why isn’t everyone move here and like, wait, you gotta, you got to experience the winter before you make any rash decisions. So I was sure to do that. And also, you know, see different neighborhoods, see the city at different times of day, early in the morning, at night, things like that. So that was a big bucket. Another bucket was, frankly, it’s a fair amount of reading. Again, to me, the governance situation is quite important. So I did a lot of reading about the politics and the land use situation and transportation and taxes and business law and all that stuff in some different municipalities, and also researching some basic stuff like the weather, for example, and seeing how that’s going to line up with how I feel about where I want to live. So, it’s kind of a mix of the more analytical, explicit, studying the situation and the more emotional, just dive in and see how it feels and then ultimately get to intuit a decision from there. 00:19:19 - Speaker 1: How many places did you seriously consider, particularly when you talk about the reading and research side. It’s one thing to go visit a friend for a weekend and just be like, oh, the city’s nice. Maybe I wouldn’t mind living here, but it’s a whole other thing to think, you know, I’m going to really consider this as a serious place to live and what would my life look like and let me do some deep research on it. 00:19:39 - Speaker 2: Yeah, so honestly, there weren’t a ton of candidates because I did want to live in a global city with an international airport and a reasonable population. And even if you include other westernized countries in addition to the US, there’s not a ton of cities that fit that bill. Actually, another thing that was pretty much a hard criteria for me was walkability. So especially in the US that limits you to a pretty small. Set of cities. So in my kind of first round of consideration, I did have maybe a large handful of cities in the US in the bucket, including Seattle, New York, Chicago, and then a few others internationally, Berlin and Tokyo were two big ones for me. But actually it pretty quickly got narrowed down to Seattle and Berlin, and I ended up spending a fair amount of time in both those cities and thinking about it pretty hard. How about you, Adam? Did you just dial in on Berlin right away, or is that more of a winding process? 00:20:28 - Speaker 1: Definitely more of a winding process, yeah, similar to you both more focused research, but also, yeah, the visits. I often would use, I don’t know if maybe this was on the tail end of my experience. I was still getting invited to speak at professional conferences or yeah, just would have a friend to visit or something like that. And if I had an opportunity like that in a city that I was interested in, I would be more likely to go and do it and then I would purposely plan extra days to just, yeah, go feel the vibe of the city, go to a coffee shop, try to not go hit the top tourist attractions on TripAdvisor because that’s not what your life’s gonna be like when you live there, but see this is a place where knowing someone that lives there versus landing in the natural tourist districts is helpful, but just try to absorb that urban character. And this is something I love about cities. I’m very much a city boy and I love that they each have this personality that seems stronger and bigger. than even in the national character. People say Berlin’s not Germany, for example, which is absolutely true, but it’s the same thing. Yeah, San Francisco, New York, Los Angeles, these places all have a very different character, not only than the United States generally, but even in their immediate surrounding state. And I love that and trying to go and get to know whatever that character is, is a fun part of travel. 00:21:43 - Speaker 2: It’s funny that you mentioned going to coffee shops. People often ask me, Mark, what do you do when you go to these cities? And I’m like, uh, I uh go to the coffee shop and uh walk around the neighborhood and I don’t know, maybe go grocery shopping. It always feels weird to them, I think that you would go halfway around the world and do this very mundane stuff, but the grocery store. But for me, that’s like that’s the vibe. That’s what you’re looking at and that’s what’s in some ways, that’s just daily life. So it’s the most interesting thing. 00:22:06 - Speaker 1: Yeah, coffee shops, libraries, another one I like to do. And then I’ll also just look for big public parks or if there’s a dock or a waterfront or some space like. That it kind of open public spaces where people naturally walk or cycle or walk the dogs or just hang out with their friends. A really good way to get a feel for what the people who live there are like, right, because that’s a lot of the energy. When we talk about the energy, often what we’re picking up on is that vibe from the people. What are the kinds of people that are here and how do they behave when they’re out in public. 00:22:37 - Speaker 2: Yeah, speaking of vibe, one interesting thing for me about Seattle is I had this sort of 2 by 2 quadrant that corresponds to the geography of the US. So in California, I think of it as being informal and kind of cowboy, and in the Northwest, I think of it as being informal but professional. And in the Northeast, I think of being Being formal and professional. So in the Northeast, you have like the bankers in suits, and in Northwest, you have the really elite systems programmers, but they wear like t-shirts. And in California, you have sort of people wearing flip flops, right? And for me, actually, that upper left quadrant, the Washington State Quadrant was a good vibe for me. But it’s kind of hard to figure that out until you spend some time in the place. 00:23:19 - Speaker 1: Yeah, so for me, I did some visits again both in the states but also internationally. Another thing I did quite a bit of was just talking to people, to people that I knew had either lived in one place or another for a long period of time and would have thoughts on it, as well as just asking them, even just asking well traveled people where they thought I would be interested in. I at one point I ended up I think with the 4th ranked list of five places and Berlin made it to the top there based on often the conversation I would have is saying something along the lines of not just what did you like, but what do you think I would like. That question often had people answering Berlin, which they turned out. You write about. So yeah, there was very much that kind of open ended process and yeah, the cities did include some places in the states like Boston and Austin, Texas, but also I was really interested in this living abroad experience. And so yeah, Berlin, Amsterdam, Cape Town, Tokyo were all under consideration. One of the things I like to do, and these days I didn’t have Muse, of course, so I would use just kind of my paper sketchbook and Dropbox, I think it’s kind of my collection point, but I would take a few notes or my Google Maps, I would kind of star places that I thought were interesting and then photos was really big for me. I would just snap photos and of course you can snap photos when you’re traveling and those are memories of the. But for me, it’s a very evocative way to remember that vibe of the city. What was it that I liked or didn’t like about this place and putting all those together and then I have a pretty distinct memory actually of scribbling in a sketchbook one morning when I was actually visiting Denver, which is another place I was thinking about just because I’ve had some friends move there and having this feeling of looking at all this together, kind of looking through the photos and some notes and Writing in my sketchbook and kind of an emerging for me that, you know, I really think I want to try one of these European cities. And that was basically a surprising result for me. I would not have thought that before, but I feel like that is the benefit that can emerge from a more not systematic process exactly, but it’s not based on going to one place after another, and then at one point you feel good enough, you think I’ll do this. Kind of being able to zoom out a little bit and look at all of it together if that makes sense and having these reminders which include your notes and your photos and so forth. And you know, when I describe it that way, of course, that experience and others like it are exactly what I wanted Muse for. I wanted a digital tool that was built around that exact process versus this weird hodgepodge. So I wonder what it would be like considering a new place to live with Muse in my toolkit. 00:25:49 - Speaker 2: Yeah, interesting. Now, when you came to this realization about the European cities, were you able to back out the reason for that? Like the factors that unconsciously had come to that decision for you? 00:26:00 - Speaker 1: Absolutely. Well, there was a lot of the collect all the raw data, which is largely making visits, but also, as you said, some reading and also talking to people. But then having this sense of, OK, I like these three cities but not these two. And there was also some sense of coming back to my home in San Francisco and Seeing the ways that San Francisco wasn’t meeting my needs. You mentioned walkability, that’s a big one for me. I walk to think, to get fresh air, to just move around and exercise, and at least where I was living at the time, just was not a very walkable place, not a lot of green, not very pedestrian friendly. I don’t want to slam on San Francisco. It’s just that I had the comparison of being in some of these other places, particularly these European cities, which tend to be amazing for walkability and they have cycle paths and public transit is good and lots of trees and Berlin in particular, you know, San Francisco is very constrained by being on this little peninsula and so there’s kind of a not quite a space limitation, but things are tight and I know that ties together with the governance and all these sort of things and that low amount of space, I think contributes to this. Everything’s packed in and it’s always a little too small and there’s never quite enough space to walk by something in Berlin by comparison is this big giant flat Northern European city where there’s essentially all this space. Sidewalks are very wide and it feels much more open and comfort. And maybe what I’m describing, a lot of people go to the suburbs for that, especially once they have kids for that exact reason, they want more space, but I wanted the density and the vibes of the city. I just wanted to see if I could do that while being a little more comfortable when I took a walk. And so visiting a number of cities, which included again, some in the states but also particularly stood out in Europe, trying to look at that and say, OK, what’s the pattern here and even looking at photos of them side by side and just reflecting on my experiences and realizing that, yeah, the walkability, the greenery, and it’s not just parks, it’s not just that I want to go to a park, but it’s the amount of green and plants and things that are on each street, it’s the history and architecture. Yeah, of course, it’s things like, is there a good coffee there and bohemian vibe and some other stuff like that. So I saw some patterns, and there’s some things that are specific to places like, for example, Berlin has this music culture. I was a music creator earlier in my life, and being around that feels good to me even though I’m not involved in sort of music stuff anymore. So that’s kind of unique to Berlin, but then I also saw these patterns across and again it’s something I think would be hard to get if you didn’t look at them in relatively short succession and then from there I could back out. Now I feel like I could actually make a pretty good list of abstract criteria. Here’s the things that I would want out of a city or a place to live, and that’s visible to me now because of that sort of data gathering and reflection process. 00:28:44 - Speaker 2: Yeah, so looking at the examples gives you the criteria instead of always insisting on going the other direction of starting with the criteria and applying them to the examples. 00:28:52 - Speaker 1: Exactly. I feel like I use this a lot in my work. A good example here is user research. So I really like the exercise of, OK, we’re going to start to work on a new area of the business or a new area of the product. Let’s go and collect everything everyone’s ever said to us in support tickets and Twitter and whatever. Let’s also go look through our user interview notes, but maybe do some new user interviews and get everything that’s related to one particular thing. I don’t know what, you know, reading long PDFs or something like that, get a bunch of quotes all together in one place that that pulling out the specifics of that and seeing it all together, that’s where the patterns emerge from. That’s sort of like key technique in my general toolkit. 00:29:32 - Speaker 2: So you did end up eventually deciding on Berlin and Germany, which is a big change from the states. Was that a hurdle for you to get over? 00:29:40 - Speaker 1: Yeah, a huge one. There’s been some incredible benefits to, first of all, just the experience of living abroad and experiencing a culture and a nation that’s different from my own, as well as specifically the ways that Berlin really fits my vibe and makes my day to day life a happy one, but it comes with huge costs. For sure going any new place, you have to learn new stuff, you have to adapt to the culture and even figure out, I don’t know, I remember when I moved to Los Angeles many, many years ago. I spent several years just struggling with trying to understand the freeway system and the intensity of the traffic, just trying to get around the city was just this really difficult thing. And eventually I figured it out. I figured out the rhythms and I mastered it and I was comfortable. Then I moved to San Francisco and it was a whole new story because things are very different there in terms of how you get around the city. So there’s always some element of that. But going to a new country where there’s just different cultures, business happening in another language is always a challenge, but then German for whatever reason. Ends up being a particularly challenging one for a lot of native English speakers. Yeah, it comes as being an immigrant is a, it’s like a tax on your life and everything you do, certainly trying to start a business, but even something as simple as opening a bank account. I was turned down by several banks because they don’t really like doing business with the Americans because the US tax authority, the IRS requires certain reporting from foreign banks that it’s just sort of not worth their while to take on American customers. So the list is pretty long and it’s ongoing, even though I’m pretty settled and adapted now, having been here 7 years, basically not a week goes by that there isn’t something that would be much, much easier to get done in my home country. And I’m aware of that and that’s time and energy and money that takes away from things I could be doing otherwise. The fact that that cost is worth it to me tells you how much, I don’t know, what’s the word for it. I’m just living a happy life, and it feeds my creative soul, and I’ve found a sense of home and a sense of a nest that maybe I hadn’t had in other places I lived. So, in the end it’s worth it, but it comes with a big, big cost. So, certainly moving within your own country is a much safer bet if you’re not prepared to bear that cost. 00:31:50 - Speaker 2: Yeah, and I ended up on the other side of that equation. In terms of the city life of Berlin and the vitality of the city, it’s probably my favorite city in the world. Just being in the physical environment, it’s so energizing. There’s so many interesting people. There’s all kinds of different families, amazing businesses and art and history. It’s just an incredible place to be, but I couldn’t get over moving. From the US to Germany, it didn’t make sense for me. I was trying to reflect back like you were saying, like kind of trying to pull out why that was. And I think for me, I really value understanding where I’m living, and not just the language, but the history, the political environment, the legal environment. That’s all a big deal to me. And I had spent, you know, several decades learning that stuff, and I really valued that security here in the US. I was feeling actually, in retrospect, really bullish on the US. I know that’s not a popular sentiment now, perhaps, but I was surprised to see that, you know, I came in with this very global flexibility, could live wherever I want, maybe I’ll move to New Zealand, who knows. But in the end, it was like, actually, I’m willing to bet on the US and that’s where I want to spend the next years of my life. 00:32:56 - Speaker 1: Yeah, I’ll second that the United States remains one of the best places in the world to live. It’s certainly a great place to work and start a business, and I feel incredibly lucky that that’s where I was born. And in fact, one of the reasons I was motivated to go have the experience of living abroad is I met so many people living first in Los Angeles and later San Francisco who are immigrants that came from other places, sometimes very far away. I had so much respect for what they went through to transplant their whole lives, to come pursue the opportunities and the lifestyle that’s afforded to Americans and Californians. But because I happen to be lucky enough to be born in California and be a Californian, I could certainly Just sit back and enjoy the fruits of that serendipitous occurrence, but I felt like I wanted to have the experience of living in another place. And it certainly has given me new appreciation. Being an immigrant just gives you a whole new perspective on nations and cultures because you’re outside of As programmers like to say there’s 1 and there’s N, so most people only have ever really seen the inside of one nation and one culture. Once you’ve seen two, now you can see the, call them pros and cons, but even more than that, you just see the variations, you see the ways that human nature is pretty constant across all these cultural differences, but you also see things that are maybe more accidents of history or fallout of particular geography or history that a culture evolved in. So yeah, it’s a really mind expanding experience, but certainly I am and continue to be thankful that I was lucky to be born in a time and place that is really, frankly, a great place to be. So another interesting factor of this decoupling of where people live from their sort of work and school life is that when it comes time to incorporate a business, now you have also a similar decision. So for example, in our case, we had 3 founding partners and they were all essentially located in different places and so basically you just got to pick where one of them is located and that’s where your business is going to be. In our case, that made sense to be Seattle, but you can even take it a step further. Other than that, for example, it’s been for a pretty long time. I think most San Francisco tech companies are incorporated in Delaware. I don’t have exact numbers there, but I’d be willing to wager it’s in the 80 to 90% range. 00:35:13 - Speaker 2: Oh yeah, it might even be higher. And to be clear, we are a Delaware corporation, you know, we’re incorporated there, and our HQ is in Seattle. It was kind of funny because you basically have to pick an HQ and, you know, we don’t have an office and I guess we’ll pick Seattle because it needs to be somewhere and Mark lives there and that’s where the lawyers are sure. 00:35:32 - Speaker 1: We did the same thing for I and Switch, which was again, distributed founding team. We just arbitrarily picked Miami because that’s where my colleague Ryan lived, so, yeah. Some are taking it even a step further. You’ve got services like Stripe Atlas or Firstpace is a company I just recently invested in, where they actually take this a step further and say, OK, you can be anywhere in the world, most anywhere in the world, and in corporated company in the United States, and it’s really more of a shopping for a jurisdiction, a legal jurisdiction, a legal home for your legal entity, which again takes that uh Whole another step that fits into this globalization story, but all of these mechanisms I feel like were created for, yeah, I live in any town USA and I want to open a restaurant on Main Street, so of course, what do I do? I incorporated the local jurisdiction because that’s just what makes sense. And now in this global internet connected world, the both people and the companies kind of can choose their home based on, I don’t know, more expansive criteria. But what do you think about the whole, yeah, stripe Atlas kind of phenomenon? 00:36:42 - Speaker 2: Well, I think first of all, anything that makes it easier to start a business and gives the opportunity to more people is awesome. I think entrepreneurship is such a powerful force in our society, and I think a lot of people are limited by just the practical things of it costs money and time and expertise to know how to start a business, especially before these two things existed, and they’ve made it much easier. So that’s huge. I’m also pretty bullish on this idea of having more flexibility in jurisdictions. I do think there’s a lot of benefits to that. There’s the long running example of being able to incorporate in Delaware, and just gives a lot of practical benefits for people to have familiarity and confidence in their jurisdiction and There’s some sense of competition, dynamism among the different jurisdictions to be a good home for businesses. So I think that’s quite good. I do think they’re going to be some big challenges. I think one is going to be the tax situation. I think honestly, that’s going to be a fiasco. I mean, it already is internationally. So the deal there is companies take advantage of being able to move jurisdictions for tax purposes, so they might flow a lot of profits through, I’m not an expert in this, but like, you know, Ireland or something, and it’s basically totally artificial. 00:37:46 - Speaker 1: As I say, wasn’t there a big court case with Apple over that a lot of their profits flow through Ireland and so the way they were paying taxes, maybe to the at least American authorities felt like they were not doing their fair share. 00:37:58 - Speaker 2: Yeah, that’s kind of one of many examples of what’s going on here where historically you had businesses where the business, the physical plant, the employers, the customers, transactions, they were all in the same place. Like if you have a mom and pop shop that they’re all in the same place, for example. And so it’s kind of obvious what to do. But if you have a business where you’re incorporated in one place, your headquarters in another place, your employees are in different place, your customers are in different place, the transactions. Nominally somewhere else, the servers are somewhere else, your lawyers are somewhere else, who gets that tax money? And it’s not an obvious question. And there’s a lot of wrangling over that right now. And by the way, it might actually get even worse this coming year because everyone’s going to have to do their taxes with everyone working from home. And you know, is your income in where you used to work, or is it in where you spent 7 months or yeah, it’s going to be a mess. But I’m confident eventually we’ll be able to figure this out. 00:38:48 - Speaker 1: Yeah, I think it’s one of these problems that society needs to tackle and find a way that’s fair and comprehensible and navigable to everyone. I think of something like the Amazon sales tax issue, which I think took many years to sort out, but essentially collecting sales tax once. commerce largely moves online. You buy and sell stuff in the cloud and then where does sales tax get charged? 00:39:11 - Speaker 2: I’m smiling here on the podcast because while the sales tax situation is better, it’s still not fully figured out as we recently realized with news, we’re getting there. 00:39:21 - Speaker 1: Yeah, that’s right. And then when you have small businesses that should be focused on survival, they’re trying to, you know, in our case, try an innovative new product and see if people will pay for it, and we have a small team and we don’t want to be caught up in tax law jurisdiction stuff that’s just going to drain energy and time and everything else away from just making a good product and pleasing our customers. But at the same time, yeah, it’s often not clear. I have a personal story on that, which was funny. I living this immigrant lifestyle is I often mystify my working with tax advisors or attorneys or other things like that. For example, a state planning, you know, I pay into both the American Social Security system but also the German pension system, and there’s all sorts of weird ways that those interact. Many cases, there’s international treaties that govern that kind of stuff, you know, is a driver’s license from this place accepted over here, or can you Diverted or if so, how? So yeah, things get thorny and then my partner, my life partner is from yet another country and then we’re living in this, so you’ve got two people from different countries who are living together in a third country and they want to do things like I don’t know, a joint bank account or purchase a home together or something like that. Yeah, things get confusing fast, even hiring experts, attorneys and advisors and other things, they’re often just mystified or You know, who’s going to be an expert in either 2 or certainly all three of these jurisdictions and sometimes it’s just not even clear. One good example for that is because I do so much work for companies where I earn equity rather than cash or some mix of cash and equity, which is of course really, really standard in the startup world, but I have earned equity from companies over the course of many, many years, have a portfolio on that that I’ve built up over. Time and of course it takes a long time to pay out. Most of it’s never worth anything, but some of it eventually is worth something. And I recently had a company I did work for back in 2010 went to IPO, so I made some good money from that and that was nice, but I’ll tell you what, trying to figure out the tax situation as it relates to Germany is quite interesting because there you go, OK, well, I worked for a company, you know, almost 10 years ago at the time, almost 10 years ago, in a country. The company was in the United States. I was in the United States. I had never even been to Germany at that point. I had no work visa or anything. That’s when I did the work and I earned the equity then and of course it wasn’t worth very much then, basically, effectively worth 0. And then here I am, but now I’m here in Germany, I have a work permit and I I should be paying taxes on my earnings. The work was actually done previously and honestly, no one really knows. It’s just a legal gray area and you end up in this position where you have to try to figure out, obviously I want to pay what’s fair to all of these nations who are involved in it, the United States that was hosting me and the company and at the time as well as to my new adopted home, but it’s in many cases people don’t know what’s fair and then you’re trying to figure that out as you go along. 00:42:12 - Speaker 2: Yeah, the tax stuff is quite a rabbit hole for sure. 00:42:15 - Speaker 1: Well, maybe we can end on, if you were to give advice or give you at least your thoughts on how someone could or should approach thinking about where they want to live, if they have that flexibility in 2020 in this new Zoom centric world that we live in, what tips would you offer them? 00:42:33 - Speaker 2: Hm. I think I’d go back to a sort of personal motto of mine, which is to be honest with yourself, and this means really understanding what motivates you and drives you. So whatever your process is, try to dial into what is in fact really important to you and where you live. And I think it’s being open to the possibility that that is not obvious, that’s maybe a little bit alarming to you, that it’s not what your friends expected or think should be the case, but really being true to what you actually want and need, and then going forward from there. What about you, Adam? 00:43:05 - Speaker 1: Yeah, I like that. I’ll add on to it that I think when I’ve been in the position of offering this perspective to someone, I’ve compared it to dating, which is you can have some idea in your mind of who your ideal partner is just like you can have an idea of what your ideal home is, but in many cases you don’t know until you see it because you don’t really know what the variables are, what the options are, and sometimes a place or a person just has some special combination of. Elements, some chemistry with you that never would have predicted just from the on paper analysis. So I think that’s for being a little open, maybe trying to cut free of what is expected from you by your culture, your friends, your family, and being open to seeing what place you vibe with and then doing that reflection and trying to understand for me, a lot of the reflection. was realizing, you know, I thought maybe I was in a place in my life where I want to be a little bit out of the hustle and bustle of the city, the big bad city with all its crime and dirt and intensity. That’s a young person’s game. But I actually found when I looked at the different options, now, I really thrive off of urban energy, but I also at a point where I want a little more green, a little more quiet, a little more space, and can I get those two things together. In fact, you can. There’s a huge amount of diversity in cities in the world, and if you’re open to absorbing and seeing what your experiences are in terms of this place feels good to me. I feel at home or I feel comfortable here and the self reflection on understanding what that means for you in terms of understanding what you value, but maybe also stage of life. Maybe you have an image of yourself in the mind that I’m a young dynamic person and I want to be in. Some young dynamic oriented place like Manhattan, but maybe in fact, that’s not really what you want. Maybe you wanted it when you were younger and you don’t want it now or the other way around. So I think being very open but also self-reflective is the key. 00:44:56 - Speaker 2: Right on. 00:44:57 - Speaker 1: If any of our listeners out there have feedback, maybe a little about your own journey in thinking about where you want to live and work, then reach out to us at @museapphq on Twitter or by email, hello at museapp.com. We always love to hear your comments and ideas for future episodes. And Mark, thanks for holding down Muse World Headquarters there in Seattle for us. You bet. Thanks, Adam. See you next time.
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: I think at some point I would love to go back to just work on, I don’t know, album artwork, or just lock myself away in a cabin and just draw typography. But for now, I feel like there’s some stories I want to tell. And for some of those stories to really resonate, they need to be put into people’s hands and experience. And so until I’ve told those stories, I feel like there’s unfinished business. 00:00:25 - Speaker 2: Hello and welcome to Meta Muse. Us is a tool for thought on iPad. This podcast isn’t about use the product, it’s about mus the company and the small team behind it. My name is Adam Wiggins. I’m here today with my colleague Mark McGranaghan. Hey, Adam. And our guest, Jason Yuan. Hello. And Jason, you are a prolific creator of all sorts. The one that struck me as very interesting from your background is that you got your start in stage design, which you described as a bit of a two-way interface. I’d love to hear about that. 00:00:59 - Speaker 1: Yeah, I think what’s interesting about stage design and theater design in general is that It’s so inherently multidisciplinary. So even if you say I’m designing on a show, you might mean costume design, stage design, set design, sound design, and all of those have to be choreographed perfectly. They have to work together. And then, obviously, the stage needs to be used by the actors. It needs to be functional. People need to be able to enter and exit. It needs to be safe. So that’s one aspect of like, I guess the people that it needs to work for and then obviously you have the audience who rely on. The culmination of how the stage design works in conjunction with all the other elements to bring them into a world and to tell the story. And so it’s fairly high pressure because so many people rely on it and because theater is sort of in the moment, if something doesn’t work or God forbid if something unsafe happens, like that’s on you, partially, so. Design has always sort of felt very high stakes, even in interaction design now where you could always ship a bug fix or you might be able to delay the launch or incrementally improve things over time in theater unless you’re a very prolific show, you don’t really get that luxury. 00:02:12 - Speaker 2: Yeah, I can imagine the live performance element creates a sense of, well, I suppose drama would be the word for it, but for the people who are creating it as well, you have this showtime moment and everything’s got to come together and work right, and if it doesn’t, the problems are all up there for everyone in the audience to see very dramatically. 00:02:32 - Speaker 1: Yeah, yeah, something that frustrates a lot of people that I’ve worked with in tech, sort of, I’ve always carried the show must go on mentality. That sometimes, you know, applies, but then if you’re working on indie projects where like there’s no real deadline, people are like, why, why though? It’s ready when it’s ready. And I’m like, no, like the show must go on. So that’s been interesting trying to find elements I want to keep from my past now that I’m practicing something that’s fairly different. 00:03:01 - Speaker 2: At some point you made the transition to the digital technology world and lots of interesting work in your portfolio there, including Mercury OS we’ll talk maybe a bit on a little bit, which was how I first discovered your work. You’ve also been working on MakeSpace. What else is on the recent portfolio. 00:03:21 - Speaker 1: You know, after Mercury came out, there was so much feedback from people who wanted to see it become real in some way. I worked on several smaller spin-off projects that were inspired by the initial vision, like, I don’t think it was ever designed to be a thing that I saw ship as this. It’s a very point of view. Mercury was designed from a very specific point of view through the lens of someone who is frustrated that my own mind as someone who lives with ADHD and PTSD and just, I find a lot of things particularly stressful in computers like file systems and how I have to constantly open and close apps and switch context uses. It was a very specific point of view there about like operating systems, but, you know, trying to think about a way to make some of the ideas actually happen. Has taken up a lot of my past year, I think. And in some ways makespace is kind of an offshoot of that in the sense that I think the spirit of reimagining something that I felt like could have a lot more potential exists in Maspace. And, you know, when Asa and I first started working on it, the code name was untitled OS. So I think from Makespace came this fascination. Of like exploring platforms, but then also exploring smaller, more contained experiences that attempt to deliver sort of flow state to people. I think I’ll be sharing some of them soon, is what I’ll say. There’s two particularly I’m excited about. The first one is sort of looking at screenshots as a metaphor, sort of inspired by. I saw this guy tweet once like screenshots and then you save and then obviously Omar’s work on screen notate. 00:05:15 - Speaker 2: Universal solvent is usually the way we put that now. 00:05:18 - Speaker 1: A screenshot sort of experience is something I’ve been working on with a collaborator called Tyler Egert, and he’s currently at this startup called Reple. And then a separate project is sort of like a take on a to do list that sort of imagines to do lists in the context of your social media feed. But that’s a much longer conversation, and I’m looking forward to sharing some of that soon. 00:05:40 - Speaker 2: We’ll be excited to see those. Well, yeah, I’ll link the projects we’re mentioning here other than the ones that aren’t out yet, of course, in the show notes. So yeah, Mercury OS, which is kind of a rethink everything in the sort of the operating system interface, and then MakeSpace, I can see the thread there, I can see how that’s related. Makespace is an app for lack of better word for kind of spatial video chat experience if I’m understanding that correct. But you can see how that’s an offshoot or a different way to cut the kind of the operating system space, but maybe a little bit more focused specifically around the video meeting domain. Does that sound about right? 00:06:18 - Speaker 1: Yes, and I think the original prototype that Asa hacked together was just spatial browsing. I think video was the second thing we added. Oh, interesting. Yeah, so it kind of started as a vision for a spatial browser. And when we brought Wei Wei into the project, she had all these amazing ideas about like bidirectional linking and then we had ideas about like how to use web apps, like how this might enable people to disassemble and reassemble web apps. And like use them as modules and how you could essentially author your own ideal interface environments. And then sort of the faces going into that experience is sort of like COVID was raging here. It was having a grand old time and we just felt like, why not coexist next to, we think about breaking boundaries between app silos. What about the silo between what I do on my computer and people. So yeah, that’s a little bit about how that project came together. 00:07:14 - Speaker 2: Maybe that’s a good way to tee up the topic that we’re kind of theming around today, which is rethinking the OS, and I wrote an article recently kind of talking about some core interactions and I listed off some of these what I would call concept projects. You tell me if you think it’s fair to group these together, but I put Mercury Desktop Neo is one that our colleague. Leonard, the Muse designer did while he was in university. There’s another one called artifacts, which is very interesting, goes very deep, and all of these have maybe the quality of sort of really rethinking from the ground up. It’s not just how do we remake one part of this, but if we really had a blank slate, how would we, how, how would we want. to be knowing what we know now in terms of new software, new paradigms with, yeah, whether it’s social media or video capabilities or really large screens or touch screens. A lot has changed since the core interactions that make up certainly the desktop operating systems, even mobile in a way is now well established compared to all that’s come up. 00:08:19 - Speaker 1: I remember I seen Desktop Neo and then this other project artifacts and around the time that I was writing the story around Mercury, and I remember thinking like, oh fuck, am I allowed to swear? 00:08:32 - Speaker 2: Oh, it just means that when I edit the XML for the episode, I have to flip the explicit switch from yes to no. Although it is very good that the podcast RSS feed format lets you flag specific episodes. I had to first do this for Josh Miller from the browser company. He was an enthusiastic swearer, and I felt like editing that out would be taking away some of the. The character. So please proceed. 00:08:55 - Speaker 1: You, you can feel free to add a bleep somewhere. I think that’s always fun and dramatic and it feels like you’re in a sitcom. Anyway, so, yeah, I remember seeing Desktop Neo and artifacts, and I was like, fuck. People are gonna be like, you ripped them off, because the things that I recognized was this desire to extend the desktop horizontally. To have the component of like your windows should be able to flow horizontally and off this arbitrary bounding box. And I think like Mercury is definitely not the first project to sort of envision that. And I really think that all of these speculative projects point towards that future of people wanting, for lack of a better word, more space, and also, I think it’s something that I would be curious to see. Happening in some way. I mean, one could argue that with iOS 14 widgets, I know that it seems like quite an incremental or even catch up, so to speak, but if you look into the future and you imagine like widgets and also app clips, and now things can live in your home screen that are more than just icons, and then your home screen having the ability to obviously swipe between pages, some interesting connections there that I would be curious to see where that leads. 00:10:11 - Speaker 2: Hm. Mark, what’s your take on rethinking the OS, these concept projects, and then more to the point maybe where they point, which is, do we need or is there value in a fairly dramatic rethink of the fundamental interactions versus, you know, what we have is tried and true. 00:10:30 - Speaker 3: Well, I think it’s certainly always worth trying. There’s so much upside if you get it right, if you land on something interesting. So I’m glad to see all the experiments, and I do think that the fundamentals underpinning all of our work are changing, so we’re getting bigger screens, we’re getting touch screens, we’re getting new. Graphics pipelines that are much more GPUs and parallellyzed, and I think a huge one is we’re getting very different economic models around the operating systems and the platforms and all of those have, and I think will continue to drive changes. So iOS was about touch and the new economic model mostly. And things like these new desktop explorations, I would say are more powerful, bigger screens and touch moving into the desktop platform and things like that, as well as having enough processing power and media that things become much more rich, interactive, visual in a way that they weren’t really even 10 years ago. So, I think it’s worth pursuing. 00:11:21 - Speaker 2: Yeah, that’s one of the things I think a lot about with what do computing for productive uses look like in the relatively near future is we now have this huge screens, the multimedia stuff, you know, video is just absolutely everywhere, for example, but we also have the diversity of input. This is one thing I like a lot about the. iPad stylus, touch with the fingers, trackpad, keyboard, you can throw voice in the mix there, and then if you go to, OK, everyone’s waiting for that drafting table sized or maybe just IMAX sized iPad that seems likely to come in the not too distant future or something like it. And then you can imagine something that feels a lot more like a room-sized thing where maybe you have multiple screens, which is already the case that we all kind of have our phones sitting there in the desktop and maybe you’ve also got the tablet. You got the voice interfaces, you’ve got the different kinds of inputs, and you put all that together and I don’t know what it adds up to necessarily, but it does seem to imply some fundamentally different relationship with your computing devices, even just how you relate to them in physical space, your posture as you use them. 00:12:28 - Speaker 3: And speaking of the human element here, we’ve done a kind of systems analysis of why might you different operating systems to emerge. There’s also the human side, which is when you put these new OS’s in front of people, you get a very positive reaction. They say things like, yes, this is how I want to feel as a user of my computer. It’s a very visceral reaction. And so I think there is a, there’s a gap between how computers currently work and how people want to feel when they’re using their tools. And that I think is still a big space to explore. 00:12:55 - Speaker 1: Yeah, I think when I started with Mercury, it started as a purely like surface level ergonomics project. It was so funny. It started as a design system of like, let’s make things look better. And then I’m like, wait, no, like that’s not actually why I don’t like my computer. Things look OK, generally, and I’m like, OK, well, maybe let’s make things move better. And then I’m like, hm I don’t know that the choreography is necessarily a problem that much. And then there was a phase where I realized that the ways that we are conditioned to think about interaction design. When I first started learning about it, it was like you use sketch, and then you, which is basically illustrator, and you have art boards, and then you link art boards together and then you basically make a choose your own adventure presentation thing. And that’s interaction design. And I realized like the real ergonomics part that I felt like was missing was the in between. Each moment of transition should feel like a moment of power, should feel like you can sort of change your mind or keep going, but the way that we’ve been conditioned to design sort of digital products don’t really. I don’t really feel like it affords that way of thinking about how interfaces work, unless you use something like origami or court composer or code. And so it was at that moment that I’m like, maybe this ergonomic problem goes a little deeper, and that’s when I started to think on more of like a system level. I think before that, I didn’t feel like I had permission to, you know? During my internship at Apple, it was actually a friend of mine, Marissa. We were just having a conversation about Siri one night and she just started asking like, do you think this is really like what voice interfaces should be like? Do you think there should be all these different modes? Do you think that having a little brick in your phone that holds all the power is the right way for computers to sort of expand into and. I had just never thought about things like that before. I was just trying to make screens that moved, that looked and felt ergonomic. I wasn’t thinking about the actual base layer, why? And so after that, it sort of felt like suddenly a whole new world of just asking questions and digging myself into a rabbit hole was just possible. And the process behind thinking of Mercury was very similar. It was basically that, but in a design process. And I think what you’re saying about people being drawn to These very tactile experiences, I think, in the process of researching for Mercury, I read a lot of like white paper style things. And I was just incredibly bored or not stimulated by them because I’m like, yeah, you kind of have these drawings that look like memes of diagrams that look like they go in a patent. I care about this because I happen to like designing computers, but you put it in front of anyone else, and they’re like, why should I care? And so it became apparent that If I wanted to create a vision that people cared about, that I would have to focus a lot on the craftsmanship, the visual design, and also the storytelling delivery. 00:15:45 - Speaker 3: It’s funny you mentioned that Adam and I were just talking about this this morning. You basically can’t explainm to people with text. It just doesn’t work as an empirical matter. What really works is video and animation. And I think this is resonant with what you were saying, where you need the right medium to convey your emotional message. 00:16:01 - Speaker 1: Yeah, I learned about the concept of a tool for thought after moving to the bay. It’s one of those things where I just like kind of don’t get it, where kind of everything is a tool for thought. Um, but I kind of understand why there is this specific community that’s very obsessed over thinking about thinking tools, essentially. And I think giving something a phrase gives it power sort of reference points. And so I think absolutely like, I think when I first found news, I can’t remember the copywriting, but I can remember seeing the gesture on the iPad and seeing things zoom in and out and seeing writing being just all over it and just thinking like, yeah, that’s how it should work. And I think it’s successful in that it makes things seem very obvious in hindsight, and I think that’s sort of a quality that I really aspire to achieve when I design. News is interesting because you can tell a lot of OS or platform level thinking goes into it and it’s an app. And same with sort of makespace where even though internally we think about it as like a social collaborative operating system, it’s an app. And then my instinct is that there’s going to be a lot more in the coming years slash months, and I would be curious to see like, you know how Android has like launchers, that, but for my desktop experience. Though I’m unclear how that might happen. But something very compelling someone said to me was like, Google search is basically an OS now. And when I think about operating systems, it’s less like Unix and like how you actually what this is, and engineers are probably going to send me death threats, but like I really don’t care. Why should I care about that? As a person who likes computers and likes to play with computers, I just want to worry about how it feels and looks, and that’s really how customers were users. I don’t like that word either, but customers would think about it or people. So double edged sword, probably. 00:17:51 - Speaker 3: I think this is also kind of inevitable because operating systems are, by definition very general and complex. It’s about being able to host other programs, and it’s the nature of complex things that they inevitably arise from simple things. I forget the person this is named after, but that’s a lie if we can put it in the show notes. So that’s why we see most of the platforms evolve from something simpler, either from an app, so I would put the Web browser in this category, it started as an app on, you know, Windows and Mac and so on, but now it’s basically a whole other platform. Or you see basically a small kernel of fixed apps evolve into a platform. This is the iOS story. There wasn’t an app store, remember, it was just, there was the calculator and the male app and Safari, and that was, you know, kind of it. If you want something else too bad. But eventually they generalized it into a real platform, a real OS that can run user supplied apps. 00:18:36 - Speaker 2: If you want that back even further, I usually think the iPod is the start of the iOS story. So it really was a completely dedicated device for playing music and had a very, very simple, but in fact innovative interface, the little wheel was recognizable. It was fit for the purpose of on the go, music listening. Very simple screen, but all designed to really solve that problem extremely well in a way that maybe MP3 players at the time didn’t. And then yeah, that evolved upwards into more and more complex platforms to the point that today I think it’s one of the world’s most sophisticated places to build applications. 00:19:12 - Speaker 3: And this to me is a really interesting and important research question in. Operating systems, what’s the path that you take in the path dependent sense to get to the place you want to be? Like you need to have a vision, you need some provocations for, OK, I think we want this style of operating system, but it’s very much a social, economic path dependent question on how you actually get there. It’s extraordinarily expensive to develop an operating system these days. So you can’t just suppose the final step. 00:19:38 - Speaker 1: Yeah, and now it also has to live up to everyone’s expectations of not only what it can do, but the ecosystem that it brings. And I think, you know, I have zero idea how any of this will happen, slash if it’s ever going to happen, but I would love to live in a world one day where instead of having like 500 note taking apps, I can just piece together and buy a la carte elements of different experiences that I like. Obviously there’s an entire conversation around like how capitalism works and what’s profitable and blah blah blah, but, you know, one can dream. Mainly I’m just tired of I’m tired of opening all my Adobe apps, and they’re basically like a canvas that you draw things on and then different ways to make things adhere to or not adhere to the grid and treating things as faster versus vector blah blah blah. Like to me, uh, it just seems like mentally I just envisioned it as a canvas that I can bring in different tools as needed and that should be how my workflow is, which one day like, it would be amazing if something like Makespace would turn into that sort of platform. Given its inherently spatial nature. 00:20:50 - Speaker 3: The Canvas thing is interesting. We’ve seen that emerge as a key content type, I would argue over the past few years. By Canvas, I mean it’s free form, it’s mixed media, uh, you have some flexibility, so Figma, Makerspace, makespace, Muse, a lot of these apps have developed this and they’re all kind of circling around a similar idea. It’s like this thing where you can put whatever you want, however you want. And that hasn’t quite been baked into an operating system proper yet, although it’s funny, it kind of harkens back to the old school classic desktops, which we almost forget about, but that’s like the OG canvas. 00:21:26 - Speaker 1: Yeah. Something that we’ve talked about a lot internally is how used to our people to this canvas metaphor when they don’t spend their days clicking around in FigMA or using Adobe Suite. 00:21:38 - Speaker 2: Yeah, it’s sort of the opposite of the particularly the phone innovation of you have one app at a time, it’s full screen, and that’s all you can do. And actually that’s an improvement for certain cases on the desktop complex windows that overlap with buttons on them, and you can minimize things and they have these menus and there’s focus and there’s all this confusing stuff to keep track of, but at the same time. Time for a more powerful environment where you do have multiple documents open, you need to move things around between them. You have different kinds of media, different kinds of things that you need to look alongside each other, move stuff between things, copy paste, and so on, the mobile one app at a time is the wrong metaphor. And so yeah, in a way, these tools where the primary document is a canvas that you can put things on in a very free form way that does. and back to the GUI operating system, uh, metaphor that came out of Xerox PARC, but there you had something where you have one document, which is sort of your desktop, maybe you have 4 if you have virtual workspaces, and then the windows that you arrange, they’re very kind of temporary, right? They’re just what’s in memory, there’s no persistence, there’s no sense of a board and certainly I can’t share it. I guess there’s screen share, but. So in a way, there is something to that metaphor. I think what you find when you reinvent or rethink something is that the best qualities of a previous or of an older idea come through, but you also leave behind a lot of the things that maybe you don’t want or you can improve upon it in a dramatic way, but you can only do that, I think by having a little bit of a break. It would be hard to imagine, for example, Linux, Windows and Mac. Evolving into Figma or evolving into makespace or uses. I don’t think that could happen. They have too much baggage in history. 00:23:25 - Speaker 1: Yeah, I think the primary change that I’ve experienced in my year in the valley is, you know, last year I was all like, it’s not too late to we start delete everything, you know, everything sucks. We need to start from scratch, just everyone to stop, like, no more software. Um, whereas now I’m a lot less. I mean, I still live for speculative proposals or provocations. I love when people ask questions and when people rebel a little bit, but I think working on the sort of future stuff like it’s Tends to be a very lonely process, and you don’t get that satisfaction of like opening night when like audiences actually get to experience the work and walk away with a little bit of their lives may be changed. Sound like such a theater kid right now, but I swear that part has not died. Silicon Valley can’t kill me. Um, but I think I’m learning more as a creator to hold both truths at once, to have a series of clear North stars that I think. would really help people that I’m curious about exploring and also finding practical concrete ways to head there. So I’m not just like randomly in a lab somewhere, which is like that’s fine too, but I don’t think I’m there yet. 00:24:38 - Speaker 2: Yeah, I think that duality is really important. You got to dream big, but also be willing to find ways to bring that into practice. I feel like you have the one extreme, which is, you might call it ivory tower head in the clouds, dreamer thing, and it’s much easier to think the big thoughts and the inspiring ideas because you’re free of the baggage of, I don’t know, reality or the status quo or what have you. But I think it’s ultimately unsatisfying and I think I’ve seen people who are Maybe tend towards that dreamer side, be even frustrated or even become bitter because they think I have all these great ideas. I figured it all out, but those ideas, if they don’t see them come to fruition somehow, it ultimately feels sort of unsatisfying. But the flip side of that, of course, which is people who are really in the day to day and the practical and being very pragmatic and incremental, which I think certainly the tech world has a very strong iterative, you know, just make your MVP and build on that. thing which I think is very good for getting going and discovering a problem and so on, but sometimes you do that that means you’re losing the ability to think big thoughts, dream big dreams, go further, move past what’s here today. And so there’s some, I feel there is some way to resolve that duality, although in a way, I think as an industry and certainly for me as an individual, I’m still trying to figure out exactly how you get the best of both worlds and hopefully the worst of neither. 00:26:04 - Speaker 1: I kind of just do things through the lens of culture to get anything to actually take off or have impact. Essentially, you need to change culture in a certain way or to have an idea influence culture. And I think there’s a place for it, you know, speculative or utopian dystopian ideas, and certainly, you know, those ideas are exciting and can excite a lot of people as like sort of aspirational pressure. Which is a term I stole from Asa, where you make something and then if enough people care about it, then that creates momentum towards that one day. And then the sort of more incremental thing is a slower way to more immediately start bending culture. I don’t think everyone should care about computers as deeply as like, maybe I do, or obviously you guys do, cause people have their own stuff going on, divorces, and I think that’s it. I think that’s the only thing that happens to people. But Um, so like, like we don’t have time. Like, don’t make me fucking worry about that. But at the same time, because computers are basically worlds that we live in now, people should feel empowered to think about it or question it if they want to. It’s sort of like, I guess politics in a way. It affects you whether you like it or not. And I think more people feel empowered to have an opinion on politics versus on like the operating system. And I think I would love to help make that conversation more accessible in some way. 00:27:24 - Speaker 3: You might not be interested in operating systems, but operating systems are interested in you. 00:27:30 - Speaker 1: The old saying, oh my goodness, is that it really, that’s that’s the same. 00:27:34 - Speaker 3: Well, it’s a classic thing with politics, right, 00:27:37 - Speaker 2: um, yeah, right, you can ignore that I don’t want to think about that, but in the end it does affect your life and that’s why it’s important for us all to be concerned citizens. Now happily, part of the magic of capitalism or just the world we live in generally is that there’s specialization. And so it’s OK that there’s people like 3 of us who for some unknown reason seem to be. obsessed with computers and we’re devoting our careers to trying to make them better as we, um, as we see, take that word to mean, whereas there’s others who are obsessed with other things and they can work on those things and hopefully we can all together make a better world for all of us. But that said, I think it is a really great point. I’m often struck when I speak to friends who are not from the tech world, and I can talk about. I don’t know, a design decision that Facebook is making, for example, and for them, it’s more like just a force of nature. There’s no the concept that there’s people behind it who are actively making a decision to do one thing versus another thing versus that it’s far away, yeah, unchangeable thing, doesn’t even enter their minds. And I understand why technology is hard to understand if you’re not in the field. Even if you’re in the field, frankly, it’s pretty hard to understand to keep up with everything, but as you said, empowered to have an opinion at the very least seems worthwhile. 00:28:55 - Speaker 1: Yeah, I remember as I was trying to think about Mercury or operating systems, I think certain people I worked with were mentors would be like, why is it something you care about? Like, are you gonna ship this thing? Like, are you gonna go propose it to like Craig Federation? Like, why? Like it’s not gonna ship. What’s the point? And I disagree still, I think. If we just stop caring about anything that we can’t change, you might as well just stop caring, period. Certainly these days it’s quite easy to just associate your life away. I mean I’ve I’ve certainly been doing a lot of that. I think something that was very interesting to me when I first arrived here, I think one of the first things. I did was my friend took me to Dynamicland. but my friend informed me of who Brett Victor was slash I, I knew who Warrior Dream was, but not who Brett Victor was, you know, and then about Dynamic land and that it existed. So I went and like the first thing that I thought was like, oh my God, people should be using this to make theater. This is interactive theater. Like, why isn’t this in my black box? Where are the artists, you know? And that’s something that from what I understand, maybe community outreach is not necessarily like a focus of theirs in this present moment, but I think if you’re serious about getting people excited and therefore affecting change on a cultural level, I think it starts with getting culture makers excited and. It takes me longer to do write-ups than to design things because it’s so important to me that people who had no idea of why they should care about an operating system can read the story I wrote and then walk away feeling like, yeah, I care now too. And I received lots of emails from people who are also had certain neurodiverse tendencies or just like friends in theater who I didn’t think I had permission. Like, I, I didn’t know that. Like, now I’m a lot more angry at my devices, and I’m like, you’re welcome. And I love that. I want to be remembered for making lots of people really angry. In a good way. 00:30:56 - Speaker 2: Well, yeah, people in my life often point out how I seem to be more dissatisfied with the digital technologies that we interact with every day than anyone else they know, and that sort of maybe seems like a strange, a surprising juxtaposition when I work in the field and claim to enjoy computers and the internet and software and all those sorts of things, but my patience for things that, you know, are trying to hijack my attention. Or faces that are too slow, or things that just treat me in ways that I think are not the way that these devices which are designed to serve us and help us and make us better, often do sadly these days, but it’s connected part of my passion for it is precisely because I think we can do better. Yeah. So when you talk about Brett Victor, his work is just the pinnacle of inspiring, but as far as I know, he is not doing things to really Bring his work to practical. He’s not trying to produce spin out startups or take one of his code bases and make it open source so someone can build on it. He’s trying to show what might be possible to get us to aspire to something higher to to get us excited. And I know many people who point directly to his work as something that got them maybe specifically interested in design or specifically interested in productivity tools design or specifically interested in. And user programming or some other aspect of this kind of computing for thinking and productivity and creativity. And so you could say that that, you know, you could do it just that way and Jason, I see your work is seeing a lot of that. You do these pieces where it’s not just the design you’ve made, of course, but it’s also like you said, the write up where your intention is to help people understand why. And get excited and follow the story and you probably would be OK to stop there. Now you don’t have much say over maybe you lack the satisfaction of getting to deliver something all the way through to a customer and see it put a smile on their face. But one way to do it is kind of say, well, I’ve done my part, which is to inspire and step away, assuming that you can make that into a livelihood and let others kind of productionize, you might say. But it sounds like you don’t find that satisfying enough, or you want to take it past just that inspiration stage. 00:33:13 - Speaker 1: Um, I think if I lived in my ideal world, I would never worry about shipping anything ever. I kind of view that sort of more as art though, versus design in a way. Like it feels more like a personal provocation expression, like a need to do something driven internally and design is a lot more. I interpret it as a service, and you could argue that doing aspirational conceptual work is kind of a service, but I think of it more as art versus design. And so I think if I was able to, and if I had that pedigree and following and just sweet, sweet cash. Live in capitalism, can’t pretend to live out of it, you know, whatever. I would do it. To be honest, I don’t know how long I will spend in the tech industry because I think at some point, I would love to go back to just work on, I don’t know, album artwork, or just lock myself away in a cabin and just draw typography. But for now, I feel like there’s some stories I want to tell, and for some of those stories to really resonate, they need to be put into people’s hands and experience. And so until I’ve told those stories, I feel like there’s unfinished business just for me personally. 00:34:18 - Speaker 3: Yeah, and to me, part of the motivation for bringing things into the real world is to understand if you got it right, because here’s the deal with reality. It’s so complex, you can’t actually understand it. These design heuristics are about coming up with a better guess and then incrementally perhaps arriving at the solution and really the only way to know is to try it. So that’s one of the reasons why I like the balance we struck with ink and switch and Muse. You have this combination of academic thinking, far out planning and vision. But then you also force that to confront reality and see what comes up, and often it’s surprising, and it’s a little bit of a bummer when your visions are contradicted by the cold hard truth, but that’s important data if you ultimately want to move the needle in the real world. 00:34:59 - Speaker 1: Yeah, I love exploring all the interesting gestures that you guys have in use, and there’s a certain point where I’m like, if I wanted to take this out of a layer, do I just hold on to it and then move and it turns out you actually just do that, which I loved. I love when things just naturally feel like. Connected to my intent in some weird magical way. Just ergonomically, I love it. And I think on the note of like designing productivity software, I think something that I wish I had done with Mercury or just in general, is thinking about all the ways that new paradigms are fun and playful. Like, I’m sure notion and Air Table are exciting advances towards tool for thought or whatever. But like, I don’t really associate spreadsheets and databases with fun. It’s like intriguing, but it’s not fun. And the thing you mentioned with iPod click wheel was it’s just fun. It was inherently fun. There’s no like real reason why that is more efficient than buttons or like a deep pad, but it was fun and because it was fun, people cared about it and it was also great for fidgeting, which I love. I think. Part of the reasons why I get so distracted in social media nowadays is my computer. I can’t really fidget. I can like move my mouse around and or I can like sort of just like fidge on my screen just by like moving things up now. But the interface itself is not really designed to let you fidget. Anyways, so iPod was so fun, and I want to see more tools for fun. Or tools for thoughts that happen to be playful and fun and really unapologetic about it. Like I could care less about bi-directional linking, like I have no fucking clue what that even means if it’s not fun and visually palatable. 00:36:44 - Speaker 3: Yeah, I think this is a huge deal. And to my mind, the real poster child for this is emojis, and emojis, they seem goofy and insignificant, but they’re actually a huge deal. They’re a huge deal for Slack and to me, they’re a huge deal in notion. I was having trouble. It’s like, isn’t this kind of just like Google Docs, but you know, better and it’s like, well, yeah, but I can pick the emoji for each of my docs, oh, you know, and it just it gives you much more energy and it also allows you to communicate. more effectively, I would argue so. Yes, I think that’s a big thread. 00:37:15 - Speaker 2: The fun, the playfulness, the maybe joy, I think is one of the biggest things to come out of the mobile touchscreen iOS world. And of course, consumer applications sort of were the first to get that, but I absolutely think yeah, even the term productivity tools I use that just because, well, it’s the kind of the industry name. But I think when you look at, I’ve used the example before of Slack, and why I think Slack was successful is they make talking to your teammates fun. And it wasn’t really that much fun with hip chat and Campfire and IRC somewhat the Slack somehow tipped over between, I don’t know, animated gifts and unfurl cards and emojis and a couple of other things and just maybe the sleekness of the overall experience, good mobile app and stuff like that. They just made it the thing you wanted to do. And I think there is a version of that for almost any, yeah, what’s a spreadsheet for the TikTok generation, right? 00:38:11 - Speaker 1: So a cursed phrase. Oh my God, no. Oh my goodness. 00:38:17 - Speaker 2: But sort of embracing that, hopefully not the bad, you know, I think there’s a lot of downsides to the kind of engagement oriented social media stuff that is dominating a lot of, let’s say mainstream design thinking, but there is a version of that which does come down to the fun, the playfulness, the emotiveness, the just general joy you get when you think I want to use this. to do the thing you’re going to do more of it. And that’s, that was absolutely our thinking with Muse. We’re a little more understated. We’re less of the emojis everywhere and animated gifts everywhere thing, but we do try to make it fun and interesting and fast and a little bit playful to interact with your ideas. And so I think thinking of our overall mission to help people. Be more thoughtful when I talk to people about sort of deep thinking who maybe they know, maybe, for example, there’s an important decision in their life, they should really think through deeply, but it’s really hard. Deep thinking is hard. But if you had a tool that made it fun and you thought, well, this was a chance to use that thing, and I know it’s fun to use that thing, so therefore, you’re likely to do the activity, then maybe just a few more for more folks will want to do that. 00:39:25 - Speaker 1: I feel like play and fidgeting are just my tools for thought. I can’t think if I’m strapped to a chair somewhere. And some of my most exciting sort of revelations just always come from doing improv, which I deeply miss. But it seems like the world is kind of just on improv right now, in a way that’s really hard to say yes to. Anyway. 00:39:56 - Speaker 2: Yeah, I mean, a little more specific nerdy tangent is like part of the reason why I think spring dampening works so well is because when you give something physics, Spring dampening here you’re talking about when you have a transition of some kind that instead of being a linear movement, it sort of speeds up at the beginning and then slows down as the transition is coming to a close, yeah. 00:40:06 - Speaker 1: Yeah, except I don’t even like to think of it as a transition. I kind of think of it as just reaction, um, because like if something is like If, if something is responsive to physics, you like bounce something a certain way, then theoretically you could also bounce it from the other way and you can start to play with it. And it doesn’t actually have to serve a concrete purpose. It’s just by nature of being responsive to physics, it makes it more playful because it kind of grounds it in the real world somehow. Whereas like, the reason why I don’t think of this transition is sort of Because it’s not like a set timing that you’re like, this transition will last for 1 2nd, it means if it’s the middle of doing something and you want it to stop, you Very difficult to describe. But that’s the more nerdy take on it is that because when you think about motion, not animation, but motion design and how things respond and react to your touch, they enforce, they create the physical world of your application. And when there is that sense of physics, there is a sense of play because then people can start experimenting with like plotting things together or breaking them apart or things like that. And to me, that’s fun. Although I feel like I hesitate to promote this. 00:41:26 - Speaker 3: It’s like very trendy right now, so you’re just like throwing it everywhere and I feel like not everything has to bounce be bouncy, but anyway, well, I think you’ve come to a very interesting distinction here because transition and animation, it almost implies that there is this point where as a user, you’ve indicated what wants to happen, the machine will now take over and for the next 200 milliseconds will direct the activities and until then you can’t do anything else. And at the end, OK, the transition is complete. Now you can go resume clicking on things, whereas physics is more like every millisecond, you’re doing something and the machine is responding to what you’re doing and you’re never giving up control. And to me, the animation for the point of showing something isn’t as interesting as making it responsive to what you’re always doing, right, 00:41:58 - Speaker 3: the physics. 00:41:59 - Speaker 1: My pet peeve is when. Everyone designs motion for interfaces on the aftereffects and just have these like really specific 3 point motion curves and I’m like, literally no one’s gonna like that after the first round. They think, oh, this is fun and smooth. And the second time they’re gonna swipe something and it’s gonna have this perfectly choreographed transition and you’re like, oh, I don’t feel like that’s because I did something. I feel like I just triggered a 1 or 0. And that’s actually like, I think like for touch, like bounce and spring dampening works because your fingers are soft, so there is the inherent element of the input device has bounced. Whereas like, I don’t, for example, for mouse cursor interactions, since it’s very much like your mouse is either down or it’s not, it might be less appropriate. Yeah. But on the most surface level, it’s fun and that was my first impression, you know, I wasn’t like, oh, this responds to my input and therefore, it’s a prosthetic to like, no, this is super fun swipe to unlock. So therefore, I shall sell out my soul to tech forever. 00:42:56 - Speaker 2: Maybe what you said there ties together a couple of themes we’ve touched on here, which is the mouse versus touch and how the system should respond in terms of like how things feel within the physics of the virtual world you’re interacting with. I think there is this tendency, Mark usually calls it transliteration, which is if you take an application or a type of application that’s sort of for the desktop and you put it on to say a tablet or. vice versa, to basically bring across some of those same basic interactions. But in fact, the mouse or the trackpad is a much more precise tool than the finger. And there’s pros and cons to that. Sometimes the precision is actually really annoying. It’s too precise, it’s too fussy, and then other times it’s what you want, but in any case, the system responding to that. And so I think, for example, one of the places that the Windows. The surface platform falls down a little bit is that it essentially treats those as the same thing. When you touch the screen, it’s essentially just kind of moving your mouse cursor there and clicking. And you know, that’s a very sort of obvious thing. They’re both ways to point, so why not do the same thing? And to be fair, they were pretty early, so they were still just exploring this, but a more thoughtful or a more considered way to go about it is to think of each of these input devices and as we have more and more of them and the diversity of them, as we talked about before, and making each one serve its different purpose, and that also means that the physics of the system should react and feel different. And obviously, it will take us a long time to build all that out potentially, but I think it’s really worth doing to make the kind of creative environment, at least that I want to have. 00:44:31 - Speaker 1: When I think about things like head tracking or eye tracking or even voice recognition, those are the moments that I’m curious to look at. You know, not necessarily like, hey Alexa do blah blah blah blah blah, and it’s like very clear start and end, and you have a single thing you want to do, but more like as you’re in the process of doing something, maybe there are small ways that your body naturally responds to something that informs some part of the UI or how, I don’t know. That starts a whole other conversation about muscle memory, modular interfaces, pros and cons, but it is a specific curiosity of mine, especially as I think we start moving away from. We’ve been accumulating more and more devices and now I think we’re naturally headed to a world where your points of contact and essentially the, the power of the computer is more distributed. It could be all over your home, it could be everywhere you go because of headphones that you’re wearing or certain headsets. And I think when that world arrives, I’m interested in seeing the ways that interfaces change to sort of see if interfaces kind of move towards the direction of like multimodal input, if at all. 00:45:39 - Speaker 3: Yeah, I think it’s exciting. This is another example of where the fundamentals are changing because until basically very recently, voice recognition wasn’t viable, wasn’t fast enough, it wasn’t cheap enough, it wasn’t accurate enough, and it’s just now, I think, crossing the threshold and probably similarly with eye tracking, but I know for a while they’ve had specialized hardware that you can use at labs but it was expensive and uncomfortable. That’s also, I think they can do it with commodity cameras now. So interesting times for sure. 00:46:03 - Speaker 1: Yeah, and something that I hope to see more in new tools for thought or productivity tools is just, as I mentioned, more embrace of just fun, physics, and also things just being more sexy in general. I think making something desirable is Oh God, I was reading this tweet the other day of some like thought leader going like, if you have to pick between like what you’re wearing in the morning, that you’re not doing real work, I’m like, shut the fuck up. Like, literally take your Patagonia vest and I don’t know, jump off the go but that’s too harsh. Just like, no, like, that’s so important to people like that. That’s what makes people human. Like we just naturally or instinctively, we just find certain things desirable, and that’s OK. And that should absolutely be a part of the consideration and focus for when we design new sort of environments and interactions that we hope people will care about. And right now, Adam, I think you mentioned that it’s very hip and trendy to work on things like, you know, perhaps Instagram. Although probably not anymore, but like maybe TikTok, spreadsheets less. And I think part of it is just the inherent fun factor. And the other part of it is like, you don’t really associate culture with spreadsheets, but you absolutely associate culture with social media. And so I really think that if you can create software with the intention of creating a cultural movement or a cultural shift, that will really perhaps help you in some way. I say you as like a disembodied you, not like you, um. It’s like if I were, I don’t know, a meme generator, I would just have that diagram of Steve Jobs with the liberal arts and technology crossroads in his background, but yeah. 00:47:45 - Speaker 2: Now I love that tools are about the communities and the culture that come along with them. We don’t use them in a vacuum. We don’t get excited to use them, and we don’t continue to use them and we don’t certainly in a collaborative work environment which we almost all find ourselves in, yeah, sharing. You could argue that for For example, a collaboration tool like GitHub or one like Figma, those bring along with them certain culture. And that’s part of why you, let’s say get into the tool and part of what keeps you there and part of what shapes your work and part of what makes it fun, and part of what inspires you or upsets you, maybe depending. But the point is, it’s not this dry, sterile, just kind of solving a problem and moving on. Uh there is culture with it. 00:48:30 - Speaker 1: I love that. And there’s that continued discourse between culture and impact and what you’re making. And something I hope to see more is like, you know, as we create these new environments to live in and live with. That we become more aware of certain implications or results of use and misuse, and that we take responsibility for those results. That if our tool for, I don’t know, if I were to create a collaborative tool for thought and it was used to orchestrate DDOS attacks on women and minorities, I would personally take a long hard look on like the things that enable that, the culture that I have created around my tool and recognize that like. I’m a human, I’m a creator. It is OK to bring your own perspective into things because you’ve made it, and that’s just something that is on my mind a lot these days, and there really is no way to ensure that your tool is not being misused to harm people, I don’t think. 00:49:27 - Speaker 2: Design ethics has become much more of a topic or perhaps technology ethics very broadly and more here you see this in social media news and news tools and things like that that are more about spreading ideas on a wide scale, but one could imagine that coming to more sort of productivity tools style space and then maybe you want to think ahead and think, OK, so the folks that were working on social media 15 years ago didn’t really picture the ways that their work could be used for harm. And of course, you can never stop something. There’s always the potential to use something for harm, but there are ways to design it that maybe encourage more positive uses and strongly discourage more negative uses. And I think there’s a tendency for tech world people who skew young, who skew optimistic to just think of the positive cases and not think of the negative cases and therefore not hedge against potential risk and think about the responsibility of the power that they’re wielding. 00:50:27 - Speaker 1: Something I hear a lot is like you’re so negative, but I think at the root of everything, I think I’m very optimistic about what people can be as a species, as cultures, and what technology could help with. I’m very optimistic about technology and people in general, but because of that optimism, sometimes it is expressed as anger or negativity, but I really admire those who kind of just believe. Uh, fuck, I’m just gonna head into some, I’m gonna not say sappy shit on your on your podcast. I’m gonna save it for my memoir or my stand or my Netflix special. My Netflix special is coming out in about 15 years. It will be called My Career, and that is the joke. Um, I, I predict massive success from over two audience members, but um. Yeah, oops, nice. 00:51:22 - Speaker 2: I actually just watched uh David Attenborough’s uh sort of career memoir. So yeah, all, all you got to do is have um 60 years of really impressive career like that guy, and then you two can have an inspiring Netflix special. 00:51:38 - Speaker 1: 60 years is a long time. Um, I don’t know. It, I’m curious for you both is thinking about computers and tools for thought and operating systems and essentially world building. When was the first time in your life that you noticed that instinct or curiosity? 00:51:59 - Speaker 3: For me, computer programming in particular came relatively late. I didn’t really get into it until college, which is late for a lot of people that are, for example, currently in the industry, but I’d always had an interest in building things more generally, you know, model planes and rockets and Other things like that. So I think I just more struck on the right medium eventually versus a general interest. 00:52:20 - Speaker 2: Yeah, well, for me, I certainly was fascinated by computers from my first encounter, but I think it probably connects to exactly what you said, which is the world building. So the interest in computers and the interest in games kind of came together and I pretty quickly got on from playing games to making my own games, and making games is fundamentally an act of world building and the really appeal to the systematic part of my mind. And I think it definitely influenced a lot of my views on the world, which includes calling back to right where we started, which is that the world around us is mostly constructed, the society we live in, the governments, even the physical structures, they’re constructed by humans and we can choose to make them different. very hard to change those things, but they’re not, well, I would say not set in stone, but some things actually are set in stone. But actually, even those are changeable. You just need a good jackhammer, right? And thinking of it as both this combination of, if you think systematically about the emergent effects of the world you’re building, whether that’s a game or something in the real world, something economic or social. And then similarly, as we have these increasing virtual worlds, even beyond games, but productivity tools. And collaboration spaces and online forums for a meeting to converse with our fellow citizens about the society we all live in. These are all things that we construct and we have the ability to think systematically about how the design choices that go into them, the outputs in the form of the world that we live in, and the way that that causes people to be prosperous and happy or not. And so to me, yeah, right from the start, I think that shaped how I see everything about the world. 00:54:06 - Speaker 1: When was that start for you? 00:54:10 - Speaker 2: I think maybe about 8 years old. 00:54:12 - Speaker 1: Wow. Yeah. Oh my goodness. To paraphrase one of my friends and collaborators on Makespace Maily, she often speaks of her different disciplines. I mean, she’s an interaction designer and also a DJ and also she’s interested in the culinary arts, and she just thinks about like those different practices as kind of canvases of art, and then You connect the canvases through your life to eventually create a path of your own. That’s purely paraphrasing and probably fucked it up. My fascination also began with video games. Tomb Raider was the first movie I ever saw, very interesting choice for a 5 year old. But after that, I was just obsessed with this idea that you could inhabit someone’s life and body and adventure, and inhabit a space that might feel safer in some ways. Obviously a very utopian view on computation. And then I started graphic designing and PowerPoint. I don’t think I used a real design tool until college. 00:55:12 - Speaker 3: It’s the power of general purpose tools. 00:55:15 - Speaker 2: Well, it’s to your earlier point that everything is a tool for thought and so in this case, everything can be a way to design, right? I do designs and text files with AskiR where needed, so. 00:55:27 - Speaker 1: Yeah. What’s exciting about talking to folks like you is it reminds me of, and it opens my eyes to all the things that I’m so deeply curious about exploring and learning about. And it’s really inspiring in the sense that It feels like if you’re digging for diamonds and the more you dig, there’s more interesting shiny things and you just want to keep going until you end up burying yourself and then you end up living in Oakland forever alone. But that’s a different fanfiction. 00:55:56 - Speaker 2: That metaphor did not end the way I was expecting it to. 00:55:59 - Speaker 1: I don’t know. I feel like if you dig a tunnel deep enough, it’s eventually going to end up in Oakland. I feel like, I don’t know why everyone’s like, I’m in Oakland. Like how did you get there? But yeah, something I’m curious to hear your thoughts on. It’s sort of, as I’ve been more acquainted with the culture of human computer interaction, including important cultural figures and milestones and perhaps dreams that once were. I’ve moved through several stages of like, let’s say grief. Of like denial and then sort of acceptance or Hm, that’s poorly phrase. As I’ve I’ve accumulated more knowledge into this specific cultural dome. I hear from a lot of people that their North Star is they want to achieve Engelbart’s vision of computation, or they want to, you know, make Brett Victor proud or something, something Ted Nelson, Alan Kay, something something Xanadu, you know. And I’m curious to hear if that sounds familiar and in what ways do you relate or not relate to those modes of thought. 00:57:04 - Speaker 2: Oh, incredibly familiar. Mark, I’m curious to hear what your journey was on this, but there was a kind of Let’s call a research rabbit hole or just path to go down of discovering the works of these visionary folks that you just described and seeing the big ideas that they had and so long ago that it’s just really eye opening when you compare to on one hand that we’ve achieved so much and technology has come such a long way, particularly when you look at say just the raw horsepower, computational power of computers, but then you look and you feel like maybe we haven’t quite achieved. As much as it seems like we should in terms of what computers actually do for us, and all of those folks that you mentioned and others in that world are absolutely a source of inspiration and ideas in work that I’ve been doing in the last, I don’t know, now 5 or 6 years of my career. At the same time, I do think you can over, not sure what the word is, fetishize that, which is this kind of romanticized past or You know, first of all, that these folks as visionaries, they didn’t fully manage to make their ideas come true, and I think that is a gap and that is one reason why I’m so interested in the topic we talked about earlier, which is not just how to have the big inspiring ideas, but how to bring them to reality. And then the second part of it I think is that there is a version of the kind of the Aristotle problem, right, which is you don’t move on with new ideas because you’re so busy kind of treating the ancients as having the ultimate wisdom and you just need to unlock, you’re searching for the philosopher’s stone, and you know you can find it in the books, the coded books written by the ancients, and if you just look long enough rather than thinking, well, These folks were really impressive and amazing humans that did amazing work, but at the same time, I can do that kind of work too. And maybe there’s new ideas and fresh directions for us to explore. It’s not about somehow achieving some ideal that was set forth previously, but more that we can fold those ideas in, and also learn from what worked and didn’t work with them and then make new ideas for an inspiring future. 00:59:14 - Speaker 3: Yeah, I had a lot of similar thoughts. For me, certainly the desiderata that were lai
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: To us, it’s very important that we design this all holistically. There’s a lot of research, for example, on cryptography schemes that assume key management or on collaboration product designs that assume the server can just read all the data. And in order for this to work with Muse, we need all of the product design, the collaboration technology, the key management, the cryptography, the mental model for how people think about documents that all need to line up. 00:00:31 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for thought on iPad. But this podcast isn’t about Muse the product. It’s about Muse the company and the small team behind it. I’m Adam Wiggins. I’m here with my colleague Mark McGranaghan. Hey, Adam, and Mark, I like to listen to podcasts in the morning, but I understand that you have a slightly more unusual and in-depth source of audio. 00:00:55 - Speaker 1: Yeah, this morning I was actually listening to the real-time oral arguments in the US Supreme Court on their very important ACA slash Obamacare case. This is obviously a very big case for the US and for many of us personally, and so I was keen to listen in and see what the judges were thinking. And this is notable because I think until recently you couldn’t actually listen to these broadcasts in real time. There wasn’t the C-SPAN equivalent for the US Supreme Court until I think COVID hit and they started doing everything via audio, audio, you know, Zoom or equivalent. And I think at one point actually, they didn’t release the audio to the public until quite a long time after the arguments had concluded. I think they did it every term or something, which is 6 months or something, and then more recently they changed it to be every week, and then now they release it in real time. And of course, that’s interesting as an interested citizen, but also it kind of connects to our topic today of privacy, because one of the ideas that we’ll talk about is how visible or non-visible your work is while it’s in process. 00:01:51 - Speaker 2: Yeah, privacy is a huge topic and something on our minds right now because we’re making some product decisions for the sharing and collaboration features that will be forthcoming from use. So in the process of working through this as a team, where do we make trade-offs on things that necessarily results in a kind of a zooming out, you can’t help but to look at the larger context, which is OK, there’s what do we want to do for our product, what matters for our customers, what’s technically feasible, what do we value as a team. Then you zoom out a little bit from there to OK, what’s going on in the technology industry. Obviously this is a very, very big topic for the tech industry right now, and then you can zoom out even from there and talk about the society-wide impacts and you know, what does privacy even mean? What can we expect, what’s important or not important in terms of our lives as citizens, but also just as technology changes, we may need to adapt to what we can reasonably expect in terms of privacy. Yeah, as you know, I always like to start at the beginning with the definition or something of that nature. So what does the word privacy bring to mind for you, Mark? 00:02:58 - Speaker 1: Hm. Well, I don’t have a super nice prepackaged definition, but what’s coming to mind is a sense of agency over who does and doesn’t have access to your work. And you might exercise that agency by saying only I can read my personal journal, for example, and so that’s private to me. Or it could also mean that we are working on a project together and so I want you and me, Adam, to be able to see some work product, but no one else. Or it could be that you want to share it very broadly, and that’s your choice as well. So some sense of controlling who does and doesn’t access your work. 00:03:31 - Speaker 2: Yeah, when I went looking for kind of what is actually the definition here versus my own vague sense of what counts or doesn’t count as privacy, which probably, by the way, has changed over the years, but the canonical one that’s often linked back to is a piece in the Harvard Law Review in 1890 called The Right to Privacy. And they point out that some of these American values of right to life, right to pursue happiness, right to secure property originally maybe meant something more practical, you know, property was your cattle, for example, but now you fast forward here now over 100 years ago, they’re writing and they say, well, wait a minute, we’ve. Started to recognize more of a spiritual nature of man’s feelings, his intellect, and so maybe these rights that we talk about broaden a little bit and the term property may include intangible things like your notes, like your thoughts, for example. They actually just use the phrase at one point, the right to be let alone, you know, maybe in modern phrasing, we would say the right to be left alone, but the idea of Maybe why you don’t want everybody in the world to have your phone number is you don’t necessarily want the equivalent of spam calls coming in. You want to give that to people that you have this trusted relationship with that you believe they’re gonna call you because there’s someone you wish to speak to, you have an existing relationship, something like that. So that lens for privacy I found thought provoking. 00:04:58 - Speaker 1: Yeah, that’s a very interesting definition because it gets at a problem that I’ve seen with a lot of the privacy discussion, which is It’s very tempting to try to imagine or infer or argue for some very natural and fundamental right to privacy. Obviously, if you like privacy, you’ll tend to do that, and I often see this in the form of privacy is a human right or privacy is a natural right. And I certainly think you can make arguments to that effect, but it kind of dodges, to my mind, the real fundamental question here of what are the trade-offs, what are the benefits, what are the costs, and what work are we willing to do as a society to bring about those benefits if we want them? Because unlike something like perhaps the right to life, you know, you can get that just by not ending other people’s lives, right? Whereas privacy is is much more complex than you need to build cryptography, you need different business models, right? It’s much harder to grapple with. 00:05:49 - Speaker 2: Yeah, another way to think about, at least for these intangibles for information privacy, which is chiefly what we’re concerned with in our business and in the technology industry generally, it’s really communication is often the thing, you know, Muse as it stands today keeps all your information on the device there and putting aside some threat vectors like someone stealing your device, for the most part, that means there isn’t so much to worry about. It’s once you go to share it with another person or share it digitally over the internet, that’s where. Things get trickier and I liked your courtroom example because another one I had kind of sketched down was the social contract or the common legal protection that’s given to what they usually call client confidentiality or patient confidentiality, so attorneys or doctors or therapists. The idea is that You are going to have a private communication with them and you can expect both kind of from just a manners perspective but also in some cases legal protections for what you say there. and that gets a little bit to what’s relevant to our business, which is in one of those communications speaking to your therapist, for example, but also sketching in your notebook. If I need to think about, OK, everyone in the world can see this either now or in the future. Maybe that is going to consume some part of my brain figuring out how comfortable I feel with that, whether I want to alter what I’m saying or writing a little bit, and there’s something freeing where I say I’m in this communication with one other person or with my notebook only, so essentially myself or my future self, and I can reasonably expect that no one else is going to hear this. or be privy to it, and that frees me in a lot of ways to be creative or to really open myself up. And it seems to be a common human experience that it’s easier to truly open yourself up when you know exactly who’s on the receiving end of that. 00:07:40 - Speaker 1: Yeah, totally. If I think about the benefits of privacy, to me, that’s one of the three big legs is this idea that when you have control over who has access to your thoughts, your work, and your data, especially when that’s quite limited, it encourages and allows creativity. And that might be creativity in terms of your personal journal, right? You’re much more inclined to write something to share it with yourself, if you will, if you know no one else is gonna see it. But it could also mean You’re doing some private brainstorming, and that would be very different if it was just you and me versus if we were in a stadium with 50,000 people watching, right? And it’s just that’s kind of how humans are. I think that’s a big piece. And also, it connects to what I consider to be the second big leg of privacy benefits, which is it allows you to manage communications. So it might be the case that you eventually want someone to know something, but while you’re working on it and you’re preparing the communication. You don’t want them to be processing all of the raw stuff. It’s something that I encountered a lot as an engineering manager, you know, if you’re working on an organizational change or something, right, you don’t want people to be reading all of the raw discussions and debates about how it’s going to happen. You want a clear and coherence and well executed communication plan. That’s again, you need privacy for that. And just to mention what it is in my mind, the third leg, and we can perhaps talk about it later, but it does have protection from governments and other large concentrated powers. And for me, that’s especially important with electronic data and communications. To my mind, this stuff is so sharp because it’s so easy for it to get replicated, for it to get distributed, for it to be intercepted, for it to be eavesdropped. In a way, that’s just not the case with something. Like paper, you know, with paper, it’s actually quite hard to make a billion copies of paper. It’s also very easy to reason about where the paper is going because it’s in this physical world that we have a lot of familiarity with. We don’t have the same intuitions or ability to reason about electronic data in terms of how long it could be persisted, how many people can see it, and all the ways that it can be processed. So I think overall, it makes this problem of concentrated data in the hands of large powers very sharp. 00:09:38 - Speaker 2: Yeah, and I think in the analog world where you’re just thinking about who might be overhearing me in my office, or as I walk down the street having a private conversation with a friend. That you can kind of scope and time and impact, but when I put my photos, my notes, my whatever it is into electronic databases that can be replicated potentially forever, I think of something like LiveJournal, which was this journaling slash blogging site 20 years back that was very popular. A lot of people, especially young people, poured their very private thoughts and things about their lives into under the reasonable expectation that was only going to go to the few friends they’ve scoped to. And then in the meantime, it’s been sold several times to several different choirs. All that stuff is in there, what someone wrote 20 years ago in a database that’s now in the hands of someone very different from who originally it was in the hands of and and I think it’s just we don’t quite yet have the capacity. to actually reason about. 00:10:33 - Speaker 1: Totally, and just to expand on this a little bit, this points to two other ways that electronic data privacy or non-privacy can be very sharp. One is this time element where the data can persist and indeed accumulate and move around for a very long time. So we might say, oh, you know, with our current privacy practices, nothing that disastrous has happened. Well, we actually don’t know because the half-life of this data is probably 50 or 100 years. So we’ll know in, I don’t know, 200 years if this is actually a bad idea, but we can’t really say that it wasn’t until all the data has fully dissolved into the ocean or something. The other huge thing here is how humans are or aren’t part of the process. So again, with electronic data for collecting it, for storing it, you just need to convince basically a few people, it’s a good idea. So if the NSA wants to read everyone’s emails, they convince a few people at Google and Yahoo, and that’s basically it. And then they get billions and billions of emails. Whereas if you wanted to eavesdrop on someone in the physical world, you got to pay someone, they got to go out, you know, to the rooftop and That’s expensive. And if you have a ton of them, you have to actually convince all these people to do this every day and maybe actually have trouble convincing thousands and thousands of people to do this. So there’s this kind of like human rate limiter friction that you get if you want to do wide scale data collection in the physical world, but you don’t have it in a digital world. This is another reason why I think the digital stuff is so sharp and potentially dangerous. 00:11:53 - Speaker 2: Feels like there’s a parallel there to spam, postal mail versus spam email, which is people sending you unsolicited advertisements in postal mail has always been a thing, it’s still a thing. But it’s limited by sort of physics and the cost of actually getting that brochure or whatever into your mailbox, and digital is just so cheap and so fast and so easy to do in this kind of anonymous, unaccountable way that then it goes from being uh maybe an advertisements in your postal mailbox or a minor annoyance to being something that potentially Overwhelms the systems of the internet and makes, you know, at one point threaten to make email a completely unusable service, and I think basically every kind of communication technology that comes online and gets substantial traction has to deal with that same kind of spam and abuse problem for that same reason. It’s just so cheap to do that and try to grab people’s attention through these automated and unaccountable means. 00:12:51 - Speaker 1: Yeah, spam is also notable because there was a very powerful technological problem, basically people sending out zillions of emails for essentially free. There’s also a very powerful technical solution, probability-based spam filtering. And so there was this battle for a long time. I think we could say that eventually the spam filtering won because they have access to all the leverage you get with electronic data that the attackers have. But yeah, that wasn’t a preordained conclusion, and I don’t necessarily think we should count on that being the case with privacy. 00:13:19 - Speaker 2: And looking at the things going on in the technology industry there, we have something like GDPR is a pretty big deal in Europe, that’s been in force for a few years and then they’ve, I think, are looking at doing more to strengthen it, sort of trying to give people more control over their personal data, more insights over what’s being captured and when it’s deleted and that sort of thing. Another notable trend in recent time is products, privacy focused products that have, if not broken into the mainstream necessarily have been pretty successful. There’s something like the Brave web browser that has built in ad blocking and essentially makes a privacy oriented pitch over using something like Chrome. And they just posted recently, they had 20 million users, which is a pretty good number. DuckDuckGo is a search engine that in many ways you could say is worse than Google in terms of results, but it’s privacy protecting and so that one selling point seems to be enough for quite a lot of people to use it. And there’s a long list of others of these protonmail for email, fathom, which we use for analytics on our website. There’s this whole class of messaging apps like Signal and Telegram that have really got a lot of traction. And it’s interesting to me, almost all of these that I just named, they’re basically worse in every way than whatever they’re competing with. Not always, I like Fathom better than the Google Analytics, and I think Brave is nicely made mostly because it’s just kind of a fork of Chrome. But in many cases they are about the same or worse, you know, using Telegram to communicate with someone versus WhatsApp or SMS for example, it’s basically the same kind of experience, but that one benefit of some kind of privacy protection or some kind of assurance that privacy is something that people who create the product care about is enough to get a lot of people to use it. I’m curious how you think about that. Are you motivated to use products that are privacy protecting versus trading that off against other things? Do you think that those kinds of products will always essentially just be a niche for the few people that care enough about it, or do you think there’s a future where that kind of focus would be something more mainstream? 00:15:26 - Speaker 1: Yeah, well, that’s not an easy question, Adam. Yeah, so I’d say first that I definitely use some of these privacy focused products. Two examples that I would give, one is Safari, which I use because it’s faster and I think it has better privacy capabilities than Chrome. Another is D. Go, which for a long time I’ve used almost exclusively instead of Google. I find that it works great and has a much better privacy story. So for me, on the margin, I’m definitely inclined to look at the privacy angle and especially if things are comparable or if for some reason I care a lot about the privacy of that data, I will make the move. And I’m glad to see that we have these offerings and people can make choices like that. To my mind, the bigger deal though is the overall dynamics of the industry and what a lot of users end up choosing. And yes, it’s great if we have options for particularly privacy conscious or privacy sensitive people. And again, I’m very thankful for that. But if you think about this third reason that I mentioned a while ago, data concentration in large powerful entities, that’s really determined by what most people do, right? So for that reason, I’m very interested in the overall dynamics of the industry and our governments and how those things interact. And there I would say that it’s perhaps a more discouraging situation. I think there’s things we can do and there’s still passed out of this, but I think it’d be very easy to imagine a world where governments just have access to all our data, which by the way, you did a good survey there of some of the current privacy focused products, but a huge deal is access to TLS. And it’s something we take for granted that you can go to HTTPS website, which basically our websites are now, and at least that data won’t be accessible to people online unless there’s some exceptional circumstances. And we take that for granted, but in my opinion, that was not a given. At one point, it’s my understanding that this public key cryptography was not a generally accessible technology. It was somewhat controlled by the government. And with Netscape and commerce moving to the internet, again, I’m not sure exactly how the story played out, but they eventually convinced the government to allow us to use that to export it outside the country, and so on. But I could absolutely imagine a world where that was not the case. Like if you can imagine, for example, that 9/11 happened before that stuff got out widely in web browsers, the government might have just said, you know what, we can’t have people communicating securely at all. This is now banned. And then that would have been a very path dependent thing where we might have stayed in that situation. 00:17:45 - Speaker 2: Yeah, I’m old enough that I lived through that process. I was in the computer world and in the industry for some of that. The clipper chip was actually a US government initiative at the time to create cryptography that had a built in backdoor for government agencies to open. And there was also things like, yeah, up until the 90s, um get in trouble here recounting this all from memory 20 years on, someone’s going to fact check me, hopefully you will, but at least the way I remember it was in the early 90s, it was the case that cryptography technologies were very rare, so I think it was up to 40 bit keys were allowed, but of course that’s low enough that you can reasonably, I think even back then, you can brute force crack them, so it wouldn’t really be that viable for something like online commerce. And then I think um the, I don’t know what you want to call it, technology, cryptography, folks, enthusiasts, slash experts uh on the then sort of growing networked world were really, you know, arguing for why this technology could be really enabling and there’s good reason for governments in the US government in particular. To be cautious and treated as a weapon because, you know, in many ways you can point to the Allies winning World War II, that was basically done through science and one piece of that was maybe the atom bomb and the Manhattan Project, but less dramatically was the cryptography story, right? The Alan Turing and the Enigma machine. And the fact that one side could read the messages, another side couldn’t, and it was that asymmetric key cryptography, that was the technology that essentially allowed the Allied communications to stay stay secret. So thinking of that as effectively having won that war, the greatest, certainly most destructive conflict in human history, and then being really cautious about who has access to that seemed quite reasonable even, I don’t know, 40, 50 years on from said war. And yet, the things that potentially enabled were so great. And of course now we live in that time where as you said, SSL and that little lock icon that you see in your web browser makes it possible to have this huge, I mean, what would the world be like without online commerce in a pandemic age, right? Just to name one thing. So, I’m glad we won that, or let’s say the people on the side of more access to encryption and privacy protecting technologies won that fight, but as you said, it definitely wasn’t guaranteed. Now, coming to Muse specifically, historically, we’ve had everything, in fact, we even say this when you first fire up the app or first log in, which is we basically say everything stored on your device locally, it’s private. That’s important to quite a lot of people, sometimes for very practical reasons. There are, for example, an attorney that has case notes in there, but in many cases just coming back to that sense of privacy allows you to be freer and if you feel like you can write stuff down and not feel like the NSA is looking over your shoulder, um, and that’s just a better state to be in creatively. But now we’re starting to move into much requested features that allow us to not be essentially in the iPad silo. So right now we already have a browser extension and an iPhone app. There’s a very simple capture into the iPad, but eventually we would like to imagine that you spans all your devices, that’s wherever you need it to be. So that’s the multi-device side of things, then it gets even more interesting with the multi-user side. Of course, we know that all these collaborative tools like Google Docs and GitHub and Notion and FigMA have really supercharged our work in the modern world and certainly for remote teams like ours. Now Muse has a different use case, which is more about developing ideas than making these end work products. So what role exactly the collaboration and sharing side will play for us is not fully known yet, we’ll explore that as we build this stuff out. But here we are confronting this thing where we on the team value privacy. We know that many of our users and customers value that a lot. It makes you feel freer, but then we also know that being able to access your stuff from all your devices and share things with colleagues and friends is immensely powerful. So you’ve been leading the charge a little bit on thinking about the particularly the technology sides of that trade-off. Where are we at right now? 00:21:55 - Speaker 1: Well, let me start with the way this is done in almost all apps today, note taking productivity style apps. There is a central server that’s run by the tool provider and that stores all of the users' data in a way that’s accessible to that company. So you might have a table that’s like documents and has the data for all documents for all users in it, and then. When you fire up your app on a device, it talks to the server and says, Give me the latest data on this document, and then it renders it on that device. And then if you share a document to another user, that just becomes metadata in the database that says for this document row, this user ID can access it. So when that user’s device requests a document, they can have authorization to get that data. 00:22:41 - Speaker 2: Right, so when I make a new blank document in notion or Google Docs, type in 3 characters, those 3 characters go into a record in a database somewhere in Google’s servers, and that the cloud, as I believe they call it, is precisely what makes it so easy to share because if I want to send this to someone else. That I need to take it off my device and put it on theirs. It’s already in Google servers. Google essentially has ownership of that. I’m just accessing it through this client or front end and so giving one other person or some number of other people access through their client or front end is a relatively straightforward operation, right? 00:23:14 - Speaker 1: And notably with these modern cloud-based tools like Google Docs and Notion, you typically don’t even have the data locally. So if you type in this document, save, exit, and later you’re off the internet and you want to open up your document, well too bad the data is not there. So that’s the standard approach, and we remain open to doing that for use. It has a lot of benefits in terms of relative ease of implementation, of course, providing all of the features that you want, as well as things like backups in the case that the user loses all their devices or something. But we’re also very interested in exploring a second way where you get the benefits that we’ve associated with cloud-based collaboration, being able to access your data from any device, being able to add collaborators and collaborate in real time, all of those things without the tool provider in this case Muse being able to read your data. So the way I pitch this is like signal meets Google Docs. You have the security model of signal where data is and then encrypted and you’re talking to your collaborators and only you and they can read that data, but you have the rich documents, multimedia collaboration, multi-device synchronization that you would associate with Google Docs, and that’s quite a hard technology and product problem, but we are looking into it. 00:24:26 - Speaker 2: You and I were both co-authors on a paper called Local First Software. And this was much more research outward thinking technology of sort of removing the cloud from the equation completely. Which is not what you were just describing there, but it does have some of these same elements of trying to make it so that it’s less about what’s out on these servers and more about what’s on the individual users' devices. I think we touched on encryption briefly, but I think, I mean, as we described in that paper, we don’t necessarily think that building a truly 100% local first application is really in reach for certainly for a small team like ours today. So it’s really parts of that we do think are achievable and other parts maybe are still a little bit more, we’re waiting for the technology to get good enough. 00:25:13 - Speaker 1: Yeah, and I might say that I still think local first, at least as I understand it is possible for us. The thing that is less valuable and interesting is pure peer to peer. So there are some apps or technologies where if you and I are collaborating, we’re sending packets back and forth directly to each other, and there’s no server interposed, which has obvious potential security benefits, but it also gives you a certain resiliency. Against DDOS and other issues with a central server. And for me, having servers on the internet is not necessarily that big of a deal. And in many cases, there’s just no way around it. For example, you need to talk to a central server to get apps onto your iPad because Apple requires it. And for me, the bigger deals are that central server being able to read all your data and you not being able to read and write your data if you’re not connected to the central server. So the world that I imagine is one where you potentially have a server or even servers, but the servers are more like symmetric nodes, you know, they behave more like any other node like your phone or your tablet, and it’s not so much of a special superpowered case. 00:26:19 - Speaker 2: And then on the encryption side, you, you reference signal and I think one of the places they’ve been very influential is, I wanna say they started as this open whisper systems sort of security consultancy or something like that, and they not only made this secure messaging app, but they wrote a lot of articles and sort of publicized their approach, and that was something that’s then been picked up by others, including WhatsApp and Telegram and I think the hard part in this is usually the key management, right? So this is asymmetric key cryptography basically relies on the person having this block of data someplace and no one else having that data, but that’s tricky because that person has to keep track of it. Maybe it’s a bit like a physical key. You lose a physical key to your house, you potentially go to a locksmith and they can crack it open for you the way that these digital keys work, if you lose it, that’s it, you just can’t get access to that data again. 00:27:15 - Speaker 1: Yeah, so there’s a couple of things going on with an app like signal. You might break it up into key management and cryptography. So on the cryptography side, this is like, OK, assume magically for a second that everyone has keys and we know who has which keys, then you need an algorithm for using those keys to encrypt the data. And there’s been a lot of work on that in industry and in academia. It has been, I think, quite focused on the messaging use case. And one of the things that we’re excited to do with Muse if we do pursue this end to end encryption path is making it more general case. Like, let’s encrypt data structures and documents and not make something that’s very specific to messaging. Also, in the case of Signal, I do think they make some specific trade-offs that are more appropriate for the grade of security, if you will, they’re looking for like signal needs to be resistant to powerful nation state actors. And in order to do that, you need to make some specific trade-offs that maybe wouldn’t be appropriate for a productivity tool. But anyways, yes, that’s what happens on the crypto side, but then the key management side. That’s a whole big challenge, and many people will tell you that key management is actually the harder of those two issues, and there are different ways to do this. There’s the fully distributed web of trust type model where you build up a model of who has which keys based on a series of ideally. In-person interactions. So, you know, you and I might meet in real life, we would exchange keys, and we might also exchange information about other people that we have, and we would sign that information and then over time, you kind of accrete up this web of process where the name comes from. That’s kind of the most distributed, but least practical model. The most practical, but least secure model is just, you ask the server who has what keys, and that’s very convenient. You get all the benefits of a centralized server telling you exactly the right answer. The downside is the server can just lie and say, this is Adam’s key, when in fact, it’s just a server’s key and it’s read all atoms data. And the thing that I’m most intrigued by and that we’re exploring a little bit with views is more of a middle ground where you get some of the benefits from the centralized registry, but you also get some of the benefits from direct or decentralized verification, especially where you need it. So one example of this in Signal, I think they have this set up where you can look up people by phone number and the signal will essentially send your data to their devices, but you can also, when you’re next to someone, you can verify each other’s QR codes and then that lets you know that you, you in fact verified. This person, I think it gives you a stronger level of security. So I think there’s more things we can do along that vein. Another example from the Zoom white paper, you know, Zoom is working on and then encryption. They said for a long time they have it, they don’t really have it as we understand and then encryption, because they’ve had this key management problem where everything was encrypted, like TLS is encrypted, but they control and administer all the keys, so they could just impersonate people if they want to. But they’re trying to move to a proper model where you can, in fact, verify people if you desire to. And one of the things that they’ll try is, on your Zoom video, you’ll have a little code. And when you’re on the call, you can say to the person on the other side, you know, the security code is ABC 123, and that’s very hard to impersonate in real time, obviously. So if you’re correctly verifying the code on each side, you know, OK, this is not being tampered with. And there are other techniques that they’re exploring too. But this basic idea of you kind of mix the benefits of a central registry for keys with more distributed ad hoc verification where you need it. 00:30:14 - Speaker 2: I think we’ll be looking for the sweet spot there between trying to give some reasonable privacy protections, but not having a very difficult or very technical. And demanding, for example, key management system. That’s probably exactly what Zoom’s grappling with right now. I think of the canonical example of inaccessible as something like PGP and I’ve used the GNU PG for a number of years. I’m pretty good with it. I’m handy at the command line and even so, it’s just very easy to mess it up, get the wrong key, delete the key. Encrypt the wrong thing, it’s just very, very unforgiving even for a technical user and so way, way out of reach for kind of more casual use. And SSL is a great example, as you mentioned, HTBS websites is a great example where we did manage to find a way that was a middle ground of real solid encryption that really does make a difference in terms of the things that enables, but it’s very accessible. It does not require some kind of deep technical cryptography, key management thing in order to get the benefits of it. 00:31:24 - Speaker 1: The last thing I might say on key management and crypto and user interface trade-offs and stuff is that to us it’s very important that we design this all holistically. There’s a lot of research, for example, on cryptography schemes that assume key management or on collaboration product designs that assume the server can just read all the data and In order for this to work with Muse, we need all of the product design, the collaboration technology, the key management, the cryptography, the mental model of how people think about documents that all need to line up. And I think that’s why this has proved quite challenging for us. It’s not something that I think very many people have grappled with, but I’m optimistic that if we can get all those things to line up in the right way, it’ll be a very powerful combination. 00:32:06 - Speaker 2: Yeah, I’m potentially excited for that, finding a new set of trade-offs. I feel like most tech industry products are essentially binary. You have either Totally local old school program saves on your hard drive, great, you know, no one else has it, but you just don’t have any of those sharing and collaboration features or you have the fully in the cloud thing, which is just so incredibly useful, and yet you just know, OK, I’m just giving up every single keystroke I type into this. I know that Google engineers and Google machine learning algorithms and the NSA and anyone in the future that may acquire this data for essentially an infinite amount of time. I’m just giving up and saying they have full access. It’s the trust us model, vendor model, and I’m excited that we can potentially find a different set of trade-offs, a different sweet spot, a different place to be that isn’t one of those two extremes. Exactly, yeah. And normally when the topic of privacy comes up in the context of the tech industry generally, one of the key things is people are talking about my data, and I think we’ve almost been entirely talking about what I would call content and so maybe content privacy. I make a document, I write a note, I record a video, that’s my content and I want to know that I am the only person, me and people I have chosen to share are the only people that have access to that. But the other category and maybe even a more common one to be in these discussions is more call it analytics or you can call it telemetry data, and it’s a really interesting question when you do frame it as data ownership, if there’s something like a motion sensor, for example, a smart home kind of motion sensor that is logging entry and exit to a location. If I put that in my home and I’m logging that into a computer I control, it feels pretty clear to me that that data about the comings and goings in my home is mine. But if it’s in another building, say a public building, and I walk in and my arrival is recorded, and of course, you know, cameras, they’re your faces, you know, in the data, is that mine? Well, probably not, but then I kind of, that is part of the discussion. It’s like, well, wait a minute, you’re kind of recording me or tracking me. I feel like that belongs to me somehow or you’re invading my privacy and it’s, but then you’re, you’re in that other person’s building, you know, the building is a public place or not something that belongs to you, so it’s a funny thing to discuss in a way. 00:34:25 - Speaker 1: Yeah, OK, so to unpack that, I think there’s actually 3 different things going on there. One is the classic analytics data, and the example that I might give for that is, say you have a web app and it’s indicating how often this user uses certain features, like, do you use the export feature? Do you use the print a PDF feature, things like that. That’s what I would think of as analytics. Then there’s the PII, the personally identifying information. This is information that ties some abstract user to you as a real person. So typically emails, as IN names, plus addresses, phone numbers, these are things that take an abstract account, you know, user ID, whatever, and tie them to Adam Wiggins. And then there’s this third issue of data in public places. I think that’s another huge challenge and to my mind, those are 3 different quite hard issues. 00:35:11 - Speaker 2: And notably the, you know, I mentioned GDPR in passing before cookie warnings are this huge thing in Europe where basically almost any site you go to pops up this morning and it’s kind of regulatory things gone wrong where they were trying, I think quite reasonably to say like if a site is going to track you in some way that they should seek your consent. But now, essentially, most websites just do a kind of blanket consent seeking because most websites set some kind of cookie, but the detail of it actually is that it only matters exactly as you said, if it’s personally identifying some way, if it’s it’s sort of tracking you around. So there are a lot of cookies that you might set that are more kind of anonymous or more kind of general telemetry, but are not about me specifically. And so for example, the Muse website does have analytics, you can see that if you do view source, but it does not have a cookie warning and that’s because the type of analytics that we use is essentially anonymous. It doesn’t track you around, it doesn’t connect to what you’re doing somewhere else, it just counts essentially. Gets to our site, which is very useful to have. It’s nice to know, especially with refers or whatever, it’s, you know, if there’s suddenly 1000 new users pop in, wow, where these folks come from? Oh, I see we got linked on some high profile site. We can see that in our analytics. It’s very useful to have for our business. 00:36:28 - Speaker 1: Yeah, and GDPR by the way, is I think a good example of the importance of systems thinking. I think the failure of that legislation, and I, I mean, that perhaps sounds blunt, but I think that’s the correct assessment was due to not thinking about it as a systems problem where you have to deal with the realities of what are people actually going to do, what our business actually gonna do, what are the capabilities or non-capabilities of the government, things like that. I do think that the differentiation between analytics and PII is important and good. To my mind, those are just very different beasts as well as being different versus content. This is something that we’ve kind of caught up in discussions with users and, you know, sometimes a privacy fundamentalist who says, you know, everyone has a right to privacy, no data should be ever transmitted over the network without my explicit permission. You know, maybe, but the reality is, it’s hugely valuable information that for most people has relatively low cost in terms of their privacy cost, if you will. So it’s not surprising that people end up sort of making that exchange. It’s much easier to, and therefore cheaper to offer software if you have access to this analytics data, whereas it’s a relatively low cost to individuals in terms of their privacy. I do think the PII and content stuff is much more tricky, and PII is also slippery because you can collect the data that’s like, quote unquote anonymous, but it’s actually very easy to deanonymize if you collect enough of their screen size OS version, browser version, yeah, the browser. 00:37:55 - Speaker 2: Fingerprinting stuff which is for a little while I was following kind of the Tor browser world of things, which is another one of these. Well, that’s even a step further on the privacy focused products, I think. It’s very interesting stuff that that team is doing trying to make truly anonymous web browsing. And one of the things they have had to face up against is the browser fingerprinting, which is exactly what you said, which is sort of knowing the exact resolution of the screen and you know what version of the operating system they’re on, you tie that together with some other data, some time stamps and things, you can work backwards from there to pinpoint someone, at least that it’s the same person repeatedly surprisingly well. 00:38:34 - Speaker 1: Yeah, I also think that the PII information can be separated from contact information and used to something interesting here. We do require an email to use the app because we need to be able to communicate with you for various reasons. But there’s no requirement that the email is like your only email or your canonical. email that it matches any other emails. So a lot of people just put in their default personal email, but a lot of people will create an email that’s specific to muse, kind of like a muse specific inbox, or they’ll just use like a burner email that has no connection, no identifiable connection to their real identity. And again, this is an example of where you can tease these things apart. You can separate out PII from ability to contact someone from analytics information from content information. 00:39:16 - Speaker 2: And speaking to use on the kind of analytics side of things, I mentioned our website, but the product itself, the iPad does report back analytics on usage, and that is for improving the product. Huge one, for example, is crash reports. So when iPad OS 14 came out a little while back. We embarrassed to say had a very rocky patch for a couple of weeks of crashchiness, and that was partially changes in the OS, partially with problems on our side. We eventually sorted it all out, I’m happy to say, but if we didn’t have reliable crash reports to be able to see, first of all, that there is a problem, and secondly, to try to hone in on what that problem is, and then once we’ve fixed it, you know, we roll out a new release, has the rate of this particular kind of crash gone down. That has a big impact for our ability to not be blind or trying to improve the product. But it also includes things like just features. So a little while back, Leonard was redesigning the action bar, which is what comes on the screen when you tap a blank space and you get the little couple of buttons down at the bottom, and we were really pondering whether the undo redo were worth including because they took up a lot of space and most people use the gesture or you can use the keyboard shortcut in the case where you have the keyboard. And so we thought, well, is it really worth the screen real estate this takes up and we could actually go ask this question of what percentage of people. are using the buttons or what percentage of the time versus using a gesture or keyboard shortcut, and I forget where it came out. I think it was like 15% or something like that, 10 or 15% of undos were from the action bar button, and I may say, you know, that’s just enough. I think it’s worth keeping. We’ll make them a little smaller maybe to represent that so we can make product choices. And of course there is ways to, I don’t go ask people, of course there’s, you know, you should be doing that and occasionally we get to observe people using the product and so on. But the ability to go and get real data about those kinds of questions, they really help us to improve the product and so it can become a better product faster. 00:41:17 - Speaker 1: Yeah, totally. And again, this seems to me like an imminently reasonable and good trade-off for both sides involved. If we had to develop use without access to this information, it would be much, much harder, and it would be worse product. You know, maybe it would cost twice as much or maybe be half as good. But is that worth this very marginal amount of privacy and In terms of analytics information, I don’t think so. Now, I’ve discussed a lot of this in terms of favoring a sense of trade-offs and opt in decisions over fundamentalism in any direction. I do think a huge issue with privacy again in the electronic realm is it’s very hard to understand what’s going on. You know, Muse, I like to think we try to be a good actor, we try to do reasonable things and nothing nefarious, but it’s basically very easy to do really bad stuff in terms of privacy, especially on non-web platforms. And to my mind, that’s actually a big technology gap. You know, how do we empower users to actually make these trade-offs instead of just having to throw up their hands. And there have been some movement on this. I think Apple is coming out with some additional required information from developers soon about what information you collect and how you use it and so on, and that’s certainly a step, but I suspect there’s much, much more to do here. 00:42:30 - Speaker 2: In general, I think I and most people would point to Apple as one of the best actors in terms of moving the ball forward on. What users can expect privacy wise, and I think this stems out from iOS from the beginning was a very securely designed operating system, much more than the classic desktop and server operating systems that that came before, and they’ve continued to do that. I think of something like the on-screen notifier when an app accesses your clipboard, when they rolled that out a little while back, then suddenly you saw all these slightly shady things that many apps were doing, including, I think. TikTok pulling from the clipboard on every single keystroke, for example, and you need that, you need a clipboard that can move between apps and apps that are going to do interesting things need to access the clipboard, but finding ways to try to surface that so that people who are not acting in good faith, not using the operating systems capabilities for the benefit of the users, but for their own benefit, or at the very least just being deceitful perhaps about what the user expectations are versus what they’re actually doing. So certainly got to give props to Apple on that. They’re not perfect, but they’re definitely one of the best players, I think in our industry, certainly at that scale. 00:43:40 - Speaker 1: Oh yeah, I mean, lots of good things going on there and it helps when you have control over the platform because you can manage access to things like the camera roll and the microphone and so on. I guess my point here is that I think there’s just a huge gap remaining, especially as you look at the meat of the data and the network connections. You know, apps, they can basically talk to anywhere on the internet they want, and they can do whatever they want with data that you input into the app. So a good example of this is perhaps you have an app for composing a message. The app can, and in fact, many of them do, just send every keystroke. Type, regardless of whether you hit send or when you hit send. So, you might not realize it, but when you’re drafting a message, whoever is running this app has a copy of that draft forever, even if you layer decide, oh, that’s actually not a good idea to send that to backspace. A, that’s really questionable, but also it’s really tough to manage against. Like, what would the interface be that prevents apps from doing that, or even alerts users that it’s happening? It’s hard. 00:44:32 - Speaker 2: Yeah, I have a tendency to type messages in progress if they’re anything more significant than just a, you know, a few words for a quick reply into my local text editor. Very programmer type thing to do, but first of all, I like the better editing capabilities, but it’s also the sense of knowing that it’s not a cloud connected thing, that it’s truly, you know, when I hit that close button, maybe it prompts me of whether I want to save but you compare to the cloud where anything you ever put into it is just always saved instantly, which by and large is a huge win for users, like unsaved documents or things you forgot to save and then your computer crashes and. And whatever, that has been a massive source of user frustration for a very long time and this modern era of mobile apps and cloud that don’t really have a concept of needing to save things and just everything you type in has ever saved is mostly a big user experience when, but for me personally, yeah, when I’m composing a message, I like to know that it’s in this ephemeral place and that if I decide, ah, this isn’t quite right or whatever, I just delete it and I know it never went anywhere. 00:45:36 - Speaker 1: Yeah, fair, that makes a lot of sense. Oh and by the way, on mobile, another huge way that the mobile platforms achieve security is just banning huge categories of stuff, especially arbitrary code execution, plug-ins, extensions, and these are capabilities on the one hand, are incredibly powerful. You could argue that they’re basically required for getting a lot of the power user workflows that you see on desktops, but they would be super gnarly to sandbox and To be clear, I’m not saying that that’s a wrong decision or that Apple or anyone else hasn’t done enough or that they’re making bad calls here. It’s more to point out that I think it’s an incredibly important research problem. Is there a way to get the benefits of third party plug-ins and security at the same time? Right now it’s very much one or the other. In the same way that is it possible to get collaboration and and then encryption at the same time, you know, it’s an open research question to see if you can figure out how to do that. 00:46:25 - Speaker 2: A little earlier you mentioned the term privacy fundamentalism. And I like this concept of trying to just better understand how much does privacy matter to people, how much does it really matter? And for us, you know, from a business perspective, we can sit here and in fact we do talk about big philosophical things that we believe in regarding privacy and what the technology industry should do and the things our society are going to be grappling with having to do with this, but we’re a small business, we need to do things that, you know. Makes sense practically for us in places we invest effort, time, energy, money, or places, you know, that is zero sum. We could be building out other features and if we’re looking into and then encryption to make a signal style thing for creative professionals to share their little notebooks, you know, that comes at the expense of other things. How important is it really to our potential customers? And one of the pieces of prior I was just kind of looking at when we’re thinking about this episode was essentially a survey of people’s attitudes about privacy. And in this case, I think it was like an internet of things kind of category, so I think this is in the context of smart home or something like that. But I like that they broke things out into three categories in terms of people’s attitudes. There was the privacy fundamentalists, which you described, which were people who would trade off almost anything for the privacy aspect of things. And then you had another category which was also a small group, but still a significant one which they called privacy and Concerned, they just said, who cares? Nothing I do is that interesting. Google has all my data anyways, what difference does it make? I don’t care. But then the biggest category by far is what they call the privacy pragmatist. That’s certainly the category I put myself in, which is this is something I care about. I think it is important. It has impacted my life in direct ways in the past, and I do see it as a big and important topic for our industry, for our society going forward, but I’m not willing to trade off everything for it. There’s a bunch of other things that I care about in terms of the utility of products that I’m using. And so finding that balance, I think, at least when I put it in this frame, I’m going to make a wager that I think a lot of users, both current and future are privacy pragmatists. 00:48:34 - Speaker 1: Yeah, I think that’s right, and I agree on privacy fundamentalism, I think that can actually mean two things. I think it can mean that one as an individual has very high standards for privacy, and I think that’s totally fine for an individual to say, and I think for some people, it’s absolutely the right decision. For example, if you are acting as an informant, if you’re doing something that the government doesn’t like, so on and so forth, right? That’s the correct trade-off to make. The thing that I am not as sympathetic towards is the sense of privacy fundamentalism that sort of the entire system should be subject to it. And this is where I come back to this idea of privacy as a fundamental human right. That sounds very appealing. But on the flip side, it’s saying that no, you should not have the ability to choose to be a privacy pragmatist. You shouldn’t be able to use software that takes a different set of trade-offs with respect to privacy. And that’s something that I’m not very sympathetic to. And I would furthermore say that I also think it’s valid that you want to live in a society where many or all people choose to be privacy. Fundamentalists or choose to have very strong standards for privacy, but I think we need to recognize that’s an enormous amount of work. It will cost many, many millions of dollars to develop and operate that software, and it will require perhaps trade-offs in terms of our day to day experience with the software. And if you kind of ignore that cost, you’re fooling yourself and it’s being intellectually dishonest, you’re gonna end up not achieving that. One other possible angle on privacy fundamentalism is again going back to governments, there’s a possibility that a loss of privacy is a one way, very destructive ratchet, and that for that reason, you want to be very careful. This is the sense that once a government has access to data, they might be extremely reluctant to forego that grip. And over time, they’re going to tend to get access to more and more through various means. And if you see the endgame as being bad, which some people do and some people don’t, but if you see that endgame as being bad, then you’ll want to resist by basically any means possible, the progression of that ratchet. 00:50:37 - Speaker 2: Well, talking about governments makes me want to recount my personal journey into thinking about privacy in a broad way. I think for a lot of Americans, it was the case that the Edward Snowden incident, which revealed how much kind of digital surveillance the US government was doing on its citizens was a bit of a wake up call. Now, for me, I think I’d always had the vague sense that, you know, this is something important and I know digital technology is going to change the game, but I don’t think I’d given a deep thought and by just a coincidence of life, this all was sort of unfolding right as I was moving to Germany. And I watched the startup I was working for at the time in Berlin, they just organized a little outing basically to see this documentary Citizenfour in the theater, which was a very interesting experience where they followed Edward Snowden around the camera, and this was You know, before the news had broken, essentially, and so you see all that unfold, and you see the crazy lengths he goes to, you know, the tails Lennox distribution and putting a blanket over his head, uh, is actually a very reasonable security precaution when he’s typing in his password, that sort of thing, a very interesting film. But that in turn led to me having kind of a lot of conversations with my colleagues there, many of whom grew up in Germany, and for them it was very much in the recent past, the East German Stasi, which was kind of a secret police that had, I think, at least as far as we know, is the most extensive government monitoring of its citizens to date. Some crazy thing like 1/3 of the entire East German population was a Stasian farmer. And when these records were revealed when the Berlin Wall came down in 1989, and these records were revealed to the population and people realized how much had been tracked and largely using at the time the new technologies of things like small microphones and wiretaps and, you know, recording things, tape and stuff like that, just the extent of it just shocked people. They had no idea that such a thing could be possible. Actually another great film worth checking out a fiction, but I think captures this well. It’s called The Life of Others, German film that sort of depicts a fictional Stasi officer and what they’re doing and they’re monitoring. But yes, I spoke to these folks who, this stuff is in their living memory. They grew up when this was happening, right? This is only now 31 years ago at the time, 24 years ago. And they said, you know, we know what it looks like. Maybe I had almost a little bit of an innocence, you might say, insofar as being this American where I guess I basically just feel like most of the time, you know, government can be bureaucratic, it can sometimes be incompetent, but ultimately, most of the people that work in government and the systems that are in place are basically there to serve the citizenry. And yeah, there’s a lot of trade-offs about law enforcement getting access to wiretaps and stuff like that, but ultimately they want to do that to catch the bad guys, keep us safe, all that kind of stuff. And speaking to the German folks where they said, you know, no, we’ve seen what it looks like to have a society where government so heavily monitors its citizens in the name of protecting that society, right? Everyone that worked. You know, in this state surveillance apparatus believed they were doing something really good. They were keeping their home safe. And I’m not saying I necessarily converted to seeing the world that way. I do see it as a series of trade-offs, and yet that was a powerful experience for me, and I think has influenced strongly how I see this topic as it unfolds in the technology world. 00:54:07 - Speaker 1: Yeah, absolutely, and I think it shows how dangerous it might be to just assume or hope that everything will go well if we concentrate an enormous amount of data in a very legible way in one or a few powerful entities. 00:54:23 - Speaker 2: Yeah, Silicon Valley is maybe already grappled with this a little bit, which is you have a bunch of young optimistic people building powerful new communications and other kinds of digital technology, and they tend to think about the positive case, you know, I think people who get into tech tend to be optimists, they tend to think of technology as a force for good, and they’re not thinking about the ways that it can cause harm. It’s a, you know, technology is neutral and can be used as a weapon, can be used for harm, can Decay the things that a society holds dear, and I don’t think that’s a reason to fear it or to kind of have a knee jerk reaction, but I do think there is a clear-eyed sense of, OK, as we open up brand new ways to do all kinds of things with our information life thanks to these digital technologies, what’s that going to mean and not to say that we can fully know or fully predict what the impact of this stuff is, but I think being mindful and having some caution as we go. That certainly goes for you and I who work on new products where we’re trying to bring new capabilities into people’s lives. What are the risks, what are the downsides and certainly the privacy product issues that we’re grappling with right now are very much in that category for me, for sure. Well, if any of our listeners out there have feedback, for example, we’d love to hear how you think about privacy and digital tools, go ahead and reach out to us at @museapphq on Twitter, or you can email us at hello@museapp.com. We always like to hear your comments and ideas for future episodes.
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: I think that the future is not determined. I think that it is up to us, and I think that we should always believe fundamentally in the ability of human intelligence when properly applied to solve problems. 00:00:17 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for thought on iPad, but this podcast isn’t about Muse the product. It’s about Muse, the company and the small team behind it. I’m Adam Wiggins. I’m here today with my colleague Mark McGranaghan. Hey, Adam, and our guest Jason Crawford from Routes of Progress. 00:00:35 - Speaker 1: Hello, thanks for having me on. 00:00:37 - Speaker 2: And Jason, when we first met, you were a tech founder working on Field Book. Tell me about that. 00:00:42 - Speaker 1: Yeah, that’s right. So most of my career has been in software and technology. I was a software engineer, engineering manager, and tech startup founder. Most recently, starting in 2013, I started a company called Field Book. Field Book was a sort of hybrid spreadsheet database, a lot like Air Table, so very much in the mode of a tool for thought and I’m very sympathetic to that general space of tools. I still have a soft place in my heart for it. In fact, Adam, one of the things That inspired me and helped give my mindset early on in developing that tool was a book that I think I learned about from you, A Small Matter of Programming by Bonnie Nardi. 00:01:23 - Speaker 2: Um, yeah, so that was a 93. Yeah, you can believe that. 00:01:27 - Speaker 1: And still very relevant today, frankly, and so I told all my employees, recommended they read at least the first few chapters of that book and there’s a significant amount in there about spreadsheets, which are probably the greatest tool for thought ever created, so. 00:01:40 - Speaker 2: Absolutely, and I think the world’s most successful end user programming tool, which is almost everyone knows how to use a spreadsheet and probably can do at least the very most basic function like summing a column, and that is a small bit of computer code. 00:01:52 - Speaker 1: Exactly. So yeah, I built Field Book, worked on it for about 5 years. Unfortunately, didn’t work out, we ended up shutting down the product and selling the team. We did a sort of aquahire to start up Flexport. 00:02:04 - Speaker 2: And to be fair, the end user programming dream is one that many have chased and few have found there’s a few success stories, yeah, spreadsheets, you know, which are now decades old, maybe Flash, maybe Unity more recently, but it remains a really elusive dream to make a tool that both brings kind of the power of programming to an audience that is not already professional programmers. 00:02:27 - Speaker 1: It’s true, although at the same time, in the last couple of years, there’s been the notion of no code and low code has become, you know, much more prominent, and there have been a couple of major successes, so I’m happy to see tools like Air Table, tools like Notion, and, you know, a number of other sort of competitors in that space all keeping the dream alive and actually creating some pretty successful products. 00:02:50 - Speaker 2: Yeah, absolutely. So going from there to, I don’t know, an independent scholar or educator or advocacy around progress studies seems like at least a pretty big leap. I’d love to hear that story. 00:03:02 - Speaker 1: Yeah, that’s right. So what happened was I got interested in the story of human progress early 2017. It began as not even a side project, it began as just a reading list, really. It was what books am I gonna read next. I always like to be reading a non-fiction book and at a certain point I discovered that it was kind of a good idea to read books in clusters, sort of pick a theme and then read a handful of books on one theme, and you can learn a lot more from that than just reading random books. So I decided to learn about the history of human progress, and mostly in the beginning at least was interested in focusing on kind of technological and industrial progress, really fascinated by just the simple basic fact of economic living conditions and standards of living throughout history, how much those have really skyrocketed in the last couple 100 years after, you know, thousands or tens of thousands of years of very slow progress and very little improvement overall in living conditions. And I just wanted to know, like, how did we get here? What were the major breakthroughs, the inventions and discoveries that created this standard of living? And ultimately I’m interested in getting to the root causes. When I started blogging about this, I called it the roots of progress. You know, so ultimately understanding what are the conditions, what are the root causes of this explosion of creativity and invention that ultimately has made everybody’s lives so much better. So it started off as just me sort of reading books, and then the books were so fascinating that I decided to start making some notes on them and maybe publishing the notes on a kind of a little blog that I didn’t even care if really anybody read except for maybe a handful of my friends. And then a couple of years went by and I was still doing it and frankly, it just became my hobby, you know, people would ask me, do you have any hobbies? And I would think about what do I do on nights and weekends? And then I would say, well, I don’t know, is economic history a hobby? Can that be a hobby? Because that was where my time was going. And so then when I decided that it was time for me to move on from the last tech job and figure out something new to do, I asked myself, what am I really obsessed with right now? What’s the one thing that I can’t see myself not doing in the near future? And it was really doing this research and writing about the history of technology. In the meantime, a couple of things that happened. One is that my audience had actually grown somewhat, some of my posts kind of got popular, one of them hit number one on Hacker News and So I was starting to actually see that there was an audience for what I was doing, people liked it. And then the other thing was that a whole community began to form around this notion of progress studies, particularly after economist Tyler Cowen and startup founder Patrick Collison wrote an article together in the Atlantic about a year and a half ago, calling for more focus on the nature of economic and industrial progress and indeed calling for a discipline of progress studies. And so that article sort of galvanized a community around this notion and it turned out there are a lot of people who are interested in this concept. And so, you know, between that community and my new audience and my just personal obsession with the topic. It was a, I won’t say it was an easy decision to kind of make a hard left turn and just take my career in a different direction, but there was something that just felt inevitable and undeniable about it. So here I am, it’s a little more than a year later, and I’m quite happy with it. It’s still a topic that continues to fascinate me and I think it’s still very important for the world. 00:06:27 - Speaker 2: Yeah, I find it really interesting that my own journey as kind of tech entrepreneur, like if you go back, I don’t know, 56 years, maybe you and I had pretty similar jobs in certain ways, you know, starting a company, building a tool, sort of standard software as a service inside the Silicon Valley startup, combinator model, and then we each in our own ways got interested in the meta process of innovation, and my path was to go off and start this research. Switch that Mark later joined up with about how we generate big breakthrough kind of step change, new digital technologies and that in turn led to me working on Muse because that was a spin out of that technology. You went a maybe more scholarly path, but I feel like they come from the same place, which is working within that box, that Silicon Valley box, which is very much about change, innovation, new technology, but it’s sort of narrow in a certain way. It doesn’t take that broader view of Human history and how do we get here? And for me, a big personal breakthrough or something like that source of inspiration was going back and researching all these older industrial research labs like ARPA and Bell Labs and even back to Thomas Edison, and you were nice enough to invite me to give a little talk at Torture Progress about that exact topic. So maybe yeah, there’s a seed of something that started in the same place, even though we ended up doing very different things in terms of our day job now. 00:07:50 - Speaker 1: Yeah, absolutely. And it’s interesting to see how much overlap there is between the software, kind of computer and internet and startup community and the progress community. It seems like it’s probably not a coincidence, but it’s interesting. 00:08:04 - Speaker 2: And Mark, you’ve been a little bit involved in the progress studies community. How do you think about this? How do you even define progress might be one place to start. 00:08:13 - Speaker 3: Well, that’s a big one. You might define progress as our ability to satisfy human wants and needs and desires. It’s a big area, right? I guess I came to it similar to Jason through the lens of economic history and reading about all the progress we had made over the past several 100 years in particular, but then also how curiously we seem to be going pretty sideways in the last 50 years. And it’s notable, I think that both you and Jason described reading about or having the sense. of there’s some sort of stagnation going on, because actually, if you look at the literature, it’s very pervasive. In many areas, it seems like we’re going a little bit sideways in terms of not making the type of progress we made in the first half of the 20th century, for example. And so as I read more and more, you keep seeing this over and over again, and it drives me to wonder what exactly is going on and how can we make it better. And I also have an interest similar to both you and the, you might call it the meta of why this is all happening the way it is and what might make it better. But to my mind, that’s perhaps the main thing. What’s the system of social technologies, if you will, that allows us to make progress or prohibits us from doing so. 00:09:16 - Speaker 2: Where do you fall on the stagnation hypothesis, Jason? 00:09:19 - Speaker 1: Yeah, short answer, I have come around to it after being initially skeptical. It was not my initial or primary motivation for sort of getting into progress studies or, you know, starting to study this story of technological progress. I was more motivated by sort of the opposite, which is how much progress there actually has been in the last few 100 years compared to the previous several 1000. Right, and I think we need to keep in mind that is still the bigger story. Even if progress has slowed today, it’s still significantly faster than it was, I think in any pre-industrial era, right? Like the big division is still between the industrial age and pretty much all the time prior to that. However, after some amount of time reading different arguments, quantitative and qualitative, looking at it in different ways. I’ve come around to this idea that progress actually has slowed down in the last approximately 50 years. I now see that. And part of what actually really helped me to see it was mapping out on a kind of a timeline, major invention. In different areas. So I made a sort of two-dimensional timeline for myself or one dimension was, well, time, and the other dimension was just sort of breaking out areas of technology into a few major categories like manufacturing, agriculture, energy, and so forth. And then I started placing on here kind of like, what were the huge breakthroughs, you know, in each of these areas at different times. And just from that, you can kind of exercise, you can really start to see it. And so the simplest way that I can summarize stagnation right now. is to just point out that around the end of the 1800s and into the early 1900s, we had, by my count, approximately 4 major technological industrial revolutions going on at once. One of them was electricity and everything that I was turning into, motors and everything, light bulbs, etc. Another was oil and all of its ramifications, including the internal combustion engine and the vehicles made from that the car and the airplane. Another was, I’ll just call it chemical engineering, the science of chemistry really coming into its own and beginning to really affect industrial processes. An early example would be the Bessemer steel process, a late example of this that really kind of capped it off would be the entire plastics industry. And then the fourth one, which maybe doesn’t always get a listed or counted as kind of a quote unquote industrial breakthrough, but which I think essentially does fit in that category, is the germ theory, the germ theory of disease and all of its ramifications in improving hygiene, improving public health, pasteurization of food, better food handling practices, especially water filtration and chlorination that improved that. And so these 4 things, oil, electricity, chemistry, and the germ theory, 4 major, mostly scientific and overall industrial innovation breakthroughs that are completely transforming one or two of those major areas of the economy, and then each one of them is having ramifications pretty much on like the entire world and on all areas of the economy, and they’re all happening at once. Now by the time you get to the end of the 20th century, the last 50 years or so, you’re basically down to 1. It’s the computer and internet revolution, right? And that is huge, and I think we shouldn’t dismiss it or discount it or downplay it, and there’s a lot of breath wasted on people arguing it across purposes a sort of like missing each other’s point going back and forth. Where I blame Peter Thiel for this a little bit. The whole, you know, we wanted flying cars, we got 140 characters. Well, what’s the matter with 140 characters? Like, That’s a pretty dismissive way of talking about this amazing information revolution that created the entire internet and put a supercomputer in everybody’s pocket and gives you access to all the world’s information and has connected everybody like never before. I mean, that is, you know, you don’t want to downplay that. But I think it’s fair to say that the computer and internet revolution itself is roughly comparable to any one of those four revolutions that I just mentioned, oil, electricity, and so forth. I don’t think it can measure up to all 4 of them going on at once. So if you just in a very crude way, if you want to count major technological revolutions that are going on, we went from 4 going on at once now to approximately 1. And by the way, that 1 has been going on for several decades, it’s kind. starting to level off. It’s starting to plateau. We’re starting to get to the point where it’s saturated the world and there’s still a lot more value to be generated out of computers and the internet, but it’s not gonna last forever, right? In a couple of decades, certainly we’re gonna start to see diminishing returns if we’re not already. And I think there’s some ways in which we are already starting to see it. So what comes next? Do we have another revolution on the bench or waiting in the wings to take over, right? Because the only thing worse from going from 4 technological revolutions to 1 is from going from 1 to 0. So that’s my current take on stagnation. 00:14:10 - Speaker 2: It does beg the question of what is the right number of revolutions to have or ideal number perhaps. There’s one version which is just more progress is better, and just 4 is good, 6 would be even better, 10 would be great, so 25, there’s another version where we say, OK, we like the world that existed and that it produced to have 3 or 4 major revolutions going on at the time. One isn’t bad. Somewhere in there seems about right, but there is such a thing as maybe too much progress or that’s not the only thing that matters in the world. There’s other things related to just human happiness. So how do we decide, I guess what what what we want in terms of societal progress. 00:14:50 - Speaker 3: Maybe that’s an internal variable in the system because you can imagine different social technologies that is different political systems, different ways for organizing society, where you have more or less ability to metabolize change. There are some structures that are very brittle, and if you put more than one, you know, industrial revolution on, it would just crumble and break. But we’ve also seen that there are systems that can handle 4 at a time, you know, reasonably well, at least get through to the other end. So I think there isn’t necessarily hard cap so much as you need the technology to be able to metabolize other technologies, if you will. The other thought is, and this one was really driven home to me by the book, The Rise and Fall of American Growth, which paints the picture that Jason just did about the huge amount of change that we had in our everyday lives before 1970 and basically the stopping aside from the information technology revolution after that. That book really focuses on the everyday lives of people and what it was like to live day to day. And a point that the author constantly makes is there are a few areas that are really key, housing, food, transportation, medicine, and these are kind of the bread and butter of everyday life. And it’s easy, I think, to forget that as people who work in the information economy. And so one way to answer the question of how many revolutions should we have is, well, we obviously have huge gaps in all of those areas. So we need enough to at least make progress in the big spaces like that. 00:16:04 - Speaker 1: Yeah, that is a good book that really does drive home, I think the how much progress there was in that late 1800s to early 1900s time frame, you know, compared to today. I deeply disagree with his conclusions about the future, where he sees basically no more progress ever, as far as I can tell, but I think his history is excellent. If you don’t want to read all 700 pages of the book, by the way, I did summarize it on my blog at roots of Progress.org. I have a sort of summary and book review. So I break it down, um, I mean, food, clothing, shelters sort of one way to look at it. I break it down as kind of manufacturing, agriculture, energy, transportation, communication, and medicine. Those are sort of the big 6 that I think about in terms of areas of the economy. And you can put almost all, not absolutely everything, but you can put almost all big breakthroughs and innovation into those categories. And so I see no reason why we shouldn’t have at least one major revolution, you know, affecting each of those things at any given time. You know, if you want to ask, well, how many technological revolutions do we need at once, right? One thing to look at is the areas that haven’t changed much and especially the technologies that seemed promising and areas where people thought there might be a revolution. But either it was aborted or hasn’t arrived yet or just hasn’t lived up to its potential. I mean, if you go back to the 1950s, everybody at the time thought that the future of energy was absolutely nuclear, you know, they almost just took it for granted that of course, this is the future, this is where it’s going, we’re gonna have nuclear powered homes, nuclear cars, nuclear batteries, nuclear everything. And I’m far, far from an expert in that technology and what is actually possible, but I think that far more is possible, at least according to the laws of physics that we know, than what we’ve achieved or than what most people actually believe to be possible. So I strongly suspect that nuclear is a far under exploited technology, and in a world where everybody is very worried about carbon emissions, that really looks like an oversight, doesn’t it? Manufacturing is another interesting one. So another book that I recently finished and reviewed on my blog is called Where Is My Flying Car by J Stors Hall. It’s basically just sort of the polar opposite of Robert Gordon’s rise and Fall of American Growth. It’s in many ways a work of futurism, and the author spent a lot of his career in nanotechnology, trying to do, you know, true or, you know, investigating, researching true, like atomically precise manufacturing, where you have basically nanobots putting together. Whatever you want, assembling it atom by atom, placing every atom in the right place, that would be an absolute revolution in manufacturing, right? That would allow us to not only create things of enormously higher quality, building 100 kilometer towers out of diamond, right? But also would, you know, like pretty much every revolution in manufacturing enormously bring the cost of everything way down, right? Because you’d be able to do everything faster and with much less human labor. You can look at genetic engineering technology and biotechnology, you know, we’re in the middle of a pandemic. Gosh, it would be really nice if we had had a broad-spectrum antiviral drug that was as broadly effective as our broad-spectrum antibiotics. We don’t have any such thing yet. I’m really, really glad that somebody was working on Messenger RNA based vaccine technologies because the first two COVID vaccines that have come through and seem to have promising results in their phase through trials are both based on Messenger RNA. That’s a brand new technology, by the way. I mean, it’s been around in the lab for a while, but there’s never been a vaccine approved or in widespread use based on that technology. So this looks like COVID will be the first. So there’s always more. More progress to be made. And I think that’s a really important theme of progress studies, something I think you learn by looking at the history and I think, you know, it was always very easy to take the current world for granted and just assume that kind of this is how things are. You know, the people 100, 200 years ago, many of them were quite happy with the world as it was. They didn’t see the need for these huge breakthroughs. They didn’t believe they were possible, they didn’t even necessarily believe that they would be a good thing. Every single one of them was fought and opposed, not only by special interests who maybe stood to lose if some new breakthrough came into the world, but also The original Luddites, right? Yeah, and also just by people who were generally afraid of the technology and didn’t know, you know, what to do with it. 00:20:27 - Speaker 2: So, yeah, well, by default, you could say that humans I think are Fearful of change, and I almost wonder if kind of the tech founder type is someone that, because I’ve always been drawn to novelty and I find adapting to change or even taking advantage of it, sort of making the most of it in some way to be an exciting and fun challenge and stagnation is sort of bad for me, but I’ve come to realize that that is very much the exception, not the rule. In general, change is just threatening, very simple. 00:20:56 - Speaker 1: Yeah, I think that’s right. So I think it’s very important that we remember that perspective and that we remember that. Now if there’s one message I really want to drive home to people, it is that the future can be as amazingly better compared to the present as the present is compared to the past. Are we in the future and our descendants can be as fantastically wealthy compared to today as we are compared to the people of 200 years ago, the vast majority of whom lived in what we today consider to be extreme poverty. So we should keep that in mind and always be working for that much, much better future. 00:21:31 - Speaker 2: And that’s part of what’s very powerful about the advocacy side of progress studies to me is that it’s probably a very crude summary of cultural attitudes about change, but I think from what I understand, most cultures through most of history, most of civilization. Saw the world is largely static and it was really fairly recent that you had this, oh, we can actually steadily improve and each generation can be better than last, but maybe that was the Victorian era concept of progress, progress with a capital P, which was the sense that things must get better, that it’s sort of mandated somehow by God or nature or it’s in our nature that if we just keep doing what we’re doing, things will continue. get better and then maybe that the pushback to that is, well, wait a minute, it’s actually not quite like that. Things can and do get worse, you know, ask the folks in the declining empire like Rome or many of the others over the millennia, but in general, we can choose a society and as individuals to say that we actually think progress is possible and desirable and then do things to try to affect that. 00:22:36 - Speaker 1: That’s right. The most interesting book I’ve read on this was A Culture of Growth by Joel McKe came out just a few years ago. It’s one of the first books I read in my study of progress, and he says much of what you just said that the very idea of progress is a relatively new one. It is not at all the default. In fact, a common view in many places and times in history was sort of the opposite, something he called. ancestor worship, where we looked back to our ancient ancestors as the most Aristotle. Yeah, or even in the Middle Ages, people looked at the, they looked around and they saw the pyramids and they saw the Colosseum and the Roman aqueducts and, you know, they just thought, well, wow, these ancient people who and then especially in the Renaissance and, you know, when they started rediscovering some of the ancient texts, and they’re just getting this knowledge. That had been lost in Europe for 1000 years, you know, like how to mix volcanic ash into your cement to make a hydraulic cement, right? That was something the Romans knew and worked with and was kind of rediscovered 1000 years later after the fall of the empire. And I think it wasn’t just in the west either. I mean, I think the West had this special sort of historical thing where there was a kind of cultural decline for a long time and Than a rebirth, but I think in many places and times people have sort of looked to ancient ancestors as the wisest people who ever lived. We will never surpass their knowledge or achievements. All we can do is kind of learn what they had to teach us. And so progress in a certain way requires reversing this notion and actually believing that we can do better, that we can discover knowledge that none of our ancestors ever had, that we can create things that work better than anything they ever made. And that takes a little bit of hubris and Mir says that that notion of progress evolved in the West roughly between about Columbus and Newton, so say the 1500s and 1600s. The Voyages of Discovery actually had a significant amount to do with it, because here we are out discovering entire new continents that the ancients never knew about. Francis Bacon had a lot to do with it, and he’s a pivotal role in Moyer’s book. Newton really put the cap on it with his system of the heavens and explaining the motion of the planets and clearly better than anything that, you know, Ptolemy or anybody ever came up with. The summary of that book is basically it’s how the Enlightenment set the stage for and led to the industrial revolution. 00:24:55 - Speaker 3: This reminds me, one of the interesting things I see with the study of progress is that it’s very contingent and embedded. And by that I mean, you generally don’t have one person who strikes out and decides, I’m going to make some progress today. Instead, you have a culture, you have a society, it often takes several 100 years. Amen. 00:25:12 - Speaker 2: Speak for yourself. That’s what I think every morning. Perfect. 00:25:17 - Speaker 3: So you do think that Adam, but that’s because in part, it’s because you spent so much time in Silicon Valley, which has become the sort of magnet and amplifier of this attitude that if you spend enough time there, you can kind of catch as a contagious disease almost. And I think it’s important to understand these very human elements of how just the notion of the improving mentality can be transmitted and encouraged culturally or conversely, it can be lost if it becomes too diffuse. 00:25:41 - Speaker 2: Yeah, it’s almost a societal level growth mindset where, yeah, again, it’s the thing we can do and we can choose to do, but it is not automatic. It’s something we have to work out and over extended periods of time. Yeah. Exactly. Yeah, and I certainly have plenty of ways that I talk about, and Mark, you and I talked recently about our decision to leave San Francisco, each on our own basis some years past, and some of that was for me at least was somewhat some Silicon Valley monoculture and feeling like I wanted to break out of that to have sort of new perspectives and new ways to pursue the things that are important to me. But at the same Time for some of the critique I have there, it is really one of the few places in the world I feel where that it is a baseline cultural thing that we’re here to make changes that we think will improve and possibly very deep changes. We talk about disruption, which is sort of an overused word, but it’s this idea that it’s the creative destruction. You can’t go beyond very incremental improvement without some tearing down. What’s already there and hopefully that shouldn’t be in a disrespectful way. And sometimes Silicon Valley startups get into trouble with that a little bit, which is they get so wrapped up in there, we’re going to change the world and it’s gonna be better that they forget about that every change, every transition has impacts, some negative, and you should be aware of those. But at the same time, yeah, that perspective of we can make the world better is quite a unique thing. 00:27:05 - Speaker 3: Yeah, now we’re kind of getting into the discussion of why we progress or don’t. So Jason, I’m curious, you’re looking back 50 years and you’re seeing we’re not making as much progress as we did in the previous couple 100 years, even though it’s more than we did 1000 years ago. Why do you think that is? 00:27:20 - Speaker 1: Yeah. I have 3 main hypotheses right now. My hunch is that they’re all true and part of the issue. The most fundamental is cultural and sort of philosophic ideas and attitudes towards progress. I think in many ways our world is not nearly as favorable to progress and doesn’t think of it as highly as we used to. We’re much less appreciative and much more fearful and angry. And I think when you value something less, you get less of it. You get less investment, you get less resources going into it. Fewer people want to devote their careers to it and so forth. Exactly why that happened and why it happened when it did, I don’t totally know. But if you go back to again, sort of the late 1800s. The culture in general, I mean, particularly in the west, and especially in America, was extremely favorable to progress. It was seen as a very good thing. It’s coming along and improving everybody’s lives. It was transforming the world. Humans were proud of themselves as a species and about our abilities and what we could do, right? That was sort of how it was seen. It’s this kind of Victorian progress with a capital P, you know, the march of progress and so forth, right? I mean, you go back and those things are, I don’t know, almost cliches now, but they were very real attitudes. People celebrated progress. You go and you look at the imagery, the posters from the old World’s Fair type exhibitions and the way that they saw. They really saw progress as this positive force moving forward. As what you mentioned earlier, yes, I think some of them even. Got to maybe see it as inevitable and unstoppable, which is wrong, it’s not inevitable in any way, but people saw it as something, you know, overall that was making the world better. Sometime seemingly around the, I’m just gonna say the middle of the 20th century, the tide seemed to turn, and by the end of the 60s and with the rise of the counterculture, you definitely see popular attitudes turning against this. I think you See most of all, but not exclusively in sort of the rise of the environmentalist movement, there was just much more concern about technology, fear for unintended consequences, a different set of values, even that may be put nature and animals, other species, the planet itself, the quote unquote ecosystem, all of that, even above and beyond what’s good for individual human beings. And overall, again, I think just people stopped believing in progress as this fundamentally good force and some people even started seeing it as a fundamentally bad thing. And so, again, when you give less honor and prestige and acclaim and social. Status to invention and science and technology and business and capitalism, you’re gonna get less of it. You know, you have fewer people devoting their energies to it and more people devoting their energies to stopping it. One of the lines from, I mentioned that book, Where is my flying car? He said something like, today for every person who’s out there trying to change the world, there’s somebody else who believes that they’re saving the world by stopping that person. So that I think is maybe the deepest explanation. So my second major hypothesis is the growth of bureaucracy and especially government regulation, although not exclusively government regulation, I think there’s been a general kind of growth of bureaucratic overhead even within private institutions. But there’s just so many more rules now, so much more, you know, that any new thing, both the invention itself and the process of research and development, there’s just so much more to comply with, right? And so much more overhead, and it’s just an enormous amount of friction added to the entire process. I mean, the multi-billion dollar FDA pipeline now, right? I mean, that’s how much it costs to get a new drug out there. The cost of getting a new drug out there has been increasing over time, over the decades. There’s sort of an inverse Moore’s law. In fact, there was a famous paper by, I believe Jack Scannell at Al. That coined the term E-room’s law. Eroom is more spelled backwards because the price of getting a new drug to market on average was doubling every 9 years. And I think that may have leveled off or so in the last decade, but still, the prices are enormously high. It costs multiple billions of dollars on average per new drug approved by the FDA. And uh you know, there’s a number of different potential explanations for this, and they mention a number in that paper, including things like, by the way, every time you add a drug to the market, all new drugs have to be better than everything that’s ever previously, right, so the bar just keeps going up, right? But you know, one of their hypotheses was what they call the cautious regulator problem or the over cautious regulator, just that the requirements for new drugs have just been going up and up. To the point where, you know, the FDA doesn’t even allow people to try drugs experimentally, even after they’ve been proven safe, right? They have a further standard of efficacy. And it’s the phase 3 of the clinical trials that costs the most money, by the way. Like, why is nobody even talking about something like a universal right to try, not even, you know, putting these drugs out there just kind of on the open market, but At least allowing people who discover them and know about them, give them the right to try in their own bodies, at least after these things are proven safe, you know, in earlier trials or once we have like a certain amount of data, right? I mean, these are the kinds of things where I think, I mean, coming back to sort of cultural foundations, I think we have evolved something of a safety culture, especially in the United States and in the world in general. And I often wonder if the safety culture has gone beyond true safety into basically safety theater, where we just keep adding overhead and processes and bureaucracy and regulation. Basically, we’ve gotten to the point where you can justify anything on grounds of safety, and you can pretty much kill anything on concerns of safety. And there just doesn’t seem to be any really ability to talk about trade-offs. And so I fear that what has happened is that we’ve kind of built up the safety theater, which is extremely low ROI like it adds tons of overhead and does not actually add an appreciable amount of safety. So I think we need to get smarter about the ways that we create safety. And this is not, by the way, to say that safety is not a valuable goal. It absolutely is. In fact, increased safety is one of the enormous accomplishments of technological and industrial progress over the last couple 100 years. Our lives are actually much safer now in many ways, although there are some arguments that they become less safe in some significant kind of, you know, tail risk ways. But in many ways, you know, our exposure to germs and disease, our exposure to air pollution, just the safety of our machines and our vehicles, all of these things, we’ve actually gotten a lot safer in many ways. So I’m not against safety, I’m very much in favor of safety. I just think there’s a trade-off in how we create it. And then the third major hypothesis, and maybe the one that is closest to the hearts of Ink & Switch, is the way we fund, organize and manage research. We have lost certain ways of doing this, in particular, it’s been a significant decline of corporate research and corporate R&D labs. At the same time, concurrent with that, there’s been a kind of centralization and bureaucratization of funding for science and research, especially in a small number of large and bureaucratic government agencies, and I think there’s a good case to be made that we don’t have ways of funding the real kind of. Contrarian maverick breakthrough ideas anymore. And that also closely related to this, that we don’t have great ways of funding very uncertain long term research that can’t prove itself with very predictable or short-term results, but, you know, is actually the kind of thing that makes long-term fundamental breakthroughs. And so looking at how we organize and manage and especially get resources to fund different types of research and development, I think is an important place that we should look at for countering stagnation. So those are my three big hypotheses. 1, culture, 2, regulation of bureaucracy, 3, funding organization and management. 00:35:23 - Speaker 2: There was so much in there, I’m trying to figure out where to start on the response. You touched on many things, I think are very interesting safety is versus like anti-fragile FDA approval is the thing I’ve been involved in in some of my advocacy work, funding research is obviously a huge one, and they can switch in kind of broader independent research world, but actually I want, if I can respond to something at the very beginning there, he talked about the potential change in attitudes about kind of progress and maybe technology and maybe capitalism is kind of a piece of that as well. And you know, I agree with you that if you of some of these mechanisms that have brought us so many great advancements, I think that is a problem both for progress and humanity. But I also wonder if in that time range you were talking about that I don’t know, 1960s, 1970s counterculture, people thinking about the environment, a lot happened in there to make people maybe have almost a reality check against the maybe more uns the word for it, unchecked, kind of just positivism of science and technology and capitalism and the modern world’s all good. And we saw that nuclear, which as you said was this great big hope for the future of clean energy, we had these horrible meltdowns were so deeply traumatic to the individual countries where they happen. Maybe there’s something like discovering the link between cigarettes and cancer and that for many, many decades, generations really, these huge corporate interests had been basically pushing this addictive drug that turned out to be quite deadly. Obviously the environmental stuff, rainforest deforestation and shrinking ecosystems and all that sort of thing and. Yeah, that basically it was sort of reasonable to have a bit of a, wait a minute, maybe we should think about some of the downsides of some of the progress, technological progress or growth in capitalism that we experience. Now maybe the place where I land on that is having a little bit of a reality check, maybe was a good thing or is a good thing, you know, you don’t throw out the baby with the bathwater. 00:37:19 - Speaker 1: Yeah, I think a major and significant factor actually was the World Wars. So if you read what people were saying and thinking pre-World War One, the excitement and enthusiasm for progress, and it wasn’t just technical and economic progress, it was scientific progress and it was in many ways moral and social progress that people saw. And the Enlightenment era was focused on all of those. And so, you know, people saw the and were hoping for, we’re looking ahead towards the perfection of morals and of society, just as we would perfect science and technology. And there was a belief and a hope that the new prosperity created by industry, the connections created by communications and transportation. The interlocking of peoples and economies created by trade, that all of this was leading to a grand new era of world peace, and perhaps even that war was a thing of the past. And the world wars completely shattered that illusion. They were, I believe, the most destructive wars in history, um, certainly they were enormous, highly destructive wars, and of course they were made more destructive through technology. You know, in World War One, we had chemical weapons, we have poison gas, right? We had the automatic guns, we had towards the end of the war, I think the tank. 00:38:44 - Speaker 2: One really powerful way to get your head around how shocking that was, the role of technology in essentially killing people in mass numbers is there’s this excellent history podcast called Hardcore History, and they had a series, I think it was like a 6 or 8 hour series on World War One, particularly the beginning of it and some of those first battles, and you know, at the start of that war, I don’t know, they have like French cavalry. Riding into battle with their blue jackets and their big puffy hats and their sabers on their side, and then you look at these battles where they pull out these new weapons that have been developed over the course of the previous few decades, and they’re able to just kill in just such efficient and brutal ways and it was just so shocking that war just took on a whole other meaning and I Listen to that whole series just as I first moved to Germany, which is of course a place that has very deep scars, cultural and otherwise from both of the World Wars and yeah, it was a really powerful thing and for me, even I tend towards techno optimism. I think I tend towards that like technology is unbalances for the good, but then listening to these kind of contemporary descriptions of the destructive power of the technology of that time. Again, it’s kind of a reality check. 00:39:59 - Speaker 1: Yeah, and then World War II, of course, was even worse. I mean, you know, World War 2 was the wizard’s war. If people could catch a glimpse of the role of technology in war in World War 1, it was very obvious by World War 2, right? I mean, we had planes and, you know, bombing runs and radar and and then to wrap it all up, the atomic bomb. And I think that when we think about people’s fears about nuclear technology and nuclear power and energy, I’m sure that a significant amount of it was the association with nuclear war. 00:40:31 - Speaker 2: Yeah, I’m pretty sure in a film if they ever want to give you the feeling of, I don’t know, technology’s gone too far, society’s gone awry, I feel like there’s a little montage of this in the Fifth Element, great little sci-fi movie from some years back where they showed that mushroom cloud, that is the icon for we went wrong somewhere and yeah, technology was a mistake, basically. Yeah. 00:40:54 - Speaker 1: So I think the World Wars were very significant in the psyche of the world overall, especially the West. But at the same time, I think that events affect people’s views of themselves in the world, but they don’t determine those views. There’s always a question of interpretation. And so, for reasons that I’m not yet clear enough on. To talk about them, people interpreted the wars in the aftermath in a particular way and in a way that caused many people to turn against technology as such, and in the phrase that you used to throw the baby out with the bathwater and to, you know, rather than saying, Well, we have put a lot of effort into creating these technologies that have made us very powerful, and we haven’t put enough effort into creating defensive technologies or creating safety technologies or Instead of just saying, well, our attention and effort has been misplaced, let’s refocus our efforts so that we make sure that progress serves mankind and not destroys it. I think a number of people turned to a particular kind of counter-enlightenment sort of romantic notion that had really been around for a long time. Had always been around in some form, a kind of a back to nature, you know, very Roussoy and sort of down to technology, back to nature, and let’s just live simpler, quiet lives rather than trying to sort of move forward and make everything better all the time the noble savage. Yeah, exactly. 00:42:22 - Speaker 3: Yeah, that’s an interesting angle in terms of the World Wars causing perceptions to be negative on progress. The people being negative on progress is interesting, because I think it’s kind of both a cause and an effect. It’s a cause for the reason that you just described, but I think something also went wrong around. The 70s in terms of how well the system was working for a lot of people. And so to some extent you had people more or less rationally saying, this isn’t going well for me, I don’t want to sign up for even more of it. And this connects to a broader theme I have around our social technology. And I keep using that phrase, to me, that means the systems, the governments, the organizations, the norms, the patterns of behavior that we have that determine how we operate day to day. It feels like that technology is becoming a worse and worse fit for purpose in the sense that a, it’s sort of Decaying, it’s becoming bloated and it’s losing the plot, but also the world is changing a lot, especially with information technology, and our social technologies largely haven’t caught up. So this is why I keep coming back to this space as being a really important frontier. We need better ways to organize and motivate our work as a better fit for our modern world. And I’m pretty optimistic that if we’re able to make progress in that domain, it will in turn facilitate progress in other areas like people feeling that the system is working better for them and also areas like funding more impactful research. 00:43:37 - Speaker 1: Yeah, it’s definitely true. I think that they’re reinforcing cycles in this, as with many things, I think in society, where the more you value progress and honor it, the more of it you get, and then the more people can see that it’s valuable. Conversely, the more that you are fearful of progress and try to block it, the more you get technological stagnation, which then leads to people saying, well, what has technology done for us lately? You know, I don’t really see how technology is making my life better, so maybe it’s not even a thing to bother with or invest in. It takes some cultural leadership with vision to break out of cycles like that. It takes somebody who can see beyond the recent past and see a different type of future other than what we’ve had to take things in either a positive or a negative direction. 00:44:27 - Speaker 3: Yeah, and I think there’s an opportunity both for people to innovate within the system and to help create new systems. So as an example of the former, I would probably give Elon Musk, you know, he’s basically operating with the parameters of existing governments and organizations and Our model for capitalism, he’s like, I’m going to Mars. It’s kind of a mess to get there because of all this weird bureaucracy, but I’m doing it anyways, you know, good for him. And I think we also need stuff like Routes of Progress and ink and switch where it’s like, OK, let’s try to change the game a little bit here and rearrange the pieces. And I hope we can encourage people to operate on both fronts. 00:44:58 - Speaker 1: Absolutely. 00:44:59 - Speaker 2: Role models is another thing I think I would like to see more of and Jason, you referenced the celebrating achievements and yeah, the tickertape parades for Lindenberg when he crossed the Atlantic, celebrations of scientists that contributed to vaccines and things like that. And I don’t know if it’s an effect of kind of our TV oriented culture or something else, but when you look at the role models that people are likely to just the famous people, people are likely to name or people that kids are likely to say, I want to be like this person when I grow up. You know, they play sports, they’re actors, they’re maybe YouTubers nowadays that we aspire to be maybe political leaders and to some degree, there is, yeah, the kind of tech world, folks, the Bill Gates and Steve Jobs and so on. But maybe we don’t have enough celebration of, and again it becomes a cycle, either a virtuous or non-virtuous cycle that if you celebrate the people who do these great achievements, and then people look at that and think, I want to be like that, I want to do what they do, and then you get more of those people. 00:45:59 - Speaker 1: Yeah, absolutely. I do think that is part of the cycle, and yeah, in one sense, one of the biggest things that Elon Musk has contributed to the world is just people look up to him as a role model of like, wow, here’s somebody who’s defining really ambitious technological visions for the future and then going after them full throttle. And I think there’s a lot of people who will come in his wake and be inspired by that, him and others like him who are doing things like that. 00:46:26 - Speaker 3: I think that this idea of role models is super important because so much of human behavior and action is basically imitation, and so much of what we do is influenced by who we just basically happen to be around. And so it sounds kind of weird, but you can make really different stuff happen just by putting different people together. And this is why one of the frontiers of social technology that I’m so bullish on is different types of organizations and replacements largely for what was previously the university. Which are basically an elaborate mechanism for getting a bunch of weird people in the same hall, and there’s all kinds of apparatuses happening around that, but that’s the core engine of it. And I’m excited to see people exploring new models that try to get that same core dynamic, but that leverage the internet so that the routes of progress community would be one of those, for example. I think there’s just so much more to do there, and I’m pretty optimistic that we’ll figure out some cool stuff. So a lot of work to do here. Jason, is there anything in particular that you’re looking forward to working on next or that you are looking for help on going forward? 00:47:20 - Speaker 1: Let’s see, so a couple of projects that are big for me right now. So one is over the summer, I created a high school program in the history of technology. We ran it initially as a summer program and it’s now being incorporated into the history curriculum. Of a high school, private high school called the Academy of Thought and Industry, and I’m continuing to do some curriculum development for them and really excited about how that’s gonna turn out. I think high school is a great time to begin learning about the detailed history of technology and how it’s improved everybody’s lives. The other somewhat longer term project is that I am working on a book. So I’m gonna take the writing that I’ve been doing at the Roots of Progress and the kinds of stories that I tell there about the development of technology and how it changed the world and I’m gonna be putting it. Together into something a little more long form and comprehensive, so that is kind of my main focus right now. Can’t say at this point how far out it is. I’ve still got a lot of research to do, but that’s the biggest driving thing, you know, for me right now and the thing I’m most excited about. 00:48:26 - Speaker 2: I’m really excited about that one too, not least of which because I think a book makes a field or a movement more tangible in some way, but also because you were nice enough to give me a peek at the list of chapters and yeah, I’m even with all of the reading I’ve done of your material, I think having together in this long form format will be, well, something I’m really looking forward to. Well, it may be a fun place to end. I think an interest that Jason and I both share is jet travel and particularly supersonic jets, which had an interesting story here. I think just recently this company Boom has been out doing kind of big product rollouts to announce their basically prototype of their supersonic jet, but I got really interested in this when I read the biography of one of the main, what you call it product managers, maybe the lead of the team that worked on the 747. The 747 is basically the plane that defined the modern airplane. When you see planes designed before that, they look kind of old timey, and the 747 and that have come after it share kind of the same rough body shape and the same style of interior and that sort of thing. So it really ushered in this new era of air travel, but one of the things that’s powerful to me about reading this book, both because I’m a. person and I like hearing the inside story about how the stuff evolved, but you realize it was just a guy, very smart guy, and he had some really good predictions about the future and what these technologies might enable for travel, but you saw, again coming back to that theme of progress is a thing we can decide to do and work towards as individuals. He had a vision for more wide travel. He saw the technology could make it possible. He got Himself in the position to work on that project and made it happen and basically ushered in this modern era of travel, which, putting aside the last year of relative lockdown has been an absolute golden age where essentially most people have the ability to get on a plane in a major city and go to almost any other city in the world for a relatively affordable price, which is a really amazing breakthrough when you think of it. But we also thought at that same time that the 747 was being developed or the industry feeling was supersonic was the future. And so at the same time they were sort of designing and developing the 747 and some of the related technologies, there was also the development of what would eventually become probably the Concorde is the best known of the supersonic technologies, but that actually turned out to be a dead end or had this eventual abandon. where essentially a combination of the air pollution from the sonic boom, the fuel cost, and a few other factors meant that even though we have this technology that would allow you to fly, say from Paris to New York in just a few hours compared to the usual 6 to 8 hours it takes us across the Atlantic, eventually we shut all that down. And now there’s a new company that’s working on it saying basically some things have changed, some technologies have changed. We can do something different, but I find that story or that evolution to be an interesting example of progress as first of all, something that individuals drive and decide to do. Obviously in groups and through mechanisms like capitalism and government funding and all sorts of other, all those social technologies that Mark talked about, but ultimately it is just people deciding this thing they want to do. But also this path of you. About the revolutions that we have, we had a revolution in air travel, but then we also thought there would be a similar or a next step change in travel based on supersonic, and that actually didn’t turn out to work out, or at least we stepped away from it. And maybe we’re coming back to it now, maybe we will be able to make it across the United States or across the Atlantic in just a few hours, but that remains to be seen. But it was exciting to me to see that banner picked up again. 00:52:16 - Speaker 1: Yeah, absolutely. I mean, the speed of passenger aircraft over time is one of the clearest graphs you can look at that just sort of shows the stagnation of the last 50 years, right? It was going up and up and up, and then it actually went up to supersonic, and then it went down. We actually regressed, right? Forget about stagnation. 00:52:37 - Speaker 3: This is actual regress, especially if you count the time in airport security lines, which is increased significantly. 00:52:42 - Speaker 2: Yeah, absolutely, which ties back to the safety emphasis topic. 00:52:45 - Speaker 1: And the regress in passenger airplanes is not unlike and in fact came around the same time as the regress in space travel, right? We used to be able to go to the moon, and then it right at a certain point, we didn’t even have the Saturn 5 rocket anymore, and our space capacity had actually regressed. And in fact, there’s an argument to be made that you can chalk both of them up to very similar causes. Both supersonic passenger travel and the space race were pursued primarily as government projects for government glory, I mean, for lack of a better word, they were put out there for national prestige and to show off technological capability. And they weren’t set up to be economically sustainable, right? And that was a real problem with Concord, wasn’t making enough money. So I think part of the lesson of these things is that big showy government projects can temporarily push the frontier forward, maybe much faster or farther and earlier than it otherwise would have. And maybe that has some good effects, but they can also set areas up for regress and stagnation for decades. The way to make something actually long term sustainable is to give it a sustainable economic model, which means a profit model. And so I’m excited that both supersonic and space travel are coming back as private efforts from for-profit companies that are setting up sustainable economic models to actually make them profitable, make them pay for themselves in the long term. That’s how they will stick around and how they’ll grow. 00:54:18 - Speaker 2: So Jason, given everything we’ve talked about, do you find yourself at this moment optimistic, pessimistic, or somewhere in between about progress? 00:54:27 - Speaker 1: Well, I think it’s important to distinguish between two types of optimism, and I’ve used the terms descriptive optimism and prescriptive optimism. So descriptively, you can predict what you think is going to happen, or, you know, whether we’re on the right track, whether we’re on a path for good or bad outcomes. And I’m somewhat ambivalent, frankly, at that. I think part of me wants to be optimistic or is optimistic. I think there’s a lot of good things going forward, you know, the vaccine efforts against COVID are just like a great example of what we can do when the best of our science and technology comes forward to. a major problem. For people who don’t know the history of vaccine development, developing a vaccine in like a year or less than a year is amazing and basically unprecedented. Generally, vaccine development is something that takes decades, and so this really shows how far some of our technologies have come and what we can do. To use a cliche when we put our minds to it and put our efforts into it and our resources. But you know, there’s a lot of things to make one pessimistic as well. I mean, the US government’s response to COVID has been mostly incompetent. I think there is a lot of buildup of bureaucratic craft, a lot of our social technologies, to use Mark’s term, are not in such a great state. And so I think we’ve got a lot of work to do and in some ways, you know, have slid backwards. But I think it’s important to distinguish that kind of prescriptive like descriptive rather, are we on the right track from the prescriptive optimism or pessimism of what should we do about it? And prescriptively, I am always and ever an optimist. I think no matter how bad things are looking. The only thing we can do is to step up, bring our best efforts to the game, and, you know, even if we’re on a bad path to snatch victory from the jaws of defeat. I think that the future is not determined. I think that it is up to us, and I think that we should always believe fundamentally in the ability of human intelligence when properly applied to solve problems and to make the world better. So, descriptively, I’m sometimes an optimist and sometimes a pessimist, and it’s very case dependent. But what I’m not and will never be is defeatist, and I think there’s a lot of defeatism out there, you know, the notion that combining perhaps a descriptive pessimism with a prescriptive pessimism that essentially tells people to give up, or to scale back our ambitions or maybe even to deliberately regress to a safer or, you know, more comfortable world. So prescriptively, I’m always an optimist. Forward, you know, let’s confront the problems, no matter the odds, and let’s do our best to make the future better. 00:57:01 - Speaker 2: Can’t think of a better place to end than there. Yeah, right on. If any of our listeners out there have feedback, feel free to reach out to us at @museapphq on Twitter or via email, hello at museapp.com. We always love to hear your comments and ideas for future episodes. Jason, thanks for inspiring those of us who are working on building the future, and I’m looking forward to reading the book. 00:57:24 - Speaker 1: Absolutely, thank you for building the future and thanks for having us was a great conversation.
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: Digital tools which were supposed to give us a creative canvas that was more flexible, that was easier to use, actually constrained us quite a bit because as you said, I almost had to decide what’s going to be the final format. What is the output going to look like before I actually know what the output is going to look like, and I have to make this decision upstream of working on something. 00:00:26 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for thought on iPad, but this podcast isn’t about Muse the product, it’s about Muse the company and the small team behind it. I’m Adam Wiggins here today with Mark McGranaghan. Hey, Adam. My guest and Laura Le Comf. Hey Adam. We’re here entering the holidays, and I’m curious to know what you both are planning to do with your holiday break. It’s a little different this year around. For me, the winter solstice, which I think in 2020 is on the December 21st, it can be a different day. But that’s one of my personal favorites to celebrate both because it’s not connected to any particular culture, but also because living now as I do in Northern Europe, where it gets very dark and cold, it’s a nice thing to celebrate when the days are getting longer. And Laura, what do you do in the holidays? 00:01:19 - Speaker 1: I usually have a very big dinner. I’m half French, half Algerian, and I guess in Algerian culture, the biggest the number of people around the table, the better the dinner. But obviously this year is going to be a little bit different, so it’s going to be small, probably just with my parents. The one thing that’s not going to change is that we’re going to have a mix of like French, European traditional Christmas food like turkey and stuff like that, and Algerian food as well, like couscous and meshwe and other little Algerian cakes and things like this. So yeah, just eating a lot with my family. 00:01:58 - Speaker 2: Well, that description made me hungry. And maybe you could tell us a little about your background and about Nes Labs. 00:02:05 - Speaker 1: Sure. I started my career working at Google first in London and then in San Francisco, and my last role there, I was working on the digital health team, where I was looking after the marketing and partnerships for products that were helping people being healthier, more productive, around self-care, fitness, all of. These kinds of verticals, and I left about 3 years ago. I’ve had a few stints trying to start different startups that didn’t work out for lots of different reasons, and I’m currently working on NetS Labs, which is a website with a blog and a newsletter and a private community that is for knowledge workers to be more Creative and productive while taking care of their mental health. And most of the content on the website is based on what I’ve been learning in the past two years when I basically decided to go back to university to study neuroscience in 2018, and I’ve been writing about everything I was learning and trying to apply it to creativity and productivity on my blog. 00:03:11 - Speaker 2: I feel like many of my favorite, you know, YouTubers or podcasters or whatever who are talking about, you know, it’s called productivity generally, but maybe it’s about building healthy habits and how to be focused and that sort of thing are people who are in some kind of higher education and knows something about that environment or working to get a master thesis or a PhD or whatever that has you more reflective maybe about sort of the meta element of how do I do this better. 00:03:37 - Speaker 1: Yeah, absolutely. I call it mindful productivity because both at Google while I was working on startups and as a student, I actually experienced burnout a few times and I think there’s so much productivity advice out there that is really about getting stuff done. There’s very little that is about just asking yourself, should I really be doing this thing? Am I the right person to do it? Is there someone else who would actually be better to do this thing? And also just kind of checking in and asking yourself, how am I doing right now? How’s my mental health. So this is kind of what I write about as well because I think these are the basic questions you need to ask yourself if you want to do good work and find it enjoyable. 00:04:20 - Speaker 3: Yeah, I think there’s an interesting general dynamic here where Adam, you mentioned, when people are at a university, it seems like there might be more fruitful information about how to do something. I think there’s a general pattern where, OK, you’re a beginner, then you’re actively learning to become an expert, then you’re an expert, and then you’re teaching new beginners. I think steps 2 and 4 are the most fruitful, because in the case of step 2, you’ve just discovered it yourself and it’s kind of fresh in your mind. It’s not so systematized, you kind of don’t even know how. You know all the stuff. And when you’re actively teaching beginners, you have to kind of relive that process of, OK, what are the steps that you need to take to go from being a beginner to being an expert. This is something we’ve mentioned on the podcast before in the context of teaching hospitals, where often the best medicine and the most advanced techniques come out of these university teaching hospitals, and you think, wait, aren’t there’s just a bunch of like, our doctors here, you know, just learning stuff. Well, in fact, because people are actively learning and actively teaching, that’s where we often see the best results. 00:05:10 - Speaker 1: It’s super interesting what you’re saying because it reminds me of the Dune Kruger effect and if I’m thinking about this curve that you’re describing, for me, if you consider yourself an expert in any topic, there’s something static fixed about it. I’m an expert. I have authority on this topic, whereas the steps 2 and 4 that you describe are the The moments where you realize the extent of everything you don’t know, either because you’re still in the learning phase yourself and you’re like, whoa, I actually know very little about this topic. And then when you start teaching, you realize thanks to the questions you get from students that maybe you’re one of the more knowledgeable people about the topic, but you’re certainly not an expert if there’s such a thing as an expert. So I find that really interesting. 00:06:01 - Speaker 2: I think I personally find learning from someone who has sort of just learned something a lot more effective because they, as Mark says, have what it’s like to have the beginner mindset. They still remember that, that’s still in their mind, but they have the knowledge now. They’ve crossed that threshold of enlightenment, whatever you want to call that, and so they can maybe help you come there better than a like a seasoned expert who’s been doing it so long they don’t even think about it. They take it for granted. 00:06:27 - Speaker 1: That’s definitely an issue with some university professors who have been teaching a topic for so long that they seem kind of disconnected from the reality of learning the topic as a beginner, and I’ve had that several times. I think probably both of you, everyone has had that kind of brilliant, super smart teacher, very knowledgeable, who are pretty bad at actual teaching. 00:06:55 - Speaker 2: Yeah, being an expert and being able to teach are two completely different things. You sort of need both of them to convey a skill or a knowledge area well. Yeah, I think for myself, the kind of, I don’t know what you want to call productivity, self awareness, or tuning my mental machine and processes, I actually drew a lot of that from being in the startup world and in particular when I had management duties, when I had teams and particularly bigger teams depending on me because then my whole job and any The manager’s whole job is to make the team effective and so you are thinking about both the practical things of, OK, what’s the to do list, how do we line this up, how do we match up time and budget, those kinds of things, but there’s also exactly what you just mentioned, which is the mental health, how are people doing? Where are their emotions, what are they excited about, what are they dreading? You know, what are their aspirations, and a good manager is one who also covers that side of things and tries to make the team not just productive but also happy and healthy, at least within the structure of, you know, what makes sense within an organization. And once I’d done that for others or for sort of a team as an aggregate entity, I found myself a lot more aware of my own needs, not only again those practical things of time and to do this, but really that, you know, the emotional. Side and the what motivates me and why do I feel ground down, why do I feel burned out on this particular thing wait I thought this project was something I was supposed to be excited about. Why do I not feel motivated and trying to maybe prior to going through the managerial kind of path, I would be more likely to just kind of ignore it and push on through. And now I feel like, no, no, I want to dig in and understand my own psyche a little bit so that I, you know, in the end can be more productive, but also just be happier and have a nicer life. 00:08:43 - Speaker 1: Yeah, it boils down a lot to getting rid of some of the shame that we have sometimes when it comes to managing projects and being productive and work in general. You mentioned working on something and not feeling motivated anymore, and I think a lot of the shame we have internalized because of the way we’ve been educated in traditional school is to Feel bad as a person, think that it’s you doing something wrong, if your motivation is gone, if you’re not feeling excited about a project anymore, when really there’s nothing bad or negative about it. It’s just a piece of information about how you’re feeling right now that can be very helpful to almost debug the situation. And try and figure out, should you keep on working on this, or maybe should you change the way you’re working on this? Should you get some help from someone else? Should you upskill because this thing is too hard for you and just posing and asking yourself these questions instead of burying the problem because you feel like acknowledging the fact that you’re struggling means that you’re just not competent. 00:09:52 - Speaker 2: Yeah, you could even dig a little deeper on that and ask why we are so fetishizing about productivity and you know, for myself, I like to make things and I like to get stuff done and I do feel good about that, but you can take it to an extreme where I think we want to make everyday productive even if that’s a holiday or a weekend or something like that. We have some concept of how to spend even time off productively and I think another. An important journey for myself in recent years has been learning to really do nothing or have unproductive days and think those can be worthwhile too, that productivity is not the only benchmark for worthwhile use of time. 00:10:30 - Speaker 1: Totally, I was talking about it with a friend yesterday, and he was telling me, I know I’m very close to burning out because lately, when I read a book and I’m not taking notes, I feel like I’m not doing it right. And I told him, yeah, I agree. This is bad. This is really bad. You need to take a break. 00:10:52 - Speaker 2: Yeah, yeah. And the podcast and he’s working on a way to make more effective in terms of retaining and that sort of thing. And I was raising this question of, well, sometimes I don’t really care about the retaining the knowledge. I just enjoy the process of reading it, even if it’s a nonfiction book, where in theory, its purpose is to communicate information to me. But sometimes I just want to enjoy it and I don’t necessarily want to, you know, type everything I learned to do an on key flashcard. And that leads you into the whole thing about, well, to what degree do we consume information for fun and sort of enjoyment versus because we want to achieve something, and I think those things are often very tangled up for especially for knowledge worker, creative professional type people where we enjoy reading and learning and consuming information. And sometimes that has a very specific purpose, something in our work or our personal life, and other times it’s just for enjoyment. 00:11:47 - Speaker 1: And especially now that the work and life of knowledge workers has become more and more public, whether on Twitter or other websites, there can be sometimes a bit of an unhealthy competition in terms of how many books have you read this year, how many notes do you have in your note taking system, how many blog posts have you published this year, which I think it’s not necessarily good either for people’s mental health, but even in terms of creativity, as you mentioned, having these days where you do nothing, you just recharge your relax are super important as well. And unfortunately, lots of people struggle with this because they can’t stay idle. They feel like I need to do something with my time. I’m not producing, I’m not creating, therefore, I’m wasting my time, which is very dangerous as the mindset. 00:12:38 - Speaker 2: The word idle reminds me of a book I read some years back, almost a manifesto called How to Be Idle. Basically, it’s a whole long book that is both first of all, arguing the case for why this is a worthwhile way to spend time and then has a detailed list of ways to do nothing while seeming to do something, so they have, I don’t know, fishing and taking a walk and smoking, and they talk about many people, you know, being sick as in getting a cold, you know, common cold or being hungover as oh no, now my day is wasted or my couple of days wasted because I just have to stay home in bed and watch TV. Or whatever, and the author basically describes a mental mind shift of actually be glad for this day where you’re under your normal capacity because you can spend it in a different way. Maybe you can spend it with people that you care about, or you can spend it doing something that’s different from your normal thing and that can be worthwhile. That was in many ways a tough book for me to read because I think I do come from that, yeah, productivity is everything, mindset somehow, but I also think it was quite good for me for that reason. 00:13:45 - Speaker 1: It’s funny that you’re mentioning smoking because I quit smoking cigarettes. And at first, the first few days, I was incredibly tired, incredibly tired, and I didn’t know where that came from. And I realized afterwards that all of my breaks during the day were smoke breaks. 00:14:04 - Speaker 2: Smoke breaks work well. 00:14:06 - Speaker 1: Yeah, exactly. I was just going out, having a little cigarette and doing nothing, just like staring in front of me doing nothing, not thinking, and then coming back to my laptop and doing work. And when I cut these out, I was basically working nonstop. So I had to create the habit of just getting up, stretching, doing something else, which to this day still doesn’t feel as natural. I still feel like I’m forcing it, but I know that I need it because if not, at the end of the day, I’m completely dead. 00:14:35 - Speaker 2: So our topic today is an article you wrote on the Nest Labs website that I was quite drawn to, called Thinking in Maps. I’ll link that in the show notes, of course, but maybe you can tell the listeners what that’s about. 00:14:48 - Speaker 1: I’m so glad you picked this article because it’s probably my favorite, or at least one of my favorites that I wrote this year. And the reason why I wrote it is because every time I was telling people about connecting ideas, using symbols, crafting maps that are looking at different ideas, most people were replying to me and telling me, oh yeah, I know, mind maps. And every time I had to explain that no mind maps were just a tiny subset. Of the way we can think in maps, and I decided to do a little bit more research. It started as an article where I just wanted to review all of the different ways you could think in maps, but by doing research, I realized that Human beings have started thinking in maths way earlier than what I realized, thousands of years ago, and I thought that was fascinating. So the article is basically a review of the history of thinking in maps from the Lasco caves, that’s like 14,000 before Christ, something like this years ago, that’s like a long time ago, up until today. That’s what the article is about. 00:15:56 - Speaker 2: Yeah, I always love the historical example because those of us who work in digital tools of some kind, which include all of us at various points in our career here, or the three of us at various points in our career, tend to vary, I think box it into exactly how the devices or the tools that we have today work. So going back and looking at these older very different cultural contexts, very different, even writing implements and things like that. But I think the fundamentals of the human mind, because of the pace of evolution and biology, that’s gonna be the same. So you change all the other variables, but the mind is the same, and then that can be very enlightening. 00:16:35 - Speaker 1: This is what’s fascinating about looking at the historical examples as well, is that even thousands of years after these maps were created, even if you don’t speak the language that they were speaking at the time, even if you don’t understand every single symbol that they’re using, you still instinctively. roughly what’s going on, and I find that absolutely fascinating compared to text in front of you in a different language and you don’t read it or speak it, you won’t understand what it is about, but a map with symbols, it kind of just defies culture, defies time. Everyone will still roughly understand what’s going on. 00:17:17 - Speaker 2: And you had some nice examples in there that I was familiar with like Leonardo da Vinci, obviously is pretty famous for the visual thinking stuff he does in his notebooks, more recent, someone like Walt Disney or this fellow Cassor Doris, and I found that quite right, Roman fellow hadn’t seen that one before. Is there one on this list that you think is a good example or you personally found compelling? 00:17:38 - Speaker 1: The most fascinating one for me is the one that is one of the oldest ones that we’ve seen that’s from the Bible where someone It is Cassidorris, I think, actually, who took the stories from the Bible and decided to visually draw the different storylines and create this map of what’s going on in the Bible by connecting the different stories. And again, I don’t need to speak the language. I don’t need to speak Latin or anything. I look at it and I understand that each bubble is for a con. or a story and that they’re connected together with lines. And this concept of having ideas in bubbles and connecting them together with lines, the fact that I think it was created in like 600 or something, this, this one, that’s such a long time ago, someone drew this, and I can look at it in 2020 and feel like, yeah, I know what’s going on here. It is absolutely fascinating. 00:18:36 - Speaker 2: Mark, what’s your take on thinking and maps? 00:18:39 - Speaker 3: I think it’s very interesting and very important, and I also appreciate the historical angle. I’ve often argued with respect to HCI type topics that there’s a lot of embedded knowledge in very old practices. These maps that we’re looking at here, these are maps that people created when it was extraordinarily expensive to create a map and or that were preserved over thousands of years where it’s extremely hard to do that, and or where the technique was repeated again and again. So there’s Something worthwhile are working here, even if we don’t initially understand, there’s definitely something important to know. And I also think it’s useful because we often get some blinders working in digital tools because it’s actually a very limited medium, you know, the screen is very small, it’s low resolution, and so on. And so you can often learn or get ideas for new techniques that become applicable as computers get more advanced if you go back and study these old examples. So definitely worthwhile. 00:19:27 - Speaker 2: One thing that comes to mind for me is I think the word map for I think most English speakers leads you to thinking about, I guess what we call a geographical or a cartographical map, that is to say what you see when you type maps. Google.com into a browser, but one, I think it’s interesting. this is actually we think of it as being a very kind of literal map, I guess, but it’s actually quite abstract. First of all, you know, it’s sort of a projection, right? Taking the surface of the globe and the terrain and all that kind of stuff and flattening it down onto this like two dimensional thing. But secondly, putting aside, I don’t know, satellite photos or going up in a plane, we don’t see the world this way, but it seems to be quite natural for many or even most people to look at this kind of bird’s eye overhead map. It’s actually a pretty abstraction of how things are laid out and then be able to use that to navigate a complex place which is really. Quite interesting to me. 00:20:21 - Speaker 3: Yeah, it’s funny if you look at old maps, they tend to basically just be of coastlines and rivers, cause that was essentially the only way you could get around was on water. It was extraordinarily difficult to travel any distance over land, so you basically had to use the water. So the maps are just basically all these exploded coastlines and rivers, and they don’t look anything like our normal maps, but you have very high detail on all the ports and harbors, which is what you actually care about. 00:20:42 - Speaker 1: And if you go back in time, even further, the oldest maps were not even trying to capture anything real when it comes to geography. They were being used as a message to position a particular culture in the world. So if you look at one of the oldest maps ever found that it’s in good condition that was created by the Babylonians. It’s a circle that looks like a sun, and Babylon is here in the middle. And then everything else is in the shadows. What’s really interesting here is that we know from historical evidence that the Babylonians were very, very aware of the. Existence of other cultures outside of their own. So it was a deliberate choice to not include them and to position Babylon as the center of the world. And to your point, Adam, of how all maps are an abstraction. I think what’s dangerous is when we forget that. And nowadays because they feel like most geographical maps feel like they’re closer to reality. They feel more real, they feel more true when really they aren’t more true or more real than the map that the Babylonians create. at the time just gives us that impression because, as you were saying, maybe the coastlines are a little bit more detailed, maybe whatever, maybe it just looks more real, but it isn’t. All maps are just a collection of symbols and all maps are taking a subjective position as to what the world looks like. 00:22:23 - Speaker 3: Yeah, this is the map is not the territory issue, and I think it’s a great point because it’s one that we’re especially susceptible to these days. We do so much work in symbols and abstractions, and we write term papers and emails and we feel like we’re masters of this domain of information and it’s very easy to forget that that’s not in fact reality. 00:22:41 - Speaker 2: Another historical example that I like a lot that also connects to a pseudo geographical map is Alexander von Humboldt, who’s this great, to my mind, great thinker, sort of really changed the scientific world with his, he essentially invented the concept of nature or ecology as we would think about it today. There’s a great book called The Invention of Nature that documents his life, but he has this famous again map, sort of an elevation profile. It’s called the Jimborazzo map. And it’s essentially like a side view cut out of a mountain that shows the different creatures, the different flora and fauna that live at different elevations. And again, this is one of these things where nowadays kind of an elevation map that shows you this kind of information seems, if not obvious, then not too surprising to the kind of ways we’re used to visualizing information, but it was pretty breakthrough at the time. And it was part of what allowed him to first, I think have the insight and then convey that to others, which was, he was comparing the flora and fauna at different elevations on some mountains in South America to some in Europe in the Alps and saw that even though the creatures are different, there’s essentially what we would today call ecological niches, which is not an idea that People just assumed, yeah, you go to a different place, there’s different animals and different creatures, who knows why, that’s just the way the world was made versus seeing this concept of again an ecosystem and ecology and there’s niches within that and different creatures and different plants that fill different needs within an ecosystem and it was largely this now pretty famous sort of side view of a mountain that again helped convey that idea to the world. 00:24:19 - Speaker 1: It’s so interesting. There are two parts to the work he did. The first one is connecting ideas that were seemingly unconnected. So by drawing these different maps, he noticed these different ecosystems. And then the second part you mentioned, which is also fascinating and has been The use case for maps for a very, very long is just as a communication device because it’s visual, especially when a map is really well made and using the right symbols, it can help people understand a concept much quicker than if you were to write a really long book, for example. 00:24:55 - Speaker 2: So that kind of geographical or semi geographical maps. Can you give us some examples of other types of maps? 00:25:03 - Speaker 1: Yeah, so we can also have maps that are focused on connecting abstract ideas rather than real world landmarks. So mind maps, as I mentioned at the beginning, is the one that I think most people are familiar with because the person Tony Buzan who invented them is also an incredible marketer and businessman. And so he did a really great job at promoting his mind maps, but you also have concept maps, radial maps, it’s all sorts of different maps. The one thing that I think all of these more abstract maps, which goal is to connect ideas have in common is again, this idea of using lines or arrows. To connect different nodes, and the main difference between these different maps is what kind of arrows and what kind of nodes. So are the arrows bidirectional or not? Are the nodes overlapping? Can you include several nodes like Russian dolls in the same one, or are you just mapping them out on the canvas without any of them overlapping? And depending on the choices you’re making here, you’ll get different types of mental maps. 00:26:19 - Speaker 3: Yeah, one really interesting example from your article was the Disney map about how he imagined the business working and it’s amazing. See, he literally mapped this out, you know, back before it was ever built, and it’s basically exactly right, like how it all end up feeding back on each other, you know, how the merchandise supports the film, supports the music, supports the theme parks and so on. This one’s also kind of near and dear to my heart because it’s this topic of, you call it an institution, it’s a kind of a complex web of people and properties that all reinforce each other, like another example this would be a university, we aspire for Ink & Switch and it’s surrounding entities to be this, so it’s an interesting example. 00:26:55 - Speaker 1: Yeah, it’s the concept of the flywheel, right? If you manage to have a part of that map that works well, it’s going to feed into the other nodes and if you do your job well. It should just be this virtual cycle where it just keeps on working, and I feel really bad for the creator of this map because it’s not Walt Disney, it’s one of his executives, but no one knows the name of this person and everyone thinks that Walt Disney made the map. So just a thought for the anonymous maker of the Disney map. 00:27:31 - Speaker 2: Thinking of process diagrams or things flowing from one step to the next in the medical field, you have the Krebs cycle, sort of like the way that basically these acids and proteins flow through the body. And I remember my colleague Orion kind of using this as a metaphor when he was doing distributed systems engineering where you have messages being passed around the system and interpreted by different components in the system, and at some point you get really confused trying to hold out of that in your head and you naturally lean to drawing kind of a process diagram, which reminds me a bit of this Disney executive’s map. 00:28:08 - Speaker 1: This is such an important use case, the fact that there are processes that are way too complex to hold in your mind and to really understand in their entirety and maps can really help with that. Just having a canvas where you can lay them out, that allows you to see. how the system works, but also to identify any gaps, any places where really there should be an arrow here, but there’s not, or there are too many arrows going in the right direction and none of them going in the other one. So that’s definitely a use case that’s very helpful. 00:28:46 - Speaker 2: How do you think about the interaction between maps or maybe visual thinking more broadly and symbolic representation. So obviously there’s prose, text, you know, I’ll sit down and journal out paragraphs of text, but also most of these diagrams have text labels in them. They do have symbolic representations, even though there’s these maps or sort of visual thinking layouts. Do they go hand in hand? Are they for people who have maybe different kinds of minds, maybe some people do better with symbolic representation, some do better with more visual? 00:29:20 - Speaker 1: I think you absolutely need symbols for maps, and it really depends on who your audience is, but the only mistake really you can make with symbols is using symbols that you’re the only person to understand. And I see some people doing this, just assuming that the symbols that they’re using, everyone understands. One that’s really fun, I told you I did a workshop about visual thinking. Sketch noting and an example that came up in the conversation was the floppy disk, how some people were still using this as a symbol for saving something, and how if you show this to a kid who’s like 15 or 14 years old today, they’ll look at it and they may know because they’ve seen it on computers, that it means saving, but they have completely lost the connection with the physical object that was. The basis for this symbol. So symbols can be extremely helpful, and I think they’re even necessary for maps to make them easier to read and to make them more useful. However, and it’s the case with any powerful tool, it’s really good to always ask yourself, Should I use this one? Is it the right one? Do I really need it? Just being a bit mindful of how we use symbols is quite important when creating maps. 00:30:37 - Speaker 3: Yeah, symbols are very information dense and general purpose, so they think they’re good for labeling the entities and also for labeling the properties of the connections, and the map aspect is, what is the relationship among the entities. So I think they’re very complimentary in that way. 00:30:50 - Speaker 2: Right, so whether you’re talking about a geographical map and you label, here’s the name of this mountain or here’s the name of this lake, you’re naming it or you’re saying what it is, but you’re not showing its relationship similarly with a lot of these diagrams. 00:31:03 - Speaker 3: Yeah, you wouldn’t write the mountain is 100 kilometers north and 20 east of the town. You would just put it there on the map. 00:31:09 - Speaker 2: Well, that question in particular, I think is of interest to the Muse team when we’re designing our product because I think most digital tools, they’re very visual and spatial or they’re text oriented, right, you know, text editors or writing tools or processors, whatever, you can kind of put some images in, but it’s very hard to do, you know, it’s just basically flows top to bottom. You usually try to pick one or the other, and definitely it was a major evolution of our product and we added essentially these little text cards, which is sort of a simple thing. But being able to put in a few sentences of text and then draw an arrow from that to something else, which could be something visual or some more text. And so I think that the mix of them together, different people will use them for different kinds of scenarios and some people maybe tend more towards one and more towards the other, but in the end, I do think mixing them, which I think is a weak point of a lot of technology, but as a potential strength of just pen and paper, is definitely something we can get better out on the digital side, I think. 00:32:08 - Speaker 1: Yeah, that’s what I was going to say about pen and paper. It’s really interesting that we have been using this tool for so long and for the longest time, if you compare the amount of time we’ve been using digital tools compared to pen and paper, we’ve been using pen and paper for much longer. But for a very long time, digital tools which were supposed to make our life easier, to give us a creative comeback. That was more flexible, that was easier to use, actually constrained us quite a bit because as you said, I almost had to decide before creating something, what’s going to be the final format? What’s going, what is the output going to look like before I actually know what the output is going to look like? And I have to make this decision upstream of working on something, which is quite unnatural. And not really helpful when it comes to creativity. So I think any solution that gives us back this freedom of deciding as we go in the creative process, what kind of format we want to use? Do I want to use symbols? Do I want to use images? Do I want to use text here? Do I want to doodle? Do I want to do all of these different things, is something that is much, much needed. 00:33:15 - Speaker 3: Yeah, I think this is super important, and we’ve mentioned on the podcast often that the human thought is inherently multimedia. That’s the way people want to and do think, and it’s important for tools to support that. And again, it’s important to understand the historical context of why tools historically might not have. So for example, with books, until quite recently, it was extraordinarily expensive to add pictures to your books. You had to get an engraver to carve a plate, each one was individually numbered. You know, it’s much harder to press these out and so. And then eventually it got to the point where you could add images to books pretty easily, but now we’re just crossing the same threshold with computers where until relatively recently it was hard to add images and especially video all in the same document. We’re just now being able to do more of that. And so we should be mindful that it’s not an inherent property of reality that you have a text document and an image document like many of our existing computing tools in force. It’s a matter of that’s a sort of historical accident and limitation that we’re now moving beyond, hopefully. 00:34:07 - Speaker 1: And hopefully that’s going to get us closer to being able to really map our thoughts, the way they do happen. I really like this expression you just used how the mind is multimedia because it’s true when you think about something, you kind of follow these different branches of thought, and sometimes you recall an image, sometimes you recall someone’s voice when they told you something during the conversation. Sometimes you recall a Smell and you connect all of these experiences and thoughts and memories in a nonlinear way. And I really hope, and I hope, I know it’s going to happen, but I’m excited about a future where I can capture all of the diversity of, let’s call them formats of memories and thoughts that I have in my mind and capture them onto my digital device so I can work with them. Right on. 00:35:01 - Speaker 2: Maybe that’s a good transition to talking about the sort of the technology and tools that do exist that we do think are interesting on that front. One that comes to mind for me, I think is the web has always been good and especially in the last, I don’t know, 5 to 10 years on this kind of multimedia being able to mix together different formats. Now, obviously the web is, it’s sort of a publishing format. It’s not a place for raw sketchy thoughts, but when you talk about these, for example, von Humboldt and communicating about something through his diagrams in his published works, I think the web has a lot of potential and we’re seeing some Movement there, particularly when you combine it with the data side of things. So I think a great one in that world in the JavaScript world is this D3 library that has all these really interesting, unique and often quite attractive kind of data visualizations that you can do and it’s a nice way to explore expressing some concept. And there’s other kinds of these often more interactive like parametric press. Now all of these require a lot of knowledge, programming specific technical knowledge, and again, it’s more of a communicate to others at scale rather than kind of a more personal level thing, but that’s one area where I think digital technology is not only Starting to catch up to what we could do with good old pen and paper that actually offers new affordances and new ways to visualize things and communicate things that we actually even go beyond what you can do with analog tools. I’d be curious to hear if either you have particular tools or technologies that you think are promising in this area. 00:36:36 - Speaker 1: It’s not an individual tool for thinking in maps. It’s more of a collective one, but I recently, a few months ago discovered this website called Connected Papers, which you probably heard about because it’s absolutely amazing. It basically shows you by just entering the DOI of a specific research paper, it shows you a visual map of all of the papers that or. Connected to this original one that you entered, and the strength of the connection is correlated with how strongly the two research papers are connected. So instead of every time you’re reading a paper, going through the references one by one, checking the paper, reading the abstract, being like, OK, that’s not what I’m looking for, going back and Doing this very tedious work in one click you can have this constellation of papers related to this topic that you’re researching. You can navigate them, you can save them, you can click on each node to see the constellation related to that specific one. It’s fantastic, and the reason why I’m so excited about it is that I think it will also help make it more accessible for non-academically trained researchers to just do research for Just the sake of their own curiosity. 00:37:57 - Speaker 3: Yeah, that’s a good one cause that domain is inherently very networked. The process of science is all about building up this increasingly rich mesh of citations and papers, basically. It also brings to the forefront the issue of projection. This meshes like a zillion dimensions, you can’t actually look at it and forget to pick some subset of it to show and then project it down to 2D and in fact your projection is probably gonna change based on which paper you’re looking at. So the highlights again, the map is not the territory difference. 00:38:24 - Speaker 2: Mark, do you have a favorite technology or product for map-based thinking? 00:38:29 - Speaker 3: Yeah, so I’m always interested in looking at the gravity wells that form, and this is the areas that everyone seems to fall into and converge over time. So one of the more obvious ones is the idea of pinch to zoom on maps. This is so common actually that people are now getting accustomed to it at very early ages. So if you put into YouTube like babies zooming into magazines, you can see these little kids like trying to pinch into physical paper magazines, and of course it doesn’t work, but that’s what they’re used to, it’s a very natural emotion. And we’re seeing that more and more, of course, and uses one example of that. Another more tools for thought oriented example would be the emergence of cards on a canvas as a standard document type. And everyone’s coming at this from a slightly different angle. So Figma’s coming at it, for example, from the angle of product design. There’s some of the notepad type iOS apps that are coming at it more from the example of you start with a page, you add in and now you can add images. And so on. But everyone started, I think, kind of converging around this idea of you can have a canvas and you can put different types of media as well as perhaps handwriting on it and move things around in a free form way. And I think in the same way that text files and folders or directories have become a sort of standard metaphor for computing in the desktop age, I expect that this becomes a sort of standard content type that more and more apps support in a more consistent way. One other example that I’ll mention is I always bring up this theme of video games are at the forefront, eventually a lot of consumer and enterprise computing draws from them. And again, the maps on video games are like super advanced. You have imperfect information, so you tend to discover the map as the game or whatever. Go on and also you have a sort of collaborative information sharing where your teammates are also collecting information and conveying it to you, so you’re trying to build up this collective picture of where your team is and where the others are. And you have all these indicators of where other people might be like off to the edges of your screen, and you have this notion of quasi mode or HUD where you can Instead of either you’re looking at the map or you’re looking at the world, you can have them superimposed on each other, so you might have a translucent map, or to be able to hold down a key to bring up the map very quickly and then let it go. These are all advanced ideas that I suspect we’ll eventually see appear in the world of, for example, these cards on a canvas tools. 00:40:29 - Speaker 2: Earlier mention of pinch to zoom. Mark also reminded me of the iPhone one and what made that such a revelation. I was actually a bit of a skeptic about it, but I think the thing that really made it work was Google Maps and the pinching. So the multi-touch screen obviously had all this potential and I think in retrospect, folks talk about basically being an internet connected multi-touch screen, but I really think without Google Maps it would not have had the same impact. And so there you took a type of map, a type of semi-abstract representation of the world that most people were familiar with, but you put it kind of on this ready device and with this gesture that was so natural somehow, and the two put together to just be this really incredible, incredible device. 00:41:16 - Speaker 3: One other example I’ll mention that I was reminded of by the network of papers example is this class of maps that I would call like relaxation based clustering, and by that I mean you have many, many nodes and you’re in a multidimensional space and you need to figure out how to basically group them together. So I’ve seen this done with Twitter accounts where people pick some valence, it might be political ideology or geographic location or whatever, and then you can Cluster the entities so that they tend to be near people who are similar to them. Of course it’s imperfect cause you’re projecting down to 2D, but you can get a really quick sense of, OK, who are the clusters, who’s in them, which clusters are close, which clusters are far apart. I’ve actually seen this applied to academic papers where you can look at all the clusters of like the economists on Twitter or something, and you see that there’s the cluster for the macro people and a cluster for the micro people, and a cluster for the Austrians or whatever, you know, you see these cool patterns emerge. 00:42:06 - Speaker 1: It’s so interesting. I’ve seen this done where I was included in one of these maps, and they didn’t even seed it with specific portance. It was just seeded with a starter account. So you had this account in the middle, and then it would branch out and have all of their followers and you could see these different groups and For me, it was really interesting because there was kind of a difference between where I thought I was in the Twitter sphere and where I actually was. And I realized that I still had a lot of my past startup life that was showing in terms of people that were following me and that I was following back. And way fewer of the academics or the researchers that I feel like I’m engaging way more with today, but in terms of social graph, that shift actually takes way longer than you think. So that was really interesting for me to see those different bubbles, and I think lots of people who saw the map were also kind of surprised to see where they were on that map versus where they thought they were standing. 00:43:14 - Speaker 3: Interesting, yeah. 00:43:15 - Speaker 2: Uh maps to my anecdotal experience of probably a lot more of my Twitterosphere is an artifact or reflects the history of Hiroku, Silicon Valley, Y combinator, a phase of my life that’s 10 years in the past now. You know, I built up these really strong social connections over time and maybe newer things are more nascent, obviously. And so, yeah, when you actually look at the reality there, it can be surprising. I’d love to hear about both of your personal techniques, how maps of any kind appear in your thinking process, and Laura, maybe you can start us off. 00:43:50 - Speaker 1: Yeah, I use maps a lot. I have paper maps that I use whenever there’s a problem I want to try and solve. It’s just a really good way to close my laptop and get my head down and just try and think about a specific problem space and I take my, you’re not going to see it because it’s a podcast, but I take all of my colored pens. With me and I just draw and try and connect ideas together. Sometimes when I’m on my laptop and I want it to be a bit more organized or something I can use in an easier way later, I use a tool called Staple where I also map ideas this way. I really like using it. And another kind of map I’m trying to use more, which I still haven’t found that useful in terms of connecting ideas together, is my knowledge graph in Rome. I feel like at this point it’s more I can be to me. I like. Looking at it and playing with it, but I still haven’t managed to really produce or create anything new by just looking at this graph or playing with it. More creative for me is definitely pen and paper and just playing with cable. 00:45:01 - Speaker 2: Apel actually was one of our influences from you, so this is by the same folks that do Scrivener, which is a writing tool, but I guess I don’t know, there’s lots of maybe more general audience writing tools like Ulysses or Kraft is what I’m using these days that I really like. But Scrivener is really for not only authors, but I’d say fiction book authors. They have lots and lots of tools that are about organizing chapters and all that kind of thing and so. I assume you’re not necessarily writing fiction stories, but I know their ideation tool, which is another one of Mark’s kind of cards on a canvas kind of style of things, but it is very much about, yeah, understand, get your characters together, figure out your plot lines, do that all in a kind of a loose way that resembles a little bit like moving post-its around that has a lot of the benefits of digital. It’s an old school tool, but a really good one. Mark, how to maps here or not in your thinking. 00:45:53 - Speaker 3: Yeah, so I have this philosophy of idea generation that most of your good ideas come from your sleeping mind. It’s not when you’re actively trying to have a good idea, it’s that you have this background process that’s running. And you need to feed the background process. And the way that you do that is you sort of work over intellectual materials. So one thing you can do is read, one thing you can do is annotate, but another important thing is to sort of arrange and organize. So often what I’ll do when I’m working on a new topic is I’ll bring a bunch of stuff into Muse, for example, I’ll bring in some links, some images, some PDFs, maybe some handwritten notes, and that alone is good. But you can also do the exercise of how do these things relate, what are the connections, what are the different ways to organize? And you’re basically just moving stuff around the screen and putting things next to each other. And at the end, you basically throw that thing away. It’s not necessarily to produce a knowledge map per se. It’s more that when I’ve done that process, OK, that’s another way that I’m building familiarity and connections, and then back in my sleeping minds tonight, that’ll be more for my brain to use to come up with new ideas. 00:46:49 - Speaker 1: That’s very similar to the concepts of focused mode and diffused mode of thinking by Barbara Oakley. I don’t know if you’re familiar with her work, but that’s exactly what she’s explaining that there’s the focus mode where we’re trying very actively in a very specific space to solve. A problem and then this diffuse mode, which is our brain working in the background, whenever you have what we call a shower thought, that’s the diffuse mode of thinking that’s happening where you don’t really feel like you’re trying to solve the problem, but there’s this eureka moment, you find a solution without seemingly even trying. And I absolutely agree with you that it’s so important to balance the two. That’s also why sometimes when you’re trying to solve a problem and you can’t find a solution, it’s good to just step away and go and do something else or do something that activates the more diffuse mode of thinking like doodling, organizing, playing visually with different topics and ideas. Without having the explicit goal of finding a solution, which sounds like what you’re doing when you activate your sleeping brain, as you say, so I really like this. 00:47:58 - Speaker 2: For me, taking a walk is a big one. I want just enough activity and stimulation to keep me occupied, but not so much that the brain’s full capacity is taken. I will say that I think that kind of, yeah, sleep on it or take a walk or, you know, take a shower kind of thing. I think it’s not just, well, OK, can I solve all my problems by sort of not working on it. I think that is a second half to the focus time is when you really load that stuff into your head and you give the sleeping mind, as Mark would say, something to work with, but then you balance that with the non-focused time and that’s potentially the one to punch that can work really well. 00:48:38 - Speaker 1: Yeah, you need both. If you’re focusing for very long and not letting your brain do the job in the background, you’re not going to find a solution, but if you’re giving your brain the space to think about nothing, you don’t have any starting material, you’re not going to get anywhere either. So the focus time is to just try and do your best. To understand the problem as well as possible, and then the diffused time is to let your brain assimilate, connect all of this information and come up with a solution that may not be as obvious as what you would come up with consciously if you’re trying to think in too much of a linear way. 00:49:19 - Speaker 2: Two types of maps that make their appearance in my work. One is timeline, which is maybe similar to a geographic map in that it is at least on one dimension trying to make an abstraction for something in the physical world, in this case, the passage of time. But I find it surprisingly helpful for, there’s obviously like organizing a project or you’re launching a product and you want to put together a little road map of the pieces that lead up to that, you’re taking a trip and you want to make sure everything’s covered. But I find it’s a really focusing thing for when I start to lay out what I’m actually gonna do and what the sequencing needs to be, and what comes before what, and in some cases there are specific calendar marks that I want to hit. I actually find that really helps me get clarity about the meaning or the purpose of the project as a whole and what you realize, for example, you can’t fit everything in, so what needs to stay and what needs to go, or what things can be done kind of more in parallel and what things need to be done sequentially. And so it’s a, again, it’s a very simple kind of abstraction against something real, but for some reason it just really brings things into focus for me. 00:50:25 - Speaker 1: It goes back to what we were talking about a little bit earlier in the conversation, how some processes are too complex to just hold into your mind and in your case, having all of that, either on paper or in news on a tablet or wherever you put it is a way to see those places where you’re trying to cram too much in the places where you have a little bit more space that you didn’t see. So it’s a really good way to augment the way you’re visualizing your work and you think about it in general. 00:50:55 - Speaker 2: The other one I’ll name is uh Affinity Maps, the idea where I think normally you do this post-it notes or index cards or something, but you basically kind of You want to make sense of a space. You can do this in a group, can sometimes be interesting, but you can also do this as an individual, just kind of write down every thought you have on a space or a problem or a project, or what have you, and in no particular order, and then once it’s all down on say on posted notes, you kind of stick them and just put them near each other. Maybe this comes back to the same. We use spatial nearness, you might say in the case of the paper clustering you described, or the geographic map of the mountains near the lake, or some of these D3 visualizations, nearness or the Twitter graph, nearness describes a relationship. And so there’s a similar. with the affinity map here is just a set of ideas that seem to belong together somehow from those patterns emerge and we can kind of zoom out a level maybe in turn what seems like a big jumble of things and actually there’s three big themes here that lets us clarify our thinking as a group or as an individual. 00:52:00 - Speaker 1: This sounds great. 00:52:01 - Speaker 3: I wanna try it. Yeah, Adam, it’s interesting that you mentioned these cause these were two of my go to general purpose tools for engineering management. The first being make the work cues visible because all production work is essentially a series of cues. That’s the universal abstraction, and it’s very important to make work visible if you’re gonna manage it. And the other is the sort of affinity maps where a very general purpose exercise you can do is identify all the things, have people put like pluses and things that are important, and then group them together. You can basically apply that for anything, you know, what should we build retrospecting our past work, how are we feeling? It’s very universal, so good ideas there. 00:52:32 - Speaker 2: Well, before we go, and Laura, I’d be curious to know if there’s anything that you left out of that article or has since you’ve written, you feel like you would add on to it? 00:52:41 - Speaker 1: There’s something I touched upon a little bit towards the end, but I think I want to explore more in the future. All of the different maps that I talk about at the end of the article are tools for individual thinking or once you’re done crafting them, they’re communication tools to communicate whatever ideas you had or connected together with other people. I think maps can also be amazing tools for fostering collective intelligence, and that’s definitely something I want to explore more in the future. 00:53:11 - Speaker 3: Yeah, that’s very interesting. It’s those multiplayer maps as predicted. 00:53:15 - Speaker 2: Augmenting collective intelligence right on brand for us. Well, if any of our listeners out there would like to tell us about how you use maps in your thinking or your communication, or you got other feedback or questions for us, please feel free to reach out at @museapphq on Twitter or through email. Hello at museapp.com. We always really love to hear your comments and ideas for future episodes. And Laura, thanks for this great article, all the writing you’re doing over at NES, and I hope you have lovely holidays and the end of your year. Thanks for having me. All right, see you both later.
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: The entrepreneurial drive or in this case the entrepreneurial drive of feeling agitated, there’s like a problem or a thing that just seems wrong or weird or annoys you and you just can’t stop thinking about it and you look for solutions, but none of them really quite seem to fit. Hello and welcome to Meta Muse. Muse is a tool for thought on iPad. This podcast isn’t about Muse the product, it’s about Muse the company and the small team behind it. I’m Adam Wiggins here today with Mark McGranaghan. Hey, Adam. Well, we’re entering a new year here, and for me, the holidays is a time to reflect and think back on what’s learned. And for me, one of the biggest surprises of 2020 was this podcast. We got started on it. It was, I don’t know, just an idea that we wanted to try and then to my surprise, here we are now 21 episodes later with thousands of listeners and something I really enjoy doing with you every two weeks. Do you have any reflections, Mark, on this epic podcast journey so far? 00:01:07 - Speaker 2: Yeah, it’s been great. I remember when we recorded our first Uh, demo episode, episode zero, if you will. I was using my AirPods in this Airbnb in Arizona, I think, and, uh, it was really fun, and I didn’t, didn’t quite land the first time, but we felt like there was a good spark there. And sure enough, we followed through with it, and over the course of the last 20 or so episodes, we’ve gotten really great reactions from our listeners, and that’s been the most rewarding piece, I think. 00:01:33 - Speaker 1: Yeah, actually, in that same spirit of prototyping we might use for product work, we sort of prototyped the idea we had to do a podcast by recording, I don’t know, 20 minutes I think it was, yeah, in the freezing attic of this Airbnb we were staying in in Sedona, just recording into the voice memo apps on our phones, and I kind of just edited together with Ferri, which is this little audio editor for the iPad, and even I think found some stock music and just shoved it in there just to get the feel, and then we listened to it and said, OK, does this. And the audio quality wasn’t good, it wasn’t long enough, it wasn’t, you know, we were still finding our groove, but as you said, is there a spark here? Is there something worth investing in? And we felt like there was and that kind of caused us to roll forward with figuring out how to do the real thing. So I figured that since we’ve been at it for a little while, as well as the palate cleanser of the new year, I thought it’d be good to do something we wanted to do for a while, which is a listener questions episode. So happily we ask for kind of input feedback from folks at the end of every episode, and we got plenty of those over the last 9 months we’ve been doing this or whatever, sometimes by private email, sometimes from former colleagues or friends, very often from folks we don’t know at all, sometimes. Twitter, etc. And then I recently just posted a thread on Twitter asking for folks to contribute questions. Lots of great stuff there. Thanks everyone for sending things in. And, uh, yeah, I just thought we’d spend this episode walking through a few of our favorites. We can’t answer all of it, obviously. And certainly many of these things, I think probably just serve their whole own episode. So you can give us feedback on the feedback episode and tell us which of these you’d like to hear us talk about more. Do you want to uh start us off by reading the first question? 00:03:12 - Speaker 2: Yeah, so to pull the first listener question out of the mailbag here, we have a question from Gary Zoo, and we have to add a blanket caveat here about the pronunciation of names, apologies in advance. I hope we got that right. So the question is on designing advanced gestures. Says I am working on designing a new writing tool for myself that combines some of the stuff I love about Figma into writing. However, I struggle with designing with the right amount of fidelity. It feels like mockups are not enough to truly express the idea, but I don’t want to go into prototyping too early and lock in the design space. How do you design the interactions from Muse and deal with tensions while prototyping? 00:03:52 - Speaker 1: And one reason we picked this, so we’ve gotten a number of variations on these happily we have a solid following of design-minded people and yeah, the traditional design approach is static mockups, you know, you basically have these storyboards. Here’s a screen that you tap this that flows over to here and then even the prototyping tools, for example, prototyping built into FigGMA, as well as standalone prototyping tools like I used Balsam. For many years and this kind of tap through screens or click through screens is a standard mechanism, but if you’re designing something with really sophisticated gesture space, for example, or lots of sophisticated transitions, um, that kind of doesn’t quite fit that storyboard thing and I feel like that’s a little bit what Gary touches on here with this mockups are not enough to truly express the idea. And yeah, my experience with this, we’ve tried a lot of things and we definitely don’t have an answer, but certainly my experience has been that you just kind of wing it depending on what the, what the thing is. So sometimes we do do a lot of stills and just kind of classic flows, often with kind of textual descriptions that say when you do this, this should happen, but getting more into, you know, slightly more creative approaches, for example, Julia, I remember, did a great one quite some time. Back by sketching out the screens on paper and then recording a video of herself kind of manipulating the papers and so then things like sliding and other, you know, you could see the hands and you could see the gesture and she would kind of like you know puppeteer essentially. Something that’s a nice way to express the idea and we’ve also toyed quite a bit with, for example, I’ve used Framer a bit sometimes I just use HTML. Leonard has been doing stuff with origami Studio to again be more gesture and motion oriented and things you can even run on the actual device on the iPad. I don’t think one of those feels like a silver bullet or a catch all solution. 00:05:42 - Speaker 2: Yeah, I don’t think there’s a silver bullet here or a single answer, but I do think it’s really important to make it real. Adam, this is one of your rules for creative work that I’ve learned over the course of many years working with you. And here, you need to make it real because you can’t really evaluate gestures which are so physical without something there to actually be touching or at least seeing. But at the same time, implementing a full on gesture system that handles all the edge cases and is integrating into the app is super complex. So what you want is a way to cheaply evaluate and de-risk gesture decisions. So a lot of what we’re doing here is ways to kind of isolate the gesture problem or attack it more cheaply. So another example to compliment the ones that Adam gave, we have a now sort of internally famous idea of pink cards on a board, and this is a demo app, which is basically a blank screen and you have Hot pink cards that represent muse cards and you can implement new behaviors with them. And so the idea is you’re not dealing with any of the other complexities in muse, you’re just dealing with how do you manipulate these cards because we know once we have the cards, we can put an image in them or a text in them or a PDF, but the actual manipulation of the cards with gestures is quite complicated. And so in that way, you can fully evaluate how did the gestures work, how does the implementation go, but you don’t need to deal with all the other complexity and therefore cost of integrating it into. A full on app. Another example that we’ve done here recently is prototyping in the web. We’ve been doing this for our infinite canvas experiments where for various reasons, it’s just much quicker to prototype stuff on a web page. You can just do a single page HTML JavaScript thing and quickly learn how does it feel as stuff gets dragged around. Now, there, you don’t have the fidelity of you’re not actually touching something, but you are seeing, OK, these things are moving, how are the content indicators changing and stuff like that. And again, you’re really cheaply and quickly learning. 00:07:29 - Speaker 1: I think another piece of the prototyping is maybe what you described there is almost the reductionist aspect of let me just pull out this one piece rather than trying to put it into a full sophisticated app codebase, and that could even be, yeah, it’s often the case that something like HTML and JavaScript is a faster way to prototype compared to kind of mobile development environments, but Yulia does tons of standalone. prototypes where she just says, OK, we need to explore a new way that we do the transitions because we were changing the visual model and therefore I’m just going to make this iPad app that’s essentially not much more than a hella world of moving these squares around on the screen, but I can try this one idea in isolation, get it to where it feels right, and then I can go to the kind of back porting that into the main app. So another cluster of questions we have is around zooming UIs and sort of the navigation within a board, and then there’s the navigation between boards, which of course you do through pinching to zoom in and out, for example, hey bang bird, again the pronunciation caveat there says I’d love to hear your thoughts on zooming you. or Ricardo Medina asks, thinks this is one of our more interesting design choices and wants to know why it is disorienting and intimidating potentially to have the infinite canvas. So we wrote about that a bit in our memo, but maybe this is a good one to expand on a little bit. So Mark, tell us about the visual model and why we’ve made the choices that we have there. 00:08:56 - Speaker 2: Yeah, the zooming UI question is really interesting because a lot of people when they first seem, they say, oh, it’s a zooming UI app. Like that’s the thing that it does, it’s so distinctive and so prominent. But that isn’t necessarily a top level goal of Muse. We introduced a zooming UI because it solves some particular design criteria we had around how you navigate your content. So for example, I think it’s really important when you press your fingers on the screen and you go to do a gesture and you start the gesture. That it immediately does something and that it’s a continuous experience from you start the gesture all the way to you finished it. And assuming UI is a pretty natural way to do that. Like as a contrast, a lot of apps navigate with like page changes, like you just kind of teleporting around, and that is quite disorienting because you don’t know where you came from or where you’re going, and it doesn’t have the same naturalness that this gradual and incremental transition has, especially when you’re doing a continuous physical gesture. But there are potentially other ways to get that, and there are ways that we’ll consider in the future. You can have a crossfade or a slide in or slide out, things like that. So it’s not so much that we want a pure ZUI per se, it’s that it gives these nice properties, especially in the context of a gesture system. 00:10:06 - Speaker 1: Well, one of the original kind of core ideas or philosophies we were trying to explore back when we were doing this in a research context was how to tap into the user’s spatial reasoning. Because there’s a very powerful part of the human brain we evolved to navigate spaces in the real world and to the extent that computer interfaces can tap into that and make things feel place, feel like a place and access those parts of our brain, the more we can orient and move around comfortably. And I think in a lot of ways the computing industry, particularly with mobile, has gone that direction a little bit. So for example, standard iPhone apps have first of all usually. Some kind of a light spatial thing. If you tap an item, it kind of slides to the right, then when you tap a back button, that slides you back to the left and you have kind of this sense that the thing exists in a larger 2D space. I would also argue something like actually the iPhone core interface for the home screen is a very lightweight zooming UI, particularly with the swipe up gesture and the zoom kind of transition, you get this feeling that when you’re looking at an app, you’re sort of zoomed up and then you swipe up and you toss it away and it flies back to the grid and you can tap another one to zoom into that, right? So the part of what I think makes the iPhone and mobile interface is generally much more accessible and much more natural for most people is precisely because it’s tapping that spatial reasoning. So we wanted to see if there was like a power user version of that, essentially, right, exactly. 00:11:32 - Speaker 2: And as for this question of zooming potentially being disorienting or intimidating, we’ve been talking about this in the context of when you’re in a single board. And if you can arbitrarily zoom in and zoom out, and especially if you can also pan in any direction without any boundary, it’s kind of hard to know where you are. So when you start, you know you’re at zoom, you know, 100%, and you’re in the middle. But if you do some gestures, like say you zoom into some blank space, it looks blank, just like it did before. So how zoomed in are you? Well then, do you need like a zoom level indicator and then you’re into the whole Chrome thing. And then if you want to zoom out, do you snap to 100% or is it if you’re close, you snap, or otherwise, you know, there’s just so many degrees of freedom that you introduce, which sure gives you flexibility, but also makes it hard to orient, especially to some kind of standard landmarks that you would want. So if we’re thinking about our flexible canvas feature and other related ideas, we’re trying to strike a balance between, you have the flexibility to move around and to zoom when you need to see something closer, but also you don’t feel like you have no grounding in your content. And I keep coming back to this idea of drawing on the, the physical world, and here, like with your desk, you can zoom in, like lean in to see something with more detail, and you can kind of lean back to get something with more context, but there’s this natural balance point that you return to, which is like you’re sitting neutrally in your chair. And that seems really, I don’t know, obvious or straightforward, but it’s a really important idea of like you literally know where you’re sitting, and it’s so easy to lose that in a digital world where you don’t have all these physical cues. 00:13:01 - Speaker 1: a trade-off between oriented, grounded, and freedom, openness, spaciousness. It is extremely challenging. We talk about one aspect of it in our infinite canvas memo that I’ll link in the show notes, but this is an ongoing challenge for anything we ever do with the visual model, which is you want freedom, that’s part of the value of these digital tools. You don’t run out of pages in your notebook, but that actually comes at the expense of too much freedom and you’re just lost. 00:13:32 - Speaker 2: Yeah. So speaking of organizing your muse content, we very often get questions about that. So one recent one, for example, from Akash was how do you organize your boards by ideas, by articles or something else. So how do you approach this, Adam? 00:13:46 - Speaker 1: Yeah, I usually have the answer of however you want or don’t worry about it, which sort of is unsatisfying. In practice, when, you know, of course, anything you put in use is private, we can’t see it, but I have had the opportunity to kind of watch over someone’s shoulder either virtually in a screen share session or sometimes in person and see how people organize their stuff. And there are folks who do a very careful, OK, here’s my work board over here, and here’s my philanthropic activities over here, and here’s some stuff I have to do with my kids over here. And they basically have, you know, subboard kind of like organizing folders on your file system or something like that. For myself, I find that I tend to use it in a more messy way, and this is especially true for me because Muse is really about what’s on deck. What am I thinking about now? Um, it’s less about the long term kind of archival of um project material and more about what I’m working on right now. And so I tend get a thing where I have a couple of work-related boards on one side of the screen, maybe kind of in the upper left, and I have some personal stuff that’s maybe more to the right, including maybe some journaling, but also some personal admin, life admin stuff, and then I have like kind of a little archive space down the lower left, then I might, if there’s one particular project that’s really top of mind for me in the moment, I might make that a little bigger and put it towards the middle. So then I do end up with like a board per Not quite per project, but per like chunk of thinking about a project, and those kind of migrate to my archive as they’re not relevant anymore. I’ve moved on to new things. There doesn’t tend to be like a deep hierarchy where it’s neatly sorted and taxonomically correct. It’s more just I have a board for stuff that I’m thinking about, you know, by topic, and I just kind of put them roughly in clusters and then eventually those move to an archive and that’s kind of. 00:15:38 - Speaker 2: Yeah, I have a similar approach where everything comes into a sort of inbox or desk, and it’s very much a messy working set. It’s basically whatever I’m thinking about today. And then from there, any structure is sort of emergent. So if I have a few things on my desk that are related and I want to keep, I might make a board for that and put that board on my desk. But An active project I’m currently working on. And then as I complete that project or it becomes colder, I might shuffle it down further into the hierarchy. And that way, the hierarchies that I might need sort of emerge organically. So I don’t try to pre-plan anything. It’s just once my current space gets too many items on it, then, OK, I need to basically rebalance the tree and push some nodes down. Adam, you also mentioned kind of a mix of personal and work. One question that we didn’t pull up explicitly, but I’ve gotten a lot is, you know, how do I make different workspaces or can I have different users in Muse? We made a pretty explicit design decision in Muse that the way you separate your top level context shouldn’t use a different mechanism from how you organize things at a lower level. Like we want to build these general purpose primitives that you can use to organize at any level of your workspace. So for example, I have a big top level board for personal stuff and for work stuff, but those are just regular muse boards. We don’t have a separate concept of like muse workspaces or muse users or muse accounts or something like that, um, because we want you to be able to reuse these primitives and flexibly recombine them however you want. 00:16:59 - Speaker 1: The next question comes from Chris Corella. He says, I’d love to hear the projects and use cases people are using use for. And this one is for me is a personal, not sure what you call it back burner project or just a thing I’ve wanted to do for ages, which is have a gallery that shows sort of the type of person or says a few things about the work they do, but also shows their boards and we did a little of that in the newsletter sometimes users would send us screenshots, by the way, we love screenshots of your boards and of course they’re personal and often people feel vaguely embarrassed because they’re messy because thinking is messy. But it’s really great, you know, when you’re comfortable to share that, giving us a little peek at how you use it really, you know, pictures worth 1 1000 words, as they say. But in any case, for a while, I would ask folks for permission sometimes if we could put that in the Newsletter kind of dropped off on that. Love to do like a user gallery or something like that because we have really some pretty interesting people doing some pretty interesting things and I get a real kick out of that. Obviously we’ve got our, I don’t know, kind of core audience of tech people probably came out of the ink and switch days product designers, engineers, computer scientists, product managers. But then additionally we have all kinds of interesting things. We have a few restaurant owners, this was an interesting one to me, but actually it’s great because you’ve got the bring in the menu as a PDF and you can kind of mark it up and then you’ve got some photos of the food and then you got like some screenshots of reviews of your restaurant and some competitors and there’s a map and there’s, you know, you kind of mark all that up. Another one I think you uh recently did a user interview with was a pilot, and these folks often take the, what is it like an iPad mini or something and strap it to the knee. 00:18:36 - Speaker 2: Yeah, it’s an iPad, so they put some Velcro on their thigh and then put some Velcro on the back of the iPad and stick it on their thigh for the flight so it doesn’t move around when you hit turbulence. And apparently iPad is the sort of universal standard for private pilots because that’s where the best private piloting software is, I guess. And then from that and from the weather reports and from the radio during your flight, you’re collecting all this information and it’s PDFs and images and handwritten notes, and it’s nice to have a way to bring that all together in one spot. 00:19:02 - Speaker 1: Also seen some attorneys using it for casework. There’s one fellow that, or I should say one person who periodically sends in screenshots usually connected to bug reports or whatever, but turned out as a like a board game designer, so there’s really interesting card artwork, very visually rich, you might say. And then we also have a number of authors, but a really interesting case that I got to meet through our sports channel last week is a really prolific fiction author who has something like 50 published works and told a really nice story of using Muse to essentially work out a thorny point in one of their plots that they were trying to figure out for a piece. So it sounds like there’s going to be a book published soon that Muse at least had a small role in helping with the, of course not the writing of it, but the thinking of it, which ultimately is our place in the creative tool chain. So yeah, I would love to take the time to secure all the permission and get some screenshots and maybe get some photos and some quotes or something and just have a nice little gallery on our website, but haven’t quite gotten to that yet. 00:20:02 - Speaker 2: So our next question is from Edward Lee. He says, you guys clearly have a mission and you’re building towards that, but there’s also the reality of making sure you’re delivering a unique value prop over other products. So, and to paraphrase here, who do you think of as Muse’s competition, and how do you reason about that? 00:20:20 - Speaker 1: Yeah, I think competition is really important for understanding how product fits into the marketplace, and certainly when folks come to me for, I don’t know, just input or advice or whatever on their products or their startups, one of the first questions I like to ask is competition because I think that helps clarify things. For Muse, I would roughly group three categories. One is the, let’s call them other multimedia canvases, mixed media canvases. That’s Miro is probably the biggest player there, but Millaote is one I like a lot. Miro and Millaotte are both kind of web-based real-time collaborative. They don’t have the iPad component. And then one actually that our guests on the last episode mentioned using is Skel, which is this kind of targeted more at authors, but again it’s like a cards on a board type of thing that works on the desktop app. The second category I think of is this kind of broad knowledge workspace, and probably notions that maybe the hot up and comer there. Evernote actually is one that’s really well established. We hear about that one quite a bit. And then you have more specialty ones like liquid text, which is kind of focused on PDF annotation and excerpting, or actually one I’ve taken also a lot of inspiration one which is called Devonthink, which is this pretty old school desktop software you collect up a lot of material and you use it to essentially find connections and generate new ideas. And in a way I don’t necessarily think we’re directly, actually feature wise we’re not very directly comparable, but just in terms of a digital space where people go to kinda collect a bunch of stuff together and think about it, I think the Enos and notions of the world are comparable tools. And then the third category is what I would call the iPad native digital sketchbook. So all the products I’ve mentioned so far are either web-based, maybe with an app, maybe not, but they’re really native to the web or maybe they’re native to the desktop, as opposed to iPad native. And you go iPad native, there are lots of interesting choices, but the digital sketchbooks would be good notes, I think it’s a really nice one. Notability is another one. Those are really pure, I know sketching is quite the right word for it. You can, for example, Goodotes, I think is a great piece of software. It’s one I used prior to Muse, I think you did as well, but it’s really, it’s really about laying down ink on a page. It is a digital transliteration of a sketchbook. They have a lot of nice inc options. It’s good for making sketches and exploring things and writing out stuff. Can add text, but it’s clumsy, you can’t really add links. I think you can put an image in there, but that’s just not really what it’s made for. But in terms of being fast, private, and in particular that tablet posture and stylus use, you know, they’re very inspiring. So I think Muse tries to take some elements of each of those three, the mixed media canvas, kind of classic knowledge. Workspace and the iPad native sketchbook, but it also doesn’t have a lot of those features. And so for many folks when they come in and they say, well, I’m thinking of switching from any one of these products I’ve just named to Muse, but here’s the features that I need. And in some cases we have made deliberate choices to leave out, for example, really sophisticated inking options because we just don’t want to be a sketchbook as an example. 00:23:25 - Speaker 2: Yeah, and I think actually a potential 4th category would be straight up paper notebooks. 00:23:30 - Speaker 1: Ah yeah, of course. 00:23:32 - Speaker 2: Yeah, we’ve seen in our user research that a surprising number of people still swear by paper notebooks. They’re very reliable. They have low latency. They never run out of power. There’s lots of great attributes of them, and so people keep going back to them, and in many ways we’re trying to do with Muse is bring iPads up to the level of the humble paper notebook. 00:23:52 - Speaker 1: Yeah, great point. And actually if you further expand that to be all analog ideation products, sketchbooks, but also whiteboards, Post-it notes, index cards, if you count all of those, I’m pretty sure that, you know, if you just pick a random creative professional and ask them what they use to think through their ideas. is far more of them. I think that category that you just named, that kind of analog thing to would dwarf all of the others, right? That’s the real incumbent that I think we’re looking at is whether digital has something to offer against these very tried and true and rightfully beloved products for thinking. Yep. So our next question is from Brian Zimdler. This is about how we understand user needs. They ask, how did you conduct the user interview process for Muse? 00:24:38 - Speaker 2: Yeah, well, I feel like this has evolved over time, so maybe we can work backwards. So now we have quite a few users, many of whom are very active, and so we’re able to engage with them. Sometimes they just come to us and volunteer, sometimes they have support requests or feature ideas and engage them on that basis. And we say, OK, like that’s an interesting idea, you tell me more about your use case, maybe we can get on the phone and chat. That’s. Avenue that we have. And then going back in time before we had products, we would have to be more proactive about finding these and there we would try to identify the archetypes, the types of people that we would want to learn from and reach out to them. And often these people in our network or people who we had some connection to, so there was some level of trust already, and we would ask them about their creative process, what tools they use, things that they were happy about and not, and so on. 00:25:21 - Speaker 1: Yeah, I really enjoyed the pure ethnographic research that we did in those days. It’s tougher when you don’t have a product because it’s kind of you’re sort of asking someone to tell you about how they work just because, and you can say I’m associated with this research institute or, you know, we’re doing the survey, but it’s a little bit less tangible. If someone’s using your product or wants to use their product, they’re trying it out, and particularly as you said, this support becomes in a way a kind of a lightweight, steady way to get a sense of, you know, what people need and want. And you make a great point there as well, which is folks often write in very reasonably with a kind of transactional question, which is, oh, I would like feature X, and we almost always answer with something like, OK, well that’s interesting, and we might say something like, yeah, lots of people have asked so that we’ll put you on your list. We’ve got a little database basically where we just kind of tag people with what they’re interested in, but what we really want to know is why, like what’s the reasoning? Why are you driving that in the product manager lingo is use case, which I sometimes. But it may be for normal people it’s just how are you using this? Why do you want it? And so I try to dig in on that, like what kind of projects are you doing and what drives you to need this and why are there other ways you could do it not suitable and the real good information is in that. But to my surprise, sometimes folks are a little bit, not that they’re withholding but more I think they maybe just assume that we’re most interested in talking about our product. Which is actually a very reasonable assumption, but I’m much more interested in you. Like, what do you do? What is your creative process, what are you trying to accomplish? How does this tool fit into your life or not, you know, how do you aspire for it to fit in, but maybe you can’t do that today. That is much more what I’m interested in. 00:26:59 - Speaker 2: Yeah, especially with a product like Muse, because people are doing so much wild stuff with it. It’s not like, for example, uh Photoshop, it’s like people are editing images and there’s some variants on that, right? But with Muse, there’s so many projects that people are working on in so many different domains, it’s super interesting to learn about what people are up to. 00:27:14 - Speaker 1: Absolutely, and maybe it helps that maybe all of us and certainly me are speaking for myself. I just have a real passion for creative processes generally. One of the reasons I enjoyed working on Hiroku was because it was very much about the developer creative process, the software engineer creative process, and we’re getting a glimpse into a different side of that through working on news. 00:27:34 - Speaker 2: Yeah, so speaking of creative process, we have a question here from Tim Lombardo. How do you recognize good ideas to work on? 00:27:42 - Speaker 1: Yeah, I think this was a follow up to episode 12 of our podcast with Andy Matzek. We’re talking about idea development, and I had spoken about how I use for me there’s a sort of ritual to starting a new muse board and particularly giving it a name, where I’m saying there is a problem that I’m facing in work or life or just an idea I want to develop that I think is interesting enough that I want to make this blank canvas for it. And yeah, I think Tim was thinking of this as, is this a meta skill to develop, which is knowing which ideas to chase, which is really interesting. I hadn’t thought about it that way before. I certainly have a strong hunch for what things to go after, which I think of partially as like an entrepreneurial drive. Maybe it’s something that is Sort of an effective experience when you’ve been doing maker work for a long time or for a multi-decade career, you have a good, particularly if you do proper retrospectives, hopefully you have a good sense of which ideas panned out and which didn’t, and then you have a good idea of which ones to invest in. But I don’t know, I want to think about that one more. Mark, what’s your answer to that? 00:28:50 - Speaker 2: Yeah, so one angle for me is getting a lot of different reference points and potential connections with new ideas that come in. And so that’s about having a lot of raw material to work with, raw intellectual material. So a lot of reading, a lot of time discussing ideas with other people, so that when a new idea comes in, you can kind of reference it against all these other. I ideas you have in your corpus, that’s gonna happen with things that don’t even seem directly related. That’s why I think reading about science and history and the academic literature and the industrial literature, those are all really important to do, and it builds up over time. 00:29:22 - Speaker 1: So curiosity is upstream of having good ideas. 00:29:27 - Speaker 2: Yeah, exactly. Another thing is I lean quite a bit on people who I think have really good radars or radars that are in tune with mine. For example, Adam is one of these people who just seems to have a really good intuition. Well, thank you. Sometimes he comes to me and says, yeah, you know, Mark, I have a feeling we should, I don’t know, start a podcast, let’s try it. Oh, OK. I didn’t exactly thought of that, but I trust you guys, let’s do it. And there are a few other people who I have a similar level of trust and respect with. Actually, Twitter has been a pretty important vehicle for this. There’s some people that you can find and follow there and Again, it’s not about credentials or popularity, it’s more about individual people who have a specific articulated way of thinking, and on the basis of that you can come to more heavily weigh their input. 00:30:08 - Speaker 1: I’m actually reminded of a talk I saw many years ago by Paul Bhey, who’s the creator of Gmail, and this of course is in thinking in terms of product opportunities or what’s a good product to build, which is obviously a small subset of what counts as good ideas but happens to be the one I tend to operate in. And he talks about the entrepreneurial drive or in this case, the entrepreneurial drive of feeling agitated. There’s like a problem or a thing that just seems wrong or weird or annoys you and you just can’t stop thinking about it and you look for solutions, but none of them really quite seem to fit for him. I think he was telling the story of being annoyed that All email was slow and clunky and required you to do a bunch of organizing work that you didn’t really want to do, and losing track of long threads and just the nurturing of that agitation over time turned into like a good understanding of the problem and the drive, the initiative to go and do something about it. 00:31:10 - Speaker 2: Yeah, I call this my problem. So at any one time, I have 01 P problems. And this is things that I just can’t help thinking about. I’m thinking about, you know, why are they wrong? What are potential solutions, what are potential angles for it? It’s in the shower. It’s, you know, when I’m taking a walk, it’s when I’m talking to people, I can’t help but bring it up. And that’s something that you basically can’t really control directly. It’s a function of your environment and what you’re reading and so on. But when I get that, and especially when it stays the problem for a long time, I’m really inclined to go work on it because I have a lot of energy for it. 00:31:41 - Speaker 1: Yeah, one that I had a front row seat of was what eventually became your article on slow software or the article titled Slow Software, which is a look at why software is slow, why it’s important for it to be fast, a bunch of the human factors. But yeah, I remember when you were. that and a lot of it came in the form of just being constantly irritated and wanting to seek the base of that irritation, and it would, as you said it, because it’s the one thing you’re thinking about, it pops out in other places. I remember you having internal memos, you know, within in and Switch that were about maybe like a project and it was sort of related, but there would be several paragraphs that was basically ranting about like it’s got to be high performance. And it sort of, oh, OK, and like eventually that just grew and grew and grew and eventually took shape as this excellent essay that then was widely shared. So this next question is about building news with MUS. So this, unfortunately I couldn’t find the original tweet. This was from around the time of our launch back in late August, early September. There was a real fire hose going on at the time. We were just getting hundreds of messages through all these different channels Twitter, hacker news, support. Yeah, the adrenaline was running high, but I remember I thought it was a really interesting question, and I said, oh, I should actually do a whole Twitter thread on this. I should post some screenshots and talk about it. And then I don’t know, there’s a million things going on, so I just lost track of it and I couldn’t even find the tweet looking back. So apologize, we can’t to the author that we can’t give you credit. Yeah, I think this is a great one or sparked my imagination because the answer is, yeah, absolutely. I think that is just so obvious. So much of the work we are doing and in general with product and business work, so much of it is developing ideas and that precisely is what use is for. And to me it was a real milestone in the business for me at least, this piece of software crossed from a research prototype to a product with legs in the real world was when I started to be able to use it to do ideation on our business. I remember one of the first real kind of major boards I had was our first team summit in Dublin there back a year and a half ago, and you know, we had the different sessions, we’re gonna talk about the structure of the business. I had one board for some sightseeing we were going to do there in Ireland, and another one that was kind of just some of the scheduling stuff and some others that were sort of like freeform conversations that we were having that collection of things was really um helped me. Absorb and work through everything we were talking about there and in fact I think of this as being self hosting a concept from computer science which is if you’re working on a piece of software, let’s say you’re working on a programming editor, there’s a point at which in the very beginning it’s not good enough to work on its own code base. But at some point, you know, I assume that the eye and sublime text and VS code and so on, the authors writing that editor also are editing the future version of the editor in the current version of the editor. That sort of self-hosting thing is a good sign, a similar thing for programming languages and. And so on. So in that sense, the moment for me it was a big moment when news became for me self-hosting in the sense of the ideas and product roadmap and design work and so on. At least that I was contributing to the business, I was doing a lot of that in Muse itself. 00:34:57 - Speaker 2: Yeah, I feel like as Muse gets more capable, we’re able to move more and more of our work into it, which is a great sign. And I also do use Muses a lot for, let’s say designingm. A lot of work that I’m doing these days is product architecture. So that’s like, what should the pieces be and how they fit together? What should they be called, what are the nouns and verbs, what are the core primitives, how do you power the core engine and stuff like that. And that’s a very contemplative activity. And so it’s really important that you have an environment that feels conducive to that. So I like to take my muse and go on my couch and scribble some stuff and maybe do some reading, and over a course of a few days, maybe develop an idea. This actually leads nicely into questions of roadmap. So, the first one is from Nicole Carrasano, and it asks, I was wondering if there’s a Mac version or if you intend to make one. 00:35:49 - Speaker 1: Yeah, so this is a bigger rabbit hole than you might think. The short answer is yes, for sure, we need to do that for a bunch of reasons. The longer answer is more complex because we think it’s long been our hypothesis for why the iPad and tablets generally are underinvested in platforms because very often you have transliteration of either phone or desktop apps to the iPad and a mouse and a keyboard or a trackpad and a keyboard are just not the same as a touchscreen and a stylus. And so then it’s basically worse than what it would. on the computer and then in the meantime you’re not taking advantages of the unique benefits of touch and we have the same thing bringing it the other way. If you port an iPad native app to a desktop environment with that keyboard and mouse, it’s going to be worse. And in fact we’ve prototyped that out and seen that there’s a lot of ways that the basic metaphor of the cards on the board will work fine with a mouse, for example, but there’s lots of other things that really will need some rethinking. 00:36:44 - Speaker 2: Yep, I do think it’s gonna be really important to get news on the desktop. We’ve said many times in this podcast that the creative process naturally encompasses a range of devices. You have phones for on the go, look up reading and capturing, and you have tablets, which is our current focus for reading, annotating, contemplating, sketching, brainstorming, thinking, basically, and then you have the desk. To which is the power tool for authoring and editing. And it’s very helpful to have your thinking work next to your authoring and editing work, and to be able to go back and forth, as well as to do research sessions on your desktop as input into your thinking. I think it’s very important that we get onto the desktop, but it’s not going to be, like Adam was saying, it’s not going to be the same app transliterated. So there’s quite a bit of design and technical work that we need to do to get there. 00:37:31 - Speaker 1: That also points to the other big challenge, which is I think getting a version of Muse running on, for example, a Mac or any desktop computer that has some changes to the interface that will make it feel natural with that set up. I think that’s kind of a moderate amount of work. The bigger thing there is exactly what you described, which is if you’re moving back and forth between desk. To for one kind of setting and tablet for another, well, that implies syncing and good cross device syncing, uh, in particular that has some of the privacy qualities we’re hoping to be able to achieve is a very, very big technical challenge. Happily, it’s one we’re working on right now and we’re optimistic that it is an achievable end for us. So the next question again is I’m going to do more of a a paraphrasing of something we hear very, very often, which is basically just what’s the muse product roadmap, and I think some additional color on this question or a lot of the motivation is I’ve really come to realize how important it is for people to know not just what the product is and what it can do for them today, but also where it’s going, and that makes a lot of sense in the context. of subscription software, you’re not really buying it for today, you’re buying it for the, you know, in this case, if you take an annual subscription, even if you don’t renew, that’s 12 months' worth of improvements that you’re expecting to accumulate, and that gets even more so if you get into something we’ve talked about in some past episodes, which is in many ways supporting an early product like this. It’s almost more like a Kickstarter you’re saying. I want software like this to exist. I think this team is the right one to do it. I want to support you financially to make that come true, but then that also has the additional dimension of you want to know and trust the team, but you also just want to know where is it going. Maybe the places they want to go don’t match up with what you think is interesting or inspiring. So we don’t have any kind of public roadmap, but this certainly makes a lot of sense to me that people ask about this. 00:39:23 - Speaker 2: Yeah, maybe we can describe this as our areas of interest in areas that we’re being pulled and drawn to both by our vision for the product as well as quite consistent customer feedback and questions. There’s a few areas that constantly come up that people want more in. 00:39:37 - Speaker 1: Yeah, so I think really zoomed out. I think of the kind of three big tiers or sequential areas to work on is starting with the single user thinking tool. And that’s the mixeded canvas, use both hands in the stylus, it’s super fast. It uses all the screen for your content, really fully taking advantage of the iPad and stylus hardware. And actually this launch that we did a few months back to me was the feeling like we delivered that. There’s much, much more to be done there, both improvements on what’s there and more features, a very long list on that, but I feel like that pillar is well in place. Then the phase two, if you want to call it that, is what we’re working on now, and I expect we’ll take most of this year we’re just now entering, and that’s the multi-user, multi-device stuff. So that is, I can access it from all my devices, the new experience in each of those devices is appropriate to that device, phone, desktop. And so on. And then of course the multi-user collaboration, sharing, how do I send stuff to clients, how do I send stuff to colleagues, how do I share in a way with people who are not using news or people who might be using Muse, we can get additional benefits from that. Huge technical and design challenges there, but certainly a very fun space that we’re starting to get some progress on. And then the final piece, uh, to me is what I would call the end user programming or the programmability of it. I see we have a question further down the list about that one specifically, so maybe we’ll expand on that there, but that’s just my take. I’m curious how you think of the overall roadmap. 00:41:12 - Speaker 2: Yeah, that’s pretty much how I think about it too, and maybe you just drill down a little bit into the 1st and 2nd phases there. On the first phase, I agree that we have a quite solid foundation with this tablet native thinking experience. We’ve gotten very good feedback on that. Now there is some more to do, just to give you a couple examples. One is, well, we think it’s important to be able to move ink across boards as well as move it within a board, which you can currently do, and that’s quite a bit of a technical and design challenge. Another one that I’m excited about is a non-spatial collection type. This goes back a little bit to our zooming UI conversation. Right now, the only way you can collect elements in muse is on a spatial board, and spatial collections make sense in a lot of cases, but I would say not all cases. And so I think we want something more like a set type that automatically manages the position and ordering and sizing and so on of your elements. So if you just have, say, a stack of papers that you’re reading, you can do something that’s more like putting a paper on the stack as opposed to specifically laying it out somewhere on your desk. And then phase two, yes, it’s a simple matter of making it run on everyone’s devices everywhere. There’s obviously a lot under that hood. There’s a big technical challenge in going from all the data resides canonically on one device to it’s distributed across all devices. But once you unlock that, you can do a lot with syncing across one user’s device as well as collaborating across devices. So I’m quite excited for us to be pursuing that. And then we also talked about how you need basically 3 different apps, you need one for the phone, one for the tablet, and one for the desktop. So there’s quite a bit of work to do there. 00:42:41 - Speaker 1: And certainly on the product or design side, I think that while there’s a really good precedent for collaborative tools, including GitHub for code, Figma for design, Google Docs for writing, There really isn’t a collaborative thinking tool and you know the sort of obvious thing to reach for is the live whiteboard. And in fact, in many cases folks find us or imagine that that’s what we’ll be sort of like standing in front of a white board with your colleagues talking through a problem and scribbling out visual support and indeed we may support a use case very similar to that. But I suspect that there’s a lot of nuance and interesting subcas or related cases when you talk about asynchronous work and the degree to which you want to do things in private and then share them with your colleagues for kind of input or to further discuss versus like starting together with a blank slate. I think there’s a lot there. 00:43:36 - Speaker 2: Yeah, the way that people actually work together creatively or want to work together creatively is very complex. They want privacy of their information, they want to do a lot of stuff privately to themselves, and then they have a bunch of different granular collaborations. You know, you and I are collaborating on this podcast. We are collaborating together with the new partners on the business. We also have all kinds of other stuff going on in our lives and it’s kind of formed these overlapping groups and correctly representing that and supporting that in software is a really important goal of mine for this phase two. And that brings us to what you described Adam as phase 3 of Muse. Jimmy Miller has a question here. He says, I’d love to hear you all talk about end user programming, explorations that bring Muse a bit closer in that specific direction. What is the place that you see for end user programming in Tools for Thought and use? 00:44:24 - Speaker 1: So this is a huge passion of mine, career long passion. I’ve written articles about it reaching. Back 10 years and more I was one of the foundational inspirations for Hiroku and just to kind of briefly define and user programming, the idea there is that most software today is written by professional software engineers. It’s not something that basically computer code and the programming tools and everything you need to write software is something that you really have to be an expert at in order to do, not even just at a high level but just at all. And the idea of making that more accessible, such that maybe not every single person that ever uses a computing device, but many more people could have access to that, and the comparison on that is often made to literacy. So once upon a time, reading and writing was something that was a tiny tiny elite. of scribes and alerted people could do and later on through the printing press and education and some other means became something that almost everyone can do. Not everyone’s a professional author or really strong on English grammar or whatever, but almost everyone can write a shopping list or write a letter or an email to their friend. And so there’s a version of this for programming as well. How do you think about end user programming as related to Muse? 00:45:46 - Speaker 2: So I suspect for end user programming as we typically understand it, that is users writing code like stuff, I suspect you’re going to have the clearest vision for that, and you’ve thought the most about it. I have a couple different angles on this, which I’ll share. One is, I’m quite excited about the idea of the programmability of data. So we often think about programming as you have codes manipulating like in memory variables and stuff like that. I’m really excited about the Users having programmatic access to their corpus, read and write, and that being reflected in muse and outside. So you could potentially think of your end user program as you’re writing these little like bots basically that are watching and crawling and manipulating your corpus data and doing automatic things with it. It might be organizing your daily to do list or something like that, or something more complex, doing summary statistics over all of your work for the past year. And I think there’s something very powerful as well as accessible about accessing the underlying data. And that leads kind of into my next angle here, which is open ended computing, which is maybe a generalization of end user programming, and by that I mean users being able to do combinations of things that the designers of the program didn’t specifically need to plan for. So with typical mobile apps in particular, the set of things you can do is basically the set that the product manager said you should be able to do. And if you want to do something that the product manager didn’t think of or doesn’t agree with, well, too bad, delete the app or something, you’re out of luck. This is in contrast to the world of traditional desktop computing where you have the standard file formats that any program can access and manipulate and that the user can directly access via their visible file system. So to take a simple example, if you’re writing a text note and you don’t like the color of the text screen, you can just open up a different editor or you can CP it into a different. There’s so many things you can do and you have so much agency because the files and the programs have this interface that’s kind of general and that different people can access. And that’s something that I think we’ve kind of quietly lost in the world of mobile apps. You have a little bit of it with the share sheets that export standard-ish file formats, but it’s very clumsy and it’s quite limited and oftentimes the programs just don’t let you export stuff easily. So what I’m curious about is how do you bring that desktop sensibility of open-ended end user computing back to the world of mobile apps. 00:48:05 - Speaker 1: I think this point of data being the center of gravity or the thing that matters to users and customers, I think as software creators, we tend to think that the code or the running software is sort of the thing that matters and then data is this kind of thing that’s added. Onto that like a database is something you attach to an application or you write the software and opens and it reads and writes to a file, for example, but from user perspectives, the data is what they care about. It’s like I’m using your, I don’t know what piece of software to write my master thesis, you know, they may like the software or not, but ultimately they care about their work, they care about the thing they’re creating. That’s more important to them. And yeah, standard data file formats that I think once upon a time were much more kind of universal and easier to use, and those have sort of faded in utility largely because of the mobile world and finding ways to not necessarily step back to a previous time to get some of that value of I don’t know openness is quite the right word for it, but the ability to manipulate your data in a powerful and free way. I think that’s something missing. 00:49:11 - Speaker 2: Yeah, maybe agency is another way to describe it, yeah, yeah. 00:49:15 - Speaker 2: We also talked about this in our local first paper which we can link to, but yeah, the world of files gave you all this control and visibility and portability, but then they basically Fall on their face when you get into the world of mobile and especially collaborative apps. And then with mobile and collaborative apps, we kind of went all the way the other way and said, now your data is totally opaque and maybe you can’t even get it out, but at least you know, you can see each other in the Google Doc. We really need a third way, and that’s something we’re excited to pursue with Muse. 00:49:42 - Speaker 1: Yeah, this is one reason we made it a priority from the beginning to these Muse bundles that you can export are just zip archives that you can open and they contain flat files and a little bit of metadata. That was something, but that’s really just a very small step in that direction. So I’d love to see us do much more, and I agree that fits together with the the end user programming is ultimately about agency and grasping the full power of computing rather than being kind of at the mercy of the software vendor. 00:50:09 - Speaker 2: Yeah. Another thought I have on end user programming from looking at it in the wild, if you will, is that what’s really important is that people really care about the thing that they’re programming. And then they just need some little window or way in. So some examples of this one is Minecraft, where you have these Redstone contraptions, and it’s basically a very primitive way to program and it’s pretty gnarly and it’s literally quite bulky and blocky. But people are really motivated to build all kinds of wild stuff in Minecraft. Another example, you know back in the MySpace days people customizing their pages, and even I would say JavaScript and the web, like, frankly, JavaScript is a pretty gnarly programming environment. There’s a lot of things wrong with it, but People so much want to be able to script their content on the web. They basically found a way to make it work. And now you have these incredible JavaScript VMs which have wild performance. So a lot of the work I think of end user programming is not, how do you make like some editor that people can think about clearly. It’s more like having something that they want to program and then giving them a little bit of a window in. And that’s why I think this idea of the users' content and their corpus is so interesting because people care a lot about their creative work and everything they put into their music corpus potentially. And so giving them a way to unlock that could be really powerful. 00:51:17 - Speaker 1: I agree and I think this is one of the challenges of a lot of the HCI research that looks at end user programming or programming environments that are more accessible, is they tend to start with the programming environment. But almost by definition, the people who are not programming today are people who aren’t interested in programming for its own sake, right? They’re interested in it because of what it can do for them. So that means they already have a thing they care about that they want to automate, they want to extend, and so that is one of a few reasons, as a very natural reason why anything in user programming related would come late in the roadmap relative to other things. Yeah, one little teaser you could get on what that might look like is for the capstone project we did an Ink & Switch and I’ll link the end user programming article we did there, but we had one of our colleagues did essentially a series of experiments with, as you mentioned earlier, the bots. Basically you could have cards that had a little script attached to them that you would write yourself and if you drop the card onto a board, it would then Sort of do its actions. So we had a couple of examples that were something like a sorting card you could drop that on and it would sort of arrange everything in a grid. And there was another one that I think was a journaling card that would essentially put like sort of a title with the current date and time that was intended for a board you’re using kind of as a journal. And those are simple examples, but they showed the kind of stuff that a person might like to do with like a personal knowledge tool or thinking tool, and those were very, very rough and very early, but I think that kind of gives the direction of that. And furthermore, that also raises this question of end user programming can be sort of automating stuff for your own sake, but it can also be that you make a small plug-in or script or something you want to give to a friend or a couple of friends. I think a good example of this we’ve seen recently is Figma plugins, where people write plugins for themselves, but they may also distribute them a little. More widely, it’s not really intended to be sort of a full-fledged sophisticated application. It just extends or changes or customizes this environment that you’re doing creative work in in some way that makes it suit your needs and maybe you want to share with a few other people. So I’d imagine some kind of set up like that for use. 00:53:28 - Speaker 2: Yeah, this makes phase 2 and 3, if you will, very complimentary. An important learning from our ethnographic studies of end user programming and the other stuff that we’ve read is that there’s very little original end user programming. It’s mostly stuff you learned from a friend and then mutated slightly. So there’s this kind of one. Original spreadsheet and then it basically propagated through the world as people made different variants of it and copy pasted cells and so on. And I think if you have native collaboration and sharing in use, that could be the vector by which the end user programming learning gets propagated through the system. 00:54:00 - Speaker 1: Steal a cool bought card off of someone else’s board by duplicating it into your own. Exactly. Love it. Well, I can see that this is a topic that is one we could easily spend a full episode on, so maybe we should wrap it there and maybe we’ll put that on the schedule for the future. Right on. Well, if any of our listeners out there have feedback, either responses to what we’ve talked about here, or maybe you think some of these questions could be full episodes in their own right, feel free to reach out to us. We’re at @museapphq on Twitter or hello at museapp.com on email. We always love to hear your comments and
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: Cause there’s more to tapping to other people’s minds and sending something and asking for feedback. But listening to feedback through allowing other people to create in the same space that you create with the right people can definitely feel magical. 00:00:18 - Speaker 2: Hello and welcome to Meta Muse. Use as a tool for thought on iPad. This podcast isn’t about the product, it’s about music company and a small team behind it. I’m Adam Wiggins, joined by Mark McGranaghan. Hey, Adam, and Nicholas Klein of FIMA. Hey there. And Nico, I know you have been working from Europe with a US centric, maybe even a San Francisco-centric team for a few years. How do you find that experience of having the evening be your team time? 00:00:48 - Speaker 1: I think that looking at the upside of I haven’t set an alarm in the last 2 years to get up for work. I think that’s definitely on the plus side of this, but I like to kind of like keep my Friday evenings free, that kind of like gives me a little bit of like time of just spending a normal week evening, I would say. 00:01:07 - Speaker 2: Yeah, that’s right. I think the uh there was a nice thread recently about some Europe to US times and I think on the Europe side, the trick is, of course, you are giving up a lot of your evenings, but you gotta make some room in there for a social event, be, you know, be able to have dinner with friends or whatever here and there, and yeah, I agree, no alarms slash morning is more free form is a huge benefit. So for me, very well worth the extra cost of maybe needing to be a little more on my game in the evening than I would normally need to be. And let’s hear about your career journey a little bit, so I think you have quite a bit of interesting milestones along the way, including Sketch Runner and artifacts, which we talked about a little bit with Jason Wa recently here on the podcast, and I think it’s how I first discovered your work. Love to hear the steps that brought you along the way here. 00:02:01 - Speaker 1: Yeah, I studied interaction design in Schwebmund, and it’s a tiny, tiny school in a tiny city in the middle of nowhere in Germany. So I studied interaction design and I think what was very interesting kind of like studying interaction design was that you get taught these like behemoths of tools. So you get taught Flash, you get taught Illustrator, you get taught Photoshop in like classes, and you never really think about kind of like manipulating those tools themselves. And interaction design in general was really interesting because it was just about the relationship of humans to technology and application design, kind of a concrete UI design was one part of this. And I’ve never really thought about kind of like, hey, I’m learning how to design software. And tools are just software that is also being designed somewhere far, far away, but on a hack day in Hamburg where we were working on sketch plug-ins, kind of like started and like I continued to working with the team in kind of like designing and building sketch runner, and there was a plug-in with which you kind of like can still like insert components and apply styles from like a command like spot like UI. 00:03:09 - Speaker 2: I remember using this a little bit back in my sketch days, and it was quite remarkable to me at the time to bring a command line interface to a design tool. I feel like nowadays command palettes are fairly common and power tools, maybe superhuman, and some others. There’s an article from Repole where they describe a little bit the rise of the command palette, and the command lines traditionally uh kind of engineering centric, I don’t know, Unixy particular kind of power user making its way into much more of these tools, but I feel like Sketch Runner was a little ahead of its time insofar as bringing that to a design tool. 00:03:44 - Speaker 1: Yeah, it was fascinating. We’ve seen that like this aspect of I know the name of the command and originally it started with finding a way to make plug-ins more easily kind of like executable. That was the start during the hack day, like, hey, there are so many plug-ins being built for sketch. How can we make them more accessible and faster to kind of like execute? And then it kind of like we realized there are so many features that we can add on to this. And the moment that was like really exciting for me was that I was still studying in Schwabsmund. And I saw someone from the Airbnb design systems team talk about sketch runner kind of like on a meet up and then kind of like also tweeting about this. And I was just like, holy shit, this is really happening right now. And so at that moment I realized that like, hey, there is a potential for changing design tools. They’re also just software that are to be designed basically, and that kind of like got me hooked into design tools. After graduation, I was an intern at Shopify. And continued working on sketch plugins there. I was building Polaris telescope. It’s kind of like a tool from within Sketch, you could kind of like see the documentation for the design system components. 00:04:56 - Speaker 2: These were internal kind of plug-ins or tools at. Shopify or something for release to the outside world. 00:05:02 - Speaker 1: It started as an internal tool, but then since like Shopify is a public design system and is being used by third party people to design applications for the Shopify platform, we also kind of like made it available publicly. And during that time, I applied at FIMA. And one nice story was that at the end of my internship at Shopify, I had this option of going to FIMA and starting an internship there or staying at Shopify full time. And I remember my mentor telling me to kind of like take the job at Sigma because it was like, yeah, this is more interesting to you, you just kind of like go there and that was a nice kind of like end for this work at Shopify was very kind of like welcoming to let me go, if that sounds right. 00:05:43 - Speaker 2: That’s great, and this was early days for Figma, right? Pretty small team. I mean, I think nowadays it’s a giant in the design space slash startup space, but maybe this was a little riskier of a jump to go to this smaller, less proven team at the time. 00:05:59 - Speaker 1: Oh yeah, I think Stigma definitely hasn’t caught on as kind of like a major tool in the space at that time. Um, when I joined, we were, I think around 35, maybe 40 people in San Francisco, and that was it, like that was the whole company. And I think we’re now at above 250, but I’m not exactly sure when that is. I’m coming up on 3 years now, and it’s been fascinating to see. The change in the company itself or kind of like seeing it grow, but also just in the product and in the acceptance of the product in the market. Kind of like seeing how many people and how many companies have switched entirely of using FIMA, it’s still kind of like mind blowing that this actually has happened over the last years and yeah, it’s great to be a part of that. 00:06:42 - Speaker 2: Also seems fun to maybe grow in your career along with the company and see those, yeah, that rapid evolution, that hypergrowth over time can be nerve-wracking at times, at least in my experience, but also potentially really rewarding experience. It’s certainly a great learning experience. 00:06:59 - Speaker 1: Definitely, definitely, especially this aspect of Getting things kind of like onto a roadmap and actually making that happen. When you’re studying, you’re kind of like greenfield projects and you can like imagine the most beautiful things, but then when you’re building a product, you have to kind of like find a way for this to actually happen. It’s been interesting. I’ve been working on mostly focused on prototyping things and it’s been interesting that kind of like slowly we’re getting into this position where it’s like less features are immediately clear of what should happen, kind of like coming next. But it’s the things we’ve been talking about 3 years ago are slowly coming to the space where now they are actually being shipped, and we can now stand on top of them and look even further. And that’s pretty exciting to see that like these wild thoughts are now becoming reality, and now you’re thinking newer wild thoughts and I like that. 00:07:53 - Speaker 2: How do you find designing for designers? On one hand, maybe that sounds great cause you can maybe introspect your own needs a little bit, but on the other hand, it sounds miserable because they’re incredibly fussy. 00:08:05 - Speaker 1: I actually love it cause imagine the case where kind of like I would now just be a designer, basically, and I would like have all these ideas of how this design tool could be better. I kind of like love working for designers because seeing what they do. With the features that you imagine, is so much cooler than the feature itself. So kind of like building things where other people can build things, it’s just really rewarding that on one hand, and then the other hand is that having designers and user tests, but also kind of like having designers design features for you. Because I really want this feature. It is amazing. Just today, I’ve seen a tweet thread about how comments in Figma could work and it’s just amazing of how much detail and how much love people put into these ideas of helping us improve our product essentially. 00:08:54 - Speaker 2: And speaking of that, I’ll also throw out, you are a new user and customer, so thank you for your business. That came to mind because, yeah, you’ve given us really great long detailed feedback along the way, both in the forms of concrete suggestions, you know, it could work like this. But also I think cause you know what it’s like to be on the receiving end of that, sometimes more the why, like what’s the problem you’re trying to solve, what’s the feeling you’re having when you go to do a particular thing and you get this particular result, and I think you, you started with us around the time of the beta, and you know, then it was a pretty rough around the edges thing and you saw the potential, but it didn’t really Fit into your flow, but you gave us great feedback anyways and kind of check back periodically and eventually became something that hopefully fits into your creative workflow a little bit. 00:09:38 - Speaker 1: Oh yeah, it’s amazing. Like, I’ve been using it a lot more recently, especially since the alpha of like the 2D canvas. That has really changed the game for me, but I think especially kind of like seeing new too of like from a more, I would say maybe more research experiment to actually kind of like, hey, this is a day to day tool for me. And what I love a lot is how the relationship to the device changes based on the input. Just through using a pencil, it’s just a significantly different experience, a far more intimate experience really with the device, because it really feels like just I’m writing on paper. Paper with superpowers, right? Like I can drag things around and I can really easily switch my tools, and so I love using it. It’s really great. 00:10:22 - Speaker 2: Awesome, thank you, and thanks for the new marketing slogan. We might need to swap that out on the website. People with superpowers. So our topic today is collaborative creativity. And this is something, you know, Mark and I have been talking a lot about, we’ve been talking about a lot of the team because as we think about sort of multi-user features and when or if those make sense for you, and in general, I think the incredible collaboration features that are in a lot of the current, let’s say, suite of tools that a lot of folks in the tech world use, that’s Figma, of course, but it’s also something like Notion, Google Docs going back a little bit further, maybe something like Air Table, and so then you have this question about like how does solo work work or how do we sort of interleave together the solo time and then the working with others, you know, pairing or whatever you wanna call that, there’s feedback cycles and all that sort of thing. So to me it’s a very vast and interesting topic and I know you have a pretty developed, it seems to me from our conversations in the past on it, you have a pretty developed or rapidly developing, let’s say thesis on this, so why don’t you tell us a little bit about how you think about collaborative creativity. 00:11:31 - Speaker 1: I think it’s interesting also kind of like tying back to how you introduced me in the beginning, that this is a topic I’ve ultimately been working on for a couple of years now, on and off really. But my bachelor’s thesis was on this aspect of personal creativity and knowledge management, and I think at the core it’s kind of like, where do ideas come from and how could computers be set up to support these. But then recently kind of like flipping a lot more around this value of iteration, as kind of like working on Figma as a design tool, but also the value of collaboration and the combination of those two. And I think that the concept of collaborative creativity includes all of those aspects and kind of like brings it together. And I think it’s interesting that really fruitful moments where working together with other people, those memories just always kind of like relate to being together in the same physical space. And being able to work on top of each other’s ideas really fluently, and because we trust each other, we can like figure out a problem that we have in our heads really, really quickly. And this kind of rapid iteration, this rapid building on top of each other’s ideas is, I think, at the core of collaborative creativity or is collaborative creativity itself. 00:12:45 - Speaker 2: So, give us some examples of collaborative creativity. There’s obviously like, I guess what you described there is sort of being with your colleagues, you know, in a meeting room, brainstorming on a whiteboard, but how do you see this, especially in the modern distributed world. 00:13:10 - Speaker 2: What I’ve recently seen on Twitter a lot, it’s also funny but like I’ve seen these things on Twitter, but like these TikTok remixes, and I think just recently there’s this like sea shank, the sea shanty TikToks, those are great to describe what those are in case you haven’t seen them is basically people singing these songs in harmony, but they do it by one person records singing. And then the next person essentially layers their singing on top of that video, and you see all the faces and hear all the voices together, but of course it’s a very much an asynchronous process in many cases I think these people didn’t even necessarily know each other. 00:13:37 - Speaker 1: And I think that’s just so fascinating because it’s really good and I think it’s a different example. So while this collaborative creativity in the whiteboarding space feels more like an immediate way of collaborative creativity, this is definitely, it’s still the same core idea. It’s just kind of like happening asynchronously. And I think those tools like TikTok allow for this to happen because I’m able to build on top of your idea. I’m able to take your idea and not necessarily manipulate. directly, but adds to it, which creates this fascinating effect. 00:14:10 - Speaker 2: I feel like that takes us to the whole realm of sort of maybe like remix culture, certainly open source is very much built on that as well. And of course a lot of discussion, maybe not so currently, but maybe in the last decade about kind of copyright law and how that in many ways interferes with this potentially great remix culture. You had DJs and that sort of thing. You see that in the spectrum of collaborative creativity. 00:14:36 - Speaker 1: Oh yeah, definitely. I think it’s an important aspect, and we’ll get later in more detail to this that like the ultimate or kind of like original owner of ideas should be in full control over what others can do with this, essentially. I think that’s a key part of establishing trust in such a kind of like network of people who could work on the same thing. And I think that that’s one aspect of how to kind of like establish this way of working. 00:15:04 - Speaker 2: I mean, idea ownership is so fuzzy, even if you leave the realm of, I don’t know, public copyright, intellectual property, whatever. I think even on a team making a shared document, in most cases the teams I’ve been on, I and others on the team feel sort of uncomfortable doing heavy edits to someone else’s documents unless they were very specifically invited. You know, you can leave comments, maybe you can make a little fix, good suggestion changes, you can add something to the bottom, but you have this sense of like, OK, they own this and you don’t kind of want to mess it up. You feel like you’re a guest there, even if it’s in a team workspace, just sort of an interesting, I don’t know, we have this innate sense of ownership, I think, over ideas or a creative output, which may or may not be logical, but nevertheless seems to be part of the human experience. 00:15:52 - Speaker 1: I wonder how much of this ultimately comes back to the tools themselves too, in the sense that what I’ve seen happening in teams using FIMA a lot, that kind of like allowed this very immediate way of collaboratively iterating on the same space that person A creates an idea, creates a couple of marks for this. Person B comes in and takes kind of like the second. and explores the second mark further. Person C kind of like uses something else and kind of like just draws out their their direction of this. And at some point, maybe some person zooms out and sees the connecting dots between of those and kind of like puts these things together. And I think at that point. What has happened is that people inspired each other, but it’s very, very fuzzy of kind of like who had the key spark of it. And so I think at that point what we’ve seen happening, that’s actually really fascinating is that the culture of teams changed towards a culture where it feels more like our ideas over my ideas. Where just because the tools are not just because of those tools, but also because of the tools, it enabled people to take that ownership less seriously, because they realized if we take that ownership less seriously, we can actually arrive at better solutions down the road. 00:17:08 - Speaker 2: Yeah, that makes sense. And even speaking in terms of just coming back to the more just brainstorming in a group verbally or whatever, one of the ways I know the best collaboration, some of the people that I’ve worked with over many years, including Mark here, is that often it’s just not really clear exactly as you said, where the idea came from, and every so often I feel like I catch it in the moment happening. There’s one case I remember of, we’re trying to, I think it was actually just a debugging kind of scenario pair programming kind of thing. And the way we found the idea that ultimately was the breakthrough was actually one person said something and I misheard them. I was like, oh, that’s brilliant, that’s totally it. And, you know, they respond with, oh no, that wasn’t what I was saying, but now that you mentioned it, and so, wait, whose idea was that exactly? Clearly it was the product of our back and forth to claim that was one person’s idea would be, I guess, like a pointless endeavor to try to assign it to a single name. 00:18:05 - Speaker 3: Yeah, I think it’s absolutely the case that creativity, whether it’s among multiple people or with yourself over time, is a very iterative process that involves taking a lot of ideas, remixing them, borrowing stuff, eliminating stuff, adding variants, exploring, playing. I know there’s something you’ve thought a lot about because I’m curious if you have more theories on how this works. 00:18:27 - Speaker 1: One thing that during our bassists thesis and also kind of like now getting back to this a lot, is this concept of bisociation from Arthur Koestler, and it’s essentially this idea that Any form of kind of like creativity, be it like humor or science or art or conflict just I would also just include problem solving, is this aspect where you have a spark that ultimately originates from two orthogonal kind of like planes of thought or two orthogonal kind of like spaces of ideas, and because they meet. They create a new thing or when they meet, they create a new thing. It’s slightly different than association, which just means the connection between those two things, but that the connection itself is a new thing, existing from two independent frames of thoughts. That’s like at the core of where ideas come from. 00:19:16 - Speaker 2: Yeah, I even go so far as to say, or maybe I’ve heard creativity defined as connecting unrelated ideas, but maybe where this fellow Arthur Koestler, I guess his last name, where his work maybe it’s this idea of two different frames or two different domains where it’s an unexpected connection, and in fact one of the things that I think I see written in kind of like how to have good ideas type. Books like Steven Johnson’s works or whatever, is often about people who are in different domains. They work in one field, for example, and then they go to solve a problem in another field and they’re able to apply ideas that are commonplace in one field in this new place, and that’s that weird intersection that produces something truly new. 00:19:59 - Speaker 3: Yeah, and I think part of the challenge here is the ideas need to be primed in a sense to be joined or synthesized. So that’s why things like chewing over ideas, discussing, debating, remixing, these are all different ways to basically ruminate on the content, and by doing so you sort of prepare it for synthesis with another idea. 00:20:18 - Speaker 1: Exactly, that was one of the things that was also really fascinating to read through, is basically kind of like debunking this myth of this eureka moment. Whereas like, you expect this eureka moment to be this like singular entity where everything kind of like goes from 0 to 100 and it’s like all kind of like falls in place, but then you look closely at these stories around Newton and around Darwin, and you kind of like see that they have had their theories around for years before this, and they were really close. And so it’s not that in this eureka moment everything fell into place. It’s just maybe this last thing connected. But 95% of this idea was likely existing already or of this theory or of this concept. 00:20:59 - Speaker 3: Yeah, and a sort of corollary of this is that you can’t stare at something too hard. Like if you just sit down and think really hard about a particular idea or even a particular problem, you’re likely to be too constrained in your thinking, you’re get a sort of tunnel vision that obscures these other ideas that you need to connect in. So you really have to step back, chew on some other domains, chew on some other topics, and then hope that eventually it will sort of pop out as a synthesis with your other problem domain. 00:21:24 - Speaker 1: There was some interesting research we’ve read into and if there’s any kind of like neuroscientists there and I’m like representing this inaccurately, let me know, but that basically you have a set of stacks of possible kind of like positions for thoughts or snippets of thoughts, and between that stack you can create connections. And if this is a new connection, that would be considered an idea, and you do that in your subconscious all the time. But basically, when you’re staring at something for too long, all of your stack will be kind of full with all the things you’ve read and worked on. And there is a point where you just don’t see any new angles on this content, cause like the stack is the same things since 3 hours, but then you go outside, you summarize these stacks. They become kind of like less defined and more blurry, and then you see a dog walking around and some other things kind of like are popping up, and suddenly they’re like, oh, I could connect those two together, because suddenly you are free of these distractions. That’s the perfect shower moment actually fits perfectly into this. Because in the shower, there’s just not a lot of things you can do in the shower. You’re kind of like just naked there and alone with your thoughts, quite literally. 00:22:37 - Speaker 3: Rich Hickey makes a similar point in his talk, hammock Driven Development, which I very highly recommend. 00:22:44 - Speaker 2: I’ve probably recommended it on this podcast before, Mark, it’s always tricky because I think you’ve mentioned that enough times now. I’m probably gonna stop putting it in the show notes. OK. But clearly I can see it’s a high impact piece, so everyone should go and read it. 00:22:56 - Speaker 3: He makes the point, there’s also a sort of priority que element to this, which is you have end domains that you’ve ever thought about, but to pick a number, the top 7 that you’ve thought about most recently are sort of candidates for this background mind synthesis to happen. That’s not exactly true, but there’s a sense of the things that you’ve chewed on more recently. are more likely to be part of a synthesis of an idea. And so part of the work is actually to constantly shuffle your priority cue around by changing the ideas that you read about or think about together in time, and eventually you kind of find the right combination of 7 things in your head in the shower and out pops the shower idea. 00:23:31 - Speaker 1: I think this is great. Yeah, there’s a ton of approaches on how computers, but also just processes and behaviors can support this concept of by association, kind of like make the right content available at the right time is something where I think all played with of recommended content, right? But also. As a way to structure your research in a different, more natural way, ultimately follows the same goal. It’s about kind of like making the content, the knowledge that you have available at the right time, so it can be in your head, so you can connect it to other things, to new ideas. And I think that’s also where I would place muse into the space, that kind of like it’s a space primarily for kind of like maybe marinating on your ideas and exploring it maybe in different ways. Here’s a PDF, here’s a video of someone explaining this. How do you see the role of muse in this personal creative process? 00:24:25 - Speaker 2: Yeah, for sure, that’s certainly exactly how I use it. I feel like one of the cornerstone maybe features we introduced was the excerpting, which the idea of pulling out pieces. This isn’t quite a remix, it’s almost the reverse of that. It’s almost like a deconstruction, and for me I often have successive stages of that, which is, OK, I’ve read a few books on a particular topic. Now I wanna go and kind of apply that knowledge to a domain. And I’ve got my Kindle highlights and I’m pulling those, and there’s a pretty easy way to pull that in this PDF to muse and then I’ve sort of got those there and I can go through it and then I can pull out of my highlights, sort of like highlight my highlights or something like that, but I exert out the ones I think are most relevant. And then importantly order them, so they’re sort of near each other in different combinations, or do a little bit of the affinity mapping thing or something like that, push it around, but yeah, part of what I’m trying to do there is boil down to some components that hopefully for me will add up into a call it a new idea or a strategy for whatever problem I’m specifically trying to solve in the moment. 00:25:35 - Speaker 1: I think this fits into what we learned during our special the well. We interviewed an historian and she had a word document, which was, I think, up to 300 pages long, and it was just a glossary of words and references to other places where she’s read about these words in other books and other sections. And just that document alone, it was just 300 pages of references to other content. And just seeing that and how people use even a very simple tool like Word basically for something like this knowledge management task, like this humongous knowledge management task was pretty inspiring too. 00:26:13 - Speaker 3: Yeah, I think there’s an interesting spectrum here with tools for thought in terms of how explicit they try to make these connections and how much the tool is actually designed to output those. So Muse is, I would say on the end of the spectrum, it’s more like you’re meant to marinate with your content, then it’s swimming around in your head and out are gonna pop new ideas from your head. And that’s good for like intuitive domains and coming up with new ideas and brainstorming and things like that. But then when you’re writing a history paper, for example, you need extremely specific documented references, and so there it’s more important to have a very explicit trace of every connection that you might have made in the past so you can substantiate all your claims and have all your sites. And I think both of those things have their place, but I think it’s important not to confuse their purposes. I think you can’t force having new ideas by kind of structuring all your stuff in a graph or something. And conversely, if you try to intuit your way to a history paper, you’re gonna have a bad time. So I think that both of those extremes have their uses. 00:27:10 - Speaker 1: Definitely, I think that another thing that fits into this is how can you frames of thought come into your mind, kind of like diving more more deeply into iteration itself. I love this model, this, I think it’s a mind sketch model from Bill Buxton that is kind of like outlined in sketching User Experiences. It’s an amazing book. My roommate recommended it to me because he did his bachelor’s thesis on how to prototyping tool, and he basically gave this to me, I think 1 year ago or something, after I was already working for nearly 2 years on prototyping at Figma, I hadn’t seen that book before. And then when I read this, like a lot of what is today originates from this book. And the core process of federation is this aspect that you create something, you externalize something. Because you externalize this knowledge, you can now take a step back and evaluate what you’ve created and learn from it. 00:28:05 - Speaker 2: Yeah, and in Buxton’s model, that’s the sketch. And when he talks about making a sketch that has this very, it’s not just a pencil on paper or that has a particular line width or something like that. It’s specifically that it is a very rough and purposely Not complete, leaves a lot to the imagination, maybe raises more questions than answers, but it is this externalization that then you can step back from. You can both share it with others, but even just yourself, you can step back from, you can look at it, kind of look at it from different angles, squint at it a little bit, and it will reveal new things that that same idea just purely in your mind might not. 00:28:45 - Speaker 1: Exactly, exactly, and I think that’s just amazing that that’s possible, that we as humans are capable of doing this, of externalizing our own ideas and then gaining new knowledge because we’ve done that. Like, where does this information come from? 00:28:59 - Speaker 3: I think there’s actually a lot going on there, right? Because some of the knowledge you get from the process of actually having to externalize it, cause you’re changing the format basically, and that involves processing of everything. You’re also learning by looking at it and seeing, for example, the empty space, which wouldn’t have been present in your associative mind. And you’re also learning at it by being able to show people. You’re also learning by being able to refer to it later in time, and you’re also freeing up space in your mental priority queue because you no longer are subconsciously thinking, I have to remember this, I have to remember this. So it seems like a simple thing, but there’s so many different ways in which you’re learning just by doing the simple process. 00:29:34 - Speaker 1: What I love is, or also where the core of my thesis is placed around is essentially, what are the models now with collaboration that fit into this? Cause you mentioned it that collaboration can help with this process as well. And of course I can show it to someone and they can kind of like communicate things back to me, and they can talk about this and directly give me some kind of advice on how to change things. But I think it’s interesting to look at it more closely on collaboration through creation, or communication through creation or manipulation, essentially, that if I create something and let’s say I create a file, I create a design file, and I sent this design file to you, and now you have a copy of this design file, and you make changes in this design file and send it back to me. Or I just kind of like take a screenshot and send it to you and you scribble on top of that screenshot and send it back. That’s the first step, kind of like the first model of collaborative iteration, and I would call it kind of redundant collaborative federation, cause we duplicate these objects, and because we’ve duplicated these objects, we can collaborate on those, and I think that has been in a lot of times the way we just collaborated on nearly anything in the digital space. Like duplicating things in the digital world is slightly harder. But in the digital world, it has been like this since email basically existed. 00:30:55 - Speaker 3: And I’m curious if you see that as a strictly inferior form of collaboration or if it’s more like a different mode. So to my mind, to my hand here. I feel like that’s one of a few possible modes of multi-user collaboration and it has its uses. So for example, when Adam and I are writing, we’ll often have a draft and we’ll send a bunch of other individuals their own unique copy of the draft so they can be able to write whatever they want and they’re not getting groupthink by seeing everyone else’s comments. And then we take all those comments and we synthesize them in another draft, and then you might go into another type of collaboration, which is everyone’s looking at the same document and making real-time edits because you’re kind of converging. It’s a different use case. 00:31:31 - Speaker 1: Oh yeah, definitely, and I think that that was one of the big steps basically that for me at least internally you kind of like wrapping my head around this, is not looking at these different modes of collaborative federation as good or bad, but it’s just solving different types of problems, solving different kind of like steps in the process essentially cause what you’re saying is totally right, like what this redundancy also helps is comparison. And when we talk kind of like more detail about these like open canvas tools like Figma. What happens a lot of times just inside of those is redundant iteration as well, right? Like I’m duplicating this frame, I’m just not changing this frame because I need the ability to compare this. What you’ve kind of like mentioned is the need for different audiences of people ultimately, and different audience levels have to respond to the relative content level inside of there. If there’s a lot of work in progress comments. That you don’t want leadership to see, you might want to bring this into a different document where there’s an empty collaborative space. So that definitely makes sense. I think it just solves for different purposes. 00:32:36 - Speaker 2: That potentially could take us to a whole other space or a whole other discussion topic, which is feedback, what is feedback, how to give good feedback, how to solicit good feedback. Probably we don’t wanna, uh, get too diverted on that, but it, it comes to mind because talking about the different audiences, if you’re presenting something to your boss, to a client, or to anyone where you know their time and attention bandwidth is limited, and you want to get there. Like big picture view on things or just kind of a thumbs up, thumbs down, or keep them in the loop. And that’s different from, here’s my teammate, we’re both collaborating on this thing and we want to really go into all the fine details together. You’re just seeking something different from the feedback and being aware of what it is that you’re seeking in that feedback loop can help you have the right format or the right level of detail. 00:33:25 - Speaker 1: Exactly, and I think that for a tool or for a creative tool, essentially, it is important that people are in control. Like this is kind of like looping back to what we’ve discussed at the start, that people can be fluently moving between the different ways of collaborating, and that they kind of can invite the stakeholder with certain permissions, and the client with certain permissions, and the teammate. And I think the question is kind of like, can this still happen in the same space, although those people have different permissions. 00:33:58 - Speaker 3: Yeah, this is something that I feel like we’re still organically discovering as tool makers. So if you go back to the before times where everyone was emailing attachments to each other, that worked very well for the what you call redundant collaboration use case. You just send someone a copy and they can do whatever they want, and then we’re done they can send it back. But then if you want to have a Shared unified state somewhere, that’s really hard in that world. And then we got this whole world of new tools including Sigma and Google Docs, and that makes the real-time synchronized shared collaborative space, first class, but I feel like sometimes it actually makes it hard to do the individual private collaboration, often just because it’s really hard to make a copy of stuff. I feel like in Google Docs, for example, just to make a copy of a document is a bit of a heavyweight operation, it takes a few seconds and makes weird names and so on. One of the reasons I think it happens more often in Figma is that it’s very easy to make a copy, especially if you’re doing a very lightweight copy on the same canvas, you just highlight command C, V, I think, and that just pops out a new version, then you can kind of scribble on that and then go back and do your merge later. Another tool example here would be Git, which I feel like has its UX challenges, but it does get this right. Well, plus GitHub. It didn’t have this before GitHub. You know, the local Git gives you the privacy to do whatever you want and mess with stuff, and then GitHub provides the unified central state. 00:35:13 - Speaker 1: Exactly, and I think that I would categorize all of those into kind of like restricted collaboration or restricted collaborative federation because they somehow constrain how the different people can manipulate these shared objects. Either they kind of like restricted through having a private copy first that you need to kind of update manually or through kind of like enabling people to limit someone’s access in there. One thing that I’ve seen quite often now is that in Google Docs and in paper, the like, is that people create their kind of like appendix, trash, don’t look below here. Yes, these kind of spatially close areas because it maps toigma too. I was like, here’s my trash area, don’t look at these things in here like, like, like please don’t, these are bad ideas. There’s an interesting aspect there that I would love to dive deeper into at some point around like, why can’t we let those things go. Oftentimes you don’t look at these things, but you kind of still want them to be there. You want them to keep them around because in the case you need them. You feel really bad if they’re gone. 00:36:17 - Speaker 2: Yeah, old notebooks is the same way. Even older muse boards for me in a lot of cases are things that are mostly just historically interesting. Every once in a while it’s kind of cool to be able to reference it, but the reality is, you want that end thing. You usually don’t need any of the steps that led up to it. Get history. the same thing. Like you could probably for almost any project, go in and chop off all the Git history from, you know, prior to a week ago, and it wouldn’t really make any difference for any day to day work, but yet there’s that feeling of something lost, something important that every once in a while it’s nice to be able to reference. 00:36:55 - Speaker 3: Yeah, so I feel like there’s that temporal angle of eventually you might want to archive something, but I also feel like there’s sometimes a tooling limitation where, especially in these modern apps, they’re very oriented around enterprise work groups, and so if you want to have a personal space, it’s a little bit unnatural, you either need to go out into your my driver. Something which is a whole ordeal, or you need to effectively carve off your own little personal space within a document by hitting enter 10 times and saying mark notes and typing below that. And one of the things we’ve explored in the lab and with views is, can you make that more fluid by making the transition between the personal and the collaborative space much more seamless. The analogy that I always come back to is the university department. where you have a private office and you have your faculty lounge, and you can take a few steps over and back and you can bring your papers over and back and you can check out the whiteboard across the hall. And that’s sort of very seamless collaboration, where it’s all the same office building, it’s just different zones are demarcated slightly differently, and it’s very lightweight to move in between them. That’s the kind of vibe I’m hoping for with digital tools. 00:37:57 - Speaker 1: Yeah, I think that would be amazing. Like the current solution basically in Figma is that like drafts or new files always open in drafts and drafts are private by default. So that creativity as an intimate process can start in private, because oftentimes there’s a ton of internal barriers in your head of like, is this really a right idea? Do I want to share this? There might be kind of like external barriers of a culture in which kind of like bad in quotes, bad. Ideas are shut down from the beginning, or you’re fearing being judged for those ideas or just sharing those ideas in general. And I think there’s a ton that like how this flow can just feel a lot more fluent as you described. I could imagine like news sports, basically, this is my private news board and we can be together in the same news port, but down here, like inside, I’m zooming into this space, that’s my office space, right? Yeah, exactly. This is new. Because office space, you’re just technically not allowed to go in there. I think there’s a ton of fun stuff of how the interface paradigms will change the relationship of how we look at these digital collaborative spaces and how we also kind of find ourselves leveraging the cultural habits that we have with shared physical spaces and bringing them into these digital spaces. If you’re in an office building, it seems like decades ago that you’re like in an office building, right? But like you have this cultural understanding that you don’t go into someone else’s office, especially when there’s other people sitting in there. You just wouldn’t do this, right? And in digital spaces, it feels different, but I’m interested to see kind of like how this will evolve over the next 5 to 10 years. 00:39:28 - Speaker 2: I think learning from the physical spaces and the social cues and all that that we’ve built up over a very long time and trying to bring some of that to digital. is certainly a rich well to tap. I also feel like sort of video chat and screen sharing and things around the live synchronous video and audio might also have some clues for us. One to me that’s pretty telling is the screen share stuff, which of course is just huge for a distributed team, and I’ve gotten pretty handy with setting up my screen in a particular way so that I’ve got a window to share that’s kind of the right size and orientation, so it’ll look reasonable on most people’s desktops. But then if you actually have a multi-window flow, you wanna show, now you kind of need to share your whole desktop, and for some reason that seems way more intimate. I don’t even have, like, I don’t know, text messages going to my Mac, so it’s not like someone’s gonna see a personal message come in on my notification center, I don’t think, but still there’s this. that that’s a much more really letting someone into your private space, which is kind of interesting. And then, of course, there’s all the stuff around. If you have other devices that you need to show like an iPad, or you’ve got an external camera that’s showing, which we often need for showing a person actually using the iPad with their hands. So I feel like there’s a lot there that affords opportunities, but also we need to adapt to and how we think about collaboration and privacy and synchronous and asynchronous for how we work together in, let’s say the modern virtual office. 00:40:57 - Speaker 3: Yeah, I’ve mentioned this theory before that a lot of collaborative and social technology first appears in games. And according to that theory, within a few years, professionals will need to use OBS to do exactly that. I don’t know if you’re familiar with OBS, but it’s a program for streamers to basically render their stream from a bunch of different windows and graphics and stuff and kind of. Deposits it all together into whatever they want to present. And I actually know some professionals who do use this for things like teaching classes where you need to composite a bunch of stuff together. Well, the best program in the world for that is what streamers use. So just use that. And I wouldn’t be surprised if that or a technology like that becomes standard in the same way that microphones and ring lights and all that stuff did become standard for office workers. 00:41:37 - Speaker 1: Zoom definitely, I think there’s Studio Beta, which is I think basically like Snapchat like filters for Zoom, and I think there’s some feature in there that look like integrate kind of like a PowerPoint slide presentation, right, into your background and maybe key things out or something. And I think that’s a start in this. I think you’re totally right that like these things will just become a lot more accessible for day to day work of kind of like creating these mixed media streaming environments. One thing I’m really interested in though is this aspect of kind of like what makes this work ultimately in the end, like, what is the oil for this collaborative iteration process of we are improving each other’s idea really work, and I think that there’s a bunch of things to dive into in this aspect around the culture for collaborative creativity. Cause we’ve touched on it a little bit, but this aspect of people can feel comfortable sharing bad ideas, essentially, is what at the beginning of an iterative process, right? Like the ideas you’re going to share are not ideal. And if we look at collaborative iteration and we see that there’s value in bringing people together that trust each other, what cultures would we have or kind of like what cultural shifts would need to happen for this to become more fluent. 00:42:55 - Speaker 2: Well, trust certainly seems like a huge part of it, and that’s how you actually build trust on a team, you know, it’s one thing if you’re longtime friends or longtime collaborators, but when you have particularly, for example, a fast growing company, as we were talking about earlier, and you have essentially relative strangers, maybe from different backgrounds that come together, it’s probably even harder when you have less or no in person time. In the world we live in now. And so, is that something software can solve at all or is this purely a classic human management problem and we need to like do exercises where we fall backwards into each other’s arms in order to be able to make a a shared document uh together successfully. 00:43:34 - Speaker 1: I think it’s actually kind of like interpersonal maturity and interpersonal relationship that we have to learn through the tools. Tools can give us guardrails. Like, if I know that this is a production thing, this is the thing that is used in production, I’m definitely going to kind of like use GitUp and will restrict the access to this and maybe only allow me to merge things into the main branch and like have these guardrails and structures in place so that collaboration can also grow in this environment. But then separately, being together in the same file at the same time. At any point in time, you could hit command A, select everything and hit the delete key and just get rid of everything that’s there. Yet we still don’t do it. So the tools still allow this. They still allow fucking up each other’s work. So the fallback has to be a cultural way of working together. But one thing that we’ve seen with Sigma is that Sigma grows rapidly inside of a company once you invite other people, and they kind of, they invite other people, they create content, they invite other people, so it’s beautiful to see that. But then separately, one thing that at the beginning seemed kind of like independent of all of this was that like Halloween 2019. I’ve seen a lot of people dressed up as figma cursors for Halloween. And I was like, why is this happening, right? Why are you dressing up as feeling my curses? Why do people have kind of like group costumes where everyone is a thing about curses and they’re just like roaming around this like space. And it’s been fascinating looking back at this, because I think looking at the culture and looking at the tools, is that what FigMA had enabled for these teams was that they trusted each other, and now they were able to build on top of each other’s ideas in a far more efficient way than they’ve ever done before. And it might have even helped them to establish these cultures in the first place. To be like, now that we are in the same space, this maturity of how we work together becomes more important. We see how beautiful it is when it works, and now we actively want to work towards this, so that it’s not kind of like, oh yeah, this is like randomly happening, that I’m able to have another idea because you’ve had an idea and put this down and shared it. It’s not serendipity, it’s actually something that we can actively to work for. And so I believe that like the tools that open up these collaborative processes actually can incite a change of making cultures more inclusive and more open and more respectful to work with, and especially getting rid of the Steve Jobsmith of like, hey, good feedback is like direct feedback, right? Like this is dog shit. It’s not gonna help you in the long run build better ideas or come up with better ideas. 00:46:17 - Speaker 2: On the feedback side, I feel like the culture, it’s culture, it certainly is trust, but when I’m working with a new person, whether it’s on a writing project, something product design related, or even things externally in my personal life, you know, collaborating with a cohabitation partner on Decor, for example, I feel like when you’re first doing a project together, you’re first exploring that part of a relationship with someone, a new colleague, whatever it is, and I’ve sort of learned to prime people a little bit though, like, if you share something with me, I’m gonna give you tons of feedback, usually. Like, often I’ve gotten the feedback on my feedback that it’s sort of a fire hose and can be overwhelming, and I’ve actually learned to even try to trim it down a little bit to like the key points. But that’s also because it’s kind of a golden rule thing, that’s what I like to receive. And in particularly I like really stream of consciousness feedback. I don’t want you to do my thinking for me. What I want you to do is react. I want your hot take, I want your snap reaction of this made me feel like this, and this made me feel Like this, and this made me angry, and this made me happy, and this made me confused. And, you know, it’s not to say that every single point of feedback is something I’m gonna do something about, but that overlaid with feedback from others is how I get a picture of how something I’ve created is. Perceived or potentially could impact an audience, but that’s not necessarily maybe how others work, and maybe they’re surprised by that in both directions. So I really try to establish that up front. You share the thing with me, I’m gonna give you this style of feedback, and likewise, if I’m sharing a thing with you, this is what I want, is this kind of heavy feedback. 00:47:52 - Speaker 1: Yeah, and I think like getting everyone to share these thoughts in the first place, I think is going to be a big change instead of companies where with tools like FIMA, people now have the ability to communicate visually. Anyone in the organization now basically has the ability to communicate visually. But that they are actively actually doing this and using this requires them ultimately to put down ideas that they might not be sure about at that point. And that might be common for designers, right, to kind of like share early thoughts. But if we talk about kind of like PMs or engineers who may have a design idea, or an architecture idea of how something could work, maybe slightly differently, or if the user flow kind of like breaks off here and goes to the path, those things can be amazing ideas even if they’re just shared in the form of a diagram, or a little scribble, or a little kind of like, I don’t know, just like jotting on something, yeah, but those people have to also feel comfortable in sharing this in the first place. And if you’re an engineer in a company or if you’re a PM in a company and you might not be sure of how this design tool space is owned by the designers, right? Can I use this? Does that make me a designer? If that makes me a designer, are other people like annoyed that I call myself a designer, like, there’s nothing about this. It’s just kind of like a core skill of being able to communicate visually, and it can help discussions, especially if that happens in spaces where other people can take those visual objects. And immediately iterate on them. Like we’re still in this concept, we’re still in a space where people can work on top of these ideas again. But I think the key barrier that we’ve often seen is that people kind of like are a little bit shy of sharing this idea in the first place, cause they might feel that, oh, this like, will shine badly back to me. And I think that’s a call for designers essentially of sharing the bad work more openly. We have a design work in progress channel and it’s fascinating to see how much is like work that’s just happening is visible there. Although it’s not always polished, although it’s not always kind of like perfect, it’s so just like, you see that these things are happening. And it has become kind of like one of the most active channels because it established a culture of a different kind of critique, not this culture of kind of like, hey, we shouldn’t ship this, right? Like if you share something in this official design critique channel, you might get feedback of like, hey, maybe we shouldn’t ship this. This is not up to our quality standards. But then it’s like work in progress channel where the quality was just said very differently. The feedback is a lot more of like, yes and style, of like, oh yeah, we could do this too, or like, hey, this could fit into this project that I’m working on, and it feels very different culturally. 00:50:25 - Speaker 2: I have the sense, maybe it’s a stereotype or just reflects some of the designers I’ve worked with over the years, but the designer archetype for me is someone who is much more likely to want to stay in their ivory tower longer and kind of really polish something until everything is completely perfect and without any conceivable critique, and maybe to a straw man a little bit like a delicates. Flake, where when someone says, you know, I don’t completely 100% like this, they’re very upset and maybe engineering types, again, this is perhaps just a stereotype, but are more likely to be a little more willing to take feedback on work in progress. I don’t know, do you think that’s accurate? Is that an outdated point of view, or is that accurate, but something you think you and your team are working to change with your product? 00:51:11 - Speaker 1: I’m lucky that I can say that it’s like outdated for me, that the people that I work with are at least kind of like don’t show this kind of behavior that significantly, at least. I think it definitely exists. It definitely exists. I remember reading the first comments of Figma being published on design and use. If this is the future of design, I’m like changing careers. And I even remember the video, I think. It was like from Sandwich video, this like first initial teaser ad of route Pigma when it first launched, and I remember kind of like it showing a use case where someone just moved something like 10 pixels. Some senior designer moved something 10 pixels and it’s like, oh yeah, I just tightened it up a pitch. And I’m like, if this is the future of collaboration, I wouldn’t be sure if that would have worked. But I think this aspect of once you feel the value of other people adding freely to your ideas, and at the same time also being respected for the things that you’ve done, and you realize that you can now take from all of these ideas and you can like combine them into new ideas, and those are maybe your ideas again, that feeling of being able to tap into everyone else’s mind. I think it is amazing. And one thing that comes to mind is something that started very early on at FIMA that ultimately kind of like kicked off this value of collaboration or this thinking about the value of collaboration a lot more for me, because I initially joined Figma because I liked the components overriding behavior. I was like, hey, this is cool, like I can overwrite more stuff than in sketch. So I got intrigued by that, but then I joined Figma and I was working on the common pins and I just like outlined a couple of the states that we need for common pins. And we joined into the design grid. There’s just a couple of people. Dylan was also working joining Design grids at the time, that was kind of like how small the company was. And then we just for 15 minutes just riffed on top of each other’s ideas. And then I went back from this design grid room with this file in my computer that everyone literally around that has something to do with design at FIA at the time worked on. And it was an amazing feeling because I’d sat there, I was like, there’s so many good ideas in here. And the beautiful thing was that they were not named. I wasn’t even sure who created which parts in this document, and my role as a diner was then to look at these things and see kind of like, how can I combine them into something that is most promising. And so coming back to your question, I hope that this experience pushes people towards working more in the open. Because they see the value of this open iteration, they see the innovative value in being able to tap into other people’s minds, cause there’s more to tapping to other people’s minds and sending something and asking for feedback. But listening to feedback through allowing other people to create in the same space that you create with the right people can definitely feel magical. 00:53:57 - Speaker 2: It’s really powerful, and yeah, it’s kind of vulnerability, but then if you open yourself to that, it’s simultaneously open yourself to it with a team of other people who are doing the same thing, and then have that experience of the shared mind and how much more powerful that is, then maybe that. Charges you up to see the value of it and be more open in the future. Whereas maybe if you get the reverse experience, if you try to open yourself that way, you don’t have the right team or the right culture or the right setting, and you get shut down or you feel rejected or something like that, and then that’s maybe a negative feedback cycle of the same kind. 00:54:32 - Speaker 1: Yeah, exactly, and this is also one of the underlying motivations of why I’m trying to build this model on top of the core aspect of what thought or creativity is for a single mind. That, you know, creativity is pushed through having a diverse set of thoughts in your head, and that the question is, how can these diverse set of thoughts come into your head, and that at that point, you realize that like if other people share their bold ideas and if you’re comfortable sharing their wildest dreams, even though they might be kind of like going against company policy or something, that those things can be the missing spark that someone else needs. And so that because this is tied to kind of like the core aspect of creativity in the mind, you can’t really argue with this. And so that I hope that through this and through experiencing this and the tools and the products that we build, that companies see the value in an open and inclusive design process where people can feel safe of sharing ideas and do not have these experiences that you describe. And I hope that in the next 50, 100 years or something. That’s just seen as an old way of working if you don’t allow people to work like this together. 00:55:40 - Speaker 2: I feel like I can see a parallel there with open source, and in fact the style of working in public with strangers on a code base over time or relative strangers, and that in turn fed back into even private collaboration on code, which is there’s just a different perspective or a different way to be creative, maybe, but you have to bootstrap and do it. So maybe you’re helping do that for design and maybe even the larger world of technology. 00:56:10 - Speaker 1: I think the beauty in this too is that I think it could help design, elevate from being seen as this thing that people do in making things pretty, to be a lot more focused on an aspect of problem solving, essentially, that problem solving in an open solution space. We just don’t have any idea of where to go next or how to evaluate your idea in the beginning, that design can kind of like feel bigger than that, and because it feels bigger than like UI design as we know it today. That through that it becomes more inclusive too, and people might identify more with, hey, I also work creatively. I also iterate on my ideas. These
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Mark McGranaghan: Uh, so I, I imagine something like that from you where you can pick, you know, your favorite black ink, your favorite highlighter, your favorite accent pen, put them in your little toolbox, and you have this small, very curated palette that you can swipe in and out when you’re actively working on a document, and you’re not confronted with like the Photoshop style 200 buttons, most of, most of which you don’t know what they do. 00:00:33 - Adam Wiggins: Hello and welcome to Meta Muse. Use the software for your iPad that helps you with ideation and problem solving. But this podcast isn’t about Muse the product, it’s about Muse the company and the small team behind it. My name is Adam Wiggins and I’m here today with my colleague, Mark McGranahan. How are you doing, Mark? 00:00:52 - Mark McGranaghan: Doing all right. You know, it’s uh interesting times over here in Seattle with the virus, but otherwise doing pretty well. 00:00:56 - Adam Wiggins: This is a good moment to be on an all remote team, right? 00:00:59 - Mark McGranaghan: Indeed. 00:01:00 - Adam Wiggins: So the topic we wanted to talk a little bit about today is tool switching. And so this is the idea that if you take your stylus, your Apple pencil, and you touch to the screen, what happens? You know, what color is it inking? Is it erasing? Is it something else? What color is the ink? Is it something else totally different, like a a lasso or a scissor tool? And this is a a deeper topic than it might seem. Uh, because it comes to some values that I think Muse has or that we try to fulfill some principles, perhaps you could say in our design, including things about modelessness and things about sort of on-screen Chrome. But it also touches maybe on our journey from being a prototype in a research lab through to a sort of an MVP of beta and hopefully on our way to a publicly released, uh, commercial product that anyone can use. 00:01:51 - Mark McGranaghan: Yeah, it it’s been a really challenging problem, much more so than I thought it would be coming in. Uh, one does not simply ink on the iPad, it seems. 00:02:01 - Adam Wiggins: Indeed, yeah. And there’s a whole set of technical challenges that maybe one of these days we can get Julia on here to talk about would be great. Um, but yeah, maybe we can go back to the beginning. Can you, can you frame up the problem for us a little bit? What, what were we trying to accomplish? Uh, why, why not just sort of have a toolbar at the top, you tap on the thing like you would in Photoshop or any procreator or something to pick a tool and then off to the races. 00:02:24 - Mark McGranaghan: Yeah, so as a reminder just mechanically what we’re trying to do here is when you touch the uh Apple Stylist to the screen, do you get ink, do you get Eraser, what type of ink are you seeing, things like that. And the very standard way to do this in iPad apps is you have a persistent toolbar, often at the top of the screen or some other palette, where if you want to erase, you tap the erase icon and if you want to red ink, you tap the red ink icon. If you want to highlight, tap the highlighter and so on. And that’s a sort of mode where that is persistent until you go back to the toolbar and tap it again. Uh, so there are two main problems with the standard approach. One is that you have that toolbar in your face all the time, uh, which is a pretty big deal on the iPad. It’s a relatively small sized device and you want, uh, we want as much space as possible for your content and for your work, and to not always be looking at like Chrome and toolbars and buttons and other stuff that isn’t what you’re actually trying to think about and do deep work on. So that’s kind of the the chromeless goal. Uh, the other thing is modelessness. So a mode is um a property of an interface whereby when you go to do some physical action, The result depends on some hidden state of the app. So in this case, that that mode, that state is like what um inking button you have pressed in your palette toolbar or whatever. And the problem with that is that these toolbars, they tend to be off to the side of the device away from where you’re working, so you have to basically have your attention in two different places. It’s you’re looking and thinking about your, your work, the text that you’re highlighting, for example, but then you got to remember constantly what’s the actual thing that I’m currently working with. Uh, this is subtly different to, for example, if you have a physical highlighter. So you have a physical highlighter and you’re going to highlight like the highlighter is thicker, it’s bright yellow, it’s very obvious what you’re doing because you’re looking at the, your hand and your instrument and your work, which are all in the same place. But again, that’s not the case with a typical toolbar. Um, and so we wanted to try to find an interface that didn’t have this modeful property that wasn’t moded like this, uh, as well as it didn’t have, um, all this chrome in your face all the time. 00:04:33 - Adam Wiggins: And a great articulation of this uh modes concept is in the Humane interface by Jeff Roskin. And he talks about the, I think the really classic example there is the caps lock. This is just confounded many, many generations of computer users where when caps lock is on, different things happen when you press keys, specifically, you get the upper case rather than the lower case. And of course, this is really confounding for something like a password field where you can’t even see that feedback immediately. But even in a uh another case where you can see what you’re typing. You type a word or two and then you realize everything’s upper case because the caps lock indicator that being on or not, you either have to remember it, or you have to kind of look down and see an LED or some kind of indicator, and you tend not to do that because your attention isn’t there, your attention is on what you’re writing as it should be. 00:05:23 - Mark McGranaghan: Yep, this also points to a third issue with the standard moded interfaces, which is that you actually need to physically do the action of moving your hand away from your work to the toolbar and back again. And if you’re constantly switching between inking and erasing or different types of inks, that actually becomes quite troublesome. 00:05:41 - Adam Wiggins: So let’s go back in the story a little bit and kind of Work through the product or design problem. So we started from this place of let’s, let’s do the Raskin thing and try to be modeless and also that we don’t want a bunch of junk on the screen or we want as little stuff on screen as possible, be focused on the user’s content, keep all the, keep all the space for your stuff and not for the applications, uh, administrative debris. And so, uh, back when we were working on this in a research context, which probably explain what that means a little bit, but Uh, we set out with this set of goals and, and how did we first approach that or what what were some of the first things that we tried to see if we could fulfill these, these goals while still letting you, of course, do lots of things with the stylus. 00:06:23 - Mark McGranaghan: Yeah, well, so I don’t think we, we fully knew what we were getting ourselves into. Pretty early on we had these two goals. We don’t want to have any Chrome and we want it to be modeless, but if you If you do both of those things in any obvious way, you basically can only have one thing that the stylist does. um, so for a while our solution was you can only do black ink, that’s it, uh, which actually got us surprisingly far, um, but then we need to try some other things and, and then we did a whole uh litany of experiments. We, we did try some standard toolbars and palettes. We tried to make them as small and minimal and nonobtrusive as possible. Uh, we tried using various uh quasi modes, which is a term that I want to introduce here. So, uh, a standard mode is when You kind of do an action to trigger the mode and then you go and do your work and then you go back to the, the mode switcher to switch it again, whereas a quasi mode is when there’s something that you’re basically holding down, it’s like when you use the shift key or the command key or holding down some other control button, you know, that sort of thing while you’re doing the action with your other hand, basically. 00:07:28 - Adam Wiggins: Yeah, so going back to the capslock example, Caps Lock and shift do the same thing. But the difference is that with shift, you are not likely to forget you’re in the mode because you’re physically holding the button down. And if you ever get confused about how to leave the mode, you basically just release, stop doing things, and you sort of go back to your default state, exactly. 00:07:47 - Mark McGranaghan: So, we, we tried all kinds of quasi modes, uh, we, we didn’t necessarily have a keyboard, which is the obvious place to invoke a quasi mode with some kind of control key, but I think we tried, um, Using a physical keyboard, which you can sometimes get with tablets. We tried pressing like the volume button on tablets, we tried putting your thumb over the camera so that it registers a black image. Um, we tried pressing on various special places on the screen like press in the bottom left corner if you’re a right-handed anchor. Um, so there was various experiments with quasi modes. 00:08:21 - Adam Wiggins: Also worth noting there that in many cases, so Muse runs on the iPad, but In the context of the research lab, we were building for a number of different tablet stylus platforms, including the Microsoft Surface, Google’s ChromoS, and, um, I think we might have even done something with Android at one point. And so those actually platforms have different affordances or different hardware capabilities. So notably the Surface, for example, has this reversible stylus where the back is a quote eraser, which actually is really nice because again, You know, you, you have that physical reminder, just like your highlighter, um, example, you’re holding the thing in your hand in a reverse position. That’s clear, you can see it, you can feel it. And so you you flip the thing around to erase and flip it back. Fortunately, the iPad doesn’t have that. Uh, yeah, other, other platforms like ChromoS, for example, have a barrel button, all of that has certain restrictions tied into the operating system. So, we tried quite a lot of crazy stuff on this. 00:09:15 - Mark McGranaghan: Yeah, uh, we also tried some stuff just using the stylist differently. So one experiment that you had done was using the stylist to write special symbols. You called them glyphs, and it was something like if you draw an X then it’s cut or something like that and if you draw a downward V then that’s paste. um, so we did that experiment. Uh, we also tried. Um, using the stylus with different attitudes towards the tablet. So typically when you’re using a stylus, it’s like pretty vertical with respect to the tablet, uh, but you can by holding a different way, you can make it almost uh parallel with the tablet, sort of like you’re doing a a pencil shading motion, uh, and there, there are sensors in most devices to detect that altitude. Um, so we actually use that angle to trigger different behaviors of the stylus. 00:10:06 - Adam Wiggins: Yeah, notably, that one was the one that we kind of found most promising. I think we published maybe our Muse design article included that as well as Yuli’s. Yuli gave a talk at a conference last year with that approach where basically when you would hold the stylus overhand, it would allow you to move cards. Uh, or resize them, but when you held it in the, uh, more the, the standard writing grip, that would give you ink. And I, I really loved that. It worked really well, uh, in a lot of ways. It was very intuitive and, uh, you know, different grips is something that comes naturally to humans and it was pretty hard to get confused between them. But ultimately actually that one was. Killed by a technical challenge, which was the iPad, and I wouldn’t be surprised if other platforms have the same problem. I suspect it’s a hardware thing, but as you get close to the edge of the screen, for us, it was, I don’t know, 50 to 80 pixels, which maybe is, I don’t know, yeah, a couple centimeters. Uh, it would basically start to produce bad values. We did a bunch of digging on this and filed some bugs and some other things, but ultimately and and saw that this is just behavior that’s systemwide, but I think no one else ran into it because who the hell cares about the exact, uh, you know, why is it critical to hold the pencil at a certain altitude when you’re near the edge of the screen? Even like typically the only apps that really make use of this data are art kind of art drawing apps, Procreate or. by 53 or something like that, and you can see when you use them, if you move towards the edge, you lose that that sensitivity or the data gets bad about the position of the stylist, but it doesn’t really matter because it just changes fairly subtly what’s happening with the brush. But for us, the difference between moving a card, which could even have the effect of deleting it if you flick it off the screen and inking is huge. And so that ended up being a To a total non-workable thing for us, and we had to step back from it. So where did we land? So, so we went through this whole process of trying different things on different platforms, again in the research context, and then later, once we had kind of resolved onto the iPad as a platform and the prototype of what would eventually become a spin out product of Muse, by the time we went, went to make this transition from the lab to A commercial product we had actually settled on this, uh, position of the stylus as the solution, but then I think it was the early MVP and the early beta testing with with real users, not the initial usability tests. I think those, you know, if you got someone and to just try the thing for 20 minutes and and taught them how to use this different grip, that worked fine. It was more in practice over longer use in the real world where the edge of the screen problem became. Uh, basically a show stopper. And so now we’re in this mindset of, OK, we need to make this more reliable for real world use and we, we had to make the transition. So what did we eventually do on that? 00:12:55 - Mark McGranaghan: So we ended up with two mechanisms. Uh, the first is for erasing. If you press on the screen with your non-writing hand, say your left hand, while writing with the stylist in your right hand, that will actually do an erase. So while you, while a finger is pressed down on the screen, You have a quasi mode to do a race with a stylus, and then when you let go of your, of your finger, then the stylus goes back to inking. And then for selecting which ink you use, currently we have three options, a standard black ink, a sort of accent, purple ink, and a highlighter in yellow. Uh, we have this uh flow where you can drag from any edge of the iPad screen. With the stylus, and when you drag out from the edge, it reveals a small subtle um ink palette where you have those three options, and then you can select among those inks like a standard ink toolbar. Uh, and then optionally you can swipe back from that toolbar back to the edge of the screen and hide it again. So this is basically the best, uh, set of compromises that we can come up. We really like the quasi mode or you’re fairly limited on the iPad with much hardware options you have. Uh, so for now we’re just using the one finger down and that works quite well for racing, but that only gives you one, you know, degree of freedom. And so for the other inks, we have this, this toolbar that you can slide out, and it is still a mode, but you have the option, but not the obligation to kind of see what mode you’re in by uh swiping the toolbar out. And if you want to just, you know, go into pure note taking mode or pure highlighting mode, you can just hide the toolbar and you have 100% of your content again. And there are also other subtle benefits to this approach. So like, for example, you can bring out the toolbar wherever you want. So if you’re making a note in the bottom right hand corner of your document, you can just swipe out the toolbar there, pick whatever ink you need and hide it again. Right? 00:14:49 - Adam Wiggins: And I think this is a great example of the, I guess, rectifying the big ideas or the dreams or the just fulfilling these principles which create constraints in trying to make something interesting, special, unique, solves a problem in a way that hasn’t been solved before. But then you need to rectify that against the real world. And in some cases, even though we set out to make a fully modeless interface, the color of your ink or the type of ink is in fact a mode. Uh, but I think maybe that one feels a little less dramatic, or a little less problematic by comparison to the The much um more diverse modes that you have in like a Photoshop, for example, where the difference between a selection tool and the fill tool is huge. And so you’re gonna maybe, you know, in that case on the desktop, uh, program, you’re gonna click on the screen somewhere and something’s going to happen, and it could be completely fill the screen with a color when you’re expecting to do some selection, and that’s extremely surprising and disorienting. With ink colors and ink types, OK, getting the wrong color ink is not desirable, and you go, OK, I’m gonna undo that, go back and and switch to the ink I want. But it’s all making a mark on the page. So the level of surprise and confusion the user feels, uh, if they don’t get what they’re expecting, I think is far more minimal compared to the classic full fledged toolbar. 00:16:08 - Mark McGranaghan: Yeah, and this actually reminds me of a subtle reason why modes are more viable on the desktop than tablet, which is on desktops, when you switch in a mode in the app like Photoshop or Final Cut Pro, it usually changes the cursor. So if you go into a fill mode on a photo editing program, it probably gives you like a bucket with paint flowing out or something like that. Uh, where obviously you don’t have a cursor on a tablet. So that’s another reason why you have to think more carefully and more creatively on tablets about modes. 00:16:35 - Adam Wiggins: And that comes back to that where your attention is, your locus of attention, which is you’re looking at your cursor because that’s where you’re about to do whatever you’re doing. And so if that’s in the shape of a particular tool, obviously it’s not as nice as the holding the big yellow highlighter versus holding the pair of scissors, but it, it achieves some of that purpose. Now, maybe we could talk a little bit about that kind of path from uh prototype to early product to maybe production product. Um, which might beg some more fundamental questions of why were we trying all these weird things? Uh, why, you know, why, why didn’t we just sort of go with the status quo? If we wanted to make an app that is good for collecting together research and pulling together some excerpts and making a few notes, there are some very well established human interface guidelines from Apple and just general UI, um, paradigms that exist both in the desktop world and, uh, increasingly in the sort of the touchscreen world. And we could just, I guess, like any other app maker, make an app based on those standard paradigms and just put it through the the channel of what what our users want to accomplish. Uh, what, why weren’t we doing that here? 00:17:47 - Mark McGranaghan: Well, we, we have a very specific vision for how these tablet creative apps should look and feel, and we can go into what that is. Uh, as for why we haven’t just copied other tablet apps, I, I think there actually hasn’t been. A ton of original thought on tablet interfaces. Most tablet interfaces that I see are actually transliterated from either the desktop or the phone. Uh, especially see this with, um, like casual apps. They’re usually transliterated from the phone, by which I mean the app just kind of assumes you have a big phone and you’re still using it with like one finger at a time, for example, on one hand, uh, which we think is totally not, you know, the right way to think about tablets, or for creative apps, often they’re transliterated from there. The desktop cousins and you get things like, you know, toolbars which don’t necessarily make the same amount of sense on a tablet. We think that the tablet interface is unique because it, it feels very natural to do a certain type of work, work where you’re reaching in with both of your hands like directly into the content and manipulating it. So certainly things like inking but also things like, you know, arranging content um very directly on an interface. And so a lot of what we try to do with our interface design is make something that’s that’s true to that ideal. So one of my favorite examples here is moving something on a tablet. The standard way to do that on iOS is you press and hold and wait and then move and then maybe uh the app like snaps it into some box or grid or whatever, whereas surely the more natural thing to do is you just move your finger over the thing and it moves, right? Um, but that actually is requires quite a bit of technical and product work to actually make work correctly. Um, so we had a similar set of, you know, requirements if you will, with, uh, inking. It needs to be as modeless as possible, it needs to be incredibly responsive, it needs to not get in the way of your work and this process of going from a prototype to a production app, we basically maintain. Our same vision and goals, that’s been constant throughout. It’s more like understanding the limitations and the challenges that we’re going to have on the platform and confronting all the realities of getting apps in the wild with with users and uh finding something that’s still true to our vision, but that can really work in production. 00:20:09 - Adam Wiggins: Yeah, the typical paradigm for applications is you got the desktop world, which is you’ve already Mentioned is tends to be mouse cursors, keyboards, command keys. There’s usually multi-winded Gy gooey stuff, and that is where powerful professional applications tend to be today. They’re obviously very well established, and you’ve got all your video editors and audio editors, and programming editors and word processors and architecture tools and and so on. Uh, then you’ve got basically, new generations are growing up with touch screens. The touch screens are where most of the innovation is happening, but clearly a phone is not the place to edit a spreadsheet or write a long email or write a book or something like that. Um, and so part of what we were, uh, researching as part of this, this lab, which is called Iot Switch, maybe a topic for another day, but was this kind of question of what does computing look like in 5 to 10 years and specifically for these kind of productive creative apps. And productive and creative apps have the qualities that you described, which is you need to move very fast. For example, but you also need like a rich command vocabulary. You need to be able to do a lot of things. And so that kind of led us down this path of like, OK, we live in a world where touchscreen interfaces have become both the most dominant platform, but also where all the innovation is happening and yet they’re very restricted for doing more serious professional. Uh, type work. And so, that led us down this path of, OK, how can touch screens get more expressive? That leads you to tablets pretty naturally, cause they’re bigger, because you can use two hands, because there’s often a stylist that goes with it, um, and that kind of took us down this, took us down this road. 00:21:51 - Mark McGranaghan: And the endgame that I envision here is that you actually have 3 devices and 3 environments for creative work. So, your phone is used for on the go, reading, quick note capture, take a picture of something, save a tweet that you saw, that sort of quick action. Your desktop, I imagine is still used for the most sophisticated and complex authoring environments, things like uh editing a big video, writing up a big paper in law tech with a ton of references, um, just the amount of, of real estate that you have, the richness of the controls with keyboard and mouse, um, I think that’s here for a while. The place that I imagine for tablets is the sort of intermediate step. Where you’re, you’re reading, you’re annotating, you’re brainstorming, you’re forming ideas, you’re sketching outlines, you’re rearranging concepts and materials, and that seems really well suited to the tablet form factor. You have a, a moderate amount of space, you have this direct manipulation where you can move things around with your hands, you can use a stylus which is very natural for freeform ideating and annotating. Uh, and it’s very flexible. You can take it on your couch and your chair, which is better for like, you know, reading and brainstorming than, you know, sitting at your, you know, stiff desk. Uh, but if that vision is going to come to reality, we have to treat the tablet as a third and unique environment. It can’t be designed like a desktop and it. Can’t be designed like a phone. It needs to be its own thing. 00:23:19 - Adam Wiggins: Do you think it’s asking too much for people to buy, maintain, and carry around 3 devices or I guess they would be carrying 2, although potentially 3 if you count the, for a lot of people, a laptop computer, clamshell laptop is really their desktop computer. 00:23:33 - Mark McGranaghan: Yeah, I think that’s a fair question. When we’ve talked to users, and we’ve done a lot of user research for Muse and previously in the lab, a lot of people bought an iPad already, like on their own volition, because they had the same intuition, even if they didn’t quite have the words for it, they were like, I, I feel like I should be able to use my iPad for this like creative work, for reading, for note taking. You know, it’s kind of, I want to be doing that. um, so they, they were already halfway there, but they consistently found that the software wasn’t there, you know, they had their social media apps and they had their, um, you know, transliterated desktop apps, but it wasn’t that they weren’t very satisfying. Um, so, so I, I think you guys actually are already well on their way to having this 3 device set up. What’s missing is the really good tablet specific software. 00:24:23 - Adam Wiggins: What do you think about other kinds of larger Touch screens or just touch screens in different, um, I guess, forms. So there’s the uh the Microsoft Studio Surface studio, I think it is, which is kind of a drafting table. They’ve got these additional accessories like this um this little puck control dial thing, or there’s something like Google Jam board. I think Microsoft has a, has a bigger one like that. There’s a few of these where they’re basically very large touch screens that go on the wall. You can kind of interact with them the way you would interact with the whiteboard, for example. 00:24:53 - Mark McGranaghan: So I think that’s very interesting. I think there’s a hypothesis that you move to uh 3 or maybe 4 devices, but they’re all slate style. They’re all touchscreen style. Um, I suspect that’s further off for a few reasons. Uh, one is there’s just a huge library of desktop. Software, and this is the most sophisticated software. This is where you have your most complex authoring and editing environments, things like, you know, Final Cut Pro. Uh, it would be hard to rewrite all of those from scratch, but you know, perhaps we do it at some point. Uh, another reason is just the hardware is not there yet. If, if you want to get a sufficiently high resolution times a sufficiently large physical area that that’s a huge amount of pixels. Our GPUs can’t handle it yet, obviously we don’t have the screens for it. The the touch resolution isn’t there yet. The touch latency isn’t there yet. Um, I, I would say we just got there for tablets in the last few years with the iPad Pros. Those have sufficiently high resolution and sufficiently quick response times that they can be used, uh, with your hands and it and it feels good enough, like the latency is low enough and the resolution is high enough. We’re not, we’re not quite there yet with these bigger surfaces, but I think if we get there with the hardware, which I hope we do at some point. Uh, then we could follow with the software and you would have a more unified, uh, touch base environment just with different form factors. 00:26:14 - Adam Wiggins: The makers of those operating systems are actually very actively working to try to merge them together. The surface platform I previously mentioned runs Windows as an operating system and it uses, it also offers a trackpad and a keyboard, so it’s a totally standard, you know, desktop operating system in addition to being a tablet. And then, of course, Apple’s taking baby steps in this direction with, for example, mouse support on the iPad. There’s rumors now that there will be a trackpad in the next folio keyboard, uh, but whether or not that’s there, you also have things like Catalyst to bring iOS apps to the Mac desktop, and so you just see this, uh, this, um, these efforts to try to blend or bring these, these two platforms together. 00:26:55 - Mark McGranaghan: Yeah, for sure. No, I do think there is a risk here of transliteration gone awry, uh, either on the app level or the OS level. So for example, if you just made a really big iOS that ran on a desktop, I, I think that would be totally inappropriate for professional apps. You don’t have the input richness, you don’t have the arbitrary processes, you don’t have the plug-ins, um, so I, I, I think we, I think Apple and others need to be careful there, but there’s definitely a world where they’re able to create, uh. Touch, um, touch OSs across uh the three form factors. This does remind me though 11 other thing I forgot about, uh, the, the bigger touch form factor is text input. This is something we’ve thought a lot about in the lab and as far as I know there’s no good answer for this, uh, onto devices yet. 00:27:42 - Adam Wiggins: So by this you mean you want to like enter in two paragraphs of text for an email or something and you’ve got a touch screen. What do you do? 00:27:50 - Mark McGranaghan: Yeah, and actually just like typing out a two paragraph email is the relatively easier case on desktop, there’s also a lot of like uh random access editing, like where you’re editing an email or you’re editing a document or you’re writing code and jumping all over the place. And keyboards are also used very heavily as control devices, like people who are good at like Photoshop and Final Cut Pro, they do tons of stuff on the keyboard, they have all these shortcuts, all these control keys, and that requires like a very, you know, precise uh mechanism where you can do it without looking at your hands and you know exactly what you’re doing and you hear the click when you actually go to do it, things like that. Um, so I think we actually have quite a bit of work to do on the, the input, the text input, the control input front for. Um, these devices to work and it may be that you actually don’t want to have a pure flat piece of glass. You actually want to have some, some physical devices like a keyboard or something else, um, to allow really rich, precise input for these, these bigger devices. 00:28:46 - Adam Wiggins: Yeah, for me, I think of the kind of the folio keyboard and the stylus as being required accessories for my iPad. With those, it ends up being a big phone. Which is fine, but I have a small phone that fits in my pocket. 00:29:01 - Mark McGranaghan: So, yeah, I think it depends more with the tablet on your use case, like I think there’s a use case where you’re, you’re reading a PDF for example, and you’re annotating it. I think you can get away without, with just a stylus in that case. 00:29:12 - Adam Wiggins: So as a sort of a a closing topic, can we talk generally about the research mindset versus the production product mindset you mentioned here that like the the text entry problem. I think it is very much a research problem. 00:29:26 - Mark McGranaghan: Yeah, well, the thing about research is it’s OK not to come up with a an answer or the correct answer. So I mentioned with the ink switching problem for our original research work. Our conclusion was like, we don’t know, sorry, you can only use black ink for now, it’s too bad. Um, that’s not an acceptable answer for people who are paying to use Muse, for example, they need to be able to select an ink. Um, so sometimes you have these problems where you just, you have to come up with something for the production app. Um, so by default, you would start with a, a non-research answer or a non-research approach. 00:30:01 - Adam Wiggins: For me, it’s really important in My work and on teams that I’ve been on to understand where something is on that spectrum. So at Hiroku, for example, we did a lot of pretty innovative things. So this is a company both you and I, um, we’re working on some years back. We did a lot of really innovative things, uh, in our space, but it was often important, I think when someone was working on something that was a truly novel problem, literally no one had ever, no one in the history of the universe had ever tried to solve it. Uh, or, or had solved it successfully. And then you’re in there trying to, to, to solve that. It requires a longer time horizon, a much more divergent set of ideas. You need to really break out of the constraints of the box that you’re operating in day to day, and that’s totally at odds with what I would call like the operational mindset, which is exactly what you said like you have to. You’ve got customers, things are on fire for them, metaphorically speaking, and you need to deliver them some kind of solution and it doesn’t do to say, let me go into my ivory tower and think deeply about this for the next 3 years and eventually publish a paper that said this is a problem that can’t be solved right now that that doesn’t work, but. The operational mindset naturally keeps you on shorter time horizons. It keeps you sticking to things that are more known quantities as much as possible. You want to look at what are other people doing. Uh, what, what are other similar, uh, applications or software packages or companies do to to solve similar problems and borrow from that as much as you can because those are known paths. Whereas research is all about this total unknown discovery thing, and that can be very rewarding in in the sense of stumbling across novel inventions, but uh it’s it’s not super practical for production. 00:31:51 - Mark McGranaghan: Yeah, exactly. And because these domains are so different, the constraints, the requirements, even the people who tend to like working on them, um, it’s often best for them to be in quite different, like different different organizational setups and like that’s one of the reasons why I think the Ink & Switch lab plus Muse is so interesting. Muse is inherently more industrial, commercial focused. Uh, the lab is inherently more research and exploratory focused. 00:32:18 - Adam Wiggins: Yeah, the the typical set up there and actually some of our inspiration for how we did set up I can Switch was the corporate R&D lab. So this is something, uh, Xerox PARC is probably one of the most famous ones in the computing. Um, industry. So there you had Xerox, which is this big company that makes copiers and has money to spend and wants to think about, uh, what their future facing products are going to be in PARC being the small band of misfits that are working on basically inventing what came to become the desktop computer. Uh, but there’s other examples of this. Bell Labs is another very venerable, famous, successful, uh, lab that works this way. And the idea is that you, you actually need and want to If not, uh, isolate, then at least partition people who are doing research, the kind of wild mad scientists thinking way outside the box stuff from the people who are responsible for the, the, the product that you’re selling today. And hopefully people can move back and forth between them and hopefully there’s mutual respect, but they just require completely different modes of operation. So going forward from here, there’s more tool switching problems to solve. For example, a some kind of selection blasso thing is probably something that’s needed. Uh, do you have an inkling of how we’ll go about kind of solving that problem that stays consistent with our values, but also knowing how much we’ve grappled with the with how hard that problem faces? 00:33:43 - Mark McGranaghan: Yeah, so I have 3 ideas here. One is, I suspect we’ll move from ink selection to instrument selection. So again, if you go back to the physical world, you think about how you use your hands. You don’t only use it for inking, you use it for erasing, you might pick up an exacto knife, you might pick up a brush, uh, you might pick up a ruler. Um, and I think that’s, that’s a powerful metaphor. So I can imagine, for example, if you have a lasso, that becomes a sort of sibling to the inks that you can pick in the same way from the same sort of palette. 00:34:15 - Adam Wiggins: Now does that bring us back to, you know, where we started, which is basically the, you know, the on-screen toolbar that has all your tools, the Photoshop, the Procreate, and that sort of thing. Are we essentially have we, have we worked our way around backed ourselves into what is for good reason, a standard pattern? 00:34:31 - Mark McGranaghan: Well, I think that could happen. Um, but, you know, for one, we have this thing where you drag it out from the edge so you can hide it if you want. Um, but the, but the other idea I have here is going to a model where you have a small number of instruments that you’re actively working with. So again, to go back to the physical metaphor, if you’re working on some projects on your desk, you don’t have like 100 pens, you know, strewn all over your desk, which is what happens when you have a toolbar on desktop app which has a And buttons, right? You are working on something, you know that for this project, I need like a black pen, an exacto knife, and an eraser. So you go to your shelf, you bring those three things to your desk, and then it’s very easy to switch among those for this current project, and then when you want to, you know, change your project, you go and you get different instruments from your shelf. Uh, so I, I imagine something like that from you where you can pick, you know, your favorite black ink, your favorite highlighter, your favorite accent pen. And put them in your little toolbox and you have this small, very curated palette that you can swipe in and out when you’re actively working on a document and you’re not confronted with like the Photoshop style, 200 buttons, most of most of what you don’t know what they do type experience. 00:35:43 - Adam Wiggins: Although Muse probably also has the benefit that we’re not a drawing tool. So you look at something like concepts, for example, a really great iPad app with really sophisticated tool selection, and that’s appropriate there. Because that it is supposed to be a drawing app, technical drawing app with a lot of, you want a lot of options in terms of things like pen thickness. Muse is a thinking, scribbling, sketching app, and just as it would be inappropriate to have 50 different thicknesses of markers in front of your whiteboard, uh, it would be also inappropriate to have a huge amount of choice, I think for, uh, for the Muse use case. 00:36:16 - Mark McGranaghan: Yeah, and I think that’s true both for kind of in the moment, you know, so we have this, this. palette, small active palette that you’re choosing from, but also when you go to uh load out your palette, um, I think we’re going to be quite deliberate about how we present those choices. So sometimes you see these interfaces where you can, you know, choose like basically put in a float for how thick you want your pen to be. I think that’s basically not coherent because the difference between a, you know, 1.71 pen and a 1.72 pen doesn’t really make any sense. It’s not useful. Uh, and indeed, if you go to a high-end pen store and you look at like the technical pens, there’s a very specific way that they’re sized. They’re basically size in increments such that if it was a much smaller increment, it would kind of wouldn’t make a lot of sense. It would be too small to be really noticeable or or obviously differentiable, so they’re kind of there’s a set of. Of sizes such that you can cover the full spectrum, but they’re not uh too finely degraded, right? Uh, so I can imagine for choosing sizes, for choosing colors, you have a, a carefully thought out, um, set of options such that you have choice, uh, but you’re not confronted with more choice that makes sense. Well, I think those were the main three things. So curated load out, uh, the, the swipe from the side, and what I call the, the high-end pen store where you’re, you’re given a set of options that kind of makes sense versus putting in floats. 00:37:40 - Adam Wiggins: And do you imagine that then, um, having grappled with all of this and, you know, Azimuth or uh altitude rather of the stylus is probably out for a while and quasi modes don’t have enough, um, dimensionality, uh, and there’s probably not going to be some kind of extra hardware button or controller or something we can make use of that the. Uh, hidden by default, small tool palette, uh, is basically the, the solution we’ve landed on for the, let’s say the medium term. 00:38:08 - Mark McGranaghan: Yeah, I think probably for the medium term. I, I, I do think quasi modes are actually very good. Uh, so I, I definitely think we’ll continue to do the press to hold. Uh, I, I could imagine extending that slightly. So for example, maybe you press two fingers and you get a secondary option. Um, I can imagine that that is configurable. This is a pretty common pattern in professional tools like you can choose what the shift key does. You can choose what the command key does, and there’s a, there’s an obvious default, um, but if you want to set that up, you can do it. And lastly, I could imagine as a sort of optional set up for people with a physical keyboard, you know, holding down 123, quasi mode engages your ink or your instrument 12, and 3, and so on. 00:38:50 - Adam Wiggins: Yeah, or having some kind of optional accessory. I think I saw this with uh Loom. It’s a cool little um iPad animation app that came out pretty recently, and they have the optional ability to use the teenage engineering MIDI controller, which is a little dial thing, and you wouldn’t want to require that obviously, but, uh, but maybe that is something that enhances the power of the tactility of the app. 00:39:12 - Mark McGranaghan: Yeah, exactly, and uh now this gets beyond a little bit the medium term, but Uh, one idea that I’m excited about is using the phone as a sort of sidecar control panel. So everyone has a phone, they always have it on them. What if you could just put it on your desk and like, you know, you link your tablet and your phone, and then your phone becomes your palette. So you could, you have 4 or 5 buttons there, you could have a finger cording there, you could have a little slider there, um, and that would give you a lot more degrees of freedom. On, you know, quasi modes without requiring a secondary dedicated hardware. 00:39:45 - Adam Wiggins: And is the benefit there, you know, that that in that case it’s not a tactile thing like an eraser you flip over or a dial you turn, it’s another touch screen. What’s the, uh, what’s the benefit other than I suppose just more screen real estate of having it on a separate touch screen? 00:39:59 - Mark McGranaghan: Yeah, well, it’s uh more screen real estate, it’s kind of separately programmable. Um, you can have it in a physically different place. So if you think about how you use a keyboard in your mouse, it’s if you’re right handed and you have your mouse in your right hand and you have your control keys on the left side of your keyboard, there’s 12 or 18 inches because that’s kind of the, the correct and natural spread of your hands, um, if you’re in a very neutral position, whereas if you’re, you know, have your hands right next to each other, it’s a little bit artificial. Um, so it’s, it’s, it’s an exploratory idea we to see, but I think there’s some promise there. 00:40:30 - Adam Wiggins: And certainly the idea of having your offhand, you see this with um Wacom tablets, often in professional like graphic designers, artists, types, uh, or you see it even in something like um uh people who play competitive video games, something like a. Um, yeah, these first person shooters where you need to, uh, be very fast and responsive, and you tend to use the mouse in one hand, which is kind of your move, shoot, aim, uh, thing. But then you also have the keyboard which you end up kind of putting your, uh, fingers on certain keys that activate, I don’t know, switching, switching weapons or something like that. And the important thing is you don’t need to look at that hand because your fingers are in a particular position and they stay there. So I could picture that for the phone, which is you kind of have your hand, your, your offhand, that’s left or, you know, left hand if you’re right-handed positioned over the phone in a way where you, you, you don’t really need to look at it. You can press to activate different things, uh, and just go completely by feel, even though the touch screen feels, of course, not like tactile buttons, but the shape of the phone and the position of the phone is something that you sense or feel even without looking at it. Yeah, exactly. Very nice. Well, anything else we should talk about on the topic of tool switching? I don’t think so. And if any of our listeners out there have feedback, feel free to reach out to us at @museapphq on Twitter or hello at museapp.com via email. I’d love to hear your comments or ideas for future episodes. All right, it was a pleasure chatting with you. Likewise, Adam.
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: There’s so many zillions of startups trying to try every single angle and opportunity in that area. And so the marginal return to investing your personal time in terms of the impact on the world might be relatively smaller there. Whereas there’s this whole space that I feel like is really under explored. And if you just make it about 80%, making a profit and 20% making a statement, that opens up all kinds of incredible opportunities. 00:00:29 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for thought on iPad. This podcast isn’t about Muse the product, it’s about Muse the company and the small team behind it. I’m Adam Wiggins, joined by Mark McGramigan. Hey, Adam. And Mark, since we last spoke, I am a father. Congrats. Yeah, it’s great, or at least the non-sleep deprived parts are great. I’m actually on parental leave right now, but I enjoy doing this podcast enough. I thought I could sneak back for just an hour here, but if my brain is not at full capacity, let’s just say you’ll have to carry things for us. OK. Now, way back in episode 4, we talked about our partnership model. And the context there was we were hiring the 5th member of our team, our engineering partner, and I’m happy to say we have through that process, we added Adam Wulf to the team, really great engineer with a particular specialty in inking, which is quite important for us, and he’s been doing great on the team, so we’re now 5. And in the course of that, of course, we talked about kind of the nature of the company and how it’s different from other models, particularly the startup model, but I thought it would be good to both first take an episode to talk more explicitly about what this somewhat unusual business structure we chose was, and then also it’s been a year and a half actually coming up on 2 years now since we started this thing and so being able to essentially say how’s it going? Is this working out the way that we expected. And just to frame things up a little bit, a starting place and a point of inspiration for both of us is a book called Small Giants, and I read this many, many years ago, I think when I was in my startup lifestyle, I would say, but it it had a big impact on me, and the book basically profiles a bunch of, let’s call them, businesses that are maybe have an outsized impact. But they’re less about huge size or making it to the S&P 500 or something like that. So for example, they have Clif Bars in there or Whole Foods, which I think at the time the book was wrote was really kind of an up and comer, independent up and comer, or Union Square Cafe, which is quite kind of unique restaurant in the New York area, since expanded to other locations. And the process of profiling these businesses, they showed kind of a maybe an alternate to, I think they’re thinking more an alternate to the standard kind of public company path, but I at least for me, I read it as an alternate to the startup world, which at the time I was just completely immersed in. I was kind of the only way to do things with the startup way, and this book suggested another path. 00:03:03 - Speaker 1: Yeah, that book was quite influential on me as well. So Adam, I’m curious, what from the book did you find yourself taking away the most and applying to your future adventures? 00:03:13 - Speaker 2: Yeah, well, in prep for this episode, I went and pulled out my Kindle highlights as a PDF and scanned through those a bit, and I have to say I’m not sure it’s actually a great book in terms of how it’s written, but there’s just a couple of core ideas that really hit home. One of those is they talk about businesses with soul or another term they use quite a bit is mojo, which is kind of a funny one. They talk about optimizing for mojo overgrowth and growth, of course, a business exists to Earn money, that’s it’s kind of practical function in the economy, and growth typically goes with that, it’s almost a requirement. So if you’re not growing, you’re stagnating. And that is taken to a real extreme in the startup world. I mean, Paul Graham even has an essay, Startup equals Growth, which just says, that is your sole purpose for being, grow, grow, grow fast as you can, and the counterpoint this book presents is mojo and expressing something kind of artistically and Having the soul is something you can choose. Of course, you still need to pay attention to the business fundamentals. You do still need to grow, but you can choose to have maybe a different balance where you say, you know what, this mojo thing we want to optimize for that and have enough growth to be successful but not have it be growth at the cost of absolutely every other thing. 00:04:35 - Speaker 1: Yeah, exactly. For me, there are a few layers here. There’s that first layer of, OK, you don’t necessarily need to be a huge business or to grow really fast. It’s a sort of mechanical matter, there are existence proofs of businesses that haven’t gotten huge or growing that fast, they’re doing just fine. OK, that’s great. That’s kind of the first layer. Then there’s this mojo idea of you can use the business as a vehicle to accomplish something non-monetary to make a statement. To do an artistic expression, and that’s something that was really important to me in starting this venture. I’m gonna spend the next 25, 10 years of my moral life working on this. I want it to be about something more than making money. And then there’s kind of a third layer, and I don’t know how much they get into this in the book and if you would even agree, but I think there’s a sort of arbitrage here where there are so few businesses that are operating with mojo, as it were, that you can have a sort of outsized impact if you choose to do so and do it well. This is where I think the small giants can punch above their weight class. It’s because so few people are actually operating with this mojo, this sense of artistic expression, that when you do, you really stand out, even if you’re smaller. 00:05:38 - Speaker 2: There’s some examples of companies that come to mind for you that are high mojo. 00:05:43 - Speaker 1: The one that’s top of mind for me these days is Signal. I’m not sure if that’s the company name or the app name, but, you know, I’m referring to the company that makes the Signal app, and I would expect they’re quite small. I’m not actually sure about the size of the firm, but it can’t be that big, but the impact that they’re having on the global discussion around the right of citizens to communicate privately is huge, and they could choose to have a huge impact going forward. So that’s one that’s kind of mindfully these days. 00:06:08 - Speaker 2: One that comes to mind for me is Panic. So they make kind of a variety of weird things, including, I don’t know, FTP clients, but also games. And now I think they’re working on a handheld game console and probably an example of a company that does have both mojo and a lot of growth, but maybe they took their time with that. The growth happened over a relatively speaking a pretty long time period and can build up slowly over time. Another one I remember you speaking about, we talked about this before, is Vanguard. Tell me more about the unusual structure there because I wasn’t familiar with it. 00:06:44 - Speaker 1: Yeah, so Vanguard is like one of the greatest business hacks of all time, and I feel like it’s an understudied story. So my understanding of Vanguard is the founder, I believe his last name is Boggle, wanted to make investing more accessible and more successful for individual retail investors, and he had this insight around indexing, whereby if you index into the market and operate those index funds at a very low cost way, it would be very beneficial to the people who are investing. Now he could have taken this insight and developed a huge and hugely profitable firm with it, but my understanding of what he did instead was he did this move where the firm is effectively owned by the people who invest in the funds. So essentially all the profits that would get plowed back into the funds in the form of lower fees. So he basically forgoes a huge personal fortune to help bring low cost. Indexing investing to the masses. And then it got to the point where it was so successful that it becomes quite hard to compete as a for-profit indexing firm because you can’t plow all your profits back into lower fees, right? Or at least your investors wouldn’t approve necessarily. And that’s kind of the sense of almost art that he’s shared with the world in the form of this somewhat unassailable venture to bring low cost investing to the masses. 00:08:01 - Speaker 2: index funds, you know, S&P 500, ETFs, guess what they’re called nowadays, is this huge technology, or maybe you call it a social technology or just a financial tool or something, but it had this huge democratizing effect for individual investors compared to the managed mutual funds that came before and yeah, the art. Start, as you say, you know, for me that is the reason I am in business is it is a vehicle for expressing something that matters to me about how I think the world should be or how it could be better and the business and the mechanics of all that, how it’s incorporated, how it’s funded, how it earns money, all that stuff is really a means to an end. Right, so optimizing for mojo, businesses with soul, expressing something artistically, that all sounds nice. What does this mean practically in terms of the business that you’re building? And here you start to think about these mechanics, which is, OK, you’ve got a group of people and you’ve got a thing they want to express. Product they want to bring into the world or a piece of art they want to create depending on how you want to think about it. That needs time, it needs money, it needs organization, and that leads you into what I usually think of as kind of a container or a vehicle, which is typically a legal entity, could be a corporation or a nonprofit. Um, and then there are certain models that fit with different kinds of businesses. So, for example, if you’re gonna open a restaurant, and for a lot of people creating a certain kind of food and a certain kind of environment, that is very much an artistic activity for them. You certainly see that if you watch something like the Netflix series Chef’s Table on kind of the high end, but I think even more for your local corner restaurant, many times those businesses are not very lucrative. They’re open because people are really passionate about food and sharing a certain kind of experience with their customers. But there’s probably a certain kind of legal entity you’re form and you’ll probably get funding as a small bank loan or some other things like that. And that’s extremely different from, let me start a startup, move to Silicon Valley, join Y Combinator, get venture funding, and ultimately you still have the legal entity, a source of funding, you know, way to hire people or bring team members on board and the sort of mission they’re signing up to, but the mechanics of them are very, very different. And there’s, you know, there’s a list of other things as well, including nonprofits, or even pure artistic activities, art projects, Burning Man art installations, or you’re starting a band or some, you know, writing a book or something like that. All of these need capital and ways to organize people. And there’s legal mechanisms for that. And so knowing both the mechanisms, but also what you want to express, and therefore, what is the right vehicle for that, I think that’s worth thinking through rather than reaching for a default, which is, I don’t know, everyone starts startups, so I’ll start a startup, for example. 00:10:45 - Speaker 1: Yep. Well, now you got me thinking about the Wall Street that stuff that’s going on on Reddit and in that case, I guess the optimal vehicle was a series of memes. 00:10:55 - Speaker 2: That’s right, I do think it’s ever evolving, and you mostly mean that as a joke, but honestly, the internet has brought us some new structures, right? We have Kickstarter, for example, Patreon. There’s new ways potentially to, in the end, it is really about organizing groups of people. Probably if you’re a solo artist, you’re painting, you’re painting, you’re doing something. Individual, maybe this stuff matters less, but as soon as you have a group of people over time they are investing their energy, their effort, their emotion, and certainly their money, then you need mechanisms, governance and understanding for both what we’re going to put into this and what we expect to get out of it and what our goals are and all that sort of thing. So that brings us to the vehicle we created for Muse, which I think borrows elements from some of the different types of containers we’ve mentioned, but we think also has its own special blend. Can you explain a little bit what that container looks like? 00:11:47 - Speaker 1: Yeah, so first of all, we did believe that Muse needed to be a commercial entity, and the main reason was, well, maybe two main reasons. One is you need a significant amount of investment to develop a novel product like Muse and bring it to market. We’re talking about 3 to 5 engineers or 3 to 5 staff members for 123 years. So it’s not something you could do as a pure art project, you know, say. Furthermore, if you have this vision of impacting the world in a particular way, it helps to have ongoing self-sustaining funding for it. So that’s another reason to make this a business versus a nonprofit or an art project. The meat of what makes Muse unique is how we treat the staff and the other participants around the business. And the top level thing there was we wanted Muse to be the place that we wanted to work and the place that we wanted our collaborators to work. And that meant a few things. One is we wanted to be a relatively team, which has a bunch of implications that we can talk about. We wanted everyone to feel like peers who were at the top of their craft and operating at the top of their game. And we wanted everyone to be treated as well and as fairly as possible. And in particular, we didn’t want to sort of founder class versus an employee class where they’re very different, as in typical startups. And lastly, we wanted a sense of dynamism in the staff and the team, where people come in, they go, and that’s a very natural thing to happen, and you’re less kind of bound and handcuffed to the company. And furthermore, you’re also not constrained in how far you can rise in terms of your impact and your influence and your ownership, just by virtue of when you joined. It’s more a function of your contributions and commitments to the company. So those were kind of our goals that inform the structure and then in terms of where we ended up, well, first of all, we did end up with the Delaware Corp, which is the standard vehicle for startups, among other things, mostly because that’s the best understood by all the potential participants, staff, investors, and has the best support for people having ownership, a variety of people having ownership in the firm, which was really important to us. But then where we went in a quite different direction was this idea of a partner. So at a typical startup, you have sort of three classes of people. You have the investors, you have the founders, then you have all the employees, and they’re all treated very differently and have different economics in the firm, and they’re a function of kind of how you join and how you come to be participating in the firm. And we want this model, like I was alluding to before, where it’s more like the staff members are peers with each other and have the opportunity to rise to that level over time regardless of when they joined. So that’s where our partner model comes in, which is sort of drawn from the world of professional services firms, like law firms and accounting firms, and the idea that There is, if you start a law firm, you get to put your name on the sign because you started it and your partner right away, presumably, but also over time people can join and through their contributions to the firm and their commitment and they’re taking responsibility for the success of the business overall, they can eventually become a partner, just like the founding partners. So that’s sort of the idea that we have with the Muse partner. They’re someone who can become a peer with the other partners and have corresponding responsibilities at the firm. So it’s not just that you’re responsible for being a good engineer, you’re responsible for helping basically directs how the business operates, making big business decisions and things like that, and you have corresponding economic interest in the business, much more so on a percentage basis than a typical employee would have. So I guess if I had to summarize with the partner, it’s the idea of we want everyone to act like a real owner in the business, and in order to do that fairly, you need to actually make them a real owner in the business. 00:15:24 - Speaker 2: One way to understand the business structure or how the container is different, is to compare and contrast with other options. You mentioned taking investment, we did take some seed funding from a lovely firm called Harrison Metal, who happily turned out to be understanding or at least willing to try out. Weird model here, but you could compare to other ways of doing this. So bootstrapping, for example, and there’s a few different approaches on this. I’ve done this in past businesses where you essentially do consulting work on the side or maybe it’s kind of related to you can try to sell your product to someone, but you sort of do some consulting. With them at the same time that like helps you pay the bills until such time as the product is self-sustaining, or something you see a lot in the iOS developer world is these what I call these indieDevs. Many times they have multiple apps, but it’s usually one person or maybe two people tops, and they can craft an app in Pretty short amount of time, a few months, maybe they’re doing it on the side, maybe they have other kind of some passive income from existing apps, or maybe they’re just doing it in their extra time alongside a job, and they can do that reasonably in 6 months, put it out on the app store, and then start making not a huge amount of money, but enough to make it pretty worthwhile for a single person. But as you pointed out, for Muse, which has this first of all very forward thinking or trying to reinvent a lot of these gestures, the human computer interaction aspects, the tablet power user interface, there was just a big investment first on the research side when we were in the research lab, but then even once we left the lab and we’re trying to take this kind of validated prototype and turned it into a product people can really use that just took a lot of time, a lot of iterations in a way that let’s say a safer kind of app wouldn’t. And similarly, there’s something that I do think is common in the startup world, which is big investments in design and brand, and you expect this from Slack and Tesla and Apple, and certainly Any up and comer startup, you have the money to be able to put a lot of effort into that sort of thing, and maybe we didn’t want to be quite at that level, but I also felt that a lot of investment there was part of allowing this first part of what we wanted to express artistically, but then secondly I think necessary for it to be successful. So that sort of says, OK, the iOS indie developer path or bootstrap path is really not viable. We need a little more upfront capital than that. But then you can compare it to startups where, in fact, by start-up standards, the amount of money we’ve taken is ridiculously small. I don’t think it would even count as a precede. And furthermore, coming upon 2 years into this, we’re a 5 person team with no particular plans to expand, but in the startup model you’re expected to really quickly scale out the team, be 8 people, 10 people, 12 people in that first year or 1st 2 years. And so from that perspective, the 5 person team, we would be growing much too slow, but we felt that that rapid team growth first of all, wasn’t necessarily quite the kind of environment we wanted to work in. And second, it wasn’t quite right for what we wanted to express with the product. And so we ended up in this middle ground that was neither the bootstrapper path nor the startup path, and that led us to thinking, OK, how do we get some investment, be able to make that investment in things like design and brand and exploring this more radical interface, but not necessarily go on the, you got to become a unicorn startup path. 00:18:49 - Speaker 1: Yeah, exactly. Another way to think about the funding situation would be, as you get more funding and you have more external investors and owners, you tend to have fewer degrees of freedom. So at the extreme end of you’re a large publicly traded company in many respects, including basically legally at the whims of the owners, they can more or less insist that you act purely in their best judiciary interests, and if they don’t like what you’re doing, they can take over your company by various means. And at the other extreme, you would have the art project where you’re in your house, you can do whatever you want. And, you know, in some respects it’s nice to be doing the art projects you have infinite degrees of freedom, but then you don’t necessarily have the capital and the collaborators and the teammates in a sense to help you accomplish a bigger mission. So, when we were looking at funding the venture, we wanted to go in the direction of raising a little bit of funding, but no more than we kind of strictly needed to, A and B. In order to minimize the extent to which raising that funding impinged on the desired degrees of freedom in the firm, we raised the funding from people who were aligned with our sense of mojo, if you will, or what what we wanted to do with the venture, and we’re therefore not going to use the fact that they were investors and owners as a way to shape the business in a way that wouldn’t fit with what we wanted to do. So being aligned with the investors was important, I think. 00:20:10 - Speaker 2: Another piece of the puzzle on funding and money flow generally is that all businesses should go through this cycle of they need upfront capital, even if you’re a lemonade stand, you gotta get the lemons and the pitcher and the cups and the poster board and the marker so you can make your sign. Everyone needs some amount of capital, but there’s always this cycle where initially you’re in the red. You’ve put in capital but you haven’t produced a functioning business yet and you hopefully over time in that time period could be very long. I’m gonna say for, you know, a business like Amazon, maybe it took them a decade plus to go to cash flow positive, whereas maybe for more bootstrap things you expect to get there basically right away, but for us, we wanted to have enough capital to make these investments we knew were necessary to even get a product that people would want to use or pay for. But it was also important to me or it was part of what I wanted to express with the business was to make a self-sustaining business where the product exists because people are paying for it, not because of continuous injections of venture capital. And partially this is my experience in the startup world, both with my own companies and other companies I’ve advised. But in the end, you will always serve the needs of the people who give you money, and that’s just kind of the physics. You can resist that in some ways, but it’s just kind of the long term, you’ll always converge to that. And so if your customers are the ones giving you money, then they’re the ones you’re serving. But of course they can’t. Maybe putting aside some unusual cases of big Kickstarters or whatever. For the most part, you can’t be completely customer funded to start. That’s where professional investors can really help out. They want to give money to fledgling businesses for a chance at a return, and so that’s a good deal. But if the startup path tends to be one where there’s long, many, many of capital and so you’re in some ways I’ve seen the it’s quite a joke or a criticism or something, but they say that startups in many cases their product is their stock. What they’re really trying to do is sell their stock and sell it for ever increasing prices and the product that they give to users and maybe even charge for but not enough to break even, that is secondary. And I really wanted the other way around, which is, of course, we need to do our fiduciary duty to our investors and give them hopefully a solid return over time, but ultimately, the sooner we can be funded by customer money rather than investor money, I think the more that will shape the company and the product that I want to make in a way that really is focused on serving customers. 00:22:48 - Speaker 1: Yeah, for sure. And one of the reasons that I like that approach is I basically prefer to serve paying customers versus free customers in general. This goes back to kind of the patio 11 thing of, you get what you charged for or something, where customers who pay serious money for tools tend to be invested in them and want them to succeed and understand their value and things like that. So it’s yet another reason to focus on paying customers. 00:23:11 - Speaker 2: Yeah, it’s a way to filter out people who really find a lot of value in your product from those that like free stuff. Everybody likes free stuff, that’s fine, but I think a business and a product works out best if you can have that real focus on, here are the people that get the most value from what I’m doing. Yeah I’ll note that I think it worked pretty well for us, this idea of we’ll take this seed-ish round, and then we’ll try to use that to get to, if not profitability, at least kind of a sustainability, at least not be losing money, and that really did create a lot of urgency on the team, I feel, to charge sooner and it was a challenge actually because I think as craftspeople. You think, OK, I don’t feel ready to charge money for this yet. I think it can be better. It still has bugs in it. There’s so many features to add. It’s a very natural thing when you hold yourself and your work to a high bar, but then you made this spreadsheet that basically mapped out cash and how we were spending it and what would happen if we started charging and it really made a difference starting charging just a few months. Earlier, because it really takes time to build up your customer base and that that is recurring over time, we could get to this sustainability on a trajectory that would allow us to not need to sort of go back to the well for for more funds and or just go out of business, and that was really focusing and I think it pushed us to charge a little sooner than maybe we would have otherwise. And that in turn I think really changed our relationship with our users who are now customers because now we have a different obligation to them and I think that further focused our ability to make a good product. So overall that kind of charge money sooner and then in turn try to grow into that price you’re offering or that product you claim to be offering. For me that was a really powerful focusing thing for the team and for the product. 00:25:03 - Speaker 1: Yeah, I think that was big and by the way, it was made all the more challenging by our take on pricing on iOS. Part of the hypothesis about how this venture can work with a small team, a relatively modest amount of funding, but still reaching self-sustainability. Is a prosumer price level on the $10 a month, $100 a year range, versus almost all iOS apps, which are $0.03 dollars, $5 maybe $999. It’s the wrong number of zeros to be able to make the physics of the business work. And so at the same time as we are craftspeople who it’s tough to charge for a product that isn’t where we want to be eventually, we’re also dealing with the challenge of we’re doing something quite different with iOS pricing, so it’s dealing with two things at once there. 00:25:47 - Speaker 2: Great, so we’ve got kind of this partnership model, small talent dense team, people who are all owners in the business. We’ve got a small bit of seed funding, so we can do a bigger investment than a pure bootstrap thing, but something trying to get to Sustainability sooner, and not be on a long term kind of multiple rounds of investment, and we’ve got prosumer pricing that potentially makes it possible to get to something sustainable for a 5 person team within kind of the physics of how many people are out there that need a tool like this, and what they’re willing to pay and that sort of thing. So that was, I think, kind of roughly the picture we put together, we wrote an internal memo that outlined mostly everything we just talked about back in the summer of 2018. So now the question becomes, OK, we’re coming up on two years in, how’s it going? Is this working the way we thought it would? 00:26:39 - Speaker 1: Yeah, I think it’s working out great so far. Now, there is a huge question mark around the financial success and viability of the business. We haven’t fully demonstrated that yet, and that’s a question mark that’s going to be out there until we have that information, it’s hard to fully evaluate this model, right? But in terms of how it feels to work day and day and the staff that we’ve attracted, that feels. Great to me, and I especially love this feeling with the partnership model that you have 5 people who are operating at the top of their game, and who you fully trust to make great decisions for the business independently. That feeling is awesome and really helps us, I think, move quickly and punch above our weight, even as a 5 person team. 00:27:19 - Speaker 2: You know I’ve always kind of liked the what I think of as the pirate ship model, kind of a group of people who band together for a common purpose, but it’s not this top down classic command and control. One person is in charge, everyone else just executes, and individuals can pursue their own decision making, as you said, but the reality is, I think I don’t. how it would be with even more than 5, but certainly any, I don’t know, before this you were working at Stripe as part of a big team there and amazing company, but it’s just there’s hundreds or I don’t know even now thousands of people and there has to be some coherence to the decision making and so that in turn leads you into cascading OKRs and all the Big company stuff you think of it’s necessary, and you know, I think it’s necessary to do something at that scale, but for me personally, yeah, it is a lot more fun to make individual decisions for my own work and then for my teammates to be able to trust that we have enough shared vision, alignment around purposes, sense of trust in each other’s capabilities as craftspeople, but also that we were seeking a similar outcome in the business. And that people can have a lot of autonomy while at the same time, we’re working together for a common purpose. We’re not making decisions that contradict each other or will make the whole thing feel incoherent. 00:28:33 - Speaker 1: Yeah, exactly. And furthermore, I think there’s a sort of talent arbitrage that we’ve been able to pull off here in two respects. First of all, I think people are stepping into a level of responsibility and impacts and skill that they wouldn’t have stepped into so quickly or just such a. extent, if they were in a bigger organization where they had a more specialized and confined and limited and structured role. And that’s the result of you give people responsibility, you trust them with it, and you make them big owners in the business, and they take that very seriously, and they tend to step up to the challenge if you find the right people. And second of all, I do think that the model is very attractive to some people, and I won’t put on the spot here, but I, I think people have found their way to the venture that otherwise they’re basically not hirable by general purpose companies, right? But because the model is so unique and attractive, and because there is that mojo, I think you can bring people into the venture that otherwise you basically wouldn’t have been able to hire. 00:29:27 - Speaker 2: Yeah, for me, looking back at this almost 2 years, we’ve been doing this slightly unusual model. I actually went to review the memo that we wrote back in summer of 2018 just to kind of look at our original goals and see the degree to which we’ve executed that versus it’s evolved. And one interesting thing in there was essentially what the risks or open questions are, and I’m happy to say that two of those we’ve already answered in that. Intervening time, just as we’ve discussed. One is just our ability to raise money. So we went out to look for seed funding from the kinds of investors who normally would invest in startups, and we had kind of a weird story where we basically said, look, this isn’t unicorn potential. We’re not trying to follow the standard startup model. We do think there’s something quite interesting here. We think there’s a potentially a very good business here. But, you know, we’re explicitly not on that path, and we’re looking for less money in exchange for less ownership, and we’re not gonna fit the normal model and for many, actually most investors, that was a, well, we like what you’re doing, it’s interesting, but this just doesn’t fit our model. But we did manage to find some folks who liked what we were doing and certainly it helped, I think a lot that you and I have and others on the team, you know, we have a really nice CV. In the tech world and the amount of money we were asking for was so small that people felt they could take a risk. I think that would be tougher to do without the career capital that we have in this particular team, and I would like to see if there are more businesses that can do with a model like this. It would be nice if it was more possible for people who didn’t necessarily have the background of Stripe and Hiroku and whatever else to be able to get this kind of funding. So that’s one item to risk is the raising of money. The other one is the ability to hire, and I think I outlined that in the previous podcast episode on this, which at the time we’d just been joined by our fourth partner, Leonard, but it’s one is can be an outlier, so I thought, OK, well, we got pretty lucky with that, and he really seemed interested in being not just a great designer as he is, but also someone who would have broad ownership in the business and interested. All pieces of it, not just his sort of specific discipline, can we replicate that? And the addition of Adam Wulf to the team made me say, OK, yeah, it seems we can, right? We got not just the original three who wanted to do things this way, but then 2 more we were able to attract, as you said, maybe even people we wouldn’t have been able to hire if we were a slightly more conventional company, that that was appealing to them. And I do think it’s not a highly scalable model, but it’s scalable enough to serve our purposes, and we have no plans to expand the team beyond 5 for the foreseeable future, but we also think that’s the right number of people to execute on this vision. So from the perspective of answering those two risks, I would say that is going well. 00:32:02 - Speaker 1: What are the other risks on the list? 00:32:05 - Speaker 2: Uh, the other big one is the one that you just mentioned, which is can we get sustainability, right? Because I think that for the record, at the time of this recording, we are not revenue sustainable. Let us say if we run out of our little nest egg in the bank here, we would not have enough to keep the business going, at least in its current form. But the graph is trending in the right direction, we have new customers every week, and if you look at the way that the lines meet in terms of, you know, bank account going down, revenue, and new customers coming in, we do think it is viable to get there, but we won’t know until it happens. So I think that remains the biggest risk, and if we do start to get close to being in the red on the bank account, and then we have to ask the question of, OK, you know, do we just sort of give up and go to business, to be revenue based financing, which could be interesting, but I think maybe we might not be the right shape of business for that, or do we go back to Silicon Valley investors, but now we’re sort of like breaking our model, right? We’re saying, well, we were just going to raise this one round and charge money right away and try. get to sustainability based on that, but if we need to go and refresh from that well, that pretty naturally takes us into just the startup path of raising perpetual rounds of funding, and your eventual outcome is acquisition by a larger company or in some cases going public, but I just don’t think we have the right kind of business, nor is what we want to express the sort of thing that makes sense for a big public company, right? Yeah, and then addressing the more personal side of it, which is just creating this company, this vehicle uh that is a place we want to work. I like you wanted to be a little less of a manager, a little more of a maker, and It is interesting because, you know, we do spend a lot of time. I spend a lot of time tweaking CSS and manually typing expenses into QuickBooks, which is a perpetually rote and frustrating activity and many other small things that were, how we raised a little more money on the startup path. Yeah, we would be hiring office managers and other kinds of people we would have a bigger team that would mean that we could do less of that stuff. You get more leverage or something like that, but that’s actually what I wanted. I’ve gone both directions and I think I’m at my best when I’m, I like being on a team, that’s really important to me. I want to do things that are big enough that they require a team as opposed to just, you know, kind of a solo activity or even like a two person partnership. But I like to be on a very small team where you can be doing a lot, but most of what you’re doing is making, I would call it, rather than the management and leadership tasks that come naturally with the expansion of a team. 00:34:42 - Speaker 1: Yeah, totally. And I think in addition to this maker versus manager access and how that’s influenced by the size of the team, I also think that a smaller team gives you more degrees of freedom, which is great if you’re someone who just likes freedom, like me, but it’s also great if you want to do something unique that requires moving several variables at the same time. So for example, this local first idea that we’re working on, this idea that you have all the data on your device and it’s very quick to access and it’s secure to you and things like that, that requires pulling levers on engineering, products, business strategy, the client side, the server side, interfacing with the research at the lab. There’s all the stuff that you Got to kind of pull together. And if you had to coordinate a bunch of people to do that with meetings and planning documents and all that, it would take forever. It might just not get done. Whereas if it’s a small number of people or even one person, you’re much more able to come up with these weird combinations of variables to produce novel results. And that goes back to this idea of making a statement or building something unique for the world. 00:35:43 - Speaker 2: Another element of degrees of freedom is outcomes. So outcomes could include, you have a profitable business, but it could also include something like an acquisition or an IPO and the startup world, there’s really the outcomes that matter are acquisition, IPO, or go out of business, and that’s sustainable but moderately sized business is a non-goal. That’s actually a bad outcome from the perspective of investors and the whole. The system is kind of built around that. You shared a nice article with me some years back called VCM Math, which I’ll link in the show notes, but the way the person puts it is, you know, venture capitalists in pushing these businesses to become a billion dollar company in 10 years. This is not because they’re jerks, it’s because the model demands it. This is how it works. That’s where this money comes from. It’s only possible if you push for these polarized outcomes. And that’s well and good if you know what you’re getting into and you’re seeking that kind of go baker bust result, but for the, I think potentially large number of potential mid-size businesses, very solid mid-sized businesses, that’s of course not a fit. And so by keeping that smaller amount of Capital upfront, keeping the team smaller, we leave more possibilities for what counts as a good outcome. And so, of course, we still can have a startup style outcome, and that might be something we consider good, but there’s also other outcomes that I would consider extremely good. But that in turn leads into, OK, how do investors as well as the partners who have this significant equity stake and in fact are taking lower salaries than they would in other places in order to get this equity stake, but how does that equity become worth something? So the startup world typically it’s through. or IPO and there’s no other outcome. So you did quite a bit of work on the financial pieces that could potentially make this work. So how do investors or partners over the long run, if news is able to be a successful and profitable business, how do they realize the results of their effort? 00:37:52 - Speaker 1: Yeah, this is a tricky one. So certainly if there’s a standard outcome in the startup world, like an acquisition or something that’s straightforward and it’ll work like other places, just the percentages would be different because again, we’ve given much more ownership to the staff. But if you are profitable, it’s quite challenging. So I hope our listeners who have joined for discussions of gesture-based interfaces will forgive my aggression in US tax law here, but it’s actually really important for how you compensate your staff. So, tax and securities laws makes it quite hard for people, individuals to get cash out of a company like this, and I can kind of play through the different scenarios that we thought about. So one thing we’ve considered is the idea of small scale tender offers. This is where a company or someone else offers to buy shares from existing investors and in that way, existing owners of the equity could get some liquidity and have cash to support their families or what have you. 00:38:46 - Speaker 2: And small digression there when I first encountered the term tender offer, I just thought it was the sweetest thing. Here’s an offer for you tenderly for your shares, but I, I don’t think that’s what it is. It’s, it’s that they are tendering an offer, right? But it basically just refers to an internal stock purchase, right? A transaction where one person has some and they’re going to sell it to someone else on an open market transaction. And is that similar to or the same thing as stock buybacks and kind of public companies? 00:39:13 - Speaker 1: Yeah, so a stock buyback would be buying the stock from the public, which I guess could conceivably be some of your staff if they own it on the public markets, where the tender offer, I associate that more with a more closely held private company, and it’s not a public transaction, it’s more of a private offer to specific individuals to buy the equity. 00:39:33 - Speaker 2: How does that relate to, we mentioned taking inspiration from the partnership model, attorney firms, and so on, and I think it’s pretty standard there that when you’re going to leave the firm, they buy you out, right? Even maybe with a restaurant, you know, you can imagine a couple of people in a restaurant, one person decides they’ve had it with the business or they’re moving on to other things in life, it’s normal for one person to buy out the other person’s steak. Would that be a tender offer or something else? 00:39:57 - Speaker 1: Hm, interesting. I suspect that’s a little bit different because those are probably LLCs or otherwise not Corps, and again I associate tender offer with basically with the Delaware Corp, and that could, for example, even be written into the contract that not only are they gonna offer to buy you out, but in fact you have to sell. At perhaps a formulaically determined price, so that way they might specifically not want the ownership to escape the currently active employees, for example. Basically, I think when you have LLCs or other non-Corp structures, things can get a little bit weirder and different just because they’re not as solidified and standardized in terms of how they operate. But there’s some similarities in spirit of, OK, you’ve completed this part of your journey and you want to get some liquidity for that, and the company has interests in acquiring that equity, and so it makes mutual sense to do this transaction. 00:40:42 - Speaker 2: Yeah, I guess they all seem similar to me in that typically an ownership stake in a private firm of any size is just totally non-liquid. You cannot really do anything with it. You can look at, OK, in theory, our last funding round value us this amount or I could take a multiple of revenue, the company is worth a million dollars and I have 50% of it. Yay, I’m a half a millionaire, but that’s not really how it works because you can’t actually sell those shares versus public markets, which of course, It’s very good for liquidity in that way, and then an acquisition scenario where one company is buying 100% of the stock of another company, and then you just divvy up that share price among the owners, and that’s why those two scenarios create exits for the investors or create ways to get liquidity for the investors and the employees who have taken options. But if you say, as we have said, You know, we don’t plan to take either of those paths. We want to build a profitable business that goes in perpetuity, making good software. OK, then how do I ever realize the outcome of my shares? And so the tender offering is one mechanism, as are these others we mentioned for creating liquidity isn’t the word for it, but just the mechanism for one person to sell their shares and get out and get some money to someone else who’s maybe more active in the business. 00:41:58 - Speaker 1: Yep, yep. And another nice thing about tender offers is they don’t need to apply the same to every person, by which I mean if it’s just the case that you or someone else because they’re leaving or whatever, wants to make this exchange, we could potentially set that up versus having to do something equally on the basis of current ownership. And another example of something like that would be a dividend which we can talk about. Yeah, there’s a lot to like about tender offer, but it’s not something that we would do lightly. There’s a variety of reasons. One is that you need quite a bit of capital for it to actually make sense for it to be material, and for you to have an appropriate amount of cash in the bank and the company even after the transaction. So in that sense, it’s definitely a ways out. But also, unfortunately, there’s all kinds of really weird tax consequences which we don’t need to go into the details here, but Basically, by doing a tender offer, you could potentially impair the equity of the other owners, if you do it wrong or do it at the wrong time or do it too much. So it’s fairly fraught. But it’s a potential thing out there. Another thing that we thought about and liked was dividends, and dividends are nice cause they’re very mechanically fair. 00:42:56 - Speaker 2: Big fan of dividends. Yeah. So just to define that, this is the idea that in a way it feels like almost the purest expression of capitalism or how businesses are supposed to work, which is when a company turns profit, they can choose to take some portion of that profit. Some, they’ll reinvest back in the business, kind of retain earnings, I think that’s what that is usually called, but then the rest they say, hey, we made some money, let’s share it with everyone who helped make this business happen. And that share is determined by your ownership in the company. And so for me, I had a, I guess personal experience with this in my very first business, which was a basically a bootstrapped. Business, a payment gateway called Trust commerce, and we had been operating, I don’t know, founders, you know, living on their own savings and whatever, just trying to pay our bills with whatever money came in, or trying to pay the basic business bills, servers and offices and phones and stuff like that. And I remember the first time we were left with $1000 in the bank account that was not accounted for us, well, what should we do with this? Well, we could pay ourselves, that’d be great. And so we wrote dividend checks for $300 for each of us, because there were 3 people in the company, and it felt really great. It felt like this, we made a product that people valued enough that there was a little bit left over that then we could give to ourselves. And even though the, the number, the absolute number was small, that feeling of kind of profit in its purest form is a really nice one. And so dividends are just the idea that the company is making money, so you share it with the owners, and that’s something. It’s not really part of the startup world and even not really as much a part of, I feel like public equities, where I think they could usually call them growth stocks or something like this. I’m probably speaking out of my wheelhouse here or income stocks or whatever, but the idea of just you’re going to buy the stock in a company, so that then when that company makes money, they send you a dividend. Those are usually a lower return type of stock versus ones that are based on the growth of the stock itself. You buy it at a lower price, you sell it later for a higher price. But the income stocks, again, that is business at its most pure and fundamental, which is the company made money, you own a piece of the company, therefore you get a portion share of that. 00:45:04 - Speaker 1: Yeah, and it’s nice because it’s mechanically fair. If you have $100,000 to distribute in dividends, you look at the cap table, so and so has 5%, great, they get a $5000 check, and you know that everyone is being treated fairly, at least insofar as the equity in the company is owned fairly, and you don’t need to have a lot of discussions and machinations about how you actually split up the cash. But dividends are challenging for their own reasons though. One reason, for example, that you don’t see a ton of dividends in the public markets is some companies don’t have cash to throw off. A lot of it is currently, instead of being dividended out, it’s being used to buy back stock, which is kind of equivalent actually, but buybacks get basically better tax treatment. So there’s those pesky tax laws again, causing weird distortions, but in our case, it’s hard because Some staff have straight stock and some staff have options. And that again is because of tax law. Basically, the US government doesn’t want you giving straight stock to people. They view it as compensation that needs to be taxed immediately, even though it’s a liquid. So basically, to avoid bankrupting your staff, you have to give them options. But then options in uh the Corp, when you dividend now you dividend to the stock owners, the straight up stock owners, not the option holders, so that probably wouldn’t be fair to them. 00:46:13 - Speaker 2: And to be fair to the tax man here, trying to levy income taxes on stock earned for work is very challenging because that stock has zero value when you get it, and it’s very likely to have zero value ever, but then in some cases it can be worth a lot, right, that initial stake that, I don’t know, you know, the Google founders had turned out to be worth a huge amount, but the vast majority of startups and even businesses will end up. Not being worth anything. So how do you tax something when you can’t know its value except extremely retroactively? Yeah. And I’ve had my own challenges with that because I’ve basically built a career around starting companies or advising for companies and taking equity and kind of have this, I don’t know, flywheel of I basically earned some money on past ventures, and then I can use that to pay my bills or whatever and earn pure equity in future ventures, and then All of those pan out, but I kind of have a portfolio strategy, you might say if I own stock in companies I’ve started over the last decade or decade and a half as well as companies I’ve advised for in some cases invested for. And so all of that income, all of that stock was worth 0 when I got it, but much of it turns out to be worth $0 ever, but then some of it turns out to be worth a good bit. And when I can cash that out, I can use that to pay my bills and continue my career. But how do you tax that because Typically you tax things at the time they’re earned, but this can only be evaluated when it kind of resolves, which can be often 10 years later, that a piece of stock you earned pans out and has a value that can be attached to it. So it’s not an easy problem. I think it’s still an evolving area. Certainly the US tax law. I know Europe is grappling with this as well, because it’s just the standard models for how we think about income just don’t fit well with us. 00:48:04 - Speaker 1: Yeah, definitely an area that’s being worked on. It’s just too bad that it hasn’t been figured out yet in a way that would be more advantageous to basically giving staff more compensation. 00:48:13 - Speaker 2: Yeah, it can be frustrating, which is basically trying to do something that’s as fair as possible for investors and people earning what they call sweat equity, where they’re essentially earning stock in exchange for their work. We cannot treat those the same because the tax law basically means that, as you said, the people earning equity through sweat get screwed, and so then you have to create these different classes of stock and do different things, but then that effectively means You have more and more divergence in the stakeholders, which is against the spirit of what we’re trying to do. We’re trying to create this thing where everyone’s in it together, we bring different things to the table. Some people bring their efforts, some people bring their money, some people bring both, but everyone can hopefully have a sense of fairness in the sense of kind of knowing what you put in and knowing what you potentially get out or how to share in the success long term. 00:49:05 - Speaker 1: Yeah. And there are ways you could potentially work around this for dividends. You could do a sort of phantom dividend where you say there’s 100% of the cap table and straight stock and there’s an additional 40% in options. You can dividend it out 140 units, 40% to the option holders, and 100% to the stockholders, and the stock would be straight dividends and the option holders would get like a bonus basically. To do something like that, and you could even imagine doing more basically ad hoc type things like that where you essentially make a formula and then do a bonus payout, but make it more formulaic less just like, oh I think you did a good job this year, here’s a check and more you have this sort of ownership in our. Current cap structure and based on that, according to this formula, we’re doing bonus payouts like that, but that also gets messy because there is an element of discretion and also when you’re dealing with investors, like they don’t want to get a $17 check, and you got 4 more employees, you got to take down their address or whatever. This is a lot of weird mechanical stuff there. So I, I think realistically it’s, we gotta wait a few years and see how this all plays out and what the shape of the business is, but what we’ve done is we’ve built up a lot of potential energy, a lot of ownership, a lot of equity with the staff members, and hopefully we can find a way to convert that into kinetic energy to continue the analogy in the future. And I’m pretty optimistic. It is asking the staff to trust us to a significant extent that we’ll be able to figure that out and treat it fairly, but I’m pretty hopeful that we would be able to do something that’s fair to everyone. 00:50:28 - Speaker 2: So, would you recommend a structure like this to someone else who wanted to start a company and or do you imagine, you know, if you had to start a new company yourself today, would you reach for a structure like this? 00:50:42 - Speaker 1: Yeah, well, we thought about this for a very long time and it was hard to come up, and we spoke with a lot of experts, and it was hard to come up with a better setup. So one way to think of this is, insofar as we’re talking about staff compensation, equity ownership, it’s kind of in the standard Silicon Valley model, but with the percentages dialed way in favor of the staff. So in that respect, it’s kind of strictly better, I would say, than a typical Silicon Valley model. And so it can’t be that wrong, strictly better at least for the staff, I would think. And we didn’t talk about the other things that we do there in terms of very long exercise windows and more favorable investing schedules and so on, but basically, we’ve taken the standard mechanisms that are used in stock, Delaware Sea Corps and turned the variables that we can so there’s as favorable as possible as staff. And I think at least that is a good thing if you would have otherwise considered it a standard Silicon Valley model. The one other option that I do think is interesting, but that I couldn’t quite see ourselves going down was Using more like a phantom stock approach, where you have essentially an internal ledger that’s separate from the ledger that you have with Delaware in terms of the equity ownership in the company, and it’s on the basis of that internal ledger that you would make decisions about how you do payoffs. And there are some companies that are exploring this, you know, it’s like every month you work with the company, you earn a point, and then if we ever do dividends, you divide the dividend by the number of points and that’s how much we send you a check for, something like that. That’s nice cause it gives you a ton of flexibility, but it’s much less precedented, and it places even more trust in the company, because you have less of the legal guard rails to confine what they can do or not do. So I think that’s interesting because of the flexibility, and I would love to see people try that more, but I wasn’t ready to, you know, establish a whole bunch of new case law just for the sake of this venture. 00:52:21 - Speaker 2: Now, precedent is very important. There’s the general business wisdom is try not to innovate on the model, try to focus on your product and your and don’t get too caught up in company mechanics. It turned out that this was something that we were both passionate enough about in terms of the place we wanted to work, but also I honestly do think we needed a different type of container, right, that we knew that as we talked about towards the beginning there where an individual productivity tool and what you can sell for even at a prosumer price and what the mechanics of distribution and things look like there versus other, you know, there’s a reason why Venture funded stuff is either Enterprise, SAS, or, you know, a monetized consumer products. Those are models that work well with that funding style, and the thing we wanted to express in terms of the product and the thing we wanted to exist in the world, as well as the company that we wanted to work at, I think just demanded a different model. I don’t think it would have worked with another one, so I think that was a way to justify the ways in which we are deviating or innovating a little bit on the container side of it. But then at the same exactly as you said, I remember a lot of design choices we made and things like, you know, we’d love to give employees options or we’d love to give employees pure stock, but that’s just way too hard or even impossible without these punishing tax consequences. So, OK, we’ll kind of have these two classes of ownership in the company, that’s not the spirit of what we’re doing, but like, at some point you gotta bend a little bit to realities and what there’s precedent for and what attorneys and accountants are used to working with and all that sort of thing. 00:53:54 - Speaker 1: Yeah, and I think in all of this there’s also a very real morale element where let’s suppose the company is very successful some years from now, all the current and former staff are going to remember that we worked very hard to try to do the best we possibly could by them. They were like basically on all the email chains with the lawyers, more or less literally, and we would debrief and talk about, OK, here are the options that we have. What do you all think? Does this work well for you and things like that, versus a model where That was all opaque and there was not even an effort made to try to set things up as best as possible for the staff. I think that just helps people feel like they are being treated well. 00:54:28 - Speaker 2: Well, speaking for myself, I am sometimes in the position of offering advice, let’s say, to folks who are thinking about what kind of vehicle they use for their business, and kind of the new approach does come up and Certainly, it’s huge to ask, what are you actually trying to make, because you need the right vehicle for what you’re doing. If you need huge upfront capital or a big staff, I’m not sure this model can work, to be honest, or if it’s something that can be done with more of a small team, 1 people, 2 people in a shorter period of time, then maybe this is also not the right way to do it. And there’s other kinds of vehicles as well. For example, I think The nonprofit is a little bit underutilized, can be an incredible vehicle even for software and technology products. We know of maybe someone like Mozilla or the Apache Foundation. There’s many smaller examples such as processing Foundation, which does this kind of generative art coding tool language thing. There’s many others where I think if you think, OK, what we want to make is more open source or it’s more of Long term kind of benefit, less of a maybe it’s more educational or maybe the targ
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: So I think there’s space and the good thing is that niches are powerful now because niches are big enough. So if you only solve a smaller problem, but you solve that really well, you have a shot at that. 00:00:17 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for thought on iPad, but this podcast isn’t about Muse the product, it’s about Muse the company and the small team behind it. My name is Adam Wiggins, joined today by my colleague Mark McGranaghan. Hey, Adam, and our guest today, Valan Oros of Kraft. Hey, Adam. And B, you live in Budapest, which is a city I had the opportunity to visit for about a week some time back, did all the things I suppose a tourist normally does, got a bike, rode around, looked at the big beautiful bridges, observed the main government building, which is really a stunning piece of architecture. Power limits, yeah, looks even better in real life than in the pictures, I would say. But of course, that’s probably the tourists perspective. What do you like about living in the city as more of a native. 00:01:07 - Speaker 1: So for me, living in the city is really about being close to my friends and family. So I’ve been born in Budapest. I think Budapest is a very livable city in the sense it has walkable areas, it has greener areas, you can use cars. And really interesting part about Budapest is I always think, you know, we’re so small in Central Europe and nobody will know anything about Budapest. But typically, this is what happens when I talk to people, hey, I’ve been beat up and they say, yeah, I’ve been there, you know, I’ve been there for 1 week or 2 days as a tourist and I love the city. So it’s nice, it’s actually more widely visited than I would have assumed earlier. 00:01:44 - Speaker 2: Yeah, well, Berlin is also a city that has a lot of tourism, of course, but uh it’s had a different feel in this last year when travel restrictions and the normally areas that are full of tourists are pretty quiet. Not, I don’t necessarily see that as good or bad, it just changes the energy is Budapest got a different feel in this last year. 00:02:05 - Speaker 1: Yes, it got a very different feeling and I actually have to say I loved it. So we have areas like the castle in Budapest, which usually, you know, us locals do not visit because it’s very full with tourists, and in these days it’s been quite empty, so I have a small girl and we went out there a lot and, you know, play on the cannons and in the old streets. So it’s funny how a little bit it felt like you can get back very loved part of your city for locals, and it has a very, very different picture. So at least there are some things that aren’t totally negative in the sense of, we did actually rediscover a big chunk of our city. And I like that a lot. 00:02:54 - Speaker 2: Um, yeah, that makes sense. I mean, obviously there’s a big economic impact for a place that is a big part of the economy is tourism, but yeah, good to find that silver lining, I guess. And before we get into our topic here, I’d love to hear about your journey that led you to creating craft, and of course maybe you should tell the audience also what craft is. I’m a user customer. I’ve used it to write any of the recent news newsletters. I also wrote a pretty long essay called Making Computers Better that was entirely written using craft, so it’s my go to writing tool these days, but I’d love to hear your description of how you pitch the product to folks and your journey in coming here. 00:03:32 - Speaker 1: Yeah, so it’s very interesting. So for me, Cry at Kraft is a product that helps me think, and I like to think a lot through writing, and it was really inspired by the fact that I’m a very mobile person. My job has been in the last 10 years of I ran a company which built mobile apps and then I ran mobile for Skyscanner, which is a flight meta search engine, so it helps you find flights, and I’ve been overseeing the mobile product. And I always had this frustration that it’s so hard to think on our devices, so hard to capture notes, so hard to structure our thoughts, and really this was the real inspiration for me of how could I use these beautiful touch devices and it’s not just the iPhone, it’s also the iPad. And when I started in 2016, we didn’t have the pencil or the pencil probably we had, but the first generation, and it wasn’t the iPad Pros, but you could just feel that this device is so much easier to move around, you know, you can pick it up, it’s battery life, it’s superior, so it was the tool I wanted to use for my work every day, but just the lack of software because essentially at that time, And even today, frankly, most iPad products are blown up iPhone products. They’re not really optimized for that form factor, and I think that drive of just willing to use that beautiful product every day, and being able to use it productively was one of the core factors of me starting craft, because on the web, on desktop browsers, there are many, many products that are actually really good. But when it came to working on non markdown stuff, because I don’t really like markdown in the way of, I don’t like to see the syntax, and it’s too techy in a way for me, there just wasn’t anything between the complexity of Microsoft Word and plain text editors, and I just felt I need something there to be productive, and this is what led to where we are today with Kraft. 00:05:36 - Speaker 2: That certainly speaks to me personally, but also in terms of some of the motivation for Muse, even though we started in this research background. One of the things that happened there was in looking for sort of tablet platforms as a potential place to explore power tools and then realizing just how good the iPad, and particularly with the pencil once that came along, what an opportunity that represents and how exactly as you said, how woefully underutilized that opportunity is because yeah, the apps just aren’t built for it. So another notable thing here is, I think you built the iPad version first and you have a Mac app now, but that’s built on this catalyst technology and essentially allows you to start with the iPad, do the advanced gestures and that sort of thing. What motivated you to do that and what was the experience like to put it across. 00:06:26 - Speaker 1: Yeah, so we’ve been iPad first, and then actually went to iPhone, and after iPhone did a tour on the Mac. And really, Catalyst was extremely challenging. It is still is extremely challenging, and the reason we did it was, we figured if it’s for free, because we can just use the same code base, why not do it. And at the start, it seemed very easy because it’s just going to work. But then as we realized that for, you know, a Mac product, we need to do completely different UIs interaction models. It did turn out to be quite an investment, and it is still an investment, but we do see that it’s being used by a lot of users and having access to their notes and writings across platform is extremely important for them. So we would have eventually probably built it. I think we’ve been a little bit overly optimistic on how hard this is going to be, and that turned out for now quite well, but honestly, we are still struggling with performance, especially on the non-Apple silicon chip Mac. So on the new Macs, it’s amazing. I mean, the worst Mac for performance, you wouldn’t imagine, is the 2019, 16-inch MacBook Pro. So what you would think is the fastest because If it’s not plugged into the battery, it uses a much weaker graphics card for that retina display and it makes everything very slow. So it’s very unintuitive, but it’s interesting. 00:08:01 - Speaker 3: Yeah, we had a similar issue with Muse on the iPad and the iPad Pro, where the iPad Pro, large version was that 12.7 inches, 12.9, yeah. Yeah, there’s just so many pixels and so if you have any inefficiency, even the recent models, you get frame rate loss, whereas the older iPads that were 9 or 10 inches, it’s not nearly as many pixels, it’s much more forgiving. 00:08:23 - Speaker 1: And especially, and then if you go back to the old old iPads, which have only the simple, the non retina pixel density, and your product just flies, and you’re like, 00. 00:08:35 - Speaker 2: Yeah, there is a little bit of this treadmill sometimes that hardware gets better and faster, chips get more powerful and everything, but then we want to do more with it, and retin is a perfect example where that essentially just doubled the resolution on both dimensions, but of course that’s multiplying the fact of essentially 4. Tracks load on all your graphics cards and memory and storage and bandwidth and everything else. So it seems we’re always in this home stasis of computers get faster, but our software doesn’t get faster because we use it to do more impressive things. And I’ll parenthetically note here you have a great guide to using catalyst that I’ll link in the show notes for more technically minded listeners. But if you put aside just the engineering effort, even the design side, as you said, the Mac is just a totally or desktop computers is just a totally different platform mouse or trackpad, keyboard that’s very different from Touch from Stylus, and this is something that’s kind of a point we harp on with Muse that we really do think that for a lot of creatives. So these 3 devices in your life, the tablet, the computer and the computer workstation, let’s call it, and the phone, and they all serve different purposes and they’re all important and exactly as you said, it’s important to be on all of them, which is why Muse will probably have a Mac app here in the future at some point. But if you just take one from the other, you take from the desktop and import to the tablet or from the tablet to the phone, or phone to the tablet, as you pointed out, is more common, you get this. The transliteration problem of you’re bringing an interface that is not native there and then it just feels bad, it doesn’t work well. So I would imagine that that process of adapting your sophisticated gestures and your sort of very modern writing tool to also be consistent with the tool that you already had on the tablet, but also be consistent with what people expect on the desktop, that seems like a big job and one that doesn’t end as you add new features, right? 00:10:23 - Speaker 1: Yeah, it’s very challenging. Like you mentioned 3 different device classes like the phone, the touchscreen tablet, and the workstation computer. And I think really the challenging is that these are merging, right? So when you think about the new iPad Pro with Trackpad and the keyboard, and it’s when you sit in front of it and you interact with it, you want to interact as if you were on a laptop. And then when you look at, you know, some of the new Mac OS releases and how those shift visually towards more favor in iOS. So really what’s very challenging for us is the iPad actually, because the iPad is this very hybrid device which a lot of people use as their laptops, especially students, and the same interactions, fully keyboard, you know, very rarely touch the screen, and then you have the other half of people who use it with touch or stylus, and it’s not even that segmentation because the same individual within a minute difference might, you know, take it out and use it completely differently. And it’s very interesting, for instance, we have a section in search like on Mac OS we show the search previews. So when you get a list of results, you get a hover or with the keyboard you can move up and down and see the previews of actually different results. And the real challenge for us is when you have a keyboard attached, we want to do this, but when you don’t have a keyboard attached, with touch you don’t really move focus. Between UI elements, right? You just touch on something and then it opens. So then we have to hide the preview area, and there’s no really strong API which helps you to understand if the user is actually using the keyboard at the moment or not. So I still don’t think we fully understand, despite starting on the iPad of are we going to base the Mac app based on the iPad, or are we gonna move the iPad towards being similar to the Mac, or is the Mac a completely different story? So it’s extremely interesting because this whole ecosystem is a moving and shifting target. So by the time you think you understand it, there will be a new accessory or, you know, who knows, maybe in March or May we’re gonna get a touchscreen Mac and then we’re gonna go completely bonkers. But it’s extremely interesting. It’s one of the biggest challenges I’ve had in my career, and it still is, of just figuring out how pieces come together. 00:12:51 - Speaker 2: I’m a big fan of multimodal input and being able to convert modes a little bit. I use my iPad that way. I basically haven’t had a laptop in a couple of years, and I use my iPad as my travel device, and I’ve got a full-size workstation that’s stationary and plugged into the wall in my home office. And yeah, the iPad’s convertibility between Flipping out the keyboard versus more classic tablet mode, landscape versus portraits, leaning back in a chair, sitting at a desk, pulling up the stylus, touch versus mouse or trackpad. I really like that and even something like voice input. I really like having a lot of options being able to switch around. I agree that right now both the design conventions have not yet evolved to cover, I think even a tiny fraction of what’s going to make truly fluid multimodal inputs work well, and then some of it is also technical as you said, there are cases where for example we needed to detect whether the virtual keyboard was on screen versus a hardware keyboard because you do different things. There’s actually no API. For that, I think we did some hack that was around just checking the viewport. If the viewport suddenly cuts in half, that means that the virtual keyboard has split up and now you might want to do something in response to that. But I think it’s a good illustration of the deficiencies there reflect that what you are doing, what I hope we are doing as well, are really on the cutting edge of this kind of new world of multimodal input and devices. 00:14:17 - Speaker 1: And, and when you say multi-modal, you know, one person might think 2 or 3 input sources, but we really have touch. You have pencil, which is a very different type of touch. You have keyboard, and then you have mouse, and you can never know which of these the user has or does not have. So designing interfaces and workflows, which can adapt to these. Or as you mentioned, we’re just not there in terms of design patterns and evolutions, and I think even Apple’s own products often are subpar compared to what could be achieved. 00:14:49 - Speaker 2: Yeah, but that also makes it an exciting area to work in, right? 00:14:52 - Speaker 2: Absolutely. I like to be on the frontier, so, exactly. 00:14:55 - Speaker 1: If you like to throw away stuff and experiment and you know, figure out how it could be better, it’s an extremely exciting domain to be in. 00:15:03 - Speaker 2: Well, maybe that naturally brings us to our topic today, which is software which is focused on interfaces. So the contrast here I think is that Kraft and Muse and a few others I might mention are really about offering you and selling you, right? You pay money for software that will give you a really great interface for doing the thing you want to do in the case of craft, that’s writing, in the case of news, that’s thinking. And the way that most software I think is kind of built these days or the value comes often from the data, right? So the fact that with Gmail or Notion or something like that, it’s that all of your company’s data, your emails or your documents are there, and you know, maybe the interface is good. Gmail is a good example of something that I think originally was really breakthrough when that interface came out 15 years ago or whatever. But now the reason people use it, I think is more that, well, they already have their data there, their email address there, not quite lock in, but maybe more there’s a gravity to that data. And in fact, as a result, when you look to the way that companies structure their business models and things like that, they’re really oriented around how do we get people’s data and hang on to it, and that creates a kind of stickiness in the product and I think Speaking with you, you almost have an opposite view of this and in fact you just released a feature called Kraft Connect, which is more about giving people options about where they store their data, I think because it seems you want to be competing on the quality of your interface rather than owning the user’s data. Is that a fair way to describe your position? 00:16:39 - Speaker 1: It is a fair way, but I look at this at a much less strategic way, right? So, I might not be a strategic mastermind, but the way I think about this is I mean, our software’s goal is to help people, and believing that people only use our product, I think is extremely arrogant, and it’s untrue. Because we are all part of a workflow, especially in today’s world where there are just so many SA tools. I mean, you have data analytics, you have emails, you have GitHub, you have Slack, all of your data scattered across everywhere. And the reality is, if you want to think, if you wanna work, you wanna work with all of this data. And you know, we hope craft becomes part of that workflow. But we by no means want to be your single point of workflow because we will never be able to cover all of that innovation and all of those features that others do so well. So our motivation is purity of We want to acknowledge that we are not the only one in your workflow, and we want to help you be productive with your workflow. And this consists, I think, many things, but one of the things we want to do is to all similar apps which provide markdown input or APIs, we want to tailor our export, so people can move across. Because some people might say Ulyses is a competing product, but the way I look at it is Ulysus is an amazing markdown editor, and so many people love it. And if you just look from the export capabilities, it has very different export capabilities than Kraft does. So why shouldn’t you be able to move your data across without friction? So really for us, that is the motivation on this of we don’t see software as an end state of your data. We look at data as it being part of your workflow, and you use one specific tool to modify that specific data or to create that data, and then you move to another one. And the more frictionless we can make it, the more value we provide to users. So at the end of the day, I think it is very much related to what you said in a way of providing a better interface and that’s why they choose us for specific tasks, but it’s from a plain simple way. I cannot just live in craft. I mean, I love the product, I build the product, I use it a lot, but I use a lot of other tools, and I appreciate if I can really easily move my data between those tools. And I, this was a lot how it used to be in the file system where products wrote out files on your disk or even before in the Linux and Unix systems where every product produced text output and could input text input. And that has very strong attributes of how you can then own your data or use your data in creative ways. And I think data should be used in creative ways. It should be yours, and you should be able to hack it, play with it, tweak it to what you like to do versus us trying to use it as you said, as a moat or as an aspect of why you shouldn’t leave our service and keep paying us. 00:19:54 - Speaker 3: Yeah, this IO thing is really important and it’s something that we would definitely agree with. Adam had this observation when we were in the lab and then starting to use. It’s very common for product developers to look at personal information workflows and see, oh, there’s all these apps and all this data is scattered all over the place. It would be great if it was all in one place. Which is true as far as it goes, but it never happens. And in fact, if you try to make the everything box, which many people have tried to do, just make the problem worse, because then you have one more thing that has some but not all of your data inevitably. So I really like this idea of embracing good IO that is import outport, maybe they call it import export to get data in and out of the app. 00:20:29 - Speaker 1: And doing that is extremely hard because most of us have very limited resources, right? We’re a small team, we’re a small team. And you have to figure out if you’re gonna work on making it easier for the users to export, which by the way, today is not a really a requirement or you’re gonna work on all the features, I guess you also get from users, I will buy your product if you support this. You know, I will do this if you have that. You don’t have this feature, so I will not use you. And I think that’s a very challenging aspect of it. Typically, you don’t need these export or these IO tools that much, but when you need it, you really need it. So it’s not really a selling point, and I think it will become more important as people get more conscious about this and there are more examples that people can use. But because of that, it’s extremely challenging to schedule in terms of work and development and resource allocation, because first of all, you need to do a lot in order to be able to claim that you have a good import export. And second, it’s not gonna in the short term directly influence your revenues or your growth rate or anything like that, because it’s not a viral feature. At the same time, that’s why I believe, you know, fundamental values are important, because that’s the only way you can make time for these type of features. 00:21:43 - Speaker 2: Um, yeah, definitely speaking our language there. Well, I think in terms of why I was attracted to the product initially, and I liked the iPad first interface and the powerful gestures and things like image support is first class, which it isn’t in a lot of these more marked down oriented editors. But the thing that I think actually did sell. was your support for the text bundle format, which I hadn’t previously come across, but it’s essentially just like a zip file with a markdown and then a bunch of assets. So markdown’s great in terms of being pretty universal, but bringing your images across is often kind of ad hoc, doesn’t work that well, very manual. Mark and I talk a lot on this podcast about sort of the multimedia world we live in now. It’s not really just text or just images or just video, you want all those things together. So for me, if I write an article that’s interspersed with these figures, images and video, of course, that’s part of the article. And so I was pleased to both see your support for this, but then I was able to write a little Ruby script that essentially parses the text bundle format and then outputs HTML which is ultimately, of course, where I published to. You know, you could have made your own proprietary format, but this is actually something that makes it easy to move back and forth between things like Ulysses and many other writing and kind of markdown oriented editors, both on iOS and otherwise. So, I would argue you got one sale from sticking to your principles there. 00:23:07 - Speaker 1: Yeah, but you did use it before, right? So you did have a feeling that it could be nice if And it’s really interesting because I did not know about text one as I mentioned, I’m not a big fan of the markdown world from a user perspective. I, I’m a big admirer of what it enables, but I myself, I do not use markdown. And it’s been actually users who’ve been, you know, pushing us this direction. So I, I very much remember there has been a number of users pointing us towards text bundle until we finally understood it and finally said, yeah, well, we should actually do it because if it helps users, it will be good. And that’s my belief that in especially in long term, these principles, they pay back at an extreme level. At the same time in today’s startup world, where you want to create these minimum valuable products and you want to go fast and you wanna focus on growth the next month and the next week, they are often hard to validate or really just, you know, reason why you should be doing this. For instance, in our case, tables, I mean, Every day we get 50 to 100 requests on where are our tables, and we’re still fussing with export import improvements instead of building tables. Because I feel tables we can add later on on the foundation, but if we screw up export import, we add tables in a way where we don’t understand how we should implement for it to be able to support both mark down, both CSV formats. We are never gonna be able to retrospectively fit that in a functional or in a productive way. 00:24:41 - Speaker 2: Mark, your mention of the everything box earlier reminded me a little bit also of this is a differentiating point between professional tools or serious tools. I don’t call that exactly, but the category of the muse and craft both fall into versus what I would call consumer apps, and I think in the consumer world you do want that all in one easy to use. I don’t need to integrate anything. I don’t need to have any ownership over any data, whereas the more you go to professional creative flow. The more you want a mix and match of sometimes the industry jargon is best of breed, that is basically the idea that you can get a bunch of different tools and you have a flow, a workflow, exactly as you were describing earlier B where your work goes through this series of points in the authoring process. So I think of something like photography as being a good example where on the consumer side you want Instagram, your phone has a camera in it, you’ve got an all in one app, it takes the photo, it applies the filter. It maybe does a couple of other things and it actually posts it on a social network and that’s what you want. It’s nice and easy. You don’t need to, uh, you know, you don’t need to put any pieces together. But professional photographers, of course, they want their DSLR camera, they’ve got a bunch of different lenses they’re choosing between, they capture photos in raw formats, they take that into some kind of processing tool, you know, lightroom or something like that, do some things on it, maybe shift from there to and then maybe your public. The format is going to be a different place, so there’s this progression of their work through these different tools and while it’s not inconceivable to build a single everything tool that did everything a professional photographer wants to do, that would be a lot for one company to do and then especially as the world changes, yeah, just being able to mix and match the pieces is extremely valuable and so most professional tools and professional workflows do have some kind of standardized formats or ways to interoperate data. 00:26:33 - Speaker 1: So I’m not sure I agree with professional versus non-professional separation. I think both with Muse and with craft, what I like about these tools is, you know, I can give my wife these tools. I mean, sure, she needs to learn some gestures, which might take 2 minutes to fully understand, but she’s a non-technical person, a very non-technical person. She’s an HR and she can perfectly use these tools. And then I assume you have a lot of very, very deep thinkers who gain exponential value of your tools, just as with craft a lot of people create backlinking and knowledge bases which are extreme in some cases. And I think that is an attribute of a really good tool. I usually say Microsoft Excel is my role model in this case, where, you know, people use Microsoft Excel instead of a calculator or just basic personal finance, yet data scientists can use it. So I think there’s this belief that great software and there’s this understanding of how professional software looks, right? And it should be ugly, it should be, you know, like a terminal. 00:27:38 - Speaker 2: A little bit intimidating, maybe. 00:27:40 - Speaker 1: Yeah, because it’s like a terminal it should be able to do data import export. And I mean, you guys have been, you know, working a lot on really professional back and focus, you know, services and software. But I think we should just end this of, you know, saying serious software should be complex and unapproachable, and that’s why it’s a workflow. So this is very interesting for me of how We can build, I believe, software that works from the start for very simple use cases, but grows with you in a specific domain. 00:28:14 - Speaker 3: Yeah, yeah, I think, I think there’s something to that. I think there’s a way to sort of reconcile these two perspectives where there’s a spectrum of ambition or complexity or sophistication of what you’re trying to do, which tends to correlate with whether you’re a professional user or not, but it’s not 1 to 1 correlation, right? And we want to have software that has a low floor, it’s easy to get into, it has a high ceiling. To my mind, I would agree that Excel is probably the best example of this. You can get started really easily, but then people can build almost everything in Excel. But I think there’s also this like product design humility piece where as the users. Goal gets more sophisticated, the probability that any single piece of software will accomplish that goal approaches 0 as a robust empirical observation. And so you need to have the humility as a product designer to facilitate the IO to facilitate the workflow somehow as you’re dealing with these more sophisticated workflows. 00:29:04 - Speaker 2: Absolutely. You also mentioned Unix, which is certainly one of our go to’s for, first of all, just a software system that has a good founding set of principles, but also in this case specifically, the everything is the file, small sharp tools, text inputs and outputs that flow together and essentially it’s the whole design of the system is that things be composable and you don’t make the everything Unix command, you make a command that does one simple useful thing. And then you pass the data forward to the next thing as well. But I would argue that I think the app’s world, we are swimming upstream. We’ve run into this a lot with Muse, as well as other small iOS products I’ve worked on where really it’s built around this app model where the data is very much locked up in the app, it’s not even introspectable by the users without a great amount of effort, and there are some standard ways to pass data, for example, the share sheet, but often there that can be Confusing, it’s a kind of a narrow aperture. It’s hard to do all the things you want to do by comparison to the file system model, and I think there’s a huge number of benefits to that model. It makes computing much more accessible and understandable to many people and certainly the mobility. Of this hardware and that sort of stuff is great, but then trying to live in a data interoperability, you own your data world and play along with the best practices, let’s call it, or platform conventions of iOS there’s some pretty serious friction there, I would say. 00:30:34 - Speaker 3: Yeah, I think there’s something very interesting going on with a data layer here, and it’s worth double clicking on what’s happening. So back in the classic Unix world, you have typically text files and text applications, and there are many nice properties of that. For example, you have separation of the data storage layer completely from the application layer. You have this property that everything is a self-contained single stream of bytes. You have this property that you can just cat the file and you can read it and You have the property that’s easy to share. There are all these nice things you get, but it starts to break down when you add the features that we’ve come to expect from modern apps. So, for example, if you want enrich multimedia, OK, then you probably need like a directory pointing to some assets and maybe you zip it up. You can kind of do that, but it’s getting a little bit sketchy. But then if you want real time collaboration and backup and sync, the classic flat file model starts to really struggle. I’m not saying it’s totally impossible, but I think application developers have typically found it easier to just basically completely abandon that and go to something that’s more native to the real-time collaboration model. But my hope is that we can kind of go back and get some of those. Benefits of the old world. And one of the things that I’m really interested in with Kraft is they’ve tried to separate the sort of storage from the application layer, so you can use more standard storage approaches and still get at least some of the benefits that we’ve come to expect from modern apps. And I think that’s an interesting avenue because it gives users some flexibility and some agency in terms of how they store and back up their data. 00:32:00 - Speaker 1: Yeah, and that is something we’re trying to get right, but it is extremely hard because even supporting the evolution of one data structure, right, is challenging. And now with every change we make, we constantly have to look at, you know, all the additional types of data structures we want to support. So right now, one of our biggest challenges is How do we extend markdown in order for it to be able to support hierarchic? Because in craft you can have notes within notes or pages within pages, and in markdown that’s not possible. And how do we do that when, you know, mark downs core premises that it’s very easy to read and write. So there are some trivial ways you could add syntax of HTML syntax and, you know, annotations which could, you know, make this compatible at the same time would break the core principle or the core value of having a markdown, which you can just open up and you cannot really screw up. So that’s a really good thing about Park. There’s no such thing as invalid syntax or, you know, it’s gonna not render. So I think all of these challenges are actually super exciting because It’s really an interesting avenue where we’re trying to in some ways reinvent the wheel, but at the same time, we’re trying to reinvent it in a way where we bring it closer to where you said how we could use this to then support the modern requirements of modern software, and it’s a quite fun research project actually. 00:33:28 - Speaker 2: A similar thing we run into with Muse bundle exports, which you get a muse file, but it’s just a zip archive that you can open up and we, as much as possible try to use flat standard formats inside there’s a PDF. All the annotations you put on it are stored in standard format. Text cards or .txt files, images are images. Recently, I think we switched over to using SVG for the ink, so that’s kind of retrievable and even editable if you want. Uh, but yeah, exactly to your point, there is metadata that is part of what makes Muse unique, which are these nested boards that there just isn’t a multimedia board format standard. Maybe there should be, I don’t know, maybe the Melanotes and miros and muses of the world should get together and make standard format, but in the meantime, yeah, if you’re innovating on the interface, almost by definition it means there’s things that will be harder andossible to represent in standard formats. So you want to stick to that, but at the same time you don’t want it to hold back your ability to make what you think will be a great interface for your users. 00:34:30 - Speaker 1: Yeah, it’s a very strong trade-off. So you don’t want to move forward, but you just wanna move forward enough so you don’t create incompatible issues in the long term. So for a long time, we did not care a lot about will we break or will we lose features if we export to markdown. But especially with newer projects like, you know, toggle lists or tables where losing data could mean losing. Meaning or reducing the value of the document. It is extremely challenging because we’re now, our main part of our research is actually what features can we add without breaking any export and ensuring that your data will be transferable, because I don’t like severely degraded exports. Because in some ways, then that means you are still locked in, despite of the best intentions of the product. And it’s very interesting of how our designers are now looking at data structures, which typically only engineers because for us, it did become a part of the design project of what data structures there are there which we could reasonably well support and cooperate with. 00:35:45 - Speaker 2: Maybe you could tell us about the storage aspect. So I think you can use iCloud or Dropbox. This ties very nicely to a lot of the work Mark and I and other folks in ink and Switch have done around this kind of local first and data ownership and that sort of thing, and it seems you’ve tried to set it up so that people can store their documents in a way that means they can access them without running the craft apps, so that is to say the data is a little bit independent. Of the software. Can you tell us a little bit about how that works? 00:36:17 - Speaker 1: Yeah, so, I think the Incan switch offline first piece was very influential for me because I was looking for what they call this approach, and that was it, when I read it. And for us offline first really meant that you can always access and edit your data. But we wanted to make a really fluid experience when you use it on multi device, so we ended up implementing our own sync protocol to ensure speed and conflict resolution and collaboration and so on. But of course, this means you have to trust us in order to use craft, and that shouldn’t be required. I mean, you don’t know much about us and really data ownership and who you trust should be your decision, and we shouldn’t be forcing on. So for a long time now, we’ve been thinking of how could we do this where you could use craft, but you do not need to trust us to do that. And obviously local option and iCloud storage is the simplest way to go. At the same time, if you are a product which uses local storage, you are expected to satisfy certain number of checkboxes, which is reasonable. You cannot do much with your data if you cannot access it. So adding it in, for instance, a database might be OK-ish, but it’s very far from the intention of what actually people want when they say local software. And for now, what we could come up with is Essentially craft stores text as a database inside of our product. And what we did is we separated documents each with their metadata in a JSON format, which is hard to read by humans. It’s easy to read by engineers, but engineers can easily access it and you can also open it up with just a text editor and extract content if you later want. Now, over time, we want this to become Mark down this JO because that would be true power that, you know, hey, I don’t want to open craft today. I can just open this file with Vizil studio code or whatever I wanna do and add a few notes inside of that. So over time, I think our goal is for you not to require to use craft, even if you want to participate or only use raft on your phone because that’s where you want to use it and on your desktop, do something else. It’s really about embedding, as we said at the start, in your workflow, and your workflow includes your preferences, and really having that in the long term of you accessing your data very easily. Us being able to inside of the app store this as a database, meaning we can do very fast searching, very fast indexing, creating relations between them, seems like a solution, which could be best of both worlds, and I think we are relatively new to try this in this domain because most companies strictly polarize in one direction. They either say, hey, we are, you know, a primarily offline first app, which we we might do. So iClouding but collaboration and sharing and web sharing are very much out of the question, or they say, hey, we’re absolutely online only, and in order to use us, you have to trust us. And I understand the technical reasons of why it’s really hard to do both, and we don’t even have the same product doing both. So we have this thing called offline spaces or external locations, so you cannot mix online data with offline data, which point to each other. So it’s not a seamless experience, but our goal really was to give the users the choice of what they want to do. I mean, if you’re starting to blog post, you, you might want to have it in an online space because you want to have feedback on it in collaboration. But if you’re storing credit card information, I mean, I, I don’t want you to put that inside of our database, and you definitely do not want to do that. And then you can use whatever file system and whatever security your computer already provides to protect that data. And I think we tend to look at consumers from a product design perspective of We have to make a choice for them because they cannot, and I think a lot of people accept choices provided to them, but I also think there’s a huge step up in terms of education of, I mean, apps used to be these $1 things which you bought for $1 and then you used it for 10 years. It wasn’t serious. Now apps with subscriptions, these are serious and people want to have more control over how their data is handled, or they actually want to make the choice of how their data is handled, and they can understand the consequences and make the right choice, I think. 00:41:03 - Speaker 2: Um, when I think about the privacy piece of this, which Mark and I have a whole podcast on, but I suspect we’ll be talking about more in the future. For me, I think, for example, writing what will be a draft of a blog post, it’s intended for public consumption. I am going to share it for feedback on the web or whatever pretty soon, and so it feels basically pretty reasonable for me to type that into an online place. There’s obviously things that are more like, yeah, medical data, credit card stuff and there you have very tight restrictions on what you can do, but a middle ground to me is things that are more like you talked about thoughts and the degree to which your note taking tools or your writing tools are certainly used, which is entirely intended to be a tool for thought. That is a very kind of personal intimate. private thing and it doesn’t have this like strict legal restriction of credit card numbers, but it’s also not a blog post where it’s eventually or even just very soon going to be public. So it’s middle ground and and maybe that’s a place where that choice is relevant to a potential user. Now the business model side of it, that opens a whole other topic, and this comes up a lot on the, you can switch communities and just talking about local first software and what’s possible if you remove this data ownership as kind of a source of sort of the monetization piece for many companies, then what does that leave you at? And I think that does come back to kind of the topic here, which is if you’re building a piece of software that you want to be a great tool, it’s great at Again, this interface that offers you and manipulating the data rather than the company owning that data, and you’re willing to pay for that again, not $1 but like you know Kraft is $45 US per year, uses over double that. This is a good chunk of change for anyone. These are serious tools. We’re asking you to pay for the tool itself and what it lets you do rather than that we’ve accumulated a database that you’re paying for access to over time. So how do you feel this will work, you know, a lot of people have asked the question of us and maybe you get this as well, you know, will people pay a price like this for something that’s more about the software rather than the database that you’re running for them? And what do you think for maybe the industry in general, what’s the viability for business models for local first or just interface focused software? 00:43:26 - Speaker 1: So I think we’re in swings, right? You know, back in the days, like 1015 years ago, we did pay for software and software only and not for data storage and people used to buy hard drives at home and, you know, had their backups of backups and did that. And then we realized that, hey, you know, I don’t need to buy those hard drives. I can just use this all night stuff and internet speed is fast enough. So I’m just gonna do that. And now people are much more comfortable paying for services, data storage in all other areas. But I do feel a strong swing going backwards of after a couple of years, you know, first of all, people realize nothing is for free. So I think Google Photos recently has been a big announcement in terms of it’s no longer free, even Google cannot pay it, so people are starting to realize if you don’t pay your product. And when you start to pay, Actually, I think you start to have a more complex evaluation system, right? I think Muse is gonna have some level of online storage, so I don’t need to take care for surnames. If I just want them to sync and be everywhere, you will be able to craft has this. So I think we’re gonna have to Just as the iPad, right, is a blend between the iPhone and the Mac, and it’s going in one or another direction. So modern products should provide you with capabilities of what you expect from modern products, which could be data storage, which could be sharing and collaboration, and I think consumers do need that. At the same time, I think these features are becoming now almost trivial in a sense, like in 5 years, a new product won’t exist without these. And because of that, I think a much bigger Decision factor will be the interface and the user experience of the product. Because 10 years ago, real-time collaboration was something magical. Right now, not having it is almost like, you know, a point of I will not use this software. So that’s the way I think and I think in the long term, the user interface, the functionality you provide is going to be a stronger differentiator factor. And products are going to compete much more on this angle, because free data storage cannot be free forever. 00:45:45 - Speaker 2: Yeah, for some reason it seems easy for people to understand or intuitive maybe that oh if you need to run servers and do some kind of data storage that has a cost and so therefore paying that cost, you know, when I pay for a subscription for Dropbox, for example, well, they’re storing data for me and so therefore it makes sense that that costs money and costs money on a recurring basis, whereas a software interface, which maybe they see as a one and done, you write the soft. and you put it out and you don’t need to think about it anymore. And so therefore it should be a fixed price or it should be a lower price or something like that. And my experience is the reverse of that, as you said, storage is becoming more and more commodity. I mean, running servers and keeping them online and having people carry pagers and that sort of thing for when stuff happens is definitely a cost, a substantial operational cost. But building great software, truly great software, especially if you’re pushing the frontiers, whether And data interoperability, the interface, or anything else, that is a very big ongoing cost. And so in order to make that sustainable, folks need to be willing to pay. I agree we are starting to see that difference, but we’re coming out of a long period of the expectation that sort of software is free or the marginal cost is such that you shouldn’t pay or you pay in other ways, and the monetization is around, for example, data storage. 00:47:06 - Speaker 1: Yeah, and also I think we do have a backslash as app engineers of, you know, a lot of users did experience in paying subscriptions for, you know, non-online software just to not get real value in return of that, you know, product being abandoned. And I think because back in the days when you bought a hefty license, but every 34 years, there had to be a significant update for you willing to buy something new. And I think that’s another challenge at least I see us facing as people, as you said, understand the data aspect and the server cost of that, but they also say, you know, I’ve seen so many subscriptions where for, you know, 12 months, there hasn’t been a single update. Why should I be paying the subscription for that? And in some ways, that’s also true. And because Apple pushing so strongly towards the subscription model, I believe a lot of software which frankly, Does not use subscriptions as they should in order to fund software development. It’s also, you know, having, I think a negative impact on reputation of why software should be on a subscription base. 00:48:16 - Speaker 2: Yeah, that’s a great point. Actually be really interesting. So the first Muse customers came online sort of last summer, so this summer we’ll see the first sort of renewals come up. And of course, naturally you always have churn people who for whatever reason are no longer getting value from the product and and they choose not to continue paying, but that’s a great opportunity to find out who are the people for whom they paid a year ago. They say this is great, I want to continue. I feel like I’ve been exactly as you said, getting continual value, not just what the software does today, but the improvements that are happening. And I think we’ve also seen that in a lot of folks, you know, sort of the free version, they come online, they try it, they like it, but think is this really going to be worth this price and especially continuously and then they can watch and see the ways that we’re improving things and developing things and maybe after some months, they say, yeah, I like this, I like the direction this is going, and I’d like to support it. But I totally agree, you’ve got to earn that. It’s building ongoing value and doing that in a way that’s not just features for features sake. The old world of new version of Microsoft Office to get everyone to upgrade, but actually because you think that there is a very rich space for a great tool in where you are working and you can continue to understand what people are using it for and how it can be made better. 00:49:32 - Speaker 3: Yeah, totally. I also think there’s an angle here of a subscription potentially buying support, community, a sense of belonging, even just a sense of being in the professional tier, the sense of, since I pay $10 a month, if I email this team, even though I’ve never done that so far, if I email this team, we’re likely to respond. That’s another area where I feel like some apps are charging subscriptions even though they don’t really provide that. Whereas something at Mu we really pride ourselves on is definitely if you’re a customer and you email us, we’ll reply basically right away. 00:50:00 - Speaker 1: Yeah, there is the other area of expectation. Most users do expect you to answer them even if they are not subscribers, and if they say, you know, they will never subscribe because it’s too expensive for them, but they have this question and are super upset if you don’t provide support, so. I think we’re in the global world and all of these are extremely interesting to see how they will. Yeah. 00:50:22 - Speaker 3: This does remind me of the old Patrick McKenzie, this is Patio 11 on the internet, quip that like there’s kind of inverse relationship between support demand and the price you charge. So as you charge more, you actually get more and more agreeable customers and inversely, if you have a free product you get a bunch of bad support requests. 00:50:39 - Speaker 2: Well, the business model also makes me think of what Mark and I were just talking about in our last episode, which is this small giants concept, or at least the way we interpret it for our company, which is a middle path between kind of the go super big heavy funding startup. Unicorn world or the indie developer build something with one or two people. I think Kraft is kind of in this category. It’s called aspiring small giant or middle path. I’d love to hear a little bit about your team and how you see that kind of like long term sustainability for the business steady state. 00:51:13 - Speaker 1: Yes, so it’s a very interesting question because some people jump on this question of asking, is VC money good or bad, and obviously it’s a lot more complex than that. So our goal is really to be able to provide value to a relatively large number of users through keeping the principles we have. And the great thing about our world is, especially technology in the last two years has become such a huge market in the sense of, even if you’re just 0.1% or 0.01% of the market, you can make a sizable living. So I think last time I checked, Office 365 had like 40 to $50 billion of revenue, I mean 1% of 1% is still 4 or $5 million which is a very healthy, you know, small company paycheck. So I think there’s space and the good thing is that niches are powerful now because niches are big enough. So if you only solve a smaller problem but you solve that really well, you have a shot at that. Of course, it’s going to be interesting of how many products people will be willing to pay for, and will be seeing now an unbundling of, you know, specific niches and then another bundling where people come together. But from my perspective, I really feel that the core reason we started Kraft was we wanted to build a tool we are happy to use, and for us, I think that’s going to continue for the long term. As we’re getting more feedback, we are getting more confident of what we could achieve. And my previous company was Bootstrap, and it does hold you back. So we are, you know, considering potentially raising from VCs and, you know, going down the path of facilitating growth. So, I think it’s really about can we keep our identity, can we keep to our principles, and do we find partners who agree with these principles. And believe that Google had this mantra of don’t be evil, and it worked well at then. Nowadays we don’t see it much, but I think there’s gonna be a big renaissance in this of people rediscovering that don’t be evil, can be honest, you know, help the user instead of thinking in motes can become a very powerful business strategy. 00:53:33 - Speaker 2: It’s a nice combination, having principles and a strong point of view, being able and willing to serve a niche, which, as you said, because the, the software world of software and internet is so big, a niche can actually be a very viable business. Thinking in terms of sustainability, connecting together your business model versus the kind of hand wave of like, I don’t know, we’ll figure out the money later, let’s just grow and get users thing that maybe plagued some technology companies in the past. And then the last one I would say there is in thinking about taking investment, whether it’s venture investment or angels or some other thing, I think it’s also just thinking about the resources you need for the opportunity at hand. Sounds like that’s exactly the thinking you’re doing, which is, you know, if you’re just two people with an idea, maybe that’s not the right time to raise $5 million in venture money, even though it’s kind of possible to do if you have the right pitch deck because there’s so much investment money available there, that may put you down the path of hiring a big team. You’ve even really figured out what your product is, and then that creates all kinds of unbalances, whereas if you’ve kept yourself lean with a smallish team, and you’ve discovered that there’s a real market opportunity, and you see we can add fuel on this fire with investment and go a little bigger, but also stay true to our principles. The point of going bigger is to do more interesting things and have a bigger impact in the world in a way that matters to why we’re doing this business in the first place, not just to be as big as possible just because. Absolutely. Well, I think that’s a great place to wrap it. Thanks everyone for listening. If you have feedback, write us on Twitter at MuseAppHQ or via email below at museapp.com. You can help us out by leaving a review on Apple Podcasts, and Ballant, thanks so much for making a tool that I rely on for my writing as well as inspiring us all for making an interface driven software company and one that is driven by principles and just wants to make the world a better place with great software. 00:55:30 - Speaker 1: Thank you for having me.
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: What I think happened was that you got people who knew how to bend and to mold computers and software in the same place as people who were very efficient and effective and curious and playful around things like design and getting things done, and had real needs, right? And sort of that’s some biases there, I think is what drove Mac OS to become such a successful platform. 00:00:29 - Speaker 2: Hello and welcome to Meta Muse. Use as a tool for thought on iPad. This podcast isn’t about Muse product, it’s about Muse’s company and the small team behind it. I’m Adam Wiggins here with Mark McGranaghan. Hey, Adam. And joined today by Rasmus Anderson. 00:00:45 - Speaker 1: Hello, hello. 00:00:48 - Speaker 2: And Rasmus, I understand you’re an amateur gardener. 00:00:51 - Speaker 1: Yeah, that wouldn’t be very far from a lie. I do have a little front yard, tiny tiny one, and a tiny backyard, and it is a constant fight with nature, but, you know, it’s kind of fun. 00:01:07 - Speaker 2: And I always find it funny, weeds are not particularly a thing that there’s no like clear definition other than just a plant that you don’t want to be growing there. So one man’s weed is another person’s desired plant, is that about right? 00:01:22 - Speaker 1: I think that’s right, yeah. I mean, I grew up in Sweden and I remember my parents playing this like really smart game on me and my brother, where we would have these, they’re called mscruso, which are kind of pretty, but they’re definitely weed. There’s these beautiful kind of yellow flowers, and they can break through asphalt. They’re like really strong growers. You know, and as a kid, you know, parents would be like, hey, let’s do like an adventure thing, and like you find all these in the yard, and like for each of them, we line them up and count them and we would just like, Wow, this is cool. And we would go and pick them and light them up. And our parents would be like, you know, behind the corner, that would be like, we totally fooled them. So yeah, they' weeding as a kid without really knowing that I was doing that. 00:02:07 - Speaker 2: Nice one. We lived on a farm just for a little while, while my dad was stationed at a naval station that was kind of in the boonies, you might say, and my mom was a pretty serious gardener growing her own vegetables and fruits, and we had fruit trees and stuff like that. But I certainly remember that some things, the tomato plants grew fast and easy. There was the watermelon plants that we got one summer with me and my brother just ate watermelon and spit the seeds into a nearby garden bed, and then there were some others that were endless frustration for my mom trying to coax out of the ground. So yeah, I think my strategy if I’m ever in the position of being a yard owner, will be to just identify all of the hardiest plants that grow, even if you don’t want them to, and just say these are what I’m specifically cultivating. 00:02:51 - Speaker 1: I like this strategy. This someone once said this. I’m sure that there are like children books and stuff written around this. I’m not sure, but someone said this and I thought it was kind of interesting that there’s a gardening approach to like steering a system, right? And there’s sort of like more of the plan and design approach to steering a system, meaning that if you have this sort of like organic type of system, like a garden, right? Or maybe software. It’s going to just keep changing, and the gardener’s approach is that by doing something like Adam, what you were saying, you kind of identify the things that you want to cultivate, and you give them a better opportunities. And then you look at things like weed or things that you want to move, and you sort of like give them worse opportunities, right? You sort of steer the system like that and see where it goes, whereas the I don’t know if there’s a better word for it, but the planning and the signing of the system from scratch, you’re like constantly trying to hope that it evolves in the direction you want to, which is, I think, never really the case, right? 00:03:52 - Speaker 2: Yeah, I think that is I use gardening as a metaphor often for those kinds of organic growth things for something like a community where you just can’t directly direct what’s going to happen, what you can do is encourage and nurture and create opportunities, as you said, for the kinds of things you want to see and and discourage the kinds of things you don’t want to see. But that’s part of the joy maybe is you don’t know exactly how it’s going to turn out. If you come at it from a kind of a builder, engineer, architect perspective that I’m gonna plan down to every last little detail in the blueprint, and then I’ll make reality match that exactly, you’re likely to be frustrated and disappointed. 00:04:33 - Speaker 1: Yeah, that’s right. I think this somehow we just kind of slipped into this, and that’s interesting in itself, but this is kind of what I’m trying to do with my project Playbit. See, we can get into it a little bit more in detail in a few minutes, but I think that there’s this opportunity to encourage, sort of like a different way of building software, not like radically different, but sort of like somewhere in between big scale and tiny tiny scale software, kind of like personal software. But anyhow, I think that a cultural change, right? Sort of like creating this garden where interesting like plants and stuff can grow to kind of spin off this metaphor. It’s a really interesting idea, and that’s sort of like the core of playbit. That is the idea around it. That’s what I’m trying to do with it, rather than to build on a specific type of technology. Now, software is like part of, you know, my strategy to make the change happen, or at least I hope I can. But the goal of play but this is sort of like cultural change or really like offering and, you know, a different or a slightly different at least culture to software building. 00:05:39 - Speaker 2: Culture is so important, certainly for programming communities, but more broadly just creation of any end artifact comes not just from the tools and the materials and the intentions of the creators, but also this ineffable thing we call culture. Yeah, well, I’m really excited to hear more about Playbit, which is a brand new project you’re working on, just for the listener’s sake. It would be great to briefly touch on your background. You’ve got a very impressive resume fresh off of working at FIMA. Before that you did Dropbox. You were early at Spotify, and just looking down that list, you know, I find myself thinking, well, if you were an investor, that would be pretty impressive, and I would assume you’re just sort of leaving the things out that were misses. But as someone that goes to work for companies, you don’t have the ability to do such a portfolio strategy. I’m wondering if you feel like you have a particular knack for spotting high potential companies early on, or is it more a spot of luck or some combination? 00:06:35 - Speaker 1: That’s a good question. I think it’s probably the latter. It’s a little bit of a combination. Really, it’s this kind of idea of intuition, right? You have a lot of experience. I do have quite a lot of experience at this point, and I think that has put up these neurons in such a way that I have some sense at least, at least within this particular kind of industry that I’m in. Someone was asking me this the other day actually, this little Twitter like texting back and forth, but I think that there’s a couple of things you can do that don’t require experience to build up intuition. And one thing is just to like really understand what you like to do, right? And so this is not specifically around, you know, successful technology companies, but I think it’s like a foundational sort of like a cornerstone. To being successful with like, really anything, is to understand like what you really want, right? Not what your parents told you that you should want, or not what like your peers tell you that you should want, but what you really want. No, no, that’s really hard, and maybe that’s the hardest thing in life actually to know what you really want. 00:07:37 - Speaker 2: I’ll echo that as well, which is for me, I had this experience of growing up with video games and that being my passion, and I was just convinced I would go into the game industry, and that was my path, and I actually did that and then I was miserable and I didn’t like it and I what on paper you might say, or hypothetically, I thought I wanted to do in practice didn’t actually work for me. And then when I had an opportunity to join a company. Making basically from my perspective, pretty boring business software. I jumped into that and discovered I loved it and I was much better at a thing that I loved to do or fit with my natural passion somehow. So I think it’s also a maybe coming back to our gardening metaphor, a bit of a discovery and looking for opportunities and noticing what’s growing, what’s sprouting really naturally, and then encouraging. that rather than having some preconceived notion of what you think you should do, which might come from parents, certainly could come from, you know, the tech industry, which lionizes certain kinds of companies or certain kinds of people and instead kind of paying attention to your own internal compass for this is a thing that I could really see myself spending every minute thinking about for the next 5 years, 10 years, or career. 00:08:47 - Speaker 1: That’s just so interesting to hear you say that, but you had that experience, which I think a lot of us have, right? If we had this idea, maybe we want to be a chef or an astronaut, or, you know, a fire person or whatever when we’re kids, right? And like most of us end up not doing that, right? We end up doing something else. And I think that happens a few times in life where, like you, you know, We see this thing, it’s like very exciting, we pursue it, and then we stumble upon something else, and that just, you know, we stumble upon probably 100 different things, right? But one of those things where like, whoa, damn, this is really fun, and this is really interesting. Yeah, so getting back to your question a few minutes ago, I think that if you have that sort of like cornerstone idea of the learning about myself, it’s just something that I should always work on. Then on top of that, I think what you can do is To try to learn about the people that are working at various different companies or like looking for passion in people, like finding out what incentives are driving them to make a change. And with a change, I mean like a technology startup, right, usually exists for one of two reasons, and the first reason is that people want to make a change or want to see a change in the world, right? It can be a very small scale, a very big scale. And the second thing, I think that often you have these ulterior motives, you have power, fortune, you know, impressing other people, like all those things. There’s nothing bad about those things, right? But they are usually then hidden away that there’s this facade of like, no, we’re really trying to make a machine here with this YouTube for cats or whatever. And really like someone just wanted to like build a really cool thing so they can sell it and get rich, right? And again, there’s no judgment here if that’s your thing, that’s cool, but that’s not what I’m interested in. So that’s one of the things that I tried to see and figure out and really spend time on understanding when speaking with a company or a few people who want to make a change, right? Like, are they driven by passion for this change? Like, can they see this world and like, you know, in 3 years, if we have this thing, and people are using it, like, this is how their lives are different. This is how they can like do things that they can’t do before. Like that’s the sort of thing. To me it’s like, kind of rare. It might be surprisingly rare, actually, which is kind of weird. And to find that out, I think the easiest way is just to spend a little bit of time with a lot of different people. So if you’re interviewing for a company, ask if you can spend a few hours with 1 or 2 people on the team, rather than, can I spend half an hour with like 10 different people. 00:11:20 - Speaker 2: Interesting. So it sounds like you’re, you know, come back to that investor kind of analogy I made before where going to work for a company, you’re investing your time rather than your money, which in many ways is even a more scarce and valuable resource. You think of it as less in terms of let me a value. I don’t know, the market opportunity here, whether I think this has the potential to be something good or big or what have you, and instead more is kind of looking into the souls of the people who are working on it to understand their motivation and their drive and their passion. 00:11:52 - Speaker 1: For sure, yeah. This is probably a cliche at this point, but If you have a group of good people that you’re working on, it’s not that important what you’re working on. Right, I think that’s a very extreme way of looking at it. I think in reality it’s not as clear cut as that. It’s not as true as that. But I do think that it does hold true to some extent, right, that if you flip it around, right, if you do some sort of kind of Greek philosophy approach then, you know, you say sort of like, what if everything is good, right? So you start out in like ideal scenario. So it’s every person is amazing on the team. The business is doing great. The mission is something that is so close to my heart, like, I’m just thinking about it day and night, right? And so on. And now you start like taking things away, right? You have this kind of little thing in front of you, and now you start thinking that, OK, let’s see if I take away the mission, right? And I have all the other things still, like, does this feel like something I want to do for 4 years, right? Not in day, right? It’s like, oh maybe, you know, you start taking things away, and I think If you start out in the ideal case, right, you play these different stories out, and you take away the group of people, right? So you replace that with like, people who you would consider, like, not being good, right? Like, maybe they had a bad influence on you, maybe they create a lot of stress for you, maybe they’re just not good at the craft and so on, whatever that means to you. I think for most people, like, it stops pretty early in terms of like, yeah, I would still do this. Like you would be like, well, you know. With making such a big change, and I’m really involved emotionally in this mission and everything, but like the people I work with are paying, it’s like, I don’t wanna do that, right? Life is so tiny, it’s so short, and you look back in the past and the things you remember, it’s not the bugs you squashed in code or like the pixels you made. It’s gonna be the people and like. The change that the company is trying to make and the group of people are trying to make, I think it is very important, right? And this is where it really loops back the first thing that I was talking about a few minutes ago about like learning about yourself and knowing yourself. I have a few friends who are very concerned about the environment of Earth and stuff like that, and choose to leave their traditional tech jobs to go work for, you know, uh renewable energy companies and stuff like that. And for them, you know, the mission is very important, right? And the people are very important. So, I think you want to really like look at all of these different things, like, a group of people who are amazing, who are very unsuccessful at doing what they do, is not gonna be a fun experience anyways, right? So yeah, I don’t think there’s a magic bullet, there’s no sort of golden arrow or whatever metaphor here, but I think one really good thing to look for is this sort of like passionate people, and what drives them to make that change. 00:14:39 - Speaker 2: Yeah, I’m a fan of that. Seeking opportunities in my own career and when I’m in the position of giving career advice to others, I usually say something like optimize for the people, find the team that you have that collaboration magic with, and that will be just far greater return than the exact perfect mission. Um, I do think, you know, those things related, probably because if you share values and you share passions around a particular mission, that’s likely to be a team that you work really well with. But yeah, given the choice between a thing that’s slightly off from what I might actually be my ideal, the perfect team, and the other way around, I always go for the team. 00:15:16 - Speaker 1: I’m curious here, Adam and Mark, how you’re looking at this as well. You’re both experienced in the software industry, yes I am, like, kind of flipping the question back to you. What are some of the things you might do or look for in order to understand if this, you know, company group of people are gonna be successful. It’s just gonna be like a fun ride for me, so to speak. 00:15:38 - Speaker 2: Yeah, I’d love to hear from Mark on that since he’s actually, now that I think of it, picked some pretty good ones, including for Muse, he was at Stripe. And so, yeah, I guess I never asked, did you see that as, oh, these guys are gonna be huge, I really want to be on board early. My stock will be worth a lot, or was it more, this is an interesting domain, and I want to work with these people who knows the company will be successful, or that wasn’t part of your calculation. 00:16:00 - Speaker 3: Yeah, it’s tough for me to give an answer to that, because to my mind, there’s a lot of, you know, it, when you see it, and to your point about having experience and neurons and pattern matching. I feel like I’ve been lucky enough to work in the industry for a while, so I now I’m able to have perhaps some judgment of that. I do think as a tactical matter, if people actually want to have a better chance of working at a high potential company in the classic sense, you can get a lot of information by asking people whose job it is to know these things. So, Investors and hiring managers will often have a lot of data about companies that will do well. And then it kind of becomes like investors will always say, oh, it’s, it’s actually not hard to pick the company, it’s hard to get the deals. I think there’s a similar dynamic with joining companies where often a big part of it is actually getting hired. But yeah, I think it’s a tactical matter, if you do ask around, you can get a lot of good data points. But I also have similar sentiment in terms of, at a more personal level, what I look for in a company, and I would also say it’s about the people and the mission. And I always go back to this idea of You know, we don’t have a whole lot of mortal life, and it would be a shame to spend the next 2 to 4 years of it working with people you didn’t care for. And when you say it like that, oh wow, you know, really should, uh, make sure that the people that you trust and look up to and want to become more alike, because as you spend 124 years with this team, you are going to basically become more like them. So is that something that you would be proud and excited to do, or that you would be afraid and ashamed of? 00:17:18 - Speaker 2: There’s a great patio. I think it’s even in an article writing about the culture at Stripe. He says, when you’re choosing your colleagues, these are people you’re essentially giving right access in your consciousness to. We don’t realize it, but just the people you’re around all the time, you become like them, whether you like it or not. So surround yourself with people you admire and you want to become more like, and that will come true. 00:17:42 - Speaker 1: Absolutely, I really like that. 00:17:44 - Speaker 3: This also might connect a little bit to our topic of playful software, because to my mind, one aspect of playfulness is sort of undertaking the process and the work for its own sake, without a lot of accountability to the end result and just kind of enjoying the process, you know, doing it for the memes, if you will. And I feel like you can only do that well if you actually really love what you’re working on and the discipline, but I’m curious to hear Rasmus, what your perspective on playful software is. 00:18:11 - Speaker 1: Well, I think for most people playful software, the first that comes to mind is probably games, right? And games, they’re sort of like almost the purest type of playful software. That is their primary and often only goal, right? To just be playful, to just entertain. And so I think playful software that is not games have some amount of that sort of like entertainment that, you know, a privy guest of yours that Jason was saying sort of like fidget ability, you know, the idea that There’s some quality to the software that makes you want to just like, kind of toy around and play around with the software itself, not to produce something necessarily, although that might be the main reason for the software to exist. So I think if we’re looking for a definition of playful software, it’s probably something in the realms of game like entertainment like qualities that are kind of intertwined with some sort of utility. 00:19:09 - Speaker 3: Yeah, this is really interesting, this nexus of entertainment versus playfulness versus utility. So I feel like actually there’s some relations certainly between entertainment and playfulness, but I feel like they’re also somewhat separable. Like you can have a game where it’s sort of a mindless game where you just plan to get really good at it, like a competitive game. And the flip side, you can have playfulness that is more just about exploring and seeing what you can do and what you can make and perhaps the stuff in the middle, like Minecraft is kind of in the middle there, it’s both entertaining and it’s playful, and I do think people tend to go towards games, but I think there’s another important element around what we’re calling playfulness that’s really important. 00:19:42 - Speaker 1: Yeah, that’s good points. 00:19:44 - Speaker 2: I’m suddenly reminded of a book by one of my favorite authors, Virginia Postrell. And in there is a chapter where it asks the question of what actually is the difference between work and play. And it’s one of those things where you go, oh well, it’s obvious, and then when you try to come up with a definition like, well, you get paid to work and you don’t get paid to play, and really quickly, especially if you’re someone that’s, you know, in the tech industry, a designer, a developer, whatever, you find yourself doing things that look very, very similar, maybe in your free time that you do at your work, but it’s hard to pin down really what the difference is and She ends up defining it exactly as you said there, Mark, which is play is something that’s open ended, you don’t have a specific goal in mind, you can start out with, I’m gonna paint the painting of the sunset, and by the time you get to the end, you’ve decided instead to fold the canvas into an origami. Swan and, you know, you could do that if you want, whereas work you have this specific end goal that you need to get to, often in a particular time frame, and even if you find some interesting detour along the way, you kind of have to ignore that because you have made this commitment to deliver some specific result. 00:20:54 - Speaker 1: And I’d say that as a designer, like playing is often a very important part of the understanding part of design, which I think is like a really big chunk of design work, right? You know, you have this opportunity or this kind of problem, like there’s something you’re pursuing, right, with your design project and Before you can make any decisions and any changes, right, in terms of like getting closer to solving it or changing it, you have to understand it, right? And so you take things apart, you put them back together, right? You’ll learn about things as you take things apart, you’ll find new parts so you didn’t see before, right? You’ll find new constraints of the project, you’re like, oh shoot, oh I guess this material is different, right? And so, I think, as you were saying, Adam, if you take a step back and you think about like, well, this kind of looks like play, doesn’t it? And I think in many ways it is straight up play. But it is sort of a semi open ended, closed ended play, right? It’s sort of like play for the purpose of learning. And I think this is where most of us in the tech industry, like, Can relate to playfulness in like the way we use software. So maybe on a weekend you’re like, oh, I’ve heard about this new like rust thing. Maybe I should like take the first bit, right? And you put together a whole world thing and you find a rust compiler and you write some code and you’re like, oh, what is, why can’t I borrow this thing, right, whatever. And the goal here, right, is play. You might not call it play, but unless your goal is to actually like get an output in the end or make a change or something like that, really what you’re doing, right, is learning. And I think that is often the reward, so to speak, the outcome. The product of play is to learn something. 00:22:35 - Speaker 3: Absolutely. I think it’s a great point. And just to reiterate, I think it’s really important to have this play access be separate from work versus entertainment. So that is, you can play in a domain that we typically think of as work, whether that’s design, engineering. Another example that I might throw in there is Elon Musk sending the roadster to space. It’s like, why are you doing that? I don’t know, it’d be fun, I guess. That’s also in a very serious domain where he is in fact learning a lot by undertaking that activity. 00:23:02 - Speaker 2: Also connects a bit to just our humanity, which is, of course, we’re trying to achieve things, be productive in the broad sense of the word, in our pursuits in our work life, but at the same time, we’re all people, we like stuff that’s fun, we like stuff that’s playful, and if you can find ways to do that, that fit in with the work and fit in with accomplishing your ends, I think it makes it more fun and engaging and enjoyable for everyone who’s involved. 00:23:31 - Speaker 1: Yeah, there’s something naturally even about play for sure. We can’t imagine our like ancestors running around naked in the woods with clubs, you know, kind of finding a pine cone or something on the ground or a stick and be like, oh, this kind of looks like a goat, you know, and you start playing with those things, and there’s something I think is very interesting, like when I was a kid, so I grew up in the countryside and Me and, you know, the other like 5 neighbors or whatever, and the kids, we would, you know, go into the woods and that’s how we would play, we, you know, build a little like imaginary little airplanes out of a pine cone and stick through it and stuff like that, right? And as a kid, you see a stick, and the stick is like anything. It can be anything you want, it can be an airplane, it can be a rocket, right? It can be a person, right? And as an adult we lose that, and I don’t know why, but I see a stick today and I’m like, oh, that’s a stick, right? And I’m like, damn it. You know, I wanna see the stick and I wanna feel like, whoa, this could be a weird sort of creature, you know, from a different planet that has like multiple heads, that kind of looks like a stick, but it’s not a stick. At some point I listened to someone who was trying to make a point of the educational system, at least in sort of like most of the world. Takes in one end of a machine, right? Imagine people walking in one end of the machine and they come out in the other end and like, in the end you walk in, there’s all these color and difference and, you know, different voices and stuff. And the other end is like this marching uniformed people, right? School kind of prints this pattern onto us, right? This is real, that is not real. This is play, that is not play, this is serious, right? And I’m not sure that’s like good for us, especially not for people in sort of the creative industry. Which I think is like a growing industry generally. 00:25:15 - Speaker 3: Yeah, I think that’s a great point. Another way to articulate this might be as we get older and as we go through institutional education, we tend to get annealed, that is kind of solidified, optimized, focused, structured, and play in addition to a way to learn, is a way to kind of foam roll your mind, you know, get some plasticity, break up some connective tissue so you can think of some new stuff. And so now that you make that point, I see that as a second key outcome. You know, you learn some stuff and you have some more flexibility in your head. 00:25:46 - Speaker 2: It also occurs to me that that means that play and imagination have a strong relationship and maybe this, as you said earlier, Erasmus, that like, when you talk about in design, play is very important. You might even say, this isn’t quite solved yet, let me play with it and try some stuff. And that’s connected to a little bit of an open-ended divergent thinking, imagination, out of the box, you know, looking at the stick and seeing the person of the rocket ship, and that actually is what could potentially lead you to the more practical breakthrough in doing your work. 00:26:17 - Speaker 1: It’s so true, so true, I think. If you think about cool stuff that people have made, right, like art or tools or anything, what have you, that you think it’s like, wow, this is brilliant, you know, this is so fun, or this is really smart, whatever. And you start digging into like the history of that in pretty much every single case, you’ll find that it’s a remix of other things, right? And so I think imagination and playfulness. is sort of like at least partially a practice of just exploring things, right? It’s maybe that’s a play part, right? You explore stuff, you see new things, right? And then here comes the imagination part, which is like, oh, out of all these different things, there’s like a new thing that can emerge, right? Like the iPod is a remix of this like brawn handheld radio, right? And then the iPhone is a remix of the iPod. You know, those things are very obviously remixes, because they’re, you know, visually very similar, but I think that there’s also conceptual remixes, and there’s like straight up like the word I’m using a remix, right, like from audio, there’s like, that is a very common practice. 00:27:24 - Speaker 3: This is also reminding me that there’s an important element of intellectual humility in play. So we said perhaps play is when you don’t have accountability for the end work product, but wait a second, we’re in creative fields, our entire purpose is to come up with novel ideas by definition. You don’t know how to get to that work product yet. If you did, you just go right there. So really it’s taking away some of your constraints and preconceptions about what it takes to create a novel work product and and exploring for a bit and saying, you know, press on the other side, it’ll be clear that what you were calling play was in fact work or fed into work, but you don’t know what that path is yet, so who are you to say what is or isn’t gonna have a good result eventually. 00:28:01 - Speaker 1: That is really interesting. So Mark, what level of constraints, or what level of sort of like boundaries do you think you need to define in order for that to not be like this totally open ended sort of quick detour of what I’m talking about is to make sure this makes sense. So like, I’ve seen this happening a couple of times in tech companies where you have a couple of interesting smart people who are playful, and the company recognizes that, and it recognizes the value and innovation and stuff, right? So they say, hey, you know, Lisa and Robin. Would you be interested in sitting in this corner just coming up with crazy shit, right? Maybe we’ll ship it. And I think in most cases that is like a failure, right? That will come up with all these incredible stuff, but there’s never any sort of traction around it. Maybe the constraints are way too vague, similarly to an art class, you know, if you ask someone to just paint anything they want, there’s just this paralysis, right, of like where they even start. So within that framework, like looping back to my question to you, Mark, what and how do you think about like setting up the right amount of constraints to be able to play around within there? 00:29:01 - Speaker 3: Yeah, that’s a great question. I I don’t think there’s an easy answer, but One strategy that I like a lot is to follow the energy. So if you’re undertaking this project, let’s say we’re going to relax the constraint about classically measured business output, but we’re gonna maintain the constraint around there needs to be some energy here, which could be, you’re able to get other people excited about it, you’re able to get customers excited about it, you’re able to create something that’s aesthetically interesting. That to me is an important Source of energy. And so we’re not gonna kind of constantly inorganically add energy to the system. We’re gonna give you a little bit of spark and some initial fuel, but then you need to build it up from there and kind of find your own path. But you’re free to not go directly to this end destination. It could be that you go through basically an art project, or a recruiting project or a publication project, and then you go from there. That helps a lot with kind of the mechanics of keeping the project going but again people are living their short moral lives and not gonna want to work on something that doesn’t have a lot of energy on it. So as you have more success, you tend to attract more people and it goes from there. 00:29:59 - Speaker 1: So energy that makes a lot of sense, kind of sense of urgency in different words, the sort of like things are happening. Do you think that Results or milestones, or even just celebrating like discrete moments of success or progress are important as well. 00:30:15 - Speaker 3: So this is a classic atomism back from the Hiroki days to make it real. We can link to the full list of atomisms. But it’s this idea of, even if it’s just a prototype or even a CLI session mockup, something that makes it real and makes it concrete for people, really helps people understand what it is and again build that energy. I also, I mentioned it briefly, but I think this idea of aesthetics is really important. There are good threads to pull when you have an idea that’s aesthetically exciting or appealing. That’s the way that I often draw energy on projects, even like programming type projects. 00:30:45 - Speaker 1: There’s this thing I’m thinking about now, which is And this varies in different parts of the world, but I think the same thing is sort of the financial thing is true. Like, you look at a particular industry, like hairdressers, right, or pizza joints, and you look at like the topography and the colors and sort of like styling they put on their storefronts. And there seems to be these sort of like pretty tight clusters of style, right? You’re like, why are all the pizza joints in this town using hobo for the typeface, right? It will be so much more interesting if like someone used copper Gothic, you know, or comic sense or any of the other sort of, you know, funky typefaces or something, you know, stern like Helvetica. And I think what’s going on is this recognition or this thing to like make it real, right? Imagine that we were starting a pizza joint, right? And we have ambition, right? We want this to be like the freaking best pizza in our town, right? So, you know, we look at other pizza places, and we have this intuition that we talked about before, right? Of what is like a real pizza place, right? We have our heroes, right? And chances are that they use hobo, right? We might not be aware of this, this might be unconscious. So we go to, you know, our local printing press who make a sign for us, and they show us, you know, a bunch of different typefaces, they have an option, and we see the hobo one and we’re like, oh, that just feels right, you know. So you go with that and you reinforce this idea at a real pizza place to use hobo for a typeface. And so I think this connects directly to what we’re talking about with a static being important and to make it real and a good atimus, which I’m gonna start saying now, by the way, so you’re all kind of wow, is that same thing, right? Let’s say you’re building like a MacOS app. And you have this idea for it. If you create a design, just a picture, that’s like a fake screenshot that looks real, I think that there is a similar quality to that pizza you want. People are gonna look at it and they’re gonna feel like, oh damn, this can be real, you know, we can make this happen. That looks like a real thing. I didn’t think of that, right? So yeah, I think aesthetics and presentation, and that mapping that to like your heroes and your ambitions, I think it’s super important for people to feel that this is possible, you know, and to drive the energy you were talking about, Mark. 00:32:58 - Speaker 3: This reminds me of another quick story here of kind of aesthetic and emotionally driven play session. A long time ago at Hiroku, we had an issue with the command line client being very slow, and I was very frustrated with it, and I wanted to have a faster client. So I undertook this playful project of just trying to make a very fast Hoku client that kind of only does Hello World, like it just lists your apps, but does it fast. And that ended up not really going anywhere, but by undertaking that project, I discovered Go, and then eventually will go by example, and now we use Go for some of our server stuff, and that’s a whole world that I never would have been introduced to if I hadn’t just kind of followed my nose up. It would be cool if even with relaxing the constraint that eventually needs to shift to production. 00:33:36 - Speaker 1: Wait, are you behind Gobi sample? Oh yeah, man, I love that. Oh, that’s funny. Oh, that’s brilliant. Yeah. Oh, that’s fantastic, yeah. 00:33:44 - Speaker 2: Yeah, we actually use this as a bit of, I think of it as the mark publishing style, which is static HTML, maybe a little bit of, I don’t know, did you even have some kind of like template or build script for the basic site, but otherwise it’s this very almost I call brutalist HTML but a very effective design in the sense that it has the side by side code and description, if I’m remembering correctly. And yeah, it’s this very kind of sleek, it loads fast because it’s a static site, it probably still works fine now with zero maintenance, and we were certainly inspired by that, both for the you can switch articles and later all the muse stuff. I’m just basically seeing the way that Mark does kind of HTML publishing of these essentially kind of a mini book on the web, was very influential for me and everything I’ve done subsequently. 00:34:35 - Speaker 1: Hm. In an interesting way, I think go by example is playful, right? It seems to be very uniform, right? And I think that uniformity creates this, rather than create, I think it removes some anxiety around navigation. A lot of the web, I think, has this problem of creating anxiety around like, The user interface because everything is different, right? It’s like you you jumping between different planets. Anyhow, I think what makes go by example playful is that I’m guessing here and I’m extrapolating mostly from my own experience with using it. Like, when you’re in the mode of using it or visiting it, you are exploring, right? Otherwise you probably wouldn’t be visiting it, or you are there for entertainment, right, which is kind of playful too, as we talked about. So I think that there’s this category of things that They look and smell like pure utilities. They’re very uniform, they might seem boring, but they really are these like enablers or pieces of a puzzle for playfulness. 00:35:29 - Speaker 3: Yeah, and I also think that’s often an origin story, so maybe we can use this as a way to learn more about your project where, you know, one lens on these projects is, you know, it’s a way to learn a programming language. That doesn’t sound very interesting. But the other lens is it’s the result of a path that someone walked down around the change they wanted to see in the world. So likewise for your project Playbi, you could describe it as someone’s building a new operating system, another one of those, right? But there’s much more to it in terms of where you’re coming from and why you’re building this and how you’re approaching it. So maybe you can tell us a little bit about Playbit. 00:35:59 - Speaker 1: Yeah, so this, like many things, there was no eureka moments, which is interesting, I think you guys have talked about that on the show previously. The slow hunch, the slow hunch, yeah, exactly. So this very much is what happened with Playbit. So for years and years, probably over 10 years, you know, I’ve been interested in operating systems and systems. This is one of these things that I’ve learned about myself that what I find really fun and exciting to work on in terms of software are things that enable a lot of people to make things with them, right? So tools, in other words, I mean, you guys are there with me. And so I started thinking about MacO 9, it’s so tight, you know, it’s so nice. Windows 2000 came around, I was like, wow, it’s so snappy. Anyhow, fast forwarding a little bit. MacOS 10, I think is just like this wonderful amazing operating system. And this very interesting point in time in 2001 or 2002 or so, when Mac was 10.1 or so is the first kind of usable version of it, started getting some traction. I think what happened was that this is probably mostly accidental, but You got these people who were really interested in kind of moldable, malleable software and like poking at things, hacking at things, and they were using BSD and Linux and stuff, right? And they had to give up a good user experience and sure people have different opinions about this, but this is my opinion. 00:37:19 - Speaker 2: I was a Linux on the desktop user for many years and Many things I really loved about it, but I do not miss fighting with getting the Wi Fi chip working or wake from sleep or editing. I spent so many hours of my life editing XOg.com trying to get the resolution to match the refresh rate of my monitor or whatever. And that’s the kind of pain you’re willing to go through for this hackable interface. And yet, my experience was the same. I landed on Mac OS eventually because it gave me so much of that Unix underpinning that’s very kind of powerful and moldable uh with also good hardware integration. 00:37:57 - Speaker 1: Yeah, I think that’s right, that Linux traditionally and still today at least the Linux kernel is most distributions, right, is configuration over convention, whereas Mark, you were talking about Go briefly and Go is sort of like the opposite of that. I’m, I’m a huge fan of Go, like the way it’s designed as a programming language too, but in particular the way it went about the design, where it’s convention over configuration, and we can talk more about that later. But I think what happened was that you have that one part, right, of people who are really interested like you had um of the moldability of software and like the ability to fully customize your computing experience. And then on the other hand, you have people who want to use a computer and be efficient as users of a computer, right? And before MacOS 10, I think you had to make a choice. You had to say, I’m gonna use Windows or Mac OS 9. I’m not gonna be able to do this like multiple hackable stuff. I can do some basic programming or whatever, or I’m gonna do that stuff, but I’m gonna live with all this pain, right? And that quiz 10 came around and it’s like, hey, you know what, you can have both, right? And so, what I think happened was that you got people who knew how to bend and to mold computers and software in the same place as people who were very efficient and effective, and curious and playful around things like design and getting things done, and had real needs, right? And sort of that’s some biases there, I think is what drove Mac OS to become such a successful platform in terms of application quality, right? You just go and look at evidence of this, right? You go and look at a lot of web apps that are trying to mimic desktop apps. In most cases you will find them using metaphors and sometimes even a statics from Macan. It’s pretty rare that you find these things that are in the absence of a native host to mimic Windows, right? Anyhow, so that happened. I think that was very interesting. It’s clear to me now that that is a slowly dying thing, right? Macco is 10:15, you can’t use the VM Nets thing unless you have a special signed certificate from Apple that you can. To get if you’re like become a partner with them, right? You actually cannot run it, even as the owner of the computer, you cannot use it, right? Sure, you can be roots, right? You can pseudo and use it, whatever, but you can’t make any apps using it. And Mac OS 11, takes that to the next step, right? And that’s fine. Anyhow. So, in the context of all of these things, I think that there is going to be a need, right, in terms of like allowing people to keep being playful and exploring. Software at this sort of like more, I own a desktop computer. I want to be able to like do crazy shit with it, even if that means breaking it, right? And so I started thinking a few years ago, I was saying to myself that I’m gonna put a bet that in the next 10 years, there’s not gonna be a Mac OS 10 more, and Apple is just gonna be about iOS. And I think that’s, I’m still believing that. And what then, right? Is there gonna be sort of a Linux based desktop thing that emerges? Is Windows kind of like, finally. Start like a skunkworks team somewhere. They’re just like, let’s throw out like 95% of all the crap and build that. I don’t know. So I was like, should I try to do something about this? It’s really hard to build a business, I think, around the idea of an operating system, especially replacing Windows MacOs, which are just so good, right? They’re just so good and asking someone to just replace that with something is a big ask. 00:41:24 - Speaker 2: Well, maybe the way I would characterize it actually is less about good or not and more just the amount of stuff that needs to go into what people would consider a modern operating system today ranging from hardware support to networking to languages and various kinds of input devices and so on and APIs and the ability to run software and browse the web. and so on is just so huge that it is not something that an individual or even a startup can easily undertake. Hence, it’s only within reach of these incumbents that have these large existing platforms and the rare case of maybe something like Google and ChromoS being able to come in and throw quite a lot of resources and quite a lot of time at the problem. 00:42:09 - Speaker 1: But I think even in the case of Chromois, you would end up in the same place, I think, right? You would have business and money driving the main incentives, right, of like, well, if we make this work for everyone and anyone, we can just make a ton of money and then You have these competing incentives, and more importantly, competing sort of like constraints on those, right? You’re gonna need sandboxing, you’re gonna need all of these safety features, right? You’re not gonna allow people to like mess around with the OS because then most people are not gonna like know what they’re doing, right? And so I think the only way to go about this is to not trying to build an operating system or computing environment that fulfills all the expectations we have. But rather to just change our expectations or offer sort of like a, imagine like a picture on the wall, right? It’s a big picture is very complicated. And you’re very familiar with this picture, and now you’re putting a smaller picture, a much simpler picture next to it on the wall. And you say, you know, you can walk around, you can look at the simple picture, still have this big picture. And I think like, offering this idea of like, what if we shift our expectations a little bit, right? Maybe we do that just in the mode of playful software. So where Playbit started out was as more of an ambitious idea of an actual operating system. And ideas of, you know, I have like a GPU and stuff like that on a remote computer and people has time shared this because GPUs, there’s a kind of, I think a very important slightly concerning environmental impact. And right now we’ve seen this with all the foundry issues, right? And, you know, TSM and stuff like that, right? Like having issues creating ships, right? Because rare earth’s limitations, and this is mostly, you know, impacted by COVID and stuff like that, to my understanding, but still, you buy like an Nvidia high-end GPU today, and it’s very possible that a year from now, you’re gonna have to replace it with a new one, right? Because that industry has moved so quickly. And how often are you gonna use all that power, right? Probably not all the time, right? You’re gonna use that in virt a little here and there. So there’s this crazy shirt on hardware, especially if you’re in the PC world, right? Macs tend to have a longer lifetime, I think. And now I’m talking about like high end kind of high-end hardware. So this is kind of where I started and I got a lot of feedback from a lot of people who I was speaking with to try to understand, you know, and try to navigate what this would mean, and if this was crazy, and I think it was kind of like, it’s probably a little too early, and I think the approach to making this kind of change needs to happen differently. And so, through a pretty slow boil and slow process of just doing a lot of iteration, what is playbit sort of like just came out of this. So the very concretely, I think that Playbit is probably more similar to a web browser or Flash, technologically speaking. And, you know, jump in here if I’m taking this too far or there’s any curiosities to it, but I think the web is successful for a couple of different reasons, right? But one of the reasons is this uniform programming environment, this uniform runtime environment. You know, if I make this little like web program, right, and I tossed it over to you, you can use pretty much any OS, any web browser, and I have a pretty good idea that C is gonna run the same way for you. And this wasn’t always true. I think in the last 10 years this is kind of solidified to be like pretty much true. And I think that’s really remarkable, right? 00:45:32 - Speaker 2: I’ll add on to that, that, yeah, not only does it fulfill the right ones run anywhere, it was a dream of a lot of platform technologies including Flash and Java and so on, but it does it in a way that is sort of instantaneous to download and run. And then, by far the most important part of it, I think, is the sandboxing. It really gets that right. I can completely trust my program to download a program from a website. A website is a program now, a very sophisticated one potentially with all the JavaScript can do. And I can trust that I can just point my browser to URL that I don’t know who’s on the other side of that, and it will download and run that because the sandboxing is essentially perfect within that tab. It can’t go out and access the rest of my computing device. As far as I know, no other computing environment has achieved that. 00:46:23 - Speaker 1: Well, I’d say the Flash did achieve that, and I think that Flash was really brilliant in many different ways. The demise of Flash, I think, has reasons that are really unrelated to its user experience or development experience is mostly, you know, kind of a monolith owned by a single corporation, right? But the model, yeah, think about Flash or think about the web, I think it’s kind of the same thing. That model is really interesting to me and I think the one. Piece of the foundation for creating a culture where you feel empowered to play around with software and to make little fun programs is some sort of safety. And I think that’s what the sandbox does. The good part of a sandbox that you’re talking about Adam is I’m never writing perfect code, right? I’m gonna do something and I’m gonna run it and maybe like delete all the things, right? If I run it on a sandbox, it’s just gonna delete all the things in the sandbox, not, you know, my passport from a Dropbox or something like that. So, I think that’s the good part of the sandbox. The bad part, of course, is like, when you want to do something interesting, like, let’s say you have a photo sensor or something connected to a USB and you want to access that, you can’t, and you’re be damn it. And that’s why you have to jump out of if you’re like a web developer, you have to just be, well, I can’t use web for, right? And then usually you’re outside of a sandbox and there’s no sandbox. And in the last couple of years, there’s been this kind of advancement with virtualization, and virtualization sometimes is Mixed up or messed up with like emulation or the idea of like a virtual machine, right? It’s a virtual machine I would think of as a super set of emulation and virtualization. So emulation, when you run a program like let’s say like a Nintendo emulator, right? You have this program that appears to have the original Nest CPU and did they have a co-processor, I can’t remember. And DSP and all these like actual hardware things, right? So the program inside that you load it up things that is running on this hardware and stuff right there. Whereas virtualization is this idea of running the program in a way so that it’s environment, not necessarily it’s hardware, but it’s environment, appears to be that of a unique computer, right? And this is kind of how AWS and Google Cloud and all these things do it, right. And this has been around for quite a long time, probably about 20 years or so as a concept, and probably in the last 15 years it’s been increasingly like common to develop software doing this. Docker is like a popular kind of virtualization environment, right? And now you have these features built into Mac OS since 10.10. You have built into in Windows 10 with Hyper-V, you have it built in in Linux with KVM. And there’s similar things for a couple of other operating systems, right? And this has happened in the last few years. And so I was thinking that why not just make that the sandbox, right? So like, instead of making the sandbox be this, you know, there’s a DOM, right? And you have a JavaScript API and you have a fetch function, you have an array type, and so on, right? That’s sort of like the uniform runtime environment then, you know, you run that in Firefox or Chrome or Safari, that’s just kind of called completely different code, right? Implemented totally different ways, right? That’s sort of like the uniformity. Like what if that’s just like Linux and then, you know. So like when you run a program, instead of running it as JavaScript or something like that, you just run it as whatever programming language you want, you know, Mark can write in Go. And Adam, you can write in Ruby, and it’s like totally fine, you can interoperate. 00:50:01 - Speaker 2: Part of the appeal there is something like Flash. You have to use a very specific programming language and APIs through for the web as well. JavaScript is not a language a lot of people love and yet because you want to be on the web, you need to write things in JavaScript and using the web APIs. And so it sounds like this virtualization method lets you use more of the standard world of desktop computing or server computing tools, uh, but with some of those same benefits of the flash or web style sandbox. 00:50:32 - Speaker 1: Exactly. So you have the ability to think about it as this portable little box, right? As a zip file or whatever kind of metaphor you want to use. This little thing that you can copy, you can send to a friend, you can put it on a server, then you can suspend, and you can resume later. That I think is a very powerful concept. Like the idea that I can open a FIMA file or a notion document or something. And I can make some changes to it, and I just close it, right? I toss it away. I evicted from my computer, right? I clean up my work desk, and a week later I go back and it’s retains most of its state, right? I can pick up where I left off. Like, why can’t I have that on a lower level, like, in my experience on the computer? Why can’t that be like below where the windows are? Why is it just taps, right? Why is it not just entire apps or in my entire desktop? What if I had like, you know, 4 buttons on the side of my screen, right? And each button was like one of my different, this is not what I’m built, by the way, but I think this would be fun to have. What if, like, yeah, each button was mapped to one kind of VM in your computer. When you push the button, it’s instantly, like a millisecond swapped your entire computer to another one, then you have 4 computers at the reach of like a thumb, right? Yeah, so I think there now is a really good time to take this idea for a spin, and this is kind of like the technical approach to Playbit, what it is as a piece of software. And again, the goal of Playbit is not to build this piece of software. The goal of Playbit is to create and encourage like the development of small scale personal software. Maybe we can get into that more a little bit later. So like, when I’m building it right now and what I’m trying to get out in the next couple of months is kind of a Macintosh application, and I’m sure I can make a Windows app and Linux up and stuff. So Macintosh application, you start it up, and what it does is that it uses the the hypervisor of Mac OS and it boots up a Playbit OS which is this kind of based on the Linux kernel. It takes like 2 seconds or so to start it, and once it’s started inside there. You have this feature of Linux called namespaces, which you can use to create these kind of little isolated processes, right? So you can run a program and the program thinks that it’s like ha ha, I’m the operating system, I have all the power, and it kind of appears as that and it doesn’t have to be bothered about it and stuff like that. And those would be the little products that you would build and you would kind of play around with. They can crash, they can write stuff to disk, they can mess with the network. None of that is like leaking out to your real computer and not even to like the playbi OS. So the manifestation of it in the first attempt to creating a piece of software that encourages this playful thing, is this very resumable, very sort of like, Kind of stop and go, pick it up, leave it off type of software that you can play around with like today, like on your computer. And the runtime environment that you have is not the web platform, but it’s the Linux OS. So if you want to write things in in JavaScript, you can do that, right? If you want to write things and see, you can do that too. If you want interoperate between these two different things, you can just like write shit to the file system, right? You can use it as a database or you can build around an actual database if you want to. 00:53:47 - Speaker 3: Yeah, one of the reasons I was intrigued by Playbit is it seems to share this aesthetic I have around kind of collapsing the stack down. So I think it’s easiest to explain this in terms of its contrast. I feel like there’s this pathology with modern software systems where we keep adding layers and layers and layers, and that’s a few things. First of all, it tends to make it slower cause you’re going through a bunch of calls. It also tends to reduce your ability to do things because in order to have access to a feature as a programmer, that feature needs to thread through all the layers. So if any layer happens to drop or corrupt a feature, you’ve lost it. This happens a lot with graphics APIs because the original middle layers were designed for bitmaps, and then we changed it out to GPUs underneath. But then the middle layers haven’t kind of fully caught up, so you get this weird like impedance mismatch that means you don’t have access to the full power of the GPU. Anyways. And there’s also this element of you don’t understand what’s going on, because you’re kind of just casting the stone into 19 layers. Of libraries and, you know, who knows what it does, and that to me really interferes with my ability to play because I don’t kind of know what’s happening. I don’t have control over my environment. And I like these platforms, these operating system ideas where you squash that way down, you kind of start from scratch again. OK, we got name spaces and we got the GPU. What can you do now? Well, it turns out it’s a lot if you have a clean slate like that. I’m curious if that aesthetic sense resonates with what you’re trying to do with Playbit. 00:55:07 - Speaker 1: Oh, absolutely. It’s so fun to hear you talk about this, Mark. Yeah, I think that this is very, very real, and it’s something that I care a lot about. I was really early on working and using like no JS and I thought that was very exciting. And I think what ended up happening with MPM I think it’s still like fantastic, you know, both a fantastic group of people and culture and all of that stuff. But by making it really easy to pile stuff on top of stuff, people are gonna do that, path of least resistance, right? That’s why you have like someone who says, oh, look at my web server, it’s just 12 lines of code, wink wink, and the wink is like this package adjacent file that says dependencies, long freaking list, and each of those have a long freaking list of dependencies. And it’s a quick deter to the sandbox thing that we were talking about, like, isn’t it kind of bonkers that like, we don’t dare installing this program on our computer and just run it because, you know, it might just go and delete our hard drive, right? But we’re totally fine. We’re just pulling in some like random ass like MPM packages, right? One of those can just go and like delete your whole hard drive or upload all of
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: I actually say mostly seriously that games in the world of gaming predicts a lot of trends. So it goes from kind of pro games to mainstream games to consumer software to software for startups to software for enterprises. 00:00:21 - Speaker 2: Hello and welcome to Meta Muse. U is a tool for thought on iPad. This podcast isn’t about Muse product, it’s about Muse the company and the small team behind it. I’m Adam Wiggins here today with my colleague Mark McGranaghan. How are things in Seattle, Mark? 00:00:37 - Speaker 1: Going all right. We got the cherry blossoms this week in Seattle, which is exciting, and it’s a sign that we’re turning into the strong half of the Seattle weather calendar in the summer here. 00:00:47 - Speaker 2: Very nice, yeah, we’re seeing just a little bit of flowers starting to peek out on the trees. Here in Berlin, although it’s always an experience where you see the first flowers kind of try to come out when it seems like it might be warm enough on those first sunny days in March, and then inevitably it turns really cold again and they all die. Yeah. So you see this thing where there’s the pioneers that are trying to break through, and then eventually the weather turns and it comes into full bloom, which is absolutely excellent for those that like colorful flower rich environment, like me, probably pretty bad for those with allergies, I’m imagining. 00:01:23 - Speaker 1: Yeah, for sure. All right, so I’m excited to do an episode, Adam, about learning from games. Now, games, gaming, the gaming ecosystem, something that’s come up on a lot of previous podcasts. We’ve mentioned it here and there, but I thought it would be a good time to do a proper episode, collecting all of the things that we’ve learned and gleaned from that industry. 00:01:45 - Speaker 2: Yeah, we mentioned in passing lots of times. I think we talked about it last time with Rasmus Anderson. It was a big part of our conversation with Andy Works, and he’s since published a great article essentially on exactly this topic called Serious Play. I’ll link in the show notes, of course, talking about his journey of playing a lot of games when he was younger, then eventually becoming, I don’t know, an adult with responsibilities and, you know, you don’t have As much time for that sort of thing anymore, and then rediscovering really rich uh world of of games that exist now, both the big budget stuff and the indie games, and also what we can learn from that, why these are important as artistic, as cultural, and certainly as inspiration for design. So Mark, when you’ve been inclined to reference games in connection with news, productivity, software tools for thought, it seems like they don’t have much in common, right? The productivity world is very focused on, well, being productive, which is almost the opposite of what you think of games are for, which is entertainment. So why is there a connection? Why are these two things so relevant to each other? 00:02:53 - Speaker 1: Yeah, well, that’s kind of the question of the podcast, isn’t it? Maybe we can start by motivating a little bit because I think we’re kind of sleeping on games as an industry. It’s something that in the typical world of Silicon Valley kind of flies under the radar for a variety of reasons, but in fact, games are a huge deal. It’s an enormous industry. They’re extremely influential in terms of the amount of time that people spend on them and the culture, and as we’ll see, I think there’s a lot of technology, products, social things that games have figured out. I think there’s a lot to learn there. 00:03:25 - Speaker 2: Yeah, one comparison you can make there is Hollywood, right? Films, TV, and I think it’s well understood, or most people would say, yeah, of course, Hollywood and films broadly have this huge impact on our culture. It’s this really big industry. The celebrities from that movie stars are lionized in our world and in our culture, and everything from patterns of speech to social change has happened often through seeing things like, I don’t know, gay couples on TV and movies. I think that helped pave the way for a broader acceptance and legal change of that. And so, that seems fairly clear, but games maybe, as you say, we’re sleeping on them, they fly under the radar, they’re seen for some reason as less influential or less important, but of course, if you look at something like just the dollars or the total kind of money that goes into the industry, it’s actually larger than Hollywood, much larger than films, um, and maybe on par with maybe something like professional sports. So, this is something that is ongoing, already has had huge cultural impacts, and I think that’s even more so as new generations rise up. 00:04:35 - Speaker 1: Yeah, I think the professional sports analogy is really interesting and apt. For me personally, I kind of grew up watching sports. That was one of the things that I did. You watched American football and baseball primarily, but when I was an adult, it basically became illegal to do so. It’s actually very hard to watch American football if you don’t have like the satellite dish, you have to buy the package and, you know, I have. Apartment or how do you even get a dish, you know, it’s a whole mess. And likewise with baseball, it was actually quite hard to buy a subscription to watch baseball. I tried, it was not fruitful. So one of the reasons that I ended up getting more into this community of games is that it’s actually just much more accessible. So Adam, I’m curious to hear a little bit about your story and how you ended up there too. 00:05:13 - Speaker 2: Yeah, I think mine is typical in some senses that I played games as a kid and they had a really big impact on my life, and this was particularly true when for a while we lived in a pretty rural area and basically there was not a lot of other kids around and I’d go like get up to trouble at the river behind our house or whatever, but at some point, did manage to get access to a computer and that was certainly when I learned to program, but that was actually largely motivated by thinking I want to make my own games because I played these games and I had these really powerful and mind expanding experiences and I thought I want to do this too. And I dreamed of growing up to go into the game industry. In fact, I did exactly that, basically dropped out of college to work in my first game company, and went from there to working at some other relatively high profile companies, and after a few years, I got disillusioned. And essentially that was because sort of the tools and practices were so bad. This is post hoc. At the time I couldn’t quite put my finger on it, but I saw these really talented people working these crazy long hours, 60 and 80 hour weeks, and death marches to ship products and what have you, and maybe somewhat. Ironically, or maybe that’s not quite the right word for it, but there’s an interesting thing here where that’s part of what got me interested in tools, creative process, and I thought, OK, I love the output of this. I love games, or at least games as an artistic medium, I think can be really excellent, but that at some point the big budgets and the complex technology that went into it. And some dynamics of the industry just meant that the process of making them was kind of terrible. Now, this was the late 90s, I think a lot has changed since then, including the indie game revolution, but interestingly enough, that was my path. One way you could put it, or I could postdoc describe it is that the developer experience for game developers in the late 90s was terrible, and that’s one of the things that got me interested in developer tools, but also the creative process generally. So, Roku was about developing. Experience and great tools and a smooth process and of course Muse is a tool for thought and on that dimension, but they all kind of feed into that. So the bad experience I had in the game industry pursuing what was my childhood dream in fact led into what turned out to be the uniting theme for my career. 00:07:31 - Speaker 1: Yeah, interesting. So you originally sort of came at it from the developer experience as well as the user experience side, and I came at it more from the user experience side and I’ve since been learning more about the engineering side as I’ve explored the world of technology. 00:07:45 - Speaker 2: Interesting. You came in from a perspective of eSports as a replacement for sports, sort of. What were some of your first experiences or first games or first things you, I’m not even sure what you call a tournament, an e-sports tournament. What was it that was the seminal thing that opened you to this world? 00:08:04 - Speaker 1: Yeah, it’s funny. The beginning is sort of the present. So one of the games that I had played when I was much younger, like 20 years ago, it’s called Age of Empires 2. This is a real-time strategy game where you have a little civilization that you collect resources for and you use it to build armies and take over the world and so forth. And this is something I had played when I was a kid in the 90s, as one does, and had kind of forgotten about it. But then a few years ago, I saw that the game had basically been revived by this new sort of social technology around games that includes things like YouTube, Discord, pro tournaments, Twitch, all. These things to make it more like a professional sports ecosystem or community. And I sort of dialed back into that, it was such a fun game. And sure enough, there was this incredible vibrant community and ecosystem around it. And based on that, I started poking around more in the world of gaming and e-sports in general. And I saw more of that pattern. And then I looked into some of these more popular games. That’s kind of a really niche game. There’s very popular games like Counter Strike, which is another one that I played when I was a kid, and that is now a huge eSport. That’s a game where you have like a million people watching the big tournaments. It’s the real deal. There’s many professional players and teams, people do it basically for a living, and there’s an incredible amount of social energy around it as well as people just playing it for fun, of course. 00:09:18 - Speaker 2: Yeah, the competitive aspect is super interesting because I personally much prefer weird indie games that are more exploratory or puzzle games. You take it at your own pace, something like, I don’t know, Fez or Papers Please or recently been playing a lot of Babas you. So these really competitive games, particularly. I guess I can appreciate them, but maybe I’m just not a very competitive person, but I agree that the social aspect that comes with it, which includes these huge tournaments, which I have some insight into, there’s a great YouTube channel, Kora Gaming. Basically is by an insider of this competitive world of, I don’t know, Street Fighter and StarCraft and all these kinds of tournaments. And I also read a great book called Playing to Win by David Serlin, where I think he was a pretty high ranking maybe Street Fighter player, if I’m not mistaken, and he kind of goes and breaks down the elements that competitive games have their own special flavor because in the end, the thing that’s interesting about it is The other players and they can forever evolve, and that’s why games like chess and poker, for example, to take two, even though the rules haven’t changed in, I don’t know, decades or even hundreds of years, the game remains interesting and evolves because I think the meta game they call it, Playin talks about this, and Sirlin puts games like StarCraft which are still played professionally in these tournaments 20 years later, maybe like the Age of Empires you mentioned. Some of these Street Fighter games and so on, and that in fact is a sign of a truly good competitive game, that the game doesn’t need updates, it doesn’t need new content to stay interesting because what keeps it interesting is the other players. 00:11:02 - Speaker 1: Yeah, I do think that’s a big part of it. Games that are competitive in the classic sense where like you’re a competitor and you’re competing against someone that can be interesting for a long time, as you were saying, as the meta evolves. There’s also this whole other layer which gets to the sort of professional sports analogy where the reason these games have become really huge isn’t because people personally want to compete competitively. In the same way that American football isn’t huge because you want to be a world class football player, is because you want to be cheering for a team or a personality that you believe in, you want to kind of get into the play calling, you know, and understand that it’s basically a substrate for having a social dynamic. And people, they just like the competitiveness, not necessarily in all cases to compete themselves, although there are some people do. 00:11:46 - Speaker 2: Yeah, that’s fair. And I think there’s a few elements there again, looking at the sports. Example, which, while that was never a big part of my family life growing up, sounds like the way that it was for you, I’ve actually gotten more into European football since living in Germany because it is such a huge thing, particularly when the World Cup came around a few years ago. I mean, when a World Cup game is on, particularly when Germany is playing in, the streets are silent. There is nobody out, but you actually hear everyone’s TVs on or kind of Like in sync, but with like slight delays from the speed of sound, travel, and even like convenience stores will set up a TV they’ll just basically drag a TV out onto their front stoop essentially and set it up so you can walk by. So it’s this very unifying experience and actually a lot of fun, even though this particular sport of these teams are not something I follow a lot. That social element, that unifying element is, let’s say something I appreciate more now. Yeah. I feel also with sports, and this goes for e-sports as well, there is something about maybe something like the Olympics, which is maybe less directly competitive in terms of a lot of the sports they show, but it’s something about seeing humans kind of performing at their very best, like the very best at doing a kind of impressive thing. And people who have trained their whole life, and we’ve chosen the very best people in the world and put them on the spotlight to do this, and I think there’s something similar and it’s a different thing when you watch these, I don’t know, amazing StarCraft players do what they do and you watch them sitting there. It doesn’t look like much, right? They’re barely moving their wrist. to flick the mouse around, but if you know how the game works and you’re drawn in intellectually and you see what’s happening on the screen, and then of course you have the announcer voiceovers that help you understand the significance of what they’re doing and why this is interesting and the cheering of the crowd and yeah it’s quite interesting. 00:13:36 - Speaker 1: Yeah, it’s interesting you mentioned that. I think one of the reasons the Olympics works so well is that there are very universal athletic acts, running, jumping, swimming. It’s something that anyone can relate to. And so when you see someone doing it at a very high level, you can say, oh, I kind of understand what that would take and why it’s so impressive. And yeah, if you’re watching a game that you’ve never played before, it’s probably not going to be super interesting. But the reality is people are growing up on games now, and it’s becoming a huge part of people’s lives, and so a lot more people are in a position to appreciate and engage with these communities. 00:14:06 - Speaker 2: Now when it comes to the things that the productivity software world or the tools for thought world can draw from games, certainly there’s social elements which I think are interesting, but there’s also at a more I don’t know, pragmatic level there’s technology. The technology that has gone into games, I guess they’ve really driven a lot of computer hardware advances from the beginning, essentially, but especially in recent years, I feel like it’s pretty unbelievable how games are sort of pushing the envelope in terms of what computers can do. 00:14:38 - Speaker 1: Yeah, for sure, GPUs, displays, input devices, latency reduction is something that’s all been driven basically by games again, cause there’s a huge amount of dollar demand for high quality hardware. So there’s a lot of incentive on the part of hardware developers to improve it. I do think probably the biggest category for me from games is performance. Yeah. I make this joke that I can load up a game on my other computer, it’s like 300 FPS photo realistic 3D world, walk around, do whatever you want, and then I’m over here scrolling on whatever this web page and it’s like choppy choppy at 60 FPS. It’s just a kind of a whole another level of performance and focus on that, and something you probably have understood from the day you started working in games. 00:15:24 - Speaker 2: Yeah, that’s right. I think the culture there on performance. is both inside the game companies. I mean, first of all, there’s probably like you said, a lot of financial incentive that drives these companies like Nvidia and so forth to just be continuously pushing the envelope on what can be done with graphics, for example. But then within companies it’s just, for example, very, very standard to have frame rate counters and all kinds of performance metrics really built straight into the app and That’s something we’ve tried to duplicate on the Muse team a little bit. We had a frame rate counter right from the beginning, and it was part of our vision to be, you know, the iPad Pro is 120 frames per second or can update at that speed, and we wanted to see if we could keep that full frame rate throughout, and that’s a huge difference compared to, you wrote about this in your slow software article, you go to load up Google Drive or Ocean or some other thing. It’s not measured in frames per second. It’s multi-second delays to do just a very simple operation like just listing out your current documents, which by the way you looked at that same list 5 minutes ago. It’s probably in the cache somewhere, but it’s just there just isn’t that same culture of performance. And yet when you worked at a game company, it was just really standard. You had all these on-screen displays about frame rate counters and all this tooling, and of course you make it fast. You have to make it fast. It won’t feel good. If it’s not smooth, and that just doesn’t exist as much on the productivity tool side, and I’d furthermore say it’s also driven by users. Users care about frame rate, they pay attention to that, they are thinking about particularly people that I don’t know, build these PC gaming rigs. I’m probably the definition of a casual gamer. I’ve got my Nintendo Switch and I play games on my iPad and I don’t want to have to do anything. I want an appliance that makes it really easy. But people who are into pushing the envelope and getting the best graphics they can, they enjoy the process of assembling this hardware and then even running these benchmarks themselves and being able to say, OK, I can run the, I don’t know what it is, the latest Doom or some other high demanding graphics game, turn on all the settings and then be able to get this many. Frames per second, so users' care and then the developer’s care and the hardware manufacturer’s care and together all of this culture of really deeply caring about performance over the course of decades just means that games now can do incredible things and yet by comparison, most of the software we use for work is kind of sad in comparison. 00:17:55 - Speaker 1: Yeah, and it’s been going on for so long that they’re now almost completely bifurcated engineering cultures. Games is C, C++ programming the GPU mostly, whereas a lot of our productivity software is now it’s like JavaScript, electron apps, Ruby back. And stuff like that. It is a kind of totally different way of thinking about engineering stuff. But notably, I think that divergence is starting to collapse because people are realizing the power of this more game style programming model, where you have an efficient language and you’re programming against the hardware more directly. And I think we’re starting to see more of this. I will be some examples of that. 00:18:34 - Speaker 2: Yeah, Rick Aaron’s work on MakePad comes to mind immediately, so this workshop hit switch for us sometime back, but there’s basically a code editor that uses rust and maybe web assembly, I’m not sure. It is built on the web stack, but he gets rid of the DOM, and he’s essentially just trying to render straight to GPUs. For example, when the code folds or unfolds, you can get some really nice smooth animations of that happening, which is not the sort of thing you’re used to in a programming editor. Yeah, exactly. Now I will give ourselves ourselves here being folks making uh productivity tools a little bit of leeway on this, because one thing about games is that you do get this very much just blank canvas, build everything up from scratch. So for example, like a great way to make a game is you write it in C, use something like SDL, which is essentially just lets you draw pixels and polygons onto the screen. It’s this and take input from the mouse and keyboard and game control or whatever else, and it’s just this very, very simple stack, and the interfaces are very simple, and productivity tools you really need to integrate extremely well to the platform you’re on if your web app, or for example, for us where we’re on iOS with Muse. You know, we need to integrate to drag and drop and various kinds of ways you can size the window and what happens with with the sharesheet, bringing things in, bringing things out, and copy paste, and all these sorts of things, and these are expected and desirable. You can do things like, I don’t know, change various settings on the device, including language and all sorts of other things, and that cascades down through the application. And I think all that’s good and necessary, because when you’re working with applications, you often have several side by side, you’re sharing data between them, this sort of thing, they need to play together. A game can just take over the screen completely, it’s got this just draw pixels or draw polygons thing. It does not need to interoperate with anything else. It can be a world into itself, and that’s just, I don’t wanna say it’s easier, but you can have this more streamlined thing. You don’t need to play what next with others quite the same way. 00:20:41 - Speaker 1: Yeah, that’s fair. Speaking of developing these apps, I’ve always felt like there was something here with games, like with movies where they do seem to be able to plan and execute on very complex projects successfully. There’s kind of this meme in the world of typical called enterprise software development, where you have to do things super incrementally and, you know, and nothing is predictable. You can’t estimate anything. Basically, who knows? This is kind of a meme in Silicon Valley engineering, whereas if you look at things like Movies or games, they say things like, yes, we’re going to invest $200 million in this, and it’s going to be a massive creative high risk enterprise and it’s going to involve many disciplines and we’re gonna ship it, it’s gonna be awesome. Done. And I feel like we could use a little bit of that attitude in the world of enterprise software as well. 00:21:27 - Speaker 2: Yeah, now there are many famous. Big attempts at big projects. I think a recent one that comes to mind is this game Cyberpunk, which was hugely anticipated, as you said, like a huge breakthrough in terms of sort of the depth and richness of the game, or at least the game world that was promised, and in fact they did deliver something very impressive, but it was full of bugs and all kinds of problems. It didn’t work right on different platforms. There was lawsuits and You know, lots of broken marriages and fired people, and I think at some point they may have even written about it in our favorite financial newsletter money stuff about essentially like becoming securities fraud, that the game was bad because of all the money that was on the line for it. Maybe that one was pretty large in scale just because of the amount of time and money that went into it. They’re similar, called boondoggles or just struggles. Duke Newcom Forever was a really famous one on that from years back, or maybe a more indie one was this game, No Man’s Sky, where again, they set up expectation for it, which may be part of it is just the game industry is so incredibly good at hyping games that have not been released yet, which Find kind of crazy how emotionally invested the audience gets, and then if it doesn’t quite deliver, then there’s a lot of broken hearts, I guess. So it’s hard and they don’t always achieve it, but to your point, there’s also many, many cases of and probably more cases of really grand and ambitious things like for example the Mass Effect games or one really ambitious one that I played recently that I liked a lot is Horizon Zero Dawn. And yeah, it’s just amazing the amount of stuff in it, the richness of the universe and the story and the characters and the voice acting, and all the skill trees you can traverse and the modeling on the creatures, and yeah, it’s really, really astonishing what goes with these games. And that’s the technology side of things. Do you feel there’s things we can learn on product or design side, kind of as any works has talked about a little bit? 00:23:26 - Speaker 1: Yeah, for sure. I feel like there’s some things that have been so discussed that they’re almost cliche. This is like gamifying stuff. But I do think there’s some stuff there around, for example, games have very carefully designed incremental onboarding processes where you get introduced to more and more techniques and skills and moves as you become more familiar with the antecedent ones. 00:23:49 - Speaker 2: Yeah, and I’ll link in the show notes to our podcast episode on onboarding with our colleague Julia, who led that up. So Muse went through several attempted kinds of onboardings, and none of them quite clicked, and eventually we did take this game inspired one that essentially, well, there’s a few games that take this approach, but the one that was top of mind for me at the time was Untitled Goose Game, where it essentially gives you a to do list of stuff to mark off, and you don’t have to do it, but it gives you some direction while also giving you freedom, and that’s what the muse on boarding uses, and that was Yuli’s good work, and she talks about it in depth in this episode. 00:24:24 - Speaker 1: Nice, yeah, but I think perhaps the most interesting aspects of products are things you don’t jump to when you think of games. You think of games, you think of like, you know, 3D immersive worlds and noises and stuff like that, too, that I would call out our end user programming and monetization. Mm. These are both huge challenges for the world of computing and especially kind of indie enterprise type software, but I think games actually do very well, so there’s an incredibly rich ecosystem around games that allow it of end user programming of various forms like scripting, modding, skinning, different variations, but people are so motivated to create their own experiences in these game frameworks that if you give them anything at all to control their world, they’ll go wild on it. 00:25:11 - Speaker 2: Yeah, the modding thing is pretty impressive, including the whole new genres have been invented by people taking a game that you can kind of chop up and customize a little bit. Tower Defense, I think one was famously originally a mod of an existing game and is now its own dedicated genre. 00:25:27 - Speaker 1: Yeah, another example there would be Counter-Strike, which is one of these games that I mentioned earlier, that’s now one of the biggest e-sport games in the world, and it was originally like some guy in the basement doing a half-Life mod, and he shared it with his friends on the internet, and then 20 years later it’s a huge deal, right? 00:25:43 - Speaker 2: And that’s some of the argument we make with end user programming is to say that if you create a smoother on-ramp for more people to be able to get in there and make smaller pieces of software, that some, not all, but some may blossom into something that maybe would never have existed before if that large hurdle to sort of full professional, quote unquote real programming was the only option. 00:26:08 - Speaker 1: And I do think this world shows. The incredible importance of access and motivation versus the programming environment per se. I think when computer people talk about end user programming, they talk about things like languages and IDEs and things like that, whereas my sense is that what really drives end user programming access is people really, really wanting to do something in that environment and having some ability, even if it’s honestly it’s a mess, to do something with it. And at least with that, you can get the types of ecosystems you see with games where it’s not like everyone is doing. End user programming of their game environment. It’s more like there’s out of the tens of millions of people who are part of the community, maybe 10 are really into it, and they jump through all the hoops to figure out whatever the end user programming situation is for this game, and they’re able to create 5 mods, one of which becomes a huge deal its own whole game. 00:27:00 - Speaker 2: Funny little story on that as well. So many folks who followed me in my work on Hiroku might know that I’ve written about end user programming and in particular that I was inspired by this book, A Small Matter of Programming, which is an academic work from the early 90s, that essentially made a lot of the arguments that we now repeat in this kind of what we’re seeking in the end user programming utopia, driven by an academic named Bonnie Nardi. I actually Managed to get her on a video call some years back, and she was quite amused because, you know, she had written this book 20 years ago or something at the time, and I think it was even out of print and was vaguely surprised that anyone was still interested. But as I asked her what she was doing now, and it turns out she actually went on to anthropological work within multiplayer online games. And the book, I think she had just written at the time is called My Life is Night elf priest. She spent several years doing anthropological studies of World of Warcraft, which at the time was sort of the biggest multiplayer online game and really one of the biggest gaming phenomenons ever again. I think this was kind of the mid 2000s, late 2000s, something like that. And when I asked her about end user programming, actually the first thing that came to mind for her was the modding that happens in the World of Warcraft world. 00:28:16 - Speaker 1: Yeah, and it’s great that you mentioned World of Warcraft, because I think that’s a very important piece of the story around monetization and social. So with monetization, back in the before times, you would have boxes that had, you know, CDs in them and you would buy it once and that would be the game, and that would be the way that you got the game, and that would be the way that the publisher made money. And then I think it was World of Warcraft, maybe there was someone else who pioneered the subscription model, which we know from Enterprise Sass is an incredibly powerful economic model and also great for the users in many ways. And likewise, World of Warcraft, which had a subscription model, brought that to the world of games and like you said, it was a huge success, and there still existed a world of games you sort of bought once and there still are, but it’s sort of adding another layer or area of opportunity. But then there’s been this sort of 3rd wave of games where it’s not even monetized necessarily by a subscription, it might even be free to play, but it’s monetized by the broader community, or some other way in the game, so this could be cosmetic items in the game, it could be. Tournaments, it could be other things like that. And there, it becomes important for the creator of the game to invest in basically building a really big community and enthusiasm around the game, and they find other ways to monetize it that aren’t initial purchases and that aren’t subscriptions. And this kind of leads into the social thing which we can talk about next, but to my mind, those are the most advanced forms of game communities right now because there’s so many things going on that are combining to build a very rich ecosystem. 00:29:45 - Speaker 2: I’m not mistaken, one of the pioneers on the free to play with purchase cosmetic items was Team Fortress. Essentially, you could play it and you could buy stuff that I don’t think it made you stronger, just made you look cooler, get a cool hat for your guy. That game’s made by Valve, and Valve is one of the most, definitely a, I don’t know if I’d call them a small giant at this point, they probably are just a giant, but they are an incredible creative powerhouse that has done many, many great games over the years. You mentioned Half-Life and There’s Steam Fortress and there’s Left for Dead and many others, and then, of course, they made Steam, and Steam has been a total revolution in kind of the economic model, particularly for indie developers. We’ve talked here multiple times before about sort of the Steam early access program and how we see folks that bought subscriptions early on from you and Today as being in some ways similar to Steam early access, you know, supporting what the app can be rather than what it is today. So Valve is a really great one to study and look at if you like to see an innovative company. And by the way, their employee handbook is absolutely fantastic. I’ll like that in the show notes as well. 00:30:55 - Speaker 1: Yeah, classic for sure. And this type of monetization, by the way, that is not initial purchase and not subscription, for example, in a cosmetic items, it really surprised me. Like when I first heard that there were big game ecosystems funded by this, and honestly didn’t make sense. Like, why are people gonna spend a lot of money to like get a cool whatever nice skin or something. But in fact, it’s a really, really, really huge deal. The games are able to bring in tons of funding with this stuff. So it’s an example of where you really need to follow the empirical reality and see how things are actually working. 00:31:26 - Speaker 2: Now how do you fit that in with this category of games like thinking of maybe Candy Crush or, for example, Boga, which is a pretty big employer here in Berlin, actually our colleague Julia started her career there. And they tend to make these games that are free to play, they kind of draw you in. Oh, maybe Farmville was one of the classics on this and can easily turn into a maybe a slippery slope of spending, I don’t know, hundreds of bucks a month. You sort of like accelerate the game play with special tokens or something. That whole category I always feel vaguely uneasy about the model on that. 00:32:01 - Speaker 1: Yeah, I felt very uneasy about it, and I think it’s actually quite disjoint from this world of more professional games, which often have this attribute that for either the initial purchase price only or perhaps nothing, you can play at a professional level forever. Like you don’t need to buy anything to be able to play it, unlike the games where you buy like power-ups or coins to keep playing or whatever. So I’m much more interested in these games that are more, maybe you call them skill-based. And they have communities of practice around that, versus games that are more, like, honestly kind of more like gambling oriented. So I can consider them quite differently. It’s a shame because I think the Candy Crush style game taints the world of gaming on the surface, maybe it looks similar, but 00:32:44 - Speaker 2: yeah, to your mind really is not. And yeah, I think I agree with that as well. 00:32:48 - Speaker 1: Yeah, so speaking of communities, this brings us to the social aspect of the games, which to my mind is the most interesting part, and it’s kind of hard to explain what’s going on there on a podcast, but we can try. 00:33:00 - Speaker 2: Yeah, you mentioned Twitch earlier, and I do think that’s a great starting place because, well, it can be honestly mystifying, I think it was for me when I first encountered it, and seeing that there’s this whole giant platform that is almost exclusively watching other people play games. And again, maybe this comes back to the sports thing, but in many cases you’re not necessarily watching people who are great at playing games. Maybe it’s just someone you like that is playing games. I don’t know, it’s a very interesting phenomenon there. 00:33:30 - Speaker 1: Yeah, I do think the sports analogy with Twitch is a good place to start. So some groundwork here, Twitch is a streaming platform and was basically created for people to stream their gameplay, playing games on their computer. Now does a lot more stuff. 00:33:44 - Speaker 2: Fun bit of history there, if I’m not mistaken, Twitch was a pivot from Justin.tv. 00:33:48 - Speaker 1: It was, I was actually there. This was in the, what was it called, the YC startup school is when they rented out an auditorium in Palo Alto, and Justin Khan walked down onto the stage with his camera, which is like filming his entire life 24/7. And so I saw the very beginnings of that, and eventually that would pivot into Twitch, yeah. 00:34:06 - Speaker 2: Yeah, that was the startup idea was one guy filming his life around the clock with the idea that that might lead to others, and I think they ended up building a pretty robust. Video platform at the time, this might have even been before or roughly coincident with YouTube. 00:34:21 - Speaker 1: Yeah, so from those humble beginnings, you get this platform for streaming gameplay and then having a lot of social interaction around that you can think about this kind of the main window, which is the streamer, and then there’s a sidebar, which is people chatting and stuff. And it’s like your situation in Berlin where people are around the family room or around the convenience store watching a game and they’re sort of cheering on you, as well as watching the game, you’re watching your friends basically and seeing how they react and enjoying that. And yeah, I would say it’s mostly kind of pro players or strong players, but there’s also people who cast like normies or whatever, just for fun. 00:34:55 - Speaker 2: One of the ones that blew my mind is this guy CGP Gray that makes these educational YouTube videos that are pretty popular, I think. He’s done some Twitch streaming and he mostly plays games like, I don’t even know the name of it, but you’re just a truck driver, and it’s a real-time sim of driving a truck. And so it’s just him on like an open highway, you know, the simulator of a highway. And it’s precisely as boring as it sounds, that’s kind of part of the point is that it’s kind of this meditative experience, and then I think the reason in that case, it’s not that he’s a pro player. I don’t know, maybe he’s good at it, maybe you’re not, but it’s more that you like him and his personality, and it’s fun to kind of interact in this real-time way around this casual activity. 00:35:42 - Speaker 1: Yeah, so there’s Twitch now. One of the things that’s really important here with the social ecosystem around the games is that they’re open source, let’s call it. So if you are broadcasting the NFL. You need to be the one broadcaster that’s licensed by the NFL and you gotta go to the one channel that’s displaying at the time. And in fact, there’s only one caster, whereas in the world of games, it’s usually a much more distributed and open access. So a given tournament, for example, will be running, and anyone can jump in and cast the game and you get as much audience as you can. And you people can watch multiple casters at once. People can come and go. And so it’s this world in the same way that with open source software, people can kind of jump in or leave or and mix and match versus commercial software which is very closed and controlled. Typically in these game ecosystems, it’s very open access for the participants to come in and make a career as a caster or commentator or a pro player or what have you. 00:36:36 - Speaker 2: Do you feel the, maybe I’ve read something about there’s actually a legal gray area with the Twitch live streaming of games where essentially that’s copyrighted content and kind of in a way the game companies actually would have legal grounds to sue them to take that down, but of course it’s it’s incredible marketing for them. I think it was something like Among Us, which is this indie game that blew up last year, we’ve played it at our. summits where you kind of hunt down this imposter on your ship, and apparently that was a game that didn’t do that well when it came out, but it blew up essentially because, you know, a big streamer started playing it. Now everyone, including like US senators are are playing it in public places. But yeah, it’s this interesting thing where they just choose not to enforce copyright or the DMCA or whatever it is because it’s such great marketing for them. 00:37:26 - Speaker 1: Yeah, exactly. My understanding is that companies, if they wanted to, can exert varying levels of control over this. So they could say that I think they could say you can’t stream this, they could definitely say we’re going to control the officially sanctioned tournaments, and I think there are some games that especially for the latter are trying to do that, but you have this classic trade-off between Exerting that control and therefore extracting more of the consumer surplus out of the ecosystem into your company versus creating a vibrant open ecosystem where you generate a bunch more consumer surplus and even if you take a small percentage of it via say, cosmetic item sales, it ends up being a bigger deal for you. And my intuition here is that the social dynamics around these games are so powerful when they’re firing on all cylinders that it’s really hard to compete with that. 00:38:20 - Speaker 2: Another thing that comes to mind for me here as we talk about tournaments and Twitch and so on is there are actually tools that have come out of the game world that I think are what I would call productivity tools. In fact, we may even use them in our work, so Discord is one that’s become quite huge, kind of group chat, that’s very, I mean, their, their logo is a game controller, right? You think of them as a slack competitor, in fact, they’re very similar in terms of what they provide, but their culture is all comes from Gamer world, right? That was what it was made for originally. 00:38:52 - Speaker 1: Yeah, Discord is actually one of the other really big pieces in the ecosystem, so it’s worth drilling in a little bit. So you have Twitch, which is for live streaming, like the live broadcast. Typically you have recorded content on YouTube, and then for your communities, primarily those are in Discord these days. There’s some activity on Reddit, but Discord is the main one. And again, these are very granular, focused, unique, quirky, weird things happen all over the internet. So for any given game, you typically have one Discord for each personality, like each pro player, each major caster, they have their own Discord where they have like basically have their own channels and doing a bunch of random stuff, their own weird community. And so when you become interested in the game, you might join one or two of these Discords corresponding to the casters or the pro players that you follow. And there you would hear about their upcoming games and their discussion of the games and various social commentary and stuff like that. 00:39:48 - Speaker 2: Hm, I wouldn’t have guessed you would have Discord servers around a person, that almost makes it sound more like Twitter or something, you’re like following someone whose career you want to follow along with, but then I suppose the point is now you can also talk to the other people that are there who are interested in that same thing. 00:40:05 - Speaker 1: Yeah, so this is a very important point. The job of these pro players and these casters, because it’s such a big deal, it’s going way beyond just doing that single job. I think of it more as their social entrepreneurs. They’re creating communities of content, of people, of forums, of ways of interacting that are something that people want to participate in. And in fact, It’s kind of cool as an entrepreneur to watch these people because they’re basically running their own business. They’re hiring full-time staff, they’re hiring video editors, tournament coordinators, content moderators, map scriptors, they’re hiring whole teams and turning into this whole social enterprise to create a place where people want to come in and enjoy themselves. 00:40:47 - Speaker 2: What are some examples of folks you think are doing this well? 00:40:51 - Speaker 1: I’ll give you one, it’s kind of a niche example, but there’s this guy T90 official, he’s one of the casters for Age of Empires too, he’s probably now the biggest caster, and I think it was actually largely because of his work as initially a very small time streamer and caster to help bring this game out of obscurity. Again, it’s a very old game and at one point it had quite a modest number of players, but because he worked so hard over the course of, I think it was like 5 years to build up this community of players, of audience members, of tournament organizers, and so on, it brought a lot of vitality to the game. 00:41:27 - Speaker 2: YouTube is one that’s interesting to me as well, because there seems to be a pretty substantial number of what I call game critics, which maybe is a little bit different category than what you’re talking about, but to me it does have a similar kind of sense of not just community building, but it’s something that’s around the games, it’s not the games themselves. Right. Yeah, some critics are more just almost for fun. They do funny reviews, things like zero punctuation. or girlfriend reviews. The one that I love, who’s kind of a critic meets design school, is Mark Brown’s Game Maker’s Toolkit. I can highly recommend this series. He does these sort of like 20 minute long documentaries, sort of mini documentaries where he will take a particular game or a set of games and break down essentially design elements within it. And coming back to how this connects to muse and tools for thought and productivity tools, I’ve seen a number of things in there, including how you ramp up difficulty and how you make complex controls comprehensible, and so on that I find, if not directly applicable at a minimum inspiring for doing my own work, because, of course, games are this mix of Obviously they’re artistic, and they are entertainment, and they’re expressing something, but they also have these practical, lots of practical elements. You have this complete world that needs to all hang together, and trolls have to work well, and there’s physics, and there’s how the player learns it and all these elements. So diving in on that game design, in many cases for games that I have never played and probably never will, but it’s still very interesting to watch a 20 minute breakdown with lots of footage from the game about exactly what the design choices they made were. 00:43:10 - Speaker 1: Yeah, and in general, I think learning socially and learning via video are extremely powerful, and this is now the main way that people are learning games. Like 20 years ago, when we were playing games as kids, I think you mostly just kind of figured it out by yourself, or maybe you had some friends who could give you some pointers or maybe there were magazines back then, I guess. 00:43:32 - Speaker 2: Oh yeah, no, I remember playing Metroid. Just one of these great but essentially defined a genre in many ways, this kind of discovery oriented game, and I think the only way that my friend and I got through it is I had this issue of it was probably Nintendo Power that essentially had maps. You kind of look at it and figure out where you needed to go and that sort of thing, yeah. I don’t know if that’s cause I was just a kid that I couldn’t figure out, or maybe I would have been able to figure out if I hadn’t, but yeah, the knowledge you could get out of something like a magazine or that one kid in the neighborhood who was a really good player, it was just like gold, yeah, the fact that I don’t know what it’s like for a kid playing nowadays or the solution to anything you could find by Googling. 00:44:14 - Speaker 1: Yeah, well, I think it’s much more high powered now, because you have this high resolution video and you have a ton of it, and you have the social connectivity that makes you more incentivized, like you’re a better listener, you can find content that’s a better fit for your interest and your skill level. So people are learning how to play games much faster and much better. I haven’t seen a study on this, but I would guess. Between that social video factor and the new matchmaking capabilities, which match you online to play players of an appropriate skill level, that people actually play the same games at a much, much, much higher level now than they used to. That’s certainly my experience. Like if you look at even casual players today at some of these games, they’re actually quite good, because basically, they’ve been watching people on YouTube a lot. And as you were alluding to, I think that’s something that’s going to bleed over from the world of games. I actually say mostly seriously that games in the world of gaming predicts a lot of trends. So it goes from kind of pro games to mainstream games to consumer software to software for startups to software for enterprises. And you’ve seen that with a lot of stuff. And so therefore I predict that. In 10 years, you know, we’re gonna be basically doing our enterprise work on Discord or something like it. Actually, I kind of believe that. 00:45:28 - Speaker 2: Yeah, that makes sense to me. I think a lot of technologies, I wanna say maybe something like haptic feedback, for example, you know, tends to come first for games and gets adapted later on for more, call them practical uses. That actually reminds me of a just small tangent. We took some inspiration from a game called Batman Arkham Asylum for one of the you can switch projects. I don’t know if you remember this, but this game has something called detective mode. This is essentially a button you push that essentially changes your vision. It kind of inverts everything and lets you see things like power lines and maybe hidden entrances and the game’s very good at making you basically feel like Batman. That’s the point of it. And so having this special mode is part of that, that’s visually interesting and distinctive. We use that for when you can switch projects where you could hit a key and it was kind of like a developer inspection mode, but it would invert all the colors and it was very inspired by that game. Nice. Following up on your point about, basically people are better at games, I just finished reading an article about Tetris, which apparently, again, this is another one of these games that its code base hasn’t changed in decades, but people keep getting better at it. And partially this is because of being able to share this knowledge socially, and I can’t remember the exact details, but I think it started with no one thought you could get max score. Someone did it once, recorded it on VHS tape. That tape circulated. People could watch the tape and see how they did it. You start to have this analysis and then this analysis starts to reveal that things that were believed to be a good choice or a good strategy in the game, eventually they figure out actually are. Essentially they evolved the strategies and now these are all very standard. Someone new coming in can go watch a bunch of these YouTube videos and essentially it’s within reach of anyone that wants to put the work in to get a max score on Tetris, where once upon a time that was assumed to be unachievable. It’s a good example of how a whole, I’m not even sure what the word is for it, it’s not a field or an industry, just a community can advance the state of the art through simply sharing knowledge with each other. 00:47:34 - Speaker 1: Nice, it’s like the 4 minute mile phenomenon for speed runs and high scores. 00:47:38 - Speaker 2: Yeah, yeah. Well, in speed running, there’s a whole other door we could open, right? But yeah, without going too deep into it, just type speed run space, name of your favorite game, I don’t know, Super Mario Brothers or something in the YouTube and watch the a whole rich genre unfold in front of you. All right, so we got Discord, we got YouTube, we got Twitch. What are some other examples of social technologies that are coming out of games that perhaps we’ll see migrate their way to other parts of the software ecosystem? 00:48:10 - Speaker 1: Yeah, so those are all big foundational platforms for these communities. Let me give you an example of a smaller, more specific pattern that I see, which I think is illustrative of the type of thing that happens in these communities. So that is emojis in Twitch. Now, one view of emojis is that they’re kind of a goofy, unimportant thing. My view of emojis is that they’re actually incredibly expressive and personal and interesting. 00:48:37 - Speaker 2: I think you’ve said on the podcast before that notions embracing of signing an emoji to a page as kind of the visual indicator for you, that was the killer feature that tipped you over from Google Docs. 00:48:50 - Speaker 1: It was a big deal, yeah, I really like my emojis. And Twitch actually takes it to the next level, where again it’s open access, it’s open source. So the deal is as a Twitch streamer, you get some amount of emoji spaces for your channel, maybe it’s 15 spaces, and for each of these spaces you come up with a little keyword that corresponds to the emoji, and you upload your little graphic for that emoji. And then typically the way that it works is that anyone can use some subset of the emojis, and then people who are basically patrons of the channel at increasing levels can use some of the rare and elite emojis on that channel. And this thing is fascinating because, again, these are all kind of unique flowers of ecosystems and So you get their own like language and memes all encapsulated into these, into these tiny little emojis. And so you have whole discussions that happen over these emojis that are unique to the channel. And it’s actually a fairly big motivation to be able to access the rare and elite emojis for a given channel. But the most interesting thing to my mind is that these aren’t silos, they’re networks of communities and. And while the emojis are specific to a given streamer, it might be prefixed by like Mark Smiley, and then whatever my unique smiley emoji is, shows up. You can use that emoji if you have access to it anywhere on the platform. So what happens is, say you get a channel around a specific game and it’s for streamer A, but streamer B is also A member of that game community, and his folks come into the channel and they start using streamer B’s emojis. And that way the emojis and therefore the streamer spreads virally. So you see, oh yeah, that’s a cool emoji. So you hover over it and it says, oh, streamer B, and then you go follow them on to their stream. And so it’s incredibly like networked, social, dynamic, fun, very Vibrant thing. And then economically, like this is a whole economy. There are like full time Twitch emoji artists, that’s all they do. And they accept commissions, and you have the entry level Twitch artists and the like elite Twitch artists who charge a lot for their emojis. You know, it’s the whole thing. So, again, I think it’s an example of something that seems very small, but it’s actually very big socially and economically. 00:51:01 - Speaker 2: ties together a lot of things. There’s the unique economic model, as you’ve said, there’s the social technology side of things and some of these things that are only possible in software sort of internet era media, some of the virality and of course emojis themselves are very internet or computer age form of communication and so all of those together make for something. Well, let’s say it’s the sort of thing that would have been hard to imagine. Even 20 years ago, let alone further back than that, but this is how internet culture is evolving and something that, as you said at the beginning, games are on the forefront. 00:51:41 - Speaker 1: Yeah, and I do think we’re gonna see it transition over into the world of enterprise and productivity software. Like you have a notion, there’s a fixed set of emojis that you can use and Slack, there’s emojis and they’re a pretty big part of the product. You can even customize some of your emoji set for your enterprise, right? But again, it’s very siloed and you don’t really have a lot of control as a user. I think you need to be like an administrator it’s like upload emojis or whatever. I can imagine a world, in fact, I expect a world where eventually products like Notion or Slack or whatever supersedes them, adopt more of this model of open networked emojis. 00:52:14 - Speaker 2: Nice. Well, before we wrap up, I bet folks would like to know what’s an example of your favorite games. 00:52:21 - Speaker 1: I got 2. So the first I’ll give is in the classic boxed genre, and that’s missed. I still have very fond memories of playing this game, and I think for a long time it was the best selling video game ever for quite a while, and actually I replayed it not too long ago, some years ago, and it’s still great, so got to give that a spot. And then for the more modern pro style or social style game, I would go with Age of Empires 2, which is a total classic and what I’m still a big fan of. 00:52:50 - Speaker 2: And if I’m not mistaken, a nice little bit of background on missed, I think it was built in Hypercard originally. 00:52:57 - Speaker 2: Oh wow, yeah, it ties us back to the end user programming, right, again, something that may be a specific game and a very influential game for a lot of people, and even maybe kind of a genre that wouldn’t exist if it wasn’t for this kind of more accessible programming tool. 00:53:13 - Speaker 1: Yeah, and I feel like that also might be an example of driving consumer hardware, because if I remember correctly, that was one of the first things that used a CD because it was kind of unique in having all this graphics content, and so you needed at least a CD to fit it. You couldn’t put it on floppy disk, which is how you used to get games, and so people were like, well, I better get a C drive cause I want to be able to play MT. 00:53:33 - Speaker 2: That’s right, that’s right, yeah, I remember that now. For me, I could name so many, going back to my childhood, arcade games like Strider, for a while, I was into Angban, which is one of these roguelikes that, you know, sucks up a crazy amount of time, but in more recent times, where I’ve really been enjoying a lot of these indie games, I think I mentioned Baba as you earlier, the doll name is a favorite here, Papers Please by Lucas Pope. So this is a game where you are working as a border agent, and your job is to check people’s passports, and that’s the whole game. Yeah, they present their documentation, you look it over, and you stamp it either proved or denied. And to me it’s just a great example of how games are such a unique medium for artistic expression, so in the same way that a film or a book can transport you to this other world, show you a new perspective, maybe that you had not encountered before, but something where you are making choices actively, which obviously is what games are about, can actually show you something different. You can express something different artistically and without spoiling too much, the nature of this game is you start out just kind of like stamping these passports and deciding who to let through the border, it seems very prosaic and kind of boring, but very quickly it turns into something where you’re approached by members of resistance or someone comes through and says, please, my mother is dying. And yes, my passport expired two days ago, but can’t you just let me through so I can go see her and someone who’s smuggling, you know, some kind of contraband, but they offer to slip you a little money and as it turns out, you also have to pay the bills for your family and your child needs medicine and so on, and pretty soon you get all these complex moral choices. That are very powerful, and you can see how you get, depending on the choices you made, you, for example, can easily go down this path of corruption, but you see how you got there through active choices you were making. So it’s a really, really impressive indie game, and also just a lot of fun. And in general, I can recommend everything by Lucas Pope, his newer one is Return of the Oberin, and he just has a unique style and every game expresses some unique take on the world. Well, let’s wrap it there. Thanks everyone for listening. If you have feedback, write us on Twitter at museAppHQ or via email, hello and museapp.com. You can help us out by leaving a review on Apple Podcasts, and Mark, we’ve been having fun with some collaborative games in our recent team summits. I think I’ve got a new one for next time, so it be interesting to dive into the game with the team with everything we talked about here on our minds. 00:56:09 - Speaker 1: Nice, I look forward to that, Adam. 00:56:11 - Speaker 2: right, till next time, Mark. See you.
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: I can really empathize with it because even in my own sort of maths degree, I really struggled with terminology and notation. And I think a big problem in kind of maths education generally is that there’s a lot of focus on notation and terminology, and you kind of miss the forest for the trees. 00:00:25 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for thought on iPad. This podcast isn’t about Muse the product, it’s about Muse the company and the small team behind it. I’m Adam Wiggins, joined today by my colleague Mark McGranaghan. 00:00:39 - Speaker 2: Hey, Adam, and our guest Tamir Abdul of Kazul. 00:00:43 - Speaker 1: Hey guys, how’s it going? 00:00:44 - Speaker 2: And tamer, I understand you’re enjoying London Springs so far. 00:00:48 - Speaker 1: Yeah, I actually went outdoors for the first time in, I don’t know, 6 months or something. Yeah, I I’d forgotten just how nice it is to sit on the grass in the sun, just chatting with friends about nothing in particular. Yeah, it was amazing. What an experience. 00:01:03 - Speaker 2: Yeah, the ability to go out and enjoy, we’ve had sort of triple threat here in my household because we’ve had one, the lockdown, which has been pretty severe, of course, for the last 6 months or so. 2, we had a pretty serious winter. In fact, it was snowing today, and 3, I’ve got a, a young child at home, so all of those things mean that I basically barely leave the house. Happily I do have a dog, so I have to go out for walks on that. If it wasn’t for that, I would never see the outside, I think. Yeah, that’s pretty rough. Well, Tamara, maybe you can tell our audience a little bit about your background, including your podcast and the product you’re working on now. 00:01:41 - Speaker 1: Awesome. So I’m Taymor. I’m one of the co-founders of a company called Causal. We’re building a spreadsheet just for number crunching. So anything involving numbers, we want causal to be the way to do that. On the side, I have a podcast with my brother where we just catch up once a week and chat about whatever’s on our mind. And my background is mostly in maths, so I studied maths at university, and specialized in statistics and machine learning and that kind of stuff. 00:02:06 - Speaker 2: And what sorts of things do people use your product for? Is this a total replacement for a spreadsheet or just a subset of that? 00:02:13 - Speaker 1: Yeah, so it’s really just a subset of that. We can sort of think of spreadsheets as something like causal, our products, plus something like Air Table. So Air Table is kind of taking Over all the non-numerical stuff you might do in a spreadsheet. So making lists of things, managing processes, you know, internal tools and that kind of stuff. And we want causal to be used for anything involving numbers. So any time you need to sort of write formulas that do calculations or visualize data, that kind of stuff is really what causal is about. 00:02:42 - Speaker 2: And I certainly think that one of the main uses for spreadsheets for me in my business life, I guess, as well as helping others, is this modeling, often financial modeling, where you’re just trying to understand, cause of course, money is the lifeblood of a business, but how you earn money because that proves you’re providing value to people, as well as just not running out the money in the bank so that your business doesn’t die, and spreadsheets as a what if tool to understand. Both what might happen in the future, but in many cases it’s just the viability of your business model. One example I remember is I had a friend who was starting a retro kind of 1980s arcade, and they really wanted to run the games off of quarters, because that gives that authentic 80s feel, and then I’m saying, well, OK, but if you look at the inflation since the 1980s, a quarter isn’t what it used to be. This is a US dollar quarter, of course. So we actually modeled all that out and plugged in a bunch of what if values and basically figured out that under no reasonable, we’re just taking guesstimates for how many games an hour someone’s gonna play, how long they’re going to spend in the arcade, that sort of thing, but basically nothing we modeled showed that it would be viable to stay in business with all the costs. And eventually did settle on a model which was more like a flat rate, you pay $10 or $12 or something when you come in the front door, which ends up both feeling maybe more fair, more fun for the patrons, but also is actually viable. And I think it’s maybe an example of where having ranges, which we were talking about a little bit earlier, where necessarily know what exactly each patron is going to spend on drinks or quarters they’re going to put in or how many games they’re going to play an hour or whatever, but you can plug in reasonable ranges and from that you can infer maybe it ends up being like a Drake’s equation kind of thing in that scenario where you can figure out what’s viable and what isn’t. 00:04:28 - Speaker 1: Yeah, I think this idea of ranges is really powerful. And I sort of, personally, whenever I’m giving an estimate for something, I get really anxious that my estimate is gonna be wrong. And it just gives me a lot of comfort in providing a range, because then I, I know that it’s probably right, rather than sort of precisely wrong. And so I find that even when just sort of communicating day to day, if someone asks me for an estimate of something, if I give a single number, then for the next 5 minutes, I’ll be like, thinking through it in my head of like, Oh, maybe that was wrong. Whereas if I I had a range, like, yeah, I think it’s between 5 and 10, then I sort of have the peace of mind of knowing that I haven’t sort of been too inaccurate, I guess. 00:05:06 - Speaker 2: And I think that’s also a way to train yourself to give estimates. I’ve run into this with a lot of folks who, exactly as you said, don’t feel comfortable giving an estimate because they feel like, well, I don’t know, but you can always kind of start with, OK, you know, can you guess the price of product X in a supermarket, or can you Guess the weight of this and maybe you can’t do that or you feel like you don’t, but you can come up with a number that is so low that it’s clearly outside the bottom of the range. You come up with another number that’s clearly so high it’s outside of the top of the range. All right, so now you’re working on it. Now let’s narrow this window in. 00:05:40 - Speaker 1: Yeah, that’s one of my favorite tactics is a strong word, but one of my favorite things is, if I’m like talking to a friend, and, yeah, exactly like you described, I think if you ask someone to try and quantify something that they’re not used to quantifying, then they’ll probably just say, Oh, I don’t know, I, I could possibly put a number on that. But then if you ask them, Well, is it more than 10? Is it less than 500, you know, you can actually get to a pretty good range. And it is actually helpful to know that range, rather than just put your hands up and say that it’s unquantifiable. 00:06:08 - Speaker 2: Yeah. Well, maybe that brings us to our topic for today, which is thinking and probabilities, and I thought it was really interesting that you mentioned this as kind of a founding idea for you and then maybe in some ways you moved away from it in the product or maybe just in the marketing. But tell us what it means to think in probabilities. 00:06:28 - Speaker 1: Yeah, absolutely. So the sort of origin story for causal, it kind of comes from some work I did as a data scientist in a previous job. I was working for a property tech company where, essentially, the company was placing big bets on houses. And so, in typical fashion, we had a bunch of spreadsheet financial models that would forecast the company’s cash flow, and some pretty big decisions were made on the back of these models, like how many deals can we do every month, how many people can we hire, so on. And one of the really important things for this company was understanding the risk that we were taking on in each deal. If we were placing a big bet on a house, the house might be worth a lot more than what we thought it’d be worth, or it might be worth a lot less. And actually understanding how those would affect our bottom line was really important. And, you know, in spreadsheets, Google Sheets, in this instance, we had to do a bunch of work around. and hacks to try and get at this idea of essentially a probability distribution for how much a house would be worth. And there’s various kinds of ways to try and approximate that in a spreadsheet. But essentially, trying to sort of get at this idea of probability added so much complexity to these spreadsheets that they became unmaintainable. No one really understood how they worked. It was very hard to actually iterate on them. And so that was kind of my first exposure to this problem of how do you crunch numbers when some of them are uncertain? How do you build probabilistic models to try and understand the world? And our starting point for causal, and, and sort of our original mission was kind of to bring probability to the masses, to build a tool that makes it so easy to work with probability and uncertainty and so on, that it becomes sort of the standard way that people sort of think numerically. Does that kind of make sense? 00:07:59 - Speaker 2: Yeah, to me it leads into the question of how much is it a tools gap that the average intelligent educated, let’s say knowledge worker that has a reason to want to be able to think in probabilities or model uncertainty numerically, how much is it that the tools make it tricky like you described with spreadsheets, and how much is it more a matter of It’s very hard for humans to think this way, even intelligent, educated people, it doesn’t come naturally unless you’ve studied math or made this your career or your passion in life that you’ve sort of struggled to apply this approach. 00:08:39 - Speaker 1: Yeah, absolutely. I think it’s a really good question and it’s hard to know which side leads to which. An example that I often think of is this idea of having a line of best fit for some data set. It’s quite common, even sort of newspapers, magazines, to see like a 2D chart with a bunch of data points, and there’s some kind of straight line drawn through these data points to kind of extrapolate some kind of trend and tell some kind of story. And if we think about what does that actually mean? I think most people, if they look at a graph like that, they will understand immediately what the graph is trying to say. The graph will typically be trying to say that as this one thing increases, this other thing increases as well, or as this one thing increases, this other thing decreases, without a particularly maths-y background, you can read a chart like that and you understand what’s going on. I think the really cool thing about the line of best fits that is now just sort of super common and everyone gets it. Is that very few people, unless you’ve sort of studied maths or maybe computer science, very few people will be able to tell you how you’d arrive in that line of best fit. And the best part is, they don’t need to be able to tell you that. They don’t need to know that behind the scenes, you have to invert a matrix in order to, like, figure out this line or anything like that. And I think in that sense, just visualizing something in the right way is kind of a powerful tool to unlock intuition that we already had. And so, in the example of line of best fit, I, I can describe to you some effects, like, As you get closer to the center of London, property prices go up. You know, I can describe that to you. You understand what that means in your head. And if I showed that to you on a chart, you’d immediately kind of get what I’m trying to communicate. And so, I think the probability stuff might be similar, where so far, we haven’t had the line of best fit moment for probability. We haven’t found the sort of killer tool or killer sort of visualization that anyone can sort of look at and understand. I do think probability is just really unintuitive in general as well. But again, it’s hard to say whether it’s unintuitive because we haven’t had some really basic tools like just being able to visualize it, or whether it’s sort of inherently unintuitive for humans. So I studied a lot of probability and statistics in my degree. And so, after graduating, I kind of felt like I had a good handle on this stuff. But it was after actually facing a lot of these problems involving how do you account for uncertainty in models and things like that. I kind of realized that studying the theory of probability and, you know, being able to prove certain theorems and things like that is actually almost a completely separate task from having the right intuition about these things. And so, I think there’s a really common example that Naseem Taleb is a big fan of, which is that you wouldn’t want to cross a river that is 4 ft deep on average. And, yeah, obviously, if it’s 4 ft deep on average, it might be 8 ft deep in one particular part and you might drown. And so I think he often talks about the dangers of working with averages. I think another kind of Illustrative example, sort of to do with a buffet. If you imagine, you know, you’re putting together a buffet and there’s 10 dishes in the buffet, and each dish takes on average, about an hour to prepare, and the whole buffet is ready once all 10 dishes are ready. So each dish has an average time of 1 hour. And if you were trying to think about, you know, what is the average time for the whole buffet to be ready, it’s tempting to think that. 00:11:50 - Speaker 2: Each dish is ready in an hour on average, and so the whole buffet will be ready in 1 hour on average, but the two, the two answers you would jump to to there is either 10 hours because it’s sequential, or 1 hour because it’s all parallel. 00:11:57 - Speaker 1: Yeah, exactly. So actually, even in the parallel case, it turns out that the average time for the buffet to be ready is actually a lot more than 1 hour and. This is sort of like the most basic example of where average outcomes don’t always come from sort of average inputs, essentially. But I think even after studying statistics at a university level, that would be the kind of thing that I wouldn’t immediately spot. And now having sort of spent a lot of time thinking about this and kind of building a product around this concept of probability. Any time I hear the word average, an alarm bell basically goes off in my head as to like, OK, what are like the sort of 3 or 4 different traps I can fall into when thinking about this problem through the lens of averages. 00:12:37 - Speaker 3: Yeah, I agree. I tend to think there are two big hurdles people have to overcome. The first is recognizing that you’re in a probabilistic situation, which is almost all the time that you can’t use a point estimate, you can’t use an average, you need to understand the distributions and the samplings. And the second is, what is the correct formula basically to use or how exactly do you mathematically navigate this probabilistic situation? And in my experience, most people miss the first step. They go to a point estimate and then it’s already over before it started, you’re not even wrong, right? You’re in flat land. Your answer has the wrong shape. And so I think there’s a lot of value in having tools that Help you navigate the mathematics once you’re over the first step, but perhaps even more so, tools, stories, experiences, histories that help people be more likely to raise the probabilistic flag, like warning, we’re entering probabilistic territory, that alarm bell should be going off almost all the time. And so I’m very interested in things that will help people get more acclimated to that idea. 00:13:38 - Speaker 1: Yeah, absolutely. I think one sort of common-ish thing people do with spreadsheets is that, you know, if you do want to understand the uncertainty of whatever you’re trying to model, you know, some people might have 3 different scenarios, like a best case scenario and a worst case scenario, and like a sort of average case scenario. Yeah. And then you’d kind of run your whole model for the best case and the worst case and average case. And then you have these sort of 3 estimates for like, OK, this is what my outcomes could be. So some people do make an effort to do that in some settings. And it’s a step in the right direction, but actually, under the hood, the maths doesn’t really work out there, right? You know, back to our buffet, we have these 10 dishes, which we can prepare in parallel, so we can do them all at the same time. If we said that, OK, on average, each dish takes 1 hour to prepare, and in the worst case, it takes an hour and a half, and in the best case, it takes half an hour. If you were then trying to figure out what is the total time for the buffet, you might be able to get some kind of range based on sort of assuming they all hit the best case scenario, and that would be like the best case scenario for the buffet, and then assuming they all hit the worst case scenario, and that would be the worst case scenario for the buffet. But the math doesn’t quite work out there. And it’s mostly because our definition for best case and worst case changes from the start to the finish. So, by best case scenario for a single dish, in our heads, we probably don’t mean the absolute best case scenario. We probably mean that like, this is, uh, 95% of the time it’ll be slower than this or quicker than this or whatever. And same for the worst case, you know, the worst case scenario is the dish doesn’t get ready for 3 years or something, right? And so you don’t actually think about the best case. And the worst case, you are thinking about this sort of plausible range. But the issue is when you start to think about this plausible range, and you’re doing this lots of times, so we’re doing this 10 times in this case, because we have 10 dishes, the equivalent plausible range for the total buffet. It is not when every dish hits the bottom of the range or every dish hits the top of the range, because every dish hitting the top of the range or the bottom of the range is actually extremely unlikely. It’s like very implausible. 00:15:42 - Speaker 2: I think that scenario you just described is how engineers estimate their time in a sprint, which is that every single thing they’re going to implement is going to be the best possible scenario. 00:15:54 - Speaker 1: Yeah, absolutely. Yeah, I think this is why it’s so hard to plan projects, because if you just do it on the basis of averages, then, you know, there’s a decent chance at least one of your tasks is not going to be delivered on time. And if you do want to get some kind of bounds on, like, best case and worst case scenario, if you have like 10 tasks or whatever, you can’t actually just take the best case for each and sum them up, or take the worst case for each and sum them up. And so the only sort of rigorous way to do this is by running lots and lots of simulations for possible scenarios that could happen. And so, you know, in one simulation of the buffet, you know, 3 dishes might take less than an hour, and 7 dishes might take more than 1 hour or something. And another simulation, they could all take less than an hour, and so on. And if you ran a few 1000 simulations, you could get an idea of, like, you know, 95% of the time, how long does the buffet take. And so, actually running these simulations is actually the only general and rigorous way to understand the range of possible outcomes for your buffet. Does that kind of make sense? 00:16:51 - Speaker 2: And what you’re talking about here is a Monte Carlo simulation, is that right? 00:16:55 - Speaker 1: Exactly, yeah, yeah. So in maths, this would be called a Monte Carlo simulation. And actually, you know, running thousands of Monte Carlo simulations for a basic calculation that you might be doing, it’s usually pretty tricky. The only way to really do it is to write, you know, a script that can loop through some calculation 10,000 times and then show you, you know, 95% of the time your buffet takes between this time and this time. And a big part of what we’re trying to do with causal is sort of abstract away all of this stuff around simulation and probability distributions, and let people just say, Hey, you know, each of my dishes takes between 45 and 90 minutes to cook. And now, can you just tell me, like, what is the equivalent range for the total buffet? 00:17:39 - Speaker 2: Yeah, I can see how simulation does cover it, but there is something fun about the Monte Carlo name a little bit, and when I first learned about that, I don’t, unlike, I think both of you, I don’t have any kind of solid educational background in mathematics, but I later learned about it when I was kind of digging into the data science world of things, particularly with working with the R programming language, and they had essentially some exercises that involved doing these simulations, some very visual ones that I quite liked where essentially Allowed you, they said, OK, you can calculate the area of a circle with the formula, or you can run a simulation where you essentially, you know, draw a circle on the wall and then throw darts that land in random XY locations and if you do that 1000 times and count how many darts are on the inside of the circle and how many on the outside of the circle, you can close in on the value of pi, essentially, which I found somehow very amusing and fun way of going about things. 00:18:35 - Speaker 1: I love that example. Yeah, I think simulation is a surprisingly powerful tool where if you can reframe any problem as almost like a probability question where you can run simulations, it’s surprisingly generally applicable. And so in the example you gave, you’re sort of reframing the question of the area of the circle in terms of. The probability of a dart landing in the circle versus outside the circle, and as soon as you reframe it in terms of probabilities, then you can just like run a bunch of simulations, and it takes a while, but you don’t have to be particularly smart about it. I think most complex problems in maths, they’re often intractable. You know, it’s very hard to express them as a clean equation that you have to solve. And even if you can express it as a clean equation, there’s often no general way to solve this equation. And so reframing things in terms of like, how can we just do this really dumb thing a million times to get like a really good approximation to the answer is surprisingly generally applicable. 00:19:28 - Speaker 3: Yeah, very powerful technique and especially useful for situations where you have multiple steps or branches, even just a few of those, they can be very simple to describe in human terms, if this then that some chance and so forth, but Once you have any complexity and situation, it often becomes impossible to get a so-called closed form solution, which is what you were alluding to where you have basically some formula you can write down, you plug in numbers and you get the result. Mathematicians always like such closed form solutions to the point where I think initially they kind of pooh poohed the Monte Carlo world, but I think now it’s shown its power and folks are more open to the numerical approaches. The study of probability is so interesting because it pops up in so many domains. Once you know to be looking for probabilistic situations, you see them everywhere. I can give two examples from my experience. The first was in college, I worked on this thing called RoboCup. RoboCup is where you have toy robotic dogs play soccer. And these are dogs that can do basic seeing, and then you use video processing algorithms to extract information and you program the dogs to play soccer autonomously on this sort of toy soccer field. And anyways, one of the big advantages that our team had was the ability for the dogs to locate themselves on the field, which is, as you can imagine, is a sort of fundamental thing for programming dogs to play soccer. And the reason that this was so hard was because these are like really bad cameras basically so you’re getting really choppy visual information. Really the only way to deal with that is probabilistically, because the data that’s coming in is so noisy, you can’t do anything on it if this and that basis. You basically have to say, OK, given all of these observations I’m making about the different landmarks I know about on the field, what is probabilistically the most likely location for me to be in? And furthermore, what is my sort of probability cloud of where I plausibly am on the field, and if I have enough certainty about this probability cloud, then I can undertake certain actions like kick the ball towards the goal and so on. And then to give a very different example in the world of engineering management, I think it’s very fundamental to understand that engineering is a risky endeavor, especially when you’re like developing new products. This is the area where I think a lot of people think too deterministically. So one example that I like to give is, imagine you have a multi-step software development process you need to do A and B and C, and this is actually kind of similar to the buffet example. Each one takes an engineer, one unit of work, and an engineer can do 1 unit of work at any given time. Now you might think you should just assign one engineer to A, one engineer to B, and one engineer C. and in a totally deterministic world, that works perfectly. The gears, they all mesh everything turns in unison, it’s perfect, but you have to recognize that there’s inherent variability in how long these tasks take. And so what can happen is if you’re running the entire team at So-called maximum capacity, then if anyone experiences a task that’s slightly harder than you anticipated, you basically grind the gears for the entire thing because A is holding up B is holding up C, and then you go from this world of everyone is fully optimally working to everyone is basically stuck waiting for someone else and everything is kind of ground. up. And that’s where this idea of slack comes from, where if you’re in a situation where you have uncertainty about how long things are going to take and you have dependencies, counterintuitively, the correct thing to do is to spend some of your time twiddling your thumbs, basically. Because if you try to be doing stuff all the time, you’re inevitably going to be getting in the situation where you’re grinding the gears out. 00:22:50 - Speaker 2: And I think there by Slack you’re referring to the concept of slack, not the product, and perhaps there is a book that was influential to me, recommended by one of our mutual colleagues at Hiroku, that’s essentially a management book that’s titled Slack and makes that very argument. It’s sort of a. theory thing a little bit and there’s some things about creativity as well, but ultimately, even if you just want to think of everyone on the team as being a worker automaton that needs to provide end units of productivity, it actually turns out you have a more efficient system when there’s space in the system, there’s slack in the system. 00:23:25 - Speaker 3: Yeah, and along these lines for people who enjoy thinking in probabilistic terms, I would also highly recommend principles of product development flow. This is basically a mathematical cutheoretic treatment of product development, and when I first heard that, I’m like, how can you possibly write interesting equations about product development, but if you just approach it with this lens of probability or alternatively risk, all kinds of interesting things fall out. So for folks who have a mathematical inclination, I suggest that book. 00:23:54 - Speaker 2: Hm. Yeah, I guess a risk and probability the same thing in what we’re talking about here? It seems like one is sort of just like the inverse of the other, at least in my kind of layperson’s understanding, but I don’t know if that’s correct. 00:24:07 - Speaker 3: Yeah, that’s my intuition. So you could think of risk in engineering delivery time means that there’s a probability distribution. And in fact, it’s probably long-tailed, where there’s some chance it goes on time, there’s, uh, frankly small chance it happens before you expect it to happen. And then there’s the real possibility it takes 23 times as long, it never gets done, right? That’s what I mean by risk and Similarly, there’s probability distribution around how customers are likely to value or not a given feature, and that’s another thing that’s important to consider. So you can’t say customers are definitely like that. And in fact, there’s some chance they like it, some chance they don’t like it, some chance they really like it. And in the same way that you need to correctly consider distributions when you’re planning your buffet preparation, you need to consider these distributions when you’re doing product development. 00:24:50 - Speaker 1: Yeah, I think just to add to that, when I think about sort of risk and probability and kind of how are these concepts related, I think risk also kind of captures, I guess, kind of the magnitude of what could result from something. So, for example, if you knew that there was a 1% chance that you’d die by driving a car, yeah, that would be a much higher risk than if there was a 20% chance of getting wet, you know, from walking outside. So I think risk also sort of captures the actual impact of some low probability event. Right. 00:25:19 - Speaker 2: Yeah, there’s some good discussion of this, the 80,000 hours group which I follow, they spend a lot of time talking about these kind of tail risk events, pandemics, which they were big on before we had one that captured the Western consciousness. But also things like meteor strikes and other events that obviously things that are climate related and in many cases it is an acknowledgement of, yeah, the chance of this happening, the probability of this happening is small, but maybe this is sort of the expected value of something is the likelihood of it happening times the result. And so if the result is this huge, huge event like a species ending extinction event, even a very small chance of it is something that maybe it’s worth investing some resources protecting against. 00:26:04 - Speaker 3: Yeah, this is an area where even if you do take that first jump of thinking probabilistically, you can still fall short, in particular, if the cases that end up mattering in the expected value calculation are outside of the intuitive probable range. So you can think of things like meteor strikes and nuclear war and so on, but one that’s very familiar to us, Adam, is earthquakes in. So the chance of a very serious earthquake in California is on the order of 1 every 100 years. So if you just take that, you know, it’s basically outside the 95% confidence interval. So we could say, if we weren’t being too careful that basically we’re not going to have an earthquake, don’t worry about it. But in fact, the expected damage from such an earthquake is enormous. So therefore, any year the EV on earthquakes in California is actually non-trivial and therefore you should do some amount of preparation. 00:26:49 - Speaker 2: That also highlights another challenge or fallacy or just a way that this whole thing is nonintuitive for the way that humans think, which is you often hear folks in California speaking in terms of quote unquote, we’re due for a big one because you hear that we talk about it that way, we should. one every 100 years and that actually masks or does not correctly capture the probability that we’re trying to express. And so people convert that to more of a cyclical time thing like that we expect the sun to rise once a day. In fact, that is not at all what it is. So working on casual and working with your users and customers who of course are again smart people educated, need to think in terms of probabilities or risks for their work and yet maybe don’t have the same mathematics background that both of you have. I mean, there’s countless, I don’t know, well known fallacies, I don’t know, expecting a string of coin flips to have fewer. Long runs of heads and tails, for example, than it does in actuality. But what are some of the things where either one you see folks have their intuition not matching what reality is, and then two, what are some things you found in the product or maybe it’s even more of a almost like a marketing thing, and explaining thing to help folks bridge that gap without necessarily getting the mathematics degree. 00:28:09 - Speaker 1: Yeah, for sure. Yeah, I think we’ve had a ton of learnings on the more sort of marketing and positioning side of this kind of product. In the very early days, you know, our mission was to really focus on this probability stuff. And so when we, you know, on our landing page, we would literally describe causal as a probabilistic modeling tool. That means something to us. But I think what we didn’t realize is that for people without a maths background, words like probabilistic and words like Monte Carlo simulation, They’re just quite scary. I, I initially found this a little bit frustrating because, you know, the term probabilistic model to me, it means like a very specific thing and it was really hard to try and describe this concept to folks with less mathematical backgrounds. But actually, I can really empathize with it because even in my own sort of maths degree. I really struggled with terminology and notation and things like that. And I think a big problem in kind of maths education generally is that there’s a lot of focus on notation and terminology, and you kind of miss the forest for the trees. And so, you know, even when I was in my 2nd or 3rd year of university. Anytime I would see a capital sigma, you know, the big sort of sum symbol, which is basically everywhere in every branch of maths, you’re going to be summing things up. Any time I’d see like the sum of like some expression, I’d immediately think, oh man, this is so hard. This looks really complicated. There’s all these symbols going on. And so I’ve definitely felt that pain of. Being intimidated by terminology and notation. And I think that was part of the problem initially when we were using words like probabilistic, when we were using words like Monte Carlo, you know, it took me sort of, yeah, I’d say, in my 4th year of my maths degree, I didn’t have notation anxiety anymore. But it took me a long time to get over that. And I think a lot of people who didn’t like maths in school or feel like they were bad at maths, I think a lot of it just comes down to notation. You know, once you’re introduced to algebra, you start seeing all these symbols like X and Y and so on. And it takes a while to get comfortable with that. And it’s easy to fall into the trap of thinking, Oh man, I find the notation confusing. Therefore, I am bad at maths. Therefore, you know, I shouldn’t tell you this thing. But I think getting past the language, getting past the notation is actually a big hurdle. And so, for causal specifically, you know, it took us a few months to figure this out, but we stopped using words like probabilistic. We stopped. Using words like Monte Carlo. I think generally, people understand the idea of uncertainty. And so, in terms of how we position, I guess, the probabilistic aspect of causal, is that we usually describe it in terms of, you know, hey, if you’re uncertain about a particular number, so writing a single number, you can say, Hey, I think it’s between 3 and 5, or I think it’s between 5 and 10. And people, you know, pretty intuitively understand ranges. They can probably come up with a range for. Any quantity in their day to day life that they might want to model. And saying, like, I think something is between 5 and 10 doesn’t require any sort of technical knowledge, it’s sort of pure intuition. And so, in causal, people just need to apply their intuition at the point where they can do it well. So at the point where they can estimate a range for a particular quantity, where the intuition breaks down is, you know, you now have this model with a bunch of formulas, a bunch of calculations, where you’re taking all of these 5 to 10s and 10 to 20s. and so on, and combining them in some weird way to get a final result, that’s where intuition really breaks down. It’s actually very hard to punch those numbers in your head. And that’s where Corle handles it for you. It runs, you know, 10,000 simulations, and then just shows you the sort of 10 to 20 results, rather than you having to worry about that side of things. So I think, yeah, lots of learnings on the sort of positioning and kind of the marketing side of things. In terms of actually getting people to think more probabilistically. I think most of the folks that use causal previously used spreadsheets and if you’ve had to build a financial model in the spreadsheets, you’re probably somewhat familiar with the idea of best case and worst case scenarios, but I think most people just don’t do them because it’s just very fitly, it requires a bunch of formulas and things like that. And so. Actually, getting people to start thinking in terms of ranges has been pretty easy because people have wanted to do that anyway. It’s just so much of a pain to set that up in a spreadsheet that they haven’t ended up doing it. And so being able to just write in an expression, like 5 to 10 in causal comes very naturally to people, and they do tend to do that quite a lot because causal handles the complexity of all of that. 00:32:16 - Speaker 2: In terms of the output, they see, you mentioned just seeing, you put in a range or a series of ranges, and you get out a single range, but there’s also maybe you found ways to represent that visually in plots or Yeah, so representing it visually is trickier. 00:32:28 - Speaker 1: I mean, so cos all under the hood, you know, running all these simulations and so. It has a lot more information than just the range of your possible outcome. It also has the sort of precise distribution of your possible outcome. And you know, the range might be 5 to 10, but it might be more likely to be closer to 10 than closer to 5, and so on, where it might have this sort of bimodal thing where it’s really likely to be close to 5 or 10, but not likely to be anywhere in the middle. And so there’s lots of different distribution shapes that might underlie a range, like 5 to 10. We found that. Most folks don’t have too much familiarity with reading probability distribution charts. It is a featuring causal. You can actually see it, like a bell curve if it happens to be like that, or other equivalent charts. Most people aren’t too familiar with those, and so most people don’t end up using them. What people are fairly familiar with is sort of like fan charts. So if you’re projecting something over time, you know, you might have like a single line or something. And then instead of a single line, you might have like a sort of fanning out range where there’s kind of visible upper bound to this range and invisible lower bound. And most people really intuitively understand what a fan chart looks like. And so those are really common, but unfortunately, it does kind of hide the underlying distribution, and we haven’t yet figured out a really intuitive way to show people the actual distribution in a way that they’ll understand. 00:33:44 - Speaker 3: I do feel like those fan charts, which now I know the name for, that’s useful, are perhaps the closest thing we have to the line through a dots in terms of comprehensibility and universality. I’ve seen those a lot in the financial domain where you have a balance or a bankroll or similar investment balance and you run a 100 simulations, and you can kind of get a sense of the probability distribution if you have the right amount of lines in your fan chart because you see that there’s kind of more lines in the middle and fewer lines. And the scraggly edges, not perfect, but it’s pretty intuitive. I also like those because they do show the dynamism. So if you’re looking at a bankroll, for example, you see that some of these lines, they really dip close to zero and some go way up but then come back down and a lot of them just kind of chunk along, so you get some sense for the randomness. 00:34:28 - Speaker 1: Yeah, we’ve had to put a lot of thought into how much detail we want to show in these kinds of visualizations. So when it comes to fan charts, for example, causal does have all 10,000 of their simulations, and we could draw on, you know, each of those 10,000, maybe with like a sort of 1% opacity or something. And so then you can actually get an idea of the distribution. But it just adds a lot more complexity to the visualization. And so we’ve had to sort of try and find the balance between sort of complexity and comprehensibility, where if we try and be super rigorous and show every single simulation on the charts, chances are most people will look at it, get a bit confused, and not be able to make any sense of it. Whereas if we kind of show the sort of 90% range or the 95% range, it’s much more understandable. And at least People will have an idea of a range of possible outcomes, and then maybe if they want, they can kind of double click and zoom into the distribution itself. But it is very challenging to actually visually represent uncertainty. There’s a few research departments and a few universities that are doing a lot of work into figuring out the best ways to visually represent uncertainty. But, yeah, it’s all about the balance between sort of complexity and comprehensibility. 00:35:35 - Speaker 3: Now we’ve talked mostly about modeling in the sense of going forward, so you were about to begin preparation of the buffet, what should you expect in terms of the completion times approximately one hour from now. I also think there’s this very interesting world of probability, which is basically going backwards. You’ve observed that everything completed in 1 hour and 15 minutes. What does that mean about the underlying tendency for us to complete individual sections of the buffet? And there are all kinds of other examples that we could talk about. I’m curious if you see those sort of use cases in causal or if you have other thoughts on that space. 00:36:07 - Speaker 1: We definitely see less of those use cases. The one time it does come up is if you have a bunch of historical data about a particular quantity, maybe you have a bunch of historical exchange rates between the dollar and US start or something. If you then want to kind of use that exchange rate to project something forwards, it is helpful to kind of look at, you know, what has been the distribution of this exchange rate historically. And then let’s just assume it’ll probably have a similar distribution going forwards. And so, in that way, instead of just sort of plucking a range out of thin air of like, oh, I think the exchange rates between 0.9 and 0.99 or something like that, you can actually infer the distribution from historical data. And that is a feature that we do have, where if you have a A bunch of historical data for something, we can sort of try and fit an empirical probability distribution, is what it would technically be called, onto that, so that you don’t have to put your finger in the air and come up with a range. We see a lot less of that, and the more useful thing does seem to be being able to apply ranges based on your own assumptions rather than figuring out ranges or distributions from historical data. 00:37:09 - Speaker 3: Yeah, maybe we can just talk about some examples from our own experience of this type of probability. One example that I think is really cool, and this one’s due to Sammo Beria, I hope I’m pronouncing his name correctly. This is Sammo of Bismarck analytics, we can link to him in the show notes, but he’s made this point that with how we’ve historically thought about archaeological discoveries, our timelines only go backwards. So say for example, we’d find the first cave painting and we date it to 5000 years ago, and we say cave painting has been around for 5000 years. And then we find another cave painting, and it’s 8000 years old, and then we say, I guess cave painting has been around for 8000 years. Now, the first observation is that if you take this naive approach, our timelines are only ever going to go backwards, cause anytime we discover a newer one, OK, we’ve known about that, anytime we discover an older one, our timelines for when humans were doing certain things are going backwards. And perhaps Then the correct way to think about this probabilistically would be to say that when we discover the 8000 year old cave painting, there’s some underlying distribution of cave paintings, some of which are probably older than 8000 years old. So therefore, the correct estimate is probably older than that. And if we were in fact doing that correctly, we wouldn’t always be getting older. We would be kind of getting more and more refined around the true date on either side. It’s just one example of how if you don’t think about things in careful probabilistic terms, especially when you’re doing this sort of backwards projection onto the underlying distribution, you can very easily make mistakes. 00:38:38 - Speaker 1: Yeah, that’s a really interesting example. I think this actually came up during some of the stats courses that I did at the university. We did a course on Bayesian inference, so using kind of Bayesian theory of probability. And I think this is one of the few areas where people have actually been applying sort of Bayesian ideas of probability in practice in real life. And I think we actually had a bunch of examples in our sort of lecture notes specifically around archaeological digs. And if you dig up something that’s 50 layers of, I don’t know, sand deep or something, and you think that that’s dated from a certain period, how should you actually think about your new best estimate for how long we’ve been doing the cave paintings? And so there’s a bunch of maths that can actually sort of help you with that. And from my understanding, people are using that maths in archaeological stuff. Nice. I’m curious as to how you guys personally think about how much to trust numbers, how much to trust data and statistics. I found that for myself, I’m just very skeptical of any numbers that anyone tries to throw at me. And I’m, I’m usually much more convinced by a theory or an argument that I find highly plausible than by someone trying to convince me of something. Using data, where do you guys fall that spectrum and like, in what context do you trust numbers that people throw at you and in what context do you not? 00:39:56 - Speaker 3: Oh man, so this gets us into the conversation of what you should believe when you read in the newspaper according to a study. And so for me that’s very little, basically nothing. And so I have a lot of trust in statistics and numbers and experiments, but you gotta consider the whole ecosystem. And when you’re looking, for example, at the ecosystem of publicly described science, there are many, many steps where Where the data gets systematically corrupted. And so what you’re likely to read at the end is just not that useful. So just to give some examples here, when a newspaper reports on a scientific study, they’re very likely to report incorrectly because of probabilistic illiteracy. And then, even among the studies that they choose to report on that, they’re sampling from the universe of studies, and they might have biases or reasons to only. Report on a subset of them. And then furthermore, the stuff that gets published, that is systematically corrupted because only certain types of results they get published. And then in terms of the data that goes into both the published and unpublished studies, there’s a lot of fraud and other issues with it. And so by the time you get out to the end, it’s just not that useful. And if you want to have a chance, you basically need to do a meta review or a meta study. I forget what the exact term is, maybe you know. But Basically, where you round up all of the studies that have ever existed, both published and unpublished, and try to synthesize all the data to say something useful. So because these universes tend to be so complex and because of all the principal agent problems involved, I tend not to trust them that much. But when I have my hand on a specific experiment that I understand end to end, and ideally was pre-registered, then I’m quite likely to trust it. 00:41:29 - Speaker 2: And pre-registered here means they didn’t extract a meaning or find meaning post hoc once they looked at the data, but rather that they were using it to test or falsify or prove or falsify a particular hypothesis. 00:41:43 - Speaker 3: Right, so this is one of the areas where historically scientific publishing has gone very wrong. So say you have a new drug, for example, or you have 100 new drugs. And you privately conduct tests on 1 hundreds of the drugs using the standard 95% confidence interval. Well, you would expect that 5 of those will falsely return, even if all the drugs are placebos, they do nothing. You would expect that 5 of those placebos return, given you’re 95% confident intervals by definition, that they are helpful. And so if you have the opportunity to publish or not. Publish whatever studies you want, you can just publish those 5 and say, hey, look, well, we have 5 drugs that are magic. And in fact, you’re attempting to fool the public by randomness. Whereas if you pre-register all 100 studies, then you can’t do that. People can see that, you know, wait, 95% of the stuff that you think might be useful is actually not useful. So therefore, you’re just not a very good development company. 00:42:33 - Speaker 2: That makes me think of a related concept in terms of like, yeah, 95% sort of effectiveness, which is essentially medical tests. And that there’s a pretty strong argument against sort of testing. You would think that the best thing to do, whether you’re talking about a disease or early cancer screening or anything like that is just test as much and as often as possible. But the challenge with a lot of these things is that you get this asymmetry between the false positives and the false negatives, which is essentially if the test is even 99% accurate. But the disease only appears in 1 out of every 50,000 people. The number of people who get the false positive, that is to say, saying that they have the disease when they don’t, vastly outweighs the people that actually get correct positives on it, and then they spend a bunch of time with stressed out people. Thinking they have a terrible disease and in fact they want the doctors to make the judgment call if there’s some reason, some symptom we see here that makes us want to do the test rather than kind of a proactive test, which I thought was very interesting and again to me was a surprising result. I think coming back to that. Intuitively, you don’t think of a test that has, for example, 99% effectiveness as being something that would produce such kind of skewedly wrong or just misleading results, but without knowing that other number, which what’s the incidence of this particular disease in the population that you’re running the test against, you actually don’t know what the balance of false positives to true positives is. For me, the question of whether I’m convinced by data. Certainly, I think for me it does come down to putting numbers on things, quantifying things, brings a I don’t know if rigor is quite the right word, but perhaps a concreteness. When you say something is really, really big versus saying it is 50 m tall, those two have very different qualities to it, and I feel when people either do bring numbers in either from their own volition or because they’re forced to by scientific practices or something like that. That that actually sharpens the thinking. Now that doesn’t mean that numbers are a magic wand and by quantifying things and turning that into data sets, whether it’s a spreadsheet or something else or the new favorite magic wand which is data science, that just because you bring those things in that now your results are unimpeachable, but rather that I in general that is gonna probably do better than more kind of broad abstract kind of reasoning by analogy or something like that. But yeah, I guess, certainly the specific case marked names of studies as reported on in the news is something to be very suspect of, but looking at a data set and using that to draw some conclusions, I think can be a very powerful way to understand the world. Tim or I might also turn the question back to you on product development, and say to what degree, being a, certainly a very numerically literate person, to what degree do you use some kind of data or quantification in Making product decisions or business decisions, or do you really guide that, especially maybe in the early days, where just the end in terms of number of users, number of customers, total time elapsed, just isn’t big enough, you need to just kind of go with building what’s in your heart, as I said earlier, or following your product intuition and not getting hung up on trying to make sense out of a small data set. 00:46:03 - Speaker 1: Yeah, so I think, ironically, we very much err on the side of our intuition and conviction on things. I think, particularly when it comes to big product things, like, you’re just not going to find the answers in any data set. And so one a really big thing that we kind of grappled with from day one was, we’re building this tool for working with numbers, it’s very general, and so on. What should the UI for this thing actually be? And, you know, we were always kind of aware that, well, maybe we could make it look a bit like a spreadsheet, cause that’ll be more familiar to people, and so on. But, you know, maybe we want to move people away from that and get them to stop thinking in those terms and maybe don’t, don’t do that. We actually kind of had our own proprietary UI until about 4 months ago. And maybe about 6 months ago, we decided, actually, you know what, a lot of people are having trouble getting onboarded. You know, no one is explicitly telling us that, look, give me a spreadsheet interface. No one was explicitly telling us that, but You know, there was a lot of like friction. There were a lot of things which just quite weren’t working out. And so we had to, you know, in the absence of data, we had to ourselves, come up with an analytical model of the world of like, hey, you know, we’re having these problems because our interface is too hard to use for new people. It’s too confusing. And so we should build the spreadsheet. And I can’t imagine, you know, maybe we could have run some survey asking people, like, hey, you know, would you prefer a spreadsheet interface or another interface? Like, you know, but again, I think like designing a survey in a way that I would actually trust it would be really tricky, and I don’t know how much I would trust the results of that kind of survey. So I think big product stuff generally does not come from any kind of data. It’s more around our own intuitions. I’m very happy to trust data. To sort of tune an existing thing that we have created. I think data is very good for tuning something that you’ve come up with. Uh, so I think like, an onboarding flow is an example of this. So, you know, yeah, I think you guys had like a previous episode just about onboarding or something like that in the early days of the podcast. Onboarding is a big challenge for causal, and we have like a guided onboarding. Once you make an account, we then show, like, little dots on different parts of the UI saying, oh, click here, now type this thing in, now press enter, and so on to guide people through kind of the main flows. Uh, of the product. And that’s the kind of thing where we can come up with the structure of like, OK, we think these are the five steps, and this is what we should tell people. And then we can look at the data to kind of optimize this structure that we’ve come up with. And so we can see that, OK, you know, loads of people are falling off after step 3, so there’s probably a problem there, we should probably change that. Data wouldn’t tell us what the steps should be. We have to come up with that structure ourselves. And then once you have the structure, then data is good for refining it and tuning it. And so that’s really how I see data as like, you know, it’s up to us and our own conviction to build the main structure, and then we can use data to kind of refine it a little bit. 00:48:42 - Speaker 2: That reminds me of something a product manager from Pinterest told me that they did there, at least at the time, which was to use split tests automatically just to check that there isn’t a regression in whatever their core metrics are, which might include, you know, monetary things, people converting to purchase or Whatever was there, but also things having to do with, yeah, basically check their core metrics and make sure this exciting new feature they rolled out didn’t just cause something important to tank. It’s kind of a safety check, so it’s almost more of a regression test rather than something that was intended to decide product direction. 00:49:20 - Speaker 3: This conversation reminds me of a couple of things. One is so-called AA tests, where you test your AB testing framework and analysis by making the two sides of the test exactly the same. And so that’s a good way to see if you are likely to fool yourself by randomness, because if you come back with the result that A is bigger than A, well, something’s probably wrong with your probabilistic reasoning. When you mentioned the idea of a spreadsheet interface, that’s something you see in a lot of tools for thought and productivity apps, for example, notion and air table will have this idea of a sort of spreadsheet like thing that you can put in. It reminds me of the phenomenon of carsonization, which is the tendency of crustaceans to evolve into crab-like things. Spreadsheets are sort of the crab of the productivity tool world. It’s like everyone kind of wants to be a crab slash spreadsheet, depending on where you are. 00:50:08 - Speaker 1: Yeah, that’s really funny. We had similar things. So one of our sort of investors slash advisors is a chap who’s kind of been in the financial modeling game for a very long time. He sort of has a business selling Excel financial model templates. And so he’s tried every sort of number crunching tool under the sun, really. And early on, you know, he basically predicts this, and he, he sort of told us that, look, every tool that I’ve ever seen would be created for this, eventually ends up looking like a spreadsheet. That’s all I’m saying, you know, do whatever you want with that information. Um, but he called it about a year and a half ago. 00:50:39 - Speaker 2: Yeah, well, sometimes the process of being a product creator, especially when you’re trying to do something truly novel, is to try all your weird and exciting ideas, and unfortunately, most of them will probably turn out to be not effective, and then you realize why it is that the boring standard thing that everyone uses is boring and standard, is because it really works. But hopefully you find those few weird ideas that, in fact, are breakthrough and can make a difference in the world. 00:51:11 - Speaker 1: Yeah, we almost sort of had to figure out from first principles that a 2D grid is a good way of displaying two dimensional data. 00:51:20 - Speaker 2: Yeah, I like a little bit that approach of throwing out assumptions and throwing out kind of a sense of, well we’re doing it this way because that’s the way we’ve always done it. I think it’s very easy to build products that way to say, OK, well, obviously you start with the login page because everyone has a login page and then you have a page that’s like this and a screen that’s like this. And you’re just going based on assumptions of following established patterns and throwing those out and saying, OK, now what are we trying to accomplish here and what if we design something truly new? And more often than not, you do end up back at those established patterns because they’re good for a reason or they work well for a reason, but I feel like it’s a truer and more pure way to arrive at those, kind of building it up yourself, as opposed to kind of just imitating without knowing the underlying reasons. 00:52:05 - Speaker 1: Yeah, absolutely. 00:52:06 - Speaker 3: This is actually reminding me of the importance to my mind of studying combinatorics and probability as a predecessor to statistics. So a lot of folks I see these days, they study statistics and so they just get the formulas for like how do you do a two-tailed tea test or whatever. And I don’t have the underlying intuition, whereas I think it’s much more useful to have the underlying intuition of especially combinatorics, which is the study of counting and therefore gives you probability. So yeah, if folks are interested in this space, I would suggest starting with how to count things in combinatorics. 00:52:39 - Speaker 2: Well, let’s wrap it there. Thanks everyone for listening. If you have feedback, write us on Twitter at MuseAppHQ or via email, hello at museApp.com. You can help us out by leaving a review on Apple Podcasts. And Tamar, I’m glad you’re building a tool for thinking and probabilities because I think we all need it. 00:52:59 - Speaker 1: Cool, thanks a lot for having me. This has been a lot of fun.
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: What I believe, which is that a product that comes with the manual implies it has depth, that it fits together with being a professional tool, where probably the things you want to do with it are things that require skill and take time to learn, even separately from the tool itself. Hello and welcome to Meta Muse. Use a software for your iPad that helps you with ideation and problem solving. This podcast isn’t about Muse the product, it’s about Muse, the company and the small team behind it. My name is Adam Wiggins. I’m here today with my colleague, Mark McGranaghan. And Mark, how are things today? 00:00:42 - Speaker 2: Doing all right, thanks, Adam. How are you? 00:00:44 - Speaker 1: Doing well, we just had uh the spring weather break here in Berlin, so even though we’re still on home lockdown, uh, going out to enjoy the flowers in bloom and trees, uh, in starting to turn green and the kids out, uh, families out and taking my dog out for a walk. It’s uh it’s a nice break after the the long winter. So I’m very excited about our topic today, and that is manuals. So we just finished, uh, really should say you and Leonard just finished the Muse interface handbook. Put a link to that in the show notes. And I think this is a, a lovely piece of work that sort of shows the command vocabulary gestures that you can, uh, you can use with the Muse application. But the path that we took to get here is maybe an interesting one. I want to tell that story a little bit. When the team started talking about whether we needed some kind of manual or handbook or user’s guide or something like that, it really caused me to go and start reflecting a lot on what I thought makes a good manual. One experience for me that really stuck in my mind was this experience of getting a rocket espresso machine. Do you know these devices? 00:01:49 - Speaker 2: I think I’ve maybe seen it at your place or I know of it, yeah. 00:01:53 - Speaker 1: I think I got this machine around the same time as I also got some other kitchen appliances. Maybe there was like um like a slow cooker, rice cooker thing, and there was a stark contrast where the, the slow cooker came with this. Thin black and white tiny print thing that was like in 8 languages and I had to hunt through to find the English and even then it was. I don’t know, pages of boilerplate about, you know, plugging it into the right socket and don’t take it to the bathtub with you and so on, and just getting to the information I wanted, which was how to use the device to cook things, uh, was quite difficult. The rocket machine by comparison, has this lovely, uh, manual that’s sort of this a full color, it’s bound and the right on the cover it says something along the lines of how to use your machine and and make beautiful coffee. And describing what I want to accomplish as a user and it’s, it’s a quite rich technical manual that covers a lot of, has a lot of depth and certainly I think it has the safety warnings and whatever in the back somewhere, but it really was this inspiring thing that gave me enthusiasm and excitement to uh get using this product versus such a stark contrast to the basically the very sad, uh, manuals that come with uh other kinds of kitchen appliances. So that was, that was a powerful experience for me. What for you Mark makes a good manual? 00:03:16 - Speaker 2: Well, I think your example points to a few things. One is the sense of like impute that you get from actually first seeing the manual. You infer the quality of the product and the experience that you should expect from what you see in the manual. So it’s a very dull, poorly designed, uninspired manual. You might expect the same thing in the product reasonably, whereas if it’s a very, you know, well done, well designed, uh, well thought out, um, piece of work, you might again expect the same thing on the product side. Two products that I have some experience with here. One is go by example, um, which is. On the edge of being a manual, it’s kind of a website, you know, this is the site for learning the Go programming language, uh, but the idea there was to have a very example-based approach to learning. Uh, the Go programming language instead of a very abstract word-based approach. So here you go to the site, it’s basically a series of, of lightly annotated example programs so you can see just exactly how to do it. It’s a show don’t tell situation, which I think is by the way similar to the espresso machine manual you mentioned. You can imagine trying to work an espresso machine just on the basis of text. It’s like pull this lever, then depress that knob and put more water in here. It’s like what does that even mean, right? It’s so much better when you can actually see it illustrated. 00:04:30 - Speaker 1: So some examples of prior art, I think we collected we’re thinking about this, um, included uh things that we’ve worked on, of course. Go by example is a good one. for me, the, um, the early Hiroku documentation, which I think was just a little static website that had, I don’t know, a dozen pages on it, each one of which was describing how to do. Particular thing with the platform, very simple, but easy to easy to navigate. Nowadays, uh, the product has this huge dev center that is, you know, fits the sort of complexity and and quantity of capabilities that exists in that product. So sometimes maybe the the earlier products because they can have such simple manuals, uh, that can be that can be more fun. When I was looking for prior art on, um, manuals, maybe more currently, particularly around the iOS and particularly iPad apps, I looked at Ulysses, a working copy has a pretty nice one that’s sort of embedded in the, like the, the settings menu, but you can also go to his website. Uh, Goodotes has some interesting documentation with some nice kind of animations and and visuals. Um, and then Procreate was a really interesting one because they have this really beautifully made, um, so Procreates a sort of a professional art application. And fitting to that product, they have this really beautifully made, I think you can get it as an iBook, but it almost unfolds more like a presentation or something, something like that. So I think it fits the the visual style and the the beauty that you would expect from an art product. 00:05:56 - Speaker 2: Uh, another example that that I had thought about was the stripe API docs. And again, there’s this very example based practical approach where they give you, they literally give you commands that if you paste into your terminal, will execute completely the uh API endpoint in question. And for me, that’s always a huge thing with documentation. What is the specific series of actions that I need to undertake to get the result that I want, like enumerate step. 00:06:22 - Speaker 1: Yeah, instructions I think are a underrated thing. Format is huge, and I, I think that almost always you want multiple formats. So for example, yeah, the Unix man pages for those that aren’t familiar, it’s basically the Unix is a command line driven environment so you type type commands. And you can type man, short for manual space, a command that you are interested in, and it will basically show you the documentation for that. So it’s very in line in, in, it’s right in the environment where you want it. Um, and I think some of the folks some of the examples we went to look at, um, had a version of that as well. So I think the, you know, the, the working copy users' guide, you can look at it in the app, but you can also download it as a PDF, but you can also go view it on the web. 00:07:09 - Speaker 2: One other format that was actually an inspiration for me here was YouTube. YouTube has become incredibly important for uh transmitting tacit knowledge on the web. There’s actually an article we can link to this, uh, in the show notes, um, but video allows you to Um, understand all the implicit and subtle, you know, physical movements, um, you know, mental models people have in their head when they’re telling you how to do something. So for things like, you know, cooking or woodworking or playing a game, these are quite hard to explain like in text, even with diagrams, um, and having the, the video there is super helpful and um I think we’re just gonna see more and more uh things moving to video and YouTube because it’s such a powerful medium. 00:07:49 - Speaker 1: How did people figure out how to do like DIY things around the house before YouTube existed? I mean, YouTube didn’t exist for a lot of my life, and sometime I figured it, I figured it out, but I honestly can’t remember what I did back then. Yeah, it’s an incredible repository for, as you said, tacit knowledge and things that certainly things that cannot be conveyed well in the abstract. Nature of just uh written prose. One thing we talked about when we were thinking about the manual as well is the, let’s call it the bottom up versus the top down. And I think the uh the bottom up was more what you see when you view an individual man page, when you Google something and see a stack overflow, you’re looking for a solution to some specific problem in the moment, and you don’t want to see all the documentation, you just want your specific nugget of information. But I think another, uh, maybe underappreciated role that manuals can serve, they or they serve for me is they provide this overview. So we spent a good bit of time trying to figure out what the right table of contents would be, because there your information hierarchy or your taxonomy of how you’re sorting things out. Uh, offers a chance to give an overview of what is this product and what does it do. So I imagine someone, for example, might go to the Muse handbook and look at that and get a sense for what actually is this thing, what are the, what, what are its capabilities in a very practical nuts and bolts sense. 00:09:16 - Speaker 2: This actually points to two things that I think are really important in manuals. One is if the manual is well done, it, it provides that comprehensive. Uh, enumeration of things that the tool can do. So you can go to the manual and you can read it and then you know all the things, which sounds simple or obvious, but so many tools because there’s so many entry points to the functionality, you know, menus, hot keys, shortcuts, you kind of don’t know if you actually know everything yet and you’re always being surprised like, oh, this is a new, you know, button I didn’t know about before. Um, and I really like the feeling of I now. You know, I know Kung Fu, you know, like from the Matrix, uh, but the, the other thing is this idea of reference versus narrative docs which I think is similar to what you were describing. Uh, so references like there’s a, a specific. Thing you want to do, you know, I want to move a card, but that that often needs to be situated in a broader workflow, a broader, you know, use case motivation, and so often you see documentation complement that uh the the reference with a more vertical slice and narrative of here’s how you do a X in this tool and it kind of touches many of the specific things that would be covered in more detail in the reference docs. Those two types of documentation are potentially especially important with Muse, because yes, there’s a bunch of specific things that you need to know how to do, but there’s also this question of what is Muse for, which isn’t maybe as obvious as other tools like a word processor, like you know you’re going to go write a document in a word processor, whereas Muse is kind of a new type of tool, a new category, so we have some explaining to do on that front. 00:10:43 - Speaker 1: Now, do you think the handbook as it is right now accomplishes that? I felt like the even calling it the interface handbook, we really were more focused on the the nuts and bolts part rather than the broad, like what is this thing and what is it good for? Right? 00:10:56 - Speaker 2: I think right now it’s mostly reference and I could see it um expanding to include more narrative or having a complimentary source of documentation later that covers that. 00:11:06 - Speaker 1: One other memory from my past, uh. Experience working on manuals is how it feeds into product design. I think you, you brought this up when we were first brain storing the the manual. I think of it as almost like a hygiene or it brings a certain coherence when you’re forced, when you write down, even the table of contents can do that. Uh, one experience I had was working on the Hiroku add-on system, and I ended up essentially writing the manual for that in tandem with designing the way that the technical design for how the system worked. And I found it incredibly helpful for sorting through these pretty abstract concepts and the the real unlocker was writing a glossary. So I was trying to take down, I’m like, OK, I’m using all these special words throughout the throughout this documentation. What does each one mean? And I actually found that taking inventory in this way. I realized that I would use one word to mean two different things in two different places or other places. I had several words that referred to the same thing or basically the same thing, and so I forced myself to pare down to a set, a fixed set of con uh concepts, the primitives that really built up the design, and then went through and made sure I only ever used that one term. And that was, that was a much harder job than it it sounded. Um, but I felt like the, the end result was something simpler and more comprehensible. 00:12:29 - Speaker 2: Yeah, I totally agree. I think it’s a super valuable process, especially to get the, the glossary, the words right, and relatedly this idea of mental model, often when you’re having trouble writing clean docs or explaining a product to someone, it’s because you don’t have or it doesn’t exist a good mental model for how the product works. Um, and once you can write a really crisp glossary and a really crisp table of contents indicates that um there’s a, there’s a clean set of gears, you know, behind the clock face that, that, um, dictates how this product works. 00:13:00 - Speaker 1: Mental model is, is huge, particularly when you’re doing something that’s either highly technical product or a highly sophisticated power tool. Or just something that’s relatively new, that doesn’t have a clear, you get the mental model somewhat for free if you go to implement something well known in existing a to do list a word processor, when you’re doing something a little bit category breaking and a little bit new, like what we’re trying to do with Muse, that’s a much we need to develop that mental model fresh. 00:13:29 - Speaker 2: Then also more tactically, just when you go to, you know, basically test out every single thing that you’ve put in the manual, you might be surprised how many weird things you find. Like we found a couple of bugs in the course of doing the muse manual where it kind of basically works, but there was a little hesitation or you need to like do it twice, and that’s the sort of thing that you might be able to gloss over in the course of casual queueing. But once you’re, you know, filming in this case yourself, it becomes very obvious when there’s any sort of glitch. 00:13:55 - Speaker 1: Well, the filming side I’m super interested to hear about because you did some, uh, did some very interesting work on that. Uh, but before we jump forward to that, maybe we could start at the beginning of the story. Uh, I always like to hear war stories about how, uh, product features or product, uh, capabilities get developed. So maybe we can tell the story a little bit of, uh, why this handbook came to be. 00:14:18 - Speaker 2: Well, I feel like we’ve had this challenge for a while of um explaining news to our new users. And we’ve been thinking about and trying different things, you know, we’ve tried some onboarding material, which is sort of some example content with some instructions woven in. We’ve tried giving people advice over email, um. We’ve, we experimented and we thought about different, you know, more standard documentation formats like uh text with some diagrams, but we were having trouble really getting through to people basically, um, and the, the genesis of the handbook was maybe video is a especially good format for what we’re trying to show with Muse. 00:14:57 - Speaker 1: I’d previously grappled a bit with the how do you show an application, a tablet application that has sophisticated gestures and uses a stylist, more from, I guess like a marketing perspective. So for example, we have a video up on our website right now, which is just a screen recording. You can’t see the hands, and it’s a little, it works OK, but it’s a little confusing because how is the person doing these things that are happening. And with a, for example, recording a desktop operating system, you have the mouse, and there’s other kinds of things built into screen recording software to help, for example, when you type keys, they can put basically cues, put annotations for what’s being typed. So it’s much easier to see that. Uh, and then I think with like phone applications, for example, you just tend to have a big button and it’s kind of clear when you tap on the button and that’s sort of it. But for our chromeless interface where there’s not a lot of buttons and many of the um ways you do things are these sophisticated gestures, that’s that’s tough to show. So I had been down that road a little bit and went around and kind of looked at the way that lots of uh different uh companies that do have these kinds of applications do it. And there’s no real gold standard. Um, but it definitely showing the hands seems to be crucial. So we, we felt like, but, but that’s tough because we had done some video recordings in the past, both for the Muse design article, uh, as well as the capstone manuscript had some really bad low quality videos and I just knew that it was a, a pretty big production effort to to do that well. And so I kind of had the idea of, well, maybe we should stick to still images, and I experimented a bit with let’s do like a 123 that shows the steps of the gesture a little bit uh inspired actually by the rocket manual, which also has things like this where it’s, OK, turn the handle to the right and then push this button and then fill up this reservoir and they they would sort of imply motion or imply um the passage of time. So I did a version of that with uh what we called the shadow hands, which were basically um outlines of hands. Apple does this, of course, beautifully in some of their uh marketing stuff, uh, where you see some hands, but they’re sort of dark and uh maybe maybe slightly uh transparent, and the idea is you don’t want people to be focusing on the hands exactly, but you do need to see what the hands are, are doing, but you don’t want them to fully obscure the screen or the content. Um, so I experimented with that a little bit in a static format. Um, but I think that pretty quickly led to like, OK, this is OK, but we really just need to see the motion. But the idea of trying to do full motion animation using, I don’t know what after effects or something, that seemed like a huge production and sort of out of reach for our, you know, small team that has a lot we should be working on. 00:17:43 - Speaker 2: Yeah, we tried basically every way we could to avoid having to film live action hands. It’s quite hard, but none of them were quite satisfactory, and I think there are at least two reasons. Um, one is there’s this feeling you get when you use muse, like when you touch a card and it moves instant instantly or when you start pinching and it fluidly zooms in, that is really important, but it’s really hard to explain without just seeing it. I mean I really wanted to capture that. I felt like the only way to do it was video. 00:18:12 - Speaker 1: So yeah, you, you were inspired to do that and you dived in with your uh with your AV gear, which I know you’d already been kind of experimenting with in the past, partially at at I Switch, but also you’ve done a little bit with your uh virtual piano lessons here now and so I think you, you’d had interest in some of that stuff anyway, so you already had some of the gear. What, what was the final set up or what is your um hand recording studio now look like? 00:18:38 - Speaker 2: Yeah, so there are 3 pieces that are key. I found. One is something to hold the camera. So we found that the top down shot is best. We tried other angles like looking at it from the side, looking at it like kind of over the shoulder, but when you have uh multiple hands and the screen, the most consistent way we found was just to shoot it overhead and I just use an iPhone camera works quite well. And so you have a tripod that’s on the floor and then it kind of booms over and there’s this little device that clamps onto the camera and it’s attached to this kind of ball and socket joint so you can move it around and so that altogether gives you the video recording. Uh, the second really important piece is the lights, and so I use a couple uh commercial lights that are usually used by streamers for lighting themselves, but in this case I use it for lighting the hands and the desk, uh, and I use either 2 or 3. Um, lights from one from the left, one from the right, and one from kind of across the table from me. Uh, and the third thing is something to put the iPad on. So an important difficulty we had back in the Ink & Switch days was we would try to film, I try to film the iPad on my wooden desk, but the thing is that then you have the horizontal line from the wood planks, the horizontal line from the iPad, and then the, you know, the horizontal line from wherever the camera is. Uh, located and so you need to line up all three of those things exactly or it looks really weird. And so I ended up putting the iPad on a leather surface which is sort of like directionless so you can basically um fix the camera and then line up the iPad exactly to line up with the camera and it doesn’t need to be lined up exactly with the desk at that point, um, and that was actually a pretty big uh unlock for us. 00:20:19 - Speaker 1: Hm. Yeah, that was something I struggled with a little bit was um even getting the the tablet square with the camera, which I guess you can, as I say, fix it in post, right, if you have sufficient video editing software, you can kind of even that out. So I can see we’re having that many things I have to align would be a would be a problem. And then the lights, uh, from all these different angles. I know that another huge one that we ran into even just giving a workshop, we would do kind of video chat uh workshops about progress on our research prototypes and the overhead lights in the room were just absolutely killer because that turns your, uh, turns your tablet into a little mirror and you see the person’s face, not to mention that smudges all over the place, you know, the finger smudges all over the place and it’s very hard to see what’s actually on the screen. 00:21:08 - Speaker 2: Yeah, so I’ve only partially solved this. So I turn off all the the lights in the apartment and I try to do it at night, and that gives you pretty good cover so you don’t have too much light coming in from overhead. But if you actually turn off the iPad, you can see the reflection of the camera overhead. So currently it only really works when you’re on a fairly bright screen, which you’ll notice all of our videos have. Um, I actually tried recording one with my stock, uh totally black iPad background, and there was a huge camera reflection in the middle of it, so I had to change it for the video. Um, but I think we could fix that with basically cutting out more of the external light so there’s less coming in from overhead. 00:21:42 - Speaker 1: And you say at night, is this about consistency that you want all the videos to have consistent lighting, or is it more about um the direction when it comes through the window, you can’t control the direction of the color temperature or whatever. 00:21:54 - Speaker 2: Yeah, just consistency and also the overhead thing. So if I have a huge window in this apartment, so if I do it during the day, you have some diffuse light coming in from overhead, which, which exacerbates that um reflection of the camera problem. 00:22:06 - Speaker 1: Do you imagine kind of going forward that when it comes time to add a new feature that we need to, um, then add a new kind of section in this handbook for? Will it be challenging to recreate these conditions? Do you have like everything’s written down of exactly where stuff should go or there’s tape on your floor or something like that, or is it not that important? Is it actually fine to have some videos that maybe have a slightly different. Feel or the tablets in a slightly different position in the frame or something. 00:22:36 - Speaker 2: I think there’s some forgiveness here, but I would like them to be pretty consistent. Um, so as long as the equipment is sort of out, it’s not too bad. And then in Muse, where I do the filming, I actually have a little checklists, you know, right in Muse, of course, um, and there’s quite a few things you got to get right. Like you got to, you know, make sure that uh your home screen isn’t weird, make sure that you’ve cleared out your, um, You know, iMessage contacts, they don’t show up in the share sheet. There’s a lot of little steps need to take um to actually do the filming, but once you figured it all out, it doesn’t take that long to run through the process. 00:23:06 - Speaker 1: Well, there’s the sample content element uh here as well and we’ve we’ve, there’s another one I’ve grappled with, um, when I’m often and for example, we want to show a new feature in one of the email updates and I want to show, uh, as much as possible, I try to show real boards either mine or other people’s when they, um, consent to share that and so you get a sense of what Muse is really used for in the real world rather than. Something that’s kind of made up. Now, in this case, because I think this stuff was more, I guess, produced would be the word for it. It was supposed to be longer, um, it’s the word for it, a little more timeless. You did create boards that were not necessarily ones that uh you had in your, I guess your real used to call it that, is that, is that right? 00:23:49 - Speaker 2: Yeah, and we did them all around this theme of gardening, which is the same theme that we use for our onboarding sample content when you first open the app. Uh, and we like that because it’s very, it’s very generalizable, it’s very relaxing, it’s very meditative, and those are, you know, properties that we want to encourage and use. And also the I think the content that you would tend to want to film with is maybe not exactly the same as what you would use day to day and use, because basically, these videos get compressed down to pretty low resolutions and so things like bigger images work better for the video versus, you know, a whole page of handwriting. It would just basically look like a bunch of scribbles from that far away. um, so it’s a, you have to kind of um be mindful of the medium. 00:24:28 - Speaker 1: Is it a problem at all that you, you’re filming a screen? Uh, I’ve seen techniques where you basically use a green screen, simulate the movements, and then do a screen recording that you composite in later so that you get the crispness of the pixels, but it seems like they came out, it seems like they came out pretty nice. That wasn’t necessarily a problem in the final video quality. 00:24:49 - Speaker 2: Yeah, that seems fine. And you know that the iPhone camera these days are are wild. Like this is a 4K camera with really high quality. Um, and so when you’re rendering down to something like 1080p, you have a lot of, uh, resolution to spare there. We have thought about actually doing the reverse and putting a green screen, like filming the iPad on top of a green screen so you can compos it in a different background, um, that’s either, you know, for example, maybe it’s always exactly the same, or maybe it’s actually transparent, so it just blends right into the the web page, um, but that’s, that’s pending, you know, our Amazon green screen order which because of the virus is. 00:25:24 - Speaker 1: Now, can you tell me a little bit about how, sort of, you, you and Leonard were the ones that ended up uh working on this towards the end, and you ended up with, first of all, that this is a web page as opposed to a PDF or something, so you need to load that browser separately alongside Muse in a split view or something. And secondly, that most of the, um, you have all these videos that have, uh, they’re kind of these little cards that then have text, some explanatory texts below. And I know some earlier iterations when I was working on it with you a little bit more, were much more classic heavy text manual, maybe the kind of stuff you and I have done in the past, like go by example or the rogu docs or whatever where it’s mostly text with a few figures. And at some point here, we realized this is just such a visual thing and especially if we get the videos, it’s really more Images and more imagery and just a little bit of text to explain, but I’d be curious to hear how you landed on this cards expository text attached to a video or a still. 00:26:21 - Speaker 2: Yeah, well, we knew we wanted the video from the beginning and so we started with something that was more like go by example or standard manual. We have 1 or 2 videos per page and then a little bit of text, but then we found you only need maybe 123 sentences per. Video and so you have these pages that we mocked up and we did some HTML mockups, and it would just be very sparse and then you need this whole apparatus around navigating the documentation because you have multiple pages and then to get through all the docs and to get an overall sense we have to click through each of these individual links. And so it was both more work for us and it was in a way less satisfying for the user because they didn’t um get everything they were looking for right away. And there was one site that we saw that was uh an inspiration. Uh, what was it? 00:27:06 - Speaker 1: Uh, Loom, kind of a new cool indie animation app. 00:27:09 - Speaker 2: Loom, yes, and they have a cool, um, manual page of sorts, which is in this style, but it’s all text. So I think it has the kind of two or three things per row and then a series of rows on the page, um, and we liked that one page idea, but then of course we want to bring our, our video. And then when we mocked it up, it it worked quite well, so we ran with it. 00:27:30 - Speaker 1: Another notable point on the cards that are shown, some of them are clearly news. Here’s how you move a card, here’s how you delete one, here’s how you navigate and out of boards. But then there’s also things like how to take a screenshot, which is an iPad or an iOS feature. Uh, there’s some other things that are, are like that as well, like search. How did you decide where the boundary between what you can do with Muse and the full capabilities of the operating system? What, what caused something to be in or out of that list? 00:28:01 - Speaker 2: Well, we wanted to include all the things that you might want to do with Muse, broadly defined. So for example, bringing in a piece of content from another app on iOS into Muse is something that involves Muse is an important and our experience with iOS is that There are all these, these important platform features that people don’t know about. Even very experienced iOS developers and advanced users are surprised when they see uh some of these workflows, you know, whatever the magic gesture is for bringing up search or like sharing between apps or whatever. Um, and so we thought it was quite important that we gave people those instructions because without it, they might be missing this key piece of how you actually use Muse in the context of iOS. 00:28:42 - Speaker 1: This is a good reminder that one of the challenges here is iPad OS is moving in this direction of becoming more, more, more capable, more powerful, trying to be a tool for professionals, but it comes from this, uh, legacy or this foundation of the iPhone. And the iPhone, of course, was the iPhone you could argue is maybe the most successful product, certainly the most successful tech product of all time, and partially that’s because it took the complex world of computers that was always. Just out of reach for maybe a lot of The mainstream world, people who weren’t um Sort of computer nerds, so to speak. The iPhone helped make it so that everything was kind of um comprehensible without a manual. And in fact, I would say it’s part of the design ethos in the mobile world. And probably for a good thing that if you need a manual or you have a manual of some sort, you failed, right? That the um the classic uh refrain from the computer message boards, RTFM right? that’s read the fabulous manual, is something that is a legacy of the desktop operating systems where things were just too complicated. And that now in this enlightened mobile era where everyone’s got smartphones and you expect to download and install an app, and you should be able to figure it out by kind of pawing at the obvious buttons on the screen within 10 seconds. And in fact, if you don’t figure it out, you probably delete it pretty quickly. But that’s not really viable. In fact, that’s not even desirable for professional tools. You want something, of course, they shouldn’t be specifically hard to learn, but a learning curve, if it pays off with more power, more flexibility is worthwhilele. But now you have this, not only this, um, the whole operating system of iPad OS and the device and all that sort of thing, but actually a design ethos, a design um set of um values that comes from something needing a manual as a bug. Versus what I believe, which is that a product that comes with the manual implies it has depth, that it fits together with being a professional tool where probably the things you want to do with it are things that require skill and take time to learn, even separately from the tool itself. Whether you’re writing, whether you’re creating art, whether you’re doing science. These are not things that a person figures out by pushing a couple buttons, obvious brightly colored buttons on a screen. There are skills that you learn, and the tools that go with it are skills as well. 00:31:08 - Speaker 2: Exactly. We want the tool to be as easy to learn inherently, but no easier. We don’t want to sacrifice uh the power, and the capabilities on the high end. Um, for the sake of that those initial 2 minutes. That said, we have tried to meet our users, uh, somewhat in the middle because they often are coming from this mobile world where this expectation is very strong. So you can open this manual with one link, it has high production value, it has this kind of YouTube style, very quick to ingest video, um, so I think that helps a little bit bridge the gap between the standard mobile world and this world of professional tools. 00:31:43 - Speaker 1: That also reminds me of something you mentioned earlier, which is onboarding content, which is sort of the industry term or um as you likes to call it the out of box, AKA UI experience. So the onboarding content is what you see the first time you open an application. Sometimes there’s a little tour, uh, but I think for creation applications, it’s kind of nice to show content that is in the format of the application itself. So, for example, I think Bear, uh, which is a really nicely designed notes app, it just comes with some default notes that are in there that essentially explain how to use the app and will show you what its capabilities are. Notion, I think loads up with some templates, that sort of thing. So we explored this quite a bit. We, we had a couple of major iterations of our onboarding content where we tried to include sample boards and some instructions and we would walk you through all the things. And I think it, I don’t know if it’s a legacy of that kind of iPhone world where people just want to try it, they skip all the tutorials, they just ignore anything you put on the screen. They just want to start trying stuff out. And and I understand that because honestly I do the same thing, but what we discovered in some of these usability tests when we would try out our onboarding content is that people not only did not read it, they thought of that stuff as being in their way and they were pushing it out of the way, deleting it, erasing it, just trying to get past it, but then they would get frustrated and stuck because they didn’t, you know, the interface had these different uh approaches that they didn’t necessarily know, and then they would then they would sort of feel stuck. And that led us to thinking. OK, we’re not gonna, we’re not gonna get it with the initial content. People just want to play, they want to try it out. And that led us to this garden themed, um, content we have now, which explains fairly little. It just gives you a little playground or it gives you some elements to play with. And then there’s a tips panel you can go read when you wanna kind of go to the next level. And now we’ve got this handbook. I doubt that’s all we’ll need, but I thought it was interesting that we made this journey through trying to solve the, how does this thing work through onboarding content and eventually deciding that was a dead end. 00:33:47 - Speaker 2: Yeah, and I think it’s notable that in most Pro Tools you get the totally blank page. So when you first fire up the eye, for example, it’s like the super intimidating black screen. It’s actually quite hard to figure out how to do anything at all, um, and that’s, that’s kind of standard in the Pro Tools world, but that actually points to a third leg of the stool. So there’s how is the tool, how easy is the total. on its own kind of intuitively, there’s the manual and there’s the kind of social element where with a tool like Photoshop or VI there’s often someone who’s basically teaching you or encouraging you or giving you pointers, and we haven’t explored that too much with Muse, but I think that will be an important uh third leg in terms of how people learn to use the app and learn to be productive with it in practice. 00:34:30 - Speaker 1: So looking forward to the future here as we add new capabilities to Muse, uh, we’ll want to document those. My experience with documentation, one of the challenges there is keeping it up to date when you have a fast moving, agile team, you’re cranking stuff out, uh, and it’s easy to overlook that when you’re shipping new stuff or it feels. Maybe like a costly step or the people who are making the documentation aren’t totally plugged into what you’re creating. We’re obviously a small team here, so maybe that helps avoid some of this, but then we have a new problem I guess which is that as you said, these have pretty good uh production value that you really invested a lot in. How do you have ideas for how we’re going to keep this up to date, or do you expect there will be periods where they’re, we’re testing new features and those just aren’t documented, and then when we sort of decide they’re going to stick around or whatever, then we, then we lock it in by putting it in the handbook. 00:35:26 - Speaker 2: I certainly hope that the handbook continually converges to the real state of the app. It’s tough though, you know, I’m tempted to just say be diligent about it, uh, but our mutual friend, Peter would say that diligence doesn’t work. Um, one, One idea I have here is leaning on the handbook for sort of marketing purposes. And in the same way that uh document, documenting your product forces you to think through the user experience, I think the uh the expectation that the material is going to be shared in a marketing capacity is going to encourage the team to like really think through the quality of it and make sure it’s complete. Um, it’s just things like when someone asks, how do IX with Muse, you send them the anchor link in the handbook to that video. Um, I think that kind of constant exposure will help maintain the quality. This, this actually reminds me of another adage about data quality in here the data quality is like kind of the handbook quality. It’s that data quality is a function of how often and how thoroughly the content is read, not how carefully it’s written, um, and so the more exposure we get on the read side to the handbook, I think the better it will be. 00:36:33 - Speaker 1: Canonical URL for something is an incredibly powerful thing in my experience, whether it’s internally in a team because I don’t know, you have someone new joins the team and they say, wait, how does X work? and you could send them the internal Wikilink or whatever that describes that. And then externally, yeah, when you’re doing support for your customers, someone asks on Twitter, whatever it is, and you can basically just respond with bang. Here’s a, here’s a URL that explains it all. Often when you go to do that, you say, oh, this is, this is documented, it’s in our manual or whatever, but then you realize there isn’t a good link to it because there isn’t an anchor tag or it’s kind of spread around a couple of different areas. There isn’t one like single place to go to get that crisp answer. That’s exactly what they’re, what they’re looking for and, uh, that’s a chance to potentially go and prove it. Good. Well is there anything else on the topic of manuals we should, we should talk about today? 00:37:26 - Speaker 2: I think that covers it. 00:37:28 - Speaker 1: If any of our listeners out there have feedback, feel free to reach out to us at @museapphq on Twitter or hello at museApp.com via email. Love to hear your comments and ideas for future episodes. And Mark, congratulations on your new career as a hand model. Thank you. It’s great work and uh I’m really glad to have it out in the world. Thanks Adam. Alright, talk to you next time.
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: I think that the lack of interoperability or standardization between digital tools today really it means that all work created within a tool is confined to that tool, and to me that seems very clearly antithetical to creativity and specifically the collaborative aspect of creativity. 00:00:28 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for thought on iPad. This podcast isn’t about Muse the product, it’s about Muse the company and the small team behind it. I’m Adam Wiggins here with Mark McGranaghan. Hey, Adam, and our guest today, Molly Milky. 00:00:43 - Speaker 1: Hey there. 00:00:45 - Speaker 2: And how was your spring break, Molly? 00:00:47 - Speaker 1: It’s pretty good, not long enough, but it was a lovely little escape in Berkeley, and I worked on a final project for my producing class, which was a pitch on a feature film on the Whole Earth Catalog, which didn’t go over as well as I had hoped, but I’m still fingers crossed that it’ll become something. 00:01:10 - Speaker 2: And the whole Earth Catalog here being the Stewart brand work from what was the 70s or 80s. 00:01:15 - Speaker 1: Confirmed, yes, it was basically a biopic on him and the era of the whole Earth Catalog, and it was very dramatic. 00:01:23 - Speaker 2: Oh, I love that. First of all, I just love biopics. I’m a big fan of like abstract. Act on Netflix or that sort of like kind of maker documentary, but when you throw in like the weird history, I feel like the whole Earth that catalog was sort of, I don’t know, psychedelic culture meets rebel computing or something like that. 00:01:41 - Speaker 1: 100% agree, yes. In a very interesting way that I think would translate really well to film, but we’ll see. 00:01:48 - Speaker 2: Yeah, absolutely. So yeah, let me know where I can sign up to screen that I guess. 00:01:53 - Speaker 1: Amazing, yes, you’ll be the first to know. 00:01:55 - Speaker 3: Wasn’t there actually another film about Stewart Brand in general that came out recently? 00:02:00 - Speaker 1: Yep, Stripe is on it. They made a documentary that’s coming out very soon, actually, I think, and it’s as part of the SF Film Festival currently, and it was more of like looking at his whole life and his impact legacy and also the more recent like environmental stuff he’s been doing, which is much more comprehensive and honestly a much better idea. But I started this project my freshman year, so I’m pretty committed at this point. 00:02:26 - Speaker 3: Yeah, yeah, for sure. I think it just shows that there’s a lot of interest in his work. 00:02:30 - Speaker 1: It’s really interesting, like, the deeper you dig, the more you find, and the more like of a web you discover, especially on Wikipedia, in the best way, so. 00:02:39 - Speaker 2: You seem to enjoy some unearthing the history of weird characters here, your collection of computing history, folks. I’ll link that in the show notes here as well. But before we get on to that, I think the folks would love to hear your background. You’re quite early in your career and yet already have a very impressive CV here. You’ve worked at Figma, you’re now at Notion, and you just finished a thesis at UCLA, so I think we all just want to know. What’s your productivity hack? How can we all be as uh as productive as you so early on? 00:03:11 - Speaker 1: Oh God, that’s not. First of all, my little background blurb. My name is Molly. I’m currently a student at UCLA. I studied digital media, and I’m in my last year. I only have a couple more weeks left, which I’m very excited about. 00:03:26 - Speaker 2: Wow, congratulations. 00:03:27 - Speaker 1: I know, so close, yet so far. 00:03:31 - Speaker 2: The senioritis kicked in already? 00:03:32 - Speaker 1: Oh man, yes, it has been very, very present in my life ever since like September of last year. Every single week is like counting down the days, but we’re getting there. And I’m currently designing a notion, and I will be returning to Sigma at the end of the year. And I come from more of a background in visual design and storytelling, specifically filmmaking, and I got my start leading design at a startup in the Bay Area while I was transferring schools, and through that I found product design specifically, and I found that it was like this very unique fusion of the creative and the analytical at the same time, that just really clicked for me. And ever since then I basically was just exploring kind of different industries and company sizes and problem spaces more broadly, and through that and working at startups and Sigma and most recently notion, I found that creative tools were what I was the most like just completely pulled towards and really wanted to just dig deeper and explore what impact they could have. I think that there’s something about making something that enables other people to make other things that is just like incredibly gratifying for me in a way that no other product design projects really touch. And I think more broadly, I’m really interested in the combined power of like design and tech to foster creativity and community across the board, and that was definitely like the inspiration behind this thesis and also like a through line to just things that interest me across the board and in terms of like doing school and work at the same time, I think it’s really just about The space that the pandemic has provided for free time, sadly, I definitely have profited. 00:05:30 - Speaker 2: Uh, so that’s your productivity hack is be doing this all during a massive lockdown that prevents other kinds of fun things that. 00:05:38 - Speaker 1: Exactly, it’s the best one. I highly recommend. No, it’s kind of the worst, and I feel honestly a little bit guilty to have like done so well during such a terrible time, but then at the same time, I’m very grateful. So there we have it. 00:05:55 - Speaker 2: Yeah, a lot of that hits on things that speak very much to me, and I think others that I feel like are in our field, however you want to define that, they’re making tools to help others create, which I think is in many ways a harder or more interesting product design problem. It’s one that maybe historically has not been seen as very sexy when you think of, I don’t know, productivity tools, whether it’s a word processor or a video editing tool or something like that. They don’t have the same kind of sleek attention to detail that often more consumer products do. Maybe that’s starting to change now and at least I hope a little bit this concept of a tools for thought field which we talked about with all the way back in our podcast episode with Andy Matuschek about kind of transforming. From the stodgy idea of, I don’t know, word processors have been the same for 25 years and very utilitarian and just the word design doesn’t get associated with them. Maybe that’s starting to change now, which I’m very excited about. 00:06:53 - Speaker 1: Yeah, I completely agree. And also it’s interesting because I think I’m young enough to have grown up with those tools and like been in Photoshop from a very young age, and there’s something. Definitely about them that is just so intimidating and so difficult to comprehend from somebody who is not like acclimated to the environment and doesn’t understand the principles that they operate on, and I think that that’s slowly changing, but it’s definitely like, it’s still happening, we’re still figuring out the best way to do it cause it is complicated, and they’re offering a lot of different things in the same place. 00:07:27 - Speaker 2: Yeah, one thing about computing in general and creative tools in particular is they’re just so new on a relative time scale. We’re still figuring it all out. There’s some established practices, but when you compare it to a lot of other fields where I don’t know if you’re a woodworker, the best tools for doing woodworking have been slowly refined over the course of hundreds of years, and here in computing we’re still kind of just banging two rocks together to figure out how to make things, so. 00:07:52 - Speaker 1: 100%, yeah, we’re definitely still figuring things out. 00:07:56 - Speaker 2: Have you found there’s any particular, I don’t know, skills or approaches that came from this kind of film visual design background that you talked about that translate well and give you unique insights that maybe some of your colleagues don’t have doing digital product design? 00:08:10 - Speaker 1: Hm, that’s an interesting question. I mean, inherently audio and video software is. Incredibly hard to understand, and I think that it takes a preexisting like knowledge and investment and really being able to go into these tools that are just like an incredibly blank slate, and they offer so much possibility, but where it is is like up to you to really figure out and even understand what you’re looking for. And so I think Having that background in feeling comfortable just tackling these like interfaces that are very unfriendly, honestly, it does help, and I think it also helps me to understand a lot of the principles that some of the other creative tools are just beginning to adopt, and there’s a lot of like efficiency and abstraction work that has been developed and cultivated in Video and audio tools that is just beginning to kind of pop up its head in just more simple, more like consumer everyday creative tools. And I also think that fundamentally having a background in like video is also just like a Background in storytelling, which is applicable everywhere, and I think it’s becoming even more applicable in tools like design tools and writing tools and being able to help foster those stories and also to kind of weave in the story of the tool is kind of an underrated thing. And it’s not the primary concern, but it definitely is a piece of the broader puzzle of getting people to feel comfortable enough to create in the tools. So there’s something interesting there, but it’s definitely still in its nascent form. 00:09:52 - Speaker 3: Molly, it’s interesting that you mentioned growing up with complex tools like Photoshop and that being a help in using other tools in the future. I didn’t grow up on Photoshop, I grew up on Kipics. I remember when I first tried to learn programming, the tools were so foreign and unapproachable that I almost completely bounced off the field. It was like VI, which is an incredible maze and like all the Java server side stuff. It was just completely wild. And it was only because of Ruby on Rails that I found something that I could basically get working and running end to end. And once you go through it a few times, you kind of calibrate on like how terrible things should be when you’re first learning something. But I do think a lot of people just bounce off these complex Pro Tools for a reason like that. 00:10:32 - Speaker 1: 100%. I feel very lucky to have become comfortable in them at a very young age, and that was through like pirating Photoshop and getting gifted a Wacom tablet and just really starting by making really, really rudimentary like digital art and things like that. But it definitely was like the type of thing that I would try to teach my friends and things like that and kind of bring it into other areas, and it was just not adopted. It was like my understanding and knowledge of the tool was something that I definitely took for granted for a very long time. And it definitely has made me think differently too about creative tools across the board of like, wow, if you really invest in like getting people in these tools at a young age and really acclimated and understanding how they work, like there’s a lot of potential there, but it’s not scalable. So like there has to be other approaches other than that, so interesting problem that we’re only beginning to run up into. 00:11:31 - Speaker 2: So our topic today is computers and creativity, which is not at all coincidentally, the name of your thesis which you published recently, and of course I’ll link that in the show notes here, and I recommend everyone go read it. Not only is it great content, but a beautiful presentation that really takes good advantage of sort of the web as an article format. So naturally folks can go read it, but maybe for those that haven’t yet, just to prime the discussion here, maybe you want to give us a brief summary of its contents. 00:12:01 - Speaker 1: Most definitely, yeah, so my thesis is really about how can digital creative tools best augment human creativity and collaboration. And it’s really looking at the potential of creative tools as co-creators with human beings and examining kind of returning to the original vision of creative tools and how we can extract some of the things that were realized and some of them that weren’t and kind of analyze that for the present of creative tools and to kind of contextualize that with an observation, from my vantage point, I really think that the power of tools lies in their ability to Amplify human action or thought versus the power of human beings is really about our ability to think creatively. And so if that’s true, then why do computers often ask us to act as almost execution machines ourselves to create something when that’s like very uniquely the computer’s strong suit. So the paper delves into a lot of different areas and kind of the history and analyzing the present, but The main point here and like the TLDR that I kind of reach is that to foster optimal human innovation, digital creative tools really need to be interoperable or basically talk to each other. They need to be moldable or customizable to different phases of the creative process. They need to be efficient abstracted, which is similar to moldable. They basically just need to Accommodate more or less complexity at different stages, and lastly, they just need to be community driven so that people can be inspired and get help when they’re creating. So that is the very abbreviated version of my very long blog post, but I’d love to dig deeper into all of that. 00:13:52 - Speaker 2: Yeah, all of that resonates very much with stuff we’d love to talk about here and things Mark and I spent a lot of time talking about. Yeah, I guess maybe to dig in a little bit on, for example, that first section where you look back at what you called the original vision or or sort of the history. And folks who’ve been banging around in the tool space for some time will certainly recognize a lot of this, Engelbart and K and Hypercard and Flash, and Dynabook and so on, but I think it’s one of the nicer collections of summarizing all that, that isn’t, I don’t know, a super long book, so it’s a nice way to get up to speed on that. Now, it is interesting with Sort of look at this history, which I think is often presented as kind of yeah, there was these amazing visionaries who saw the potential for computers and creativity, sort of laid out a vision way back in what seems like just the Stone Ages to us, the 1960s, the 1970s, and then in some ways we lost our way and we ended up with, I don’t know, social media and Kind of lock down appliance like smartphones and in fact there’s this glorious world of I don’t know, small talk and dying a book and mother of all demos style stuff that we still need to build or we haven’t built or something like that. Do you see it as like that’s an unfulfilled vision or the flip side could be, OK, well, they had some cool ideas, some of those worked out, practiced, some of them didn’t. The reason. We don’t have everything there is that maybe some of it wasn’t practical, and I’m never fully sure how to think about the kind of lionization that we do some of these past figures. 00:15:31 - Speaker 1: Yeah, I feel the same way. I think that there’s a lot of tension and just basically more analysis that needs to be done there. I think that it’s very easy to put these people on a pedestal and just say, wow, look at this incredible vision that they outlined, and we do that, and I think that they do present some really compelling ideas and their way of framing computers as being a tool to almost augment human intelligence is something that I particularly am pretty compelled by, but obviously a lot of their ideas did fail and there’s reasons for that. Um, and I also think that they were operating in an environment that was largely kind of independent from the actual business environment and like the technology sector as we see it today. So, like, will those ideas actually thrive in reality and especially in the consumer preferences and like relationship we have with tech today. Maybe not, but I think that they Still present some really interesting kind of principles and ways of looking at computers that we can definitely take some inspiration from. And I also think that like we rely on a lot of the principles that they established. And I think it’s just really important to like recognize that and kind of piece apart what we took and what we didn’t, and maybe what we can take more of or what we should reconsider. I just think that fundamentally This is great of history, especially in a field like tech, which is kind of in some ways pretty disconnected from its own history. And there’s almost kind of like a pride in that of moving so quickly that we don’t even look to the past. 00:17:10 - Speaker 2: Yeah, or I’d almost listed as a sort of willful disregard of history because I think there’s the classic, I don’t know, why combinator or startup founder. Out of school, it’s actually their naivety that allows them to reinvent, you know, they’re not dragged down by the legacy baggage of how we do things today. They can just think about it in kind of a green field way and dream up a new idea and maybe technology has changed enough that there’s new parameters and they can really do something new, but that comes at the expense of, well, actual naivete and reinventing everything. And not using scholarship of the past to learn what’s worked and what hasn’t in order to kind of stand on the shoulders of giants or build the way that any other field would. Of course, you learn from the past and then you use that to inform what you should do going forward into the future. And yeah, the young naive startup founder or other types that we hold up as our role models sometimes in technology are not into scholarship of the past, let’s say. 00:18:11 - Speaker 1: Very well put. I couldn’t agree more. Yeah. I’m very curious though to hear what both of you think of, as you put it like the lionization of Engelbart and Kay and all of those people, cause it seems to be a pretty disputed topic. 00:18:25 - Speaker 3: Yeah, this opens a quite an interesting door for me. My sense is that a lot of people look at what these early pioneers did, and intuitively they feel like that is good, it should have succeeded. Why don’t we have this? They had it 50 years ago, what’s going on? And at the same time, the current reality, like you were saying, is not exactly that. And I think it’s really important to understand why that is, and I think you were alluding to what’s happening where a lot of this study and analysis has been at the level of the tools. So it’s like what’s on the screen, how do you program it? What’s the user interface even, but there’s an entire complex system around how software is developed and used. And like you were saying, I think the reason that the vision for the software and the reality of the software don’t line up is because we haven’t understood or Accounted for how that ecosystem works. So sometimes I call this the political economy of software development. There’s weird path dependence, there’s economic incentives. You got to understand all of that if you are going to understand how we came to where we are now. And on the flip side, if you want to predict and guide the future in that direction, you need to become a sort of political economist of software and get in not only the interfaces in the code, but also the funding and the incentives and legal stuff and all that. 00:19:39 - Speaker 1: Hm, yeah, that’s very well put too. I definitely agree. I think there’s so much complexity and also just like context that’s missing from so many of the analysis of these past tools, and they’re very like independent floating ideas versus actually tangible grounded concepts that could be turned into something real. 00:19:58 - Speaker 2: I think a lot of what you both said to me kind of just describes that these folks were visionaries in the sense of also being sort of ivory tower academics or whether or not they were an academic, they were purposefully somewhat disconnected from, for example, commercial realities and that is part of what allowed them to have big dreams. And those dreams are still inspiring to this day, but then if those dreams are to become reality, at some point they do have to be connected to the real world, and this is a huge problem in research generally, which is there’s a technology transfer, how does something go from the lab or From that more idea space that science excels at into something practical that you can use and there isn’t a good path. This is something that the I can switch research lab where Mark and I are both participants is trying to improve upon, but yeah, it’s a really hard problem because a lot of times the same people, it’s a very different kind of person that can have the big dreams versus that can kind of make it into reality. And when you think of one of the most famous examples, Xerox Park, and some of the ideas they had there, and Steve Jobs basically got a glimpse of it. He was a guy that was good at actualizing things. He got a glimpse of it and then basically stole it and then went and made a practical thing. And of course, often the visionaries feel, no, you left out important parts, but leaving out parts is actually part of how you make something come to reality. So I don’t want to dismiss these historic folks as The academics that don’t know how to bring their ideas to reality. In many cases they did make great working software or even hardware that in some cases went on to turn into underpinnings of tools we have today, right? Small talk turned into Objective C and that, you know, fed into Ruby and. SWF and other languages that, for example, we use heavily on the Muse team, you know, these are very much things that are in the real world. But maybe there is an acknowledgement that the big dreams aren’t enough, you need to do something to connect it to reality. Yeah. 00:21:58 - Speaker 3: Yeah, and I also think there are two separate axes here. So there’s the axis of What are you looking at? So it could be pure software, or it could be called the software ecosystem, and then there’s the axis of visionary and idealist versus in the weeds pragmatist. And I think in our discussion that we might have been kind of conflating those two things, but in fact, I think you can have, and I think we need more visionary idealists on the political economy side of software. Probably the closest thing we’ve seen to that is the original free software movement and that obviously got some traction and made some progress, but I think we need to re-date that for the world of cloud and mobile, where the original free software vision basically broke down, I would say. Just as an aside, this is one of my favorite creativity techniques where you identify the axes, you know, the rows and the columns of the spreadsheet, and you label each row in each column, and you see often you know what the entries in certain of those boxes are, but you can perhaps intuit that one of the boxes hasn’t been filled. yet or given a name or explored and just by sort of drawing the map like that, you can identify new quadrants. There’s a cool research paper that I read on this about data structures where they kind of identified all the different ways you can build data structures and then found the blank spots in the maps and went and synthesized those new data structures just on the basis of this cell in the spreadsheet should exist. 00:23:24 - Speaker 1: So fascinating. That is awesome. I can like visually imagine that in my brain. It’s great. 00:23:30 - Speaker 2: Yeah, if it sounds like I have a critique for some of these historic visionaries, let me bring the positive side, which is I do totally agree that they did lay out a vision for computing that is grounding in a world where we do seem stuck in, yeah, social media, consumer, I’m not. Exactly sure what everything is oriented around commerce and again, things that are all good commerce, entertainment, these things are fine. I consume these, but the reason I got interested in computers at a very young age is seeing their potential for creativity and unlocking the noblest parts of the human spirit. And it’s a good reminder to go back and look at some of this history, maybe especially because these folks didn’t have any of that prior stuff. Computers were still so new, particularly personal computing was essentially, you know, they were in the process of inventing it, thinking what could people do if they had access to computers with graphics and networking and all the things that nowadays we take for granted, but they dreamed of something very different from the world we have today, and that can be very grounding to look back at that and take a bit of a blank slate from where we are today. So yeah, I personally take a lot of inspiration from all their work as well. 00:24:44 - Speaker 1: Totally agree. I think there’s something too very compelling about. At least for me when I was reading these texts, how they kind of frame computers as partners with human beings, and I kind of integrate that as like a co-creation relationship, which is definitely a very squishy one that I think we’re still defining, but there’s something that feels very like a breath of fresh air to think about the computer as like a counterpart instead of something that is Potentially replacing us or stealing our attention or something of that sort, even just asking so much of us. It’s more like, oh, the computer is here to help. And I think that that in particular is something that I hope we optimize more for in creative tools specifically, and there’s a lot of potential there. 00:25:26 - Speaker 2: Very well said. I do feel like more often than not in the modern world you’re stealing your attention as one example. You’re sort of fighting against the computer and perhaps it’s not the computer itself, it’s the whole world of computing, the internet, or email inboxes, notifications, the way that the web works, and so on that you’re often either fighting. Again this thing trying to make you do things you don’t want to do or take away your attention or distract you, or it wants you to do its chores, you know, click this, update this, do this, fill out this box, and it should be a tool quietly waiting for what you’re asking of it and to, as you said, co-create and help you in what you’re trying to do. I like this quote from the original Tron movie which is at one point the bad guy basically says, look, you know, the systems are overloaded because we don’t have time to handle every little user request, and the guy he’s speaking to is kind of the wise and old computer sciences, actually user requests is what computers are for, and I feel like it’s so often forgotten. They are here to serve us and sometimes it feels more often the human has to serve the computer or perhaps the business. Interests and I’m a capitalist, so don’t get me wrong, but the business needs, the KPI of whoever designed the product, it’s asking me to do things to serve that rather than my needs. 00:26:49 - Speaker 1: I love that quote. That is fantastic. I want that on a bumper sticker. 00:26:54 - Speaker 3: It’s great. Related to this, Molly, one thing I really appreciate about your thesis was you surface this idea of, I forget what you call it, but I would call it like vibe, basically, it’s like emotion, motivation, valence. I think that’s so important because if you have software that’s giving you a hard time, it’s not just a tactical or mechanical issue. It’s now you’re in a whole different mindset of, uh, you know, I’m dealing with the check boxes or whatever, and you’re much less likely to be creative and to keep doing it going forward and so I thought maybe you could talk a little bit in your own words about that aspect of creative software. 00:27:23 - Speaker 1: Yeah, I think that this is one that is like just beginning to form and it’s mainly because we’ve advanced to a point where there’s enough competition that we can actually focus on vibes or whatever you want to call it. And I think when I was writing about this, and it’s something I think about a lot. I definitely think about software like Figma, which I think that there’s something to be said for just bringing a more playful approach and just treating the user with more respect and really trying to validate them, not get in their way. It really comes back to establishing the baseline of being like a very good piece of software that does the job well. But beyond that, how you can actually differentiate the piece of software, especially in creative tools, it’s really just about like the personality and the kind of attitude that the software brings to the user, and I think you see that reflected in the way that it talks to the user and the colors and just little visual things and even just like the ambient environment of their landing page. It’s just very small things, but they do add up, and it in the increasing A larger landscape of creative tools, people are going to pick the one that they identify more with. And I think that that is incredibly interesting to me personally, from like a storytelling perspective of like how we can try to create things that are more inclusive to more people and just try to get more people in the tool that might not have a background and experience scaling these tools and really navigating these usually dark gray interfaces. But yeah, I think vibe is, it’s a nascent field for software. We’re still figuring it out. 00:29:04 - Speaker 2: So there’s a section in here titled Standardization, which I think is about file formats and ultimately is how tools work together and actually something we’ve talked about on this podcast before, including with Balant from Kraft talking about the different ways he wanted to try to have essentially toolmaker humility, which is realizing that the tool you were creating for your users. One of many that they are using and you should try to as much as possible, be a good citizen and work together, although in many ways it seems with the highly sandboxed world that we get in kind of mobile apps as well as to some degree, maybe the web and cloud, you have these silos and they just aren’t really designed to work together. So what do you see as kind of the future going forward from here for, I don’t know, tools working together? 00:29:51 - Speaker 1: I think honestly, if I had to pick one concept for this project that I really like strongly stand behind and is like the hill that I’m willing to die on, it would probably be this one. I think that the lack of interoperability or standardization between digital tools today really it means that all work created within a tool is confined to that tool, and to me that seems very clearly antithetical to creativity. And specifically the collaborative aspect of creativity. I think that there’s so much to be said for tools amplifying the power of our brains and really taking over the mechanical aspects of human thought and limiting creation to a single piece of software’s capabilities is just kind of crazy if you step back and think about it. And I just think that standardization and having tools talk to each other would just fundamentally change the tide of how we use them and introduce in more collaborators and really just expand the project’s constraints beyond any One tool. And this is a really hard one. Like, solving this problem is something that I feel like is a huge problem that I just don’t even know how to approach because it is pretty much in direct contradiction to the current business models of most creative tool companies. But I’d love to hear both of your thoughts on this because it’s a huge topic and it’s definitely one ripe with controversy. 00:31:28 - Speaker 3: Yeah, and just to expand on the motivation here, I think collaborating across tools can mean several different things. It can mean, like you were saying, you have a given project and at different stages of the project, you want to be able to use different tools. That’s one case where an open format would help. You might want to collaborate with other people. And they might want to use their own tools, which is different from yours. It’s another case. And also there’s this element of time where over time software tools tend to atrophy. Companies come and go, you know, platforms change, but you at least want your data and to be able to carry that with you in some sort of archive at least. So there are many cases where having such interoperability would be helpful. Yes, it’s extremely hard and by the way, I think this is a prime example of the political economy issue. It’s very easy to say we should have X, and even if X is relatively easy to do, which is not in this case, there’s still this huge issue of the. We should. That’s quite the weasel phrase, right? Really, it’s, if we were to accomplish this, we would need a bunch of companies or individual developers to temporarily make more work for themselves, lower their profitability, make their products worse for the customers in the short term to get to some other global maximum. It’s a case where the coordination problem is really important. 00:32:36 - Speaker 1: Completely, yeah, and it’s definitely like invisible work that does not really result in much actual profit for the company, it’s much more of like a long term investment that would require all the companies getting on the same page and really agreeing to terms and it’s really a long term relationship with each other too, which is kind of crazy to even fathom how that could happen. 00:33:00 - Speaker 2: I guess to highlight what I consider a bright spot or a positive version of this, I do think files on some of these flat file formats, which includes plaintext.txt, markdown. Image formats, PNG, JPEG, probably yeah, MP4 movies increasingly audio clips, PDFs. Now PDFs come with a lot of baggage. They are very complex to render, but ultimately there are pretty standardized ways to do that. And importantly, yeah, PDF does not demand. You have, for example, Adobe Acrobat, maybe it did at one time, but now it’s a tool you can open with. very standard viewers on any platform you can edit it and so on. It’s something we strive for in Muse because we kind of have this value but again where we are subject to the same constraints as others working with, especially making an app on a platform like iOS. But for example, we do store most of the raw, you know, when you drag an image in, we store that as a raw image in one of these standard file formats and in fact, if you do a bundle. Export you just get a zip archive that it contains as much as possible formats, you know, the ink is in SVG and that sort of thing. So we try to do that as much as we can. Now in practice, a muse bundle zip archive that has a bunch of loose media in it and is not sort of you know arranged on this board maybe is of mixed value. So I guess that does lead into maybe one of the more standard objections. The standardization, which is essentially that it is maybe counter to innovation. It creates a lowest common denominator. If every markdown editor, for example, has to support that format, if you want to do something interesting like make it really easy to embed video with captions of particular time clips, and that’s just not part of the format, so you just can’t do it or you break away and do something, you basically break the format in order to add that innovation to your tool. 00:34:51 - Speaker 3: I do remain optimistic that it can, and in fact will be solved. I think we will get a general purpose data medium that’s kind of like JSON is for the synchronous single user case. It natively allows collaboration. Obviously we’ve been working a little bit towards this with automerge and so forth in the lab, but I think it’s eventually going to happen, but it’s gonna take a lot of work and I suspect it’s probably not gonna happen by a bunch of people getting in a, you know, enormous room and everyone saying, OK, let’s form the consortium for X and do a two year study, and blah blah blah. I think it will be an organic, messy process led by some champions somewhere, whether they’re individuals or companies, but I do think it’s possible. And when we get there, it’ll be great. And like you were saying, we are, I don’t know if you were saying this on the podcast or if I read this in your thesis, but we’re relatively early in this world of collaborative software. It seems so obvious to us that you have Google Docs and Figma, but that’s I don’t know what, 10 years old or something, so also just gotta give it a little bit of time. 00:35:49 - Speaker 1: Completely, yeah, I think we’re still figuring it out and really trying to understand like what to prioritize and what is the most important in the long term and just beginning to think long term, that this is going to be around and I think we’re still like even developing the social norms and values that we as like the users and the makers like care about. There’s a lot of development still happening. There that is like incredibly interesting and I think it’ll all shake out OK, but we just have to like really nail down what’s important and how we’re gonna like think about this in the long term, because even though things like standardization are not particularly enticing, like if we want it to be around for a while and if we want our work to be compounding, then it’s like you said, increasingly important. 00:36:36 - Speaker 2: And we’ll offer as a counter example to the, you know, standardization and innovation dilemma, the web, where essentially there has been a lot of innovation on the web, but no one company owns that format, and perhaps there’s some complaints you can have about a particular browser monoculture at any given time, Google Chrome at the moment. It is truly an open format, you can parse it with a lot of different tools, and it will have, I think, the longevity that will go beyond any particular browser. 00:37:04 - Speaker 3: Yeah, and I think there’s some, we do a whole podcast on protocols and stuff, but I do think there are some important lessons in the web stack, one of which is they’re relatively thin layers, or at least the layers that work the best are pretty thin. So whenever you make a layer that’s an abstraction or protocol, you get the benefit of aligning some decision space, and if it’s a relatively thick layer, you get the benefit of you’re aligning a lot of decisions together, so there’s a lot of interoperability, but then you run a sort of exponential risk of one of those things being wrong and then the whole game breaks apart. So the layers for the web are thin enough that, at least in the lower layers, you could plausibly say there aren’t huge mistakes, such that people would want to go off and do something totally different, at least for the original web use case. So here in this case, I think we’re more likely, for example, to have success with the interoperability standard that’s more like JSON and less like address book standard format, right? Something that’s less like the business objects, or if you have those, they emerge kind of organically out of more general purpose data medium, so I don’t know, we’ll see. 00:38:03 - Speaker 1: Can’t wait to see. 00:38:04 - Speaker 2: We’ve hinted a few times, I think you’ve mentioned a few times kind of the the relationship between collaboration and creativity and the co-creation element, and from my perspective, this is a relatively new element of computing creativity. You mentioned using Photoshop, growing up on Photoshop. That was a private activity. Maybe you could send a file to someone else at very great effort by putting it on a floppy disk and carrying it over to them. But you didn’t really do that very often. It was typically a private activity and furthermore, I think for many creativity is often something that is a little bit done in private. It’s sort of this vulnerable act, but then perhaps that’s changing partially because of collaborative software like Google Docs and FigMA and Notion and others. And in fact, we had a whole episode with Nicholas Cline from Sigma, who I think you might know, basically talking about, he’s also a younger guy, and I think, you know, for him, there is less of this creativity is this thing done in private, of course you make stuff together with friends, with colleagues. That’s just how it’s been. So maybe that’s culture is changing partially because the tools are changing. But for the purposes of computers and creativity and how you see it Molly, what do you see as the relationship between creating together versus a more private activity? 00:39:25 - Speaker 1: I think this is a really interesting one, and I think we’re still figuring it out from my perspective. I think creative tools, ideally should accommodate for both, um, from my perspective, I think right now they kind of still fall into two buckets of either solo or collaborative and collaborative in like the Google Docs or FIMA sense. And I think there’s immense value in having tools that do both. They optimize for incredible solo creation and incredible multiplayer building upon each other’s ideas, and I admittedly, I think I lean more in the direction of like how Nico thinks about these things of allowing in more collaborators earlier on and feeling comfortable doing so because I grew up with these tools in a fully collaborative Google Docs form. But I do think that what’s interesting here is that these tools are so new, and we’re still just like as human beings figuring out what is expected and like what does ownership mean in these environments and just trying to establish like social norms there, and that is like a very squishy one that I think will just take time. But for me, this really just like reinforces the value of moldability and ideally the tool would just accommodate, like I said, both solo and collaborative work and provide you like the resources and tools that you need to create those environments for yourself because I think Tools being less opinionated about an assumptive about what you need in those modes is going to be a great thing. I would love to see for tools to give you the features that you need to really create your unique creative space, whatever that looks like. And I think this also comes back to what Niko was talking about when he was talking about like the flywheel effect of collaboration. And really creating in the same spaces and building upon each other’s ideas. I think that that is a very different mode than like the solo creation kind of brainstorming, but ideally the tool could scale to both. So that’s like my current thinking. But I think that’s really hard, and I think that that’s two completely different things and optimizing for very, very different, almost in some ways audiences like those are sometimes the same person, but oftentimes they’re not or they’re a different subset of people and I don’t know, I think news is an interesting example here too, and I’m curious to hear what both of your thinking is because obviously that is optimizing more for the generative like solo environment in a really wonderful way. 00:42:03 - Speaker 2: Yeah, the challenge of a true thinking tool and really, you know, we’re trying to cover the very earliest part of the ideation funnel, let’s call it, or the creation funnel, which is that early ideation where you normally use a sketchbook or a whiteboard, something that is not at all intended to be a final artifact, but is about figuring out what you want to make in the first place or making a decision or just forming up your vision rather than any deliverable artifact. And that is something that does tend to be maybe creativity at its most private, like something about a sketchbook is just something that you really feel is truly private. And in fact, you know, we’ve been looking into things to try to add some collaborative capabilities, hopefully building on our values around privacy and sort of a calm sanctuary and all that sort of thing, but it is a real challenge. We could easily lose what’s good and we have even heard from Users and customers, they say no, or they’re worried, right? They say, I don’t necessarily want you to add that because then it’ll turn into this more chaotic environment that I associate with these team spaces, for example. So, I think there is a way to cut that Gordian knot, but it’s a huge design challenge, obviously. 00:43:16 - Speaker 3: Yeah, the goal is definitely to eventually accommodate all the different types or topologies of social or non-social collaboration, and it is my hope that we’re able to eventually do it in one tool, because as you have a project, you tend not to want to be jumping around through different tools, or at least to do so only with very good interoperability, and every time you do do a jump there’s a bit of an activation energy costs. And yeah, as we’ve studied the creative process by talking with creative professionals and in other ways, we have found that there’s maybe a half dozen different typical topologies. There’s you’re basically ideating alone, there’s call and response feedback, there’s real time, kind of everyone at the whiteboard collaboration, there’s a sync building up a corpus together like a tracker, uh and there’s like presentation and sharing in real time. And I think it’s possible to get all of those in one tool, but it will take some time. The reason we started with the initial ideation phase was a felt like that was the most underserved, and the one we had the most unique angle on, and also there’s something to doing the first step first, if you will, just in terms of building up the full user journey over time. 00:44:25 - Speaker 2: One thing I do imagine with any tool that has both collaborative capabilities as well as solo capabilities, and by the way, exactly as Mark said, collaborative actually covers a whole host of different modalities, even just talking about synchronous versus asynchronous, for example, I think one of the big things we’ve learned. From Google Docs, it’s not really about the real-time collaboration. It’s about having a document you know is up to date and in practice it probably is asynchronous. You sent it out, you shared it out, and someone added comments or added something to it while you were asleep, and then you’re looking at it again later, so it’s asynchronous, but you know it’s up to date. But I think if you’re clever or if you’re able to find the right combination, it shouldn’t be hopefully you’re serving those two audiences or the whatever all the modalities are, but that each one needs their own features and then pretty soon you’ve got this overstuffed product that does too many things that in fact you can find things that serve many or all of those cases. One great example to me, which is very much about creative process and how you work as version control as a developer. The first really good quality version control system I used was something called CBS many years ago. It’s kind of a precursor to this version, and then that was kind of replaced by Git in the world of decentralized revision control. But in any case, when I discovered revision control was sort of pitched as well, this is so you can work with someone else. And so in theory you don’t need it if you’re on a solo project, but I really quickly found, oh actually this is really nice. It brings a sense of OK, I’m going to work on something for a while and then package that up into what I would now call a commit, give that committed name. I can look back at my own history. I get kind of a log, you know, an undo, sort of like a large scale undo history, but it also creates a lot more structure for my own thinking about it. Obviously that’s made its way into now this collaborative space as well, which is when you’re writing the commit message, it’s for yourself, understanding what you’ve done, but also for your colleagues, so they’ll be able to see what you’re doing. And so it feels like a lot of the tools of revision control or a lot of the features of it, including how the discs work and how commits work, and all that sort of thing, both serve an individual working on a solo basis, maybe collaborating with themselves through time, you might say, and a small team or a big team working together on something. 00:46:44 - Speaker 1: Yeah, 100%. I think it’s also just like retraining ourselves a little bit to once we acclimate to the standards of like a collaborative tool or something that’s optimized for that, usually that actually directly translates to the more solo experience, not always, but I mean, having different practices in different areas, that doesn’t seem particularly intuitive either, um, and a lot of these. Processes for organization are applicable everywhere. There’s a lot of crossover between the features. I think it’s just about like establishing where we are and really like, I think making people more aware of where they are in their creative process is something that’s going to become increasingly relevant to, and that’s something that we’re still kind of figuring out in creative tools is like, which tool is used for what and like how do they, again, how do they talk to each other? Can they talk to each other? And how are we going to like use them together, which is like the bigger question and very difficult today. 00:47:39 - Speaker 2: I’m definitely a fan of the pipeline approach, at least in my own work, which is, it’s less about that I want to use 3 different tools simultaneously. At one stage, but more at a particular stage, I’m using a particular tool, so that’s the case for something like writing, where when I’m trying to figure out what I want to say, I’m using news or sketchbook or some other ideation tool for thought thing. But when I’m writing, that’s actually not the right thing. Now I want a writing tool, a scrivenner, a craft, a Google Docs. But that’s not my publishing platform. From there I’m going to go to something that’s usually on the web, but it might also be in PDF or it’s Lawtech if it’s an academic format, and sort of at each stage, in a way, the transition to the new tool, which does involve some labor to translate it across, even when they’re fairly interoperable. For me, it’s almost good for my creative process because there’s this little ritual of now I’m ready to jump over into this next stage, it’s graduated. 00:48:37 - Speaker 1: Totally, yeah, and I think acknowledging that process and paving the way and making it as seamless, but also I don’t know, building in the opportunity for you to use that as a point of reflection and almost editing cause I totally relate to that as well as like moving from ideation to first draft or something like that. That’s really like also uh editing and refinement moment as well, and you don’t want to cut that out completely. So it’s again kind of letting people choose how they want the tool to behave. I think it’s gonna become increasingly relevant for creative tools. 00:49:12 - Speaker 3: Yeah, I think this idea of acknowledging is really important. So there is the underlying platonic ideals of multi-step creative processes of social creative processes, and in fact it’s like always has been, and we can link to the always has been me here. But people have always been, you know, taking pictures of their whiteboard under their phone or like shuttling around USB sticks in the case of social collaboration. So I think if you do the careful ethnographic research and take off your blinders about what software we currently do or don’t have, you’ll see these underlying patterns and a lot of what we’re doing with Muse and a lot of what we talked on this podcast is how do you align the software with those platonic ideals of creative work. 00:49:51 - Speaker 2: All right, Mark, I think you’ve signed yourself up to create the always has been meme with that content that we can include in the Twitter thread for this episode. 00:50:00 - Speaker 3: All right, I’ll bust out the meme editor. 00:50:03 - Speaker 1: Cannot wait to see it. 00:50:06 - Speaker 2: Now when I’ve worked on really long pieces, sometimes 5 or 10,000 word pieces we did for ink and Switch or the 12factor app or other larger pieces, for me it’s the case that you ship not by finishing writing everything you want to write, but by choosing to cut out a lot of it. And so I’m curious what things might have ended up on the cutting room floor that you think are worth telling us about here. 00:50:29 - Speaker 1: Oh man, so many. I completely relate to, I think it’s so hard to know when to ship something like this, and my current rule of thumb is like, if I have way more questions, but I know just how long it’ll take to investigate them. And it’ll kind of distract from the focus of the piece. That’s when I’m like, OK, maybe I’m getting closer than I thought I was. But in terms of ideas that I’ve cut, this project actually started off focused on flow state, and I was very interested in how software could facilitate more flow state in human beings. And that’s a very broad question. I realized that’s exactly why I cut it, is because it is actually, the deeper you dig into. flow state, the more you discover that it’s very subjective and the definition of it is still kind of up in the air, depending on the discipline that you look at it through. So while it’s super interesting, that is definitely something I cut, but not before doing a lot of research on kind of the psychological conditions and what goes into flow state and how people report to experience it, which I think is really interesting still. And I would love to write a whole another thesis on that. But it’s still a tough topic to nail down. 00:51:46 - Speaker 2: And just to briefly define that one this is probably one of the most quoted or cited concepts from modern psychology, which is there’s a state that I think originally they were looking at athletes maybe when they’re sort of at their peak performance, but maybe in our own lives we’ve experienced this on running. Or doing some kind of sports or something where you’re just in this well state of flow where everything seems to come effortlessly and it seems like you’re higher, somehow you’re questioning brain narrator shuts itself down and you’re just in the moment in a way that’s very satisfying. And we talk about this a lot in the tech industry because of, I don’t know, even just a simple thing like making sure you have big blocks of time to really focus on stuff. We’ve talked about deep work, for example, that concept here before, but the idea that you want to optimize for flow state and yet technology and especially The internet now is so kind of anti-optimized for that that it wants to offer you information about things that are happening in the world and messages and notifications about everything that in the right moment can be connecting, but when you’re in flow state can be distracting. 00:52:53 - Speaker 1: Yeah, it’s a really rich topic and it is interesting too something I realized in some feedback that I actually got when I was focused on flow state specifically was more academics, but they were like, what is the relevance of this? This seems like something that you’re just throwing in as like a buzzword to get people to immediately understand that you’re talking about deep creativity, but do I actually know what flow state is? Not really. And I hear that. I think that that’s true. I think we still need to kind of define what it looks like in different contexts. And that was kind of the reason that I decided to broaden up the inquiry to just look at creativity more broadly, because I think it Functions in a lot of forms, then you don’t have to be completely 100% into your work and thinking of nothing else and just ideas are flowing. Like there’s other forms where it’s more generative, or maybe you’re building upon other people’s ideas, and that’s not encapsulated into flow state, which is interesting, and I almost think that that calls for a more definition of like what creativity looks like in human beings, but that’s another topic entirely. Another topic that ended up on the cutting room floor was actually just more closely examining the emergence of more collaborative software and like what that looks like and actually basically examining the social conditions and the psychological needs that we have when we’re in collaborative environments because from my vantage point and I feel like the collective experience of most people, it’s kind of just been a free for all, and we’re still figuring it out, and there’s a lot of potential, obviously, and we’re already benefiting from it, but it’s interesting to think about kind of returning to Some of the work that’s already been done in like academia that looks at what people need to feel comfortable collaborating and almost like in the context of arts education and creativity research, there’s a lot that can be pulled from that that is obviously much more squishy. But it also has a lot of applicability to thinking about plopping people into creative environments and expecting them just to immediately generate ideas. I think that that is a common theme in a lot of tools today, especially collaborative tools, and I’m very curious how we can try to kind of break down what we know about human beings to address like their common concerns and possible drawbacks from the current experience. 00:55:24 - Speaker 2: Yeah, obviously when people talk about collaborative software, it’s very easy for that to quickly get into design or even very technical things of, you know, is it using operational transform or CRDTs, and there’s very hard technical challenges that we’re still working on, but the social side of it, the social norms as you’ve mentioned, and also people adjusting their own attitudes about what’s expected of them or what they can feel comfortable doing. You need to be comfortable to be creative, and we’re still figuring out how to do that well. I’m reminded of Tuckman’s stages of group development, which is sort of a psychologist looking at just how teams work together, but really just any group of people, and that there’s kind of this process, these five stages that that they define, which is this forming, storming, norming, performing, and mourning, just sort of how the team comes together, but what I thought was really interesting is once I’ve read this, I can spot this. Not with just any kind of team loosely defined. As a company or a subset of a company, but really any combination of people doing anything, even friends planning an event together or something like that, and there’s typically these early stages where everyone’s super polite and they don’t wanna step on any toes, but actually that stops you from really getting into it and really the true creativity happening, and then there has to be some level of conflict and discovering of roles in the group through, yeah, friction and problems and Even fights or whatever, and then social norms emerge from that, and then that’s when you really go into sort of the magic time, they’re performing stage because it’s sort of all figured out how to do things, and then you can be truly creative. 00:57:05 - Speaker 3: This also reminds me of the satir change model, which is a similar idea, maybe just generalize a little bit, where when things change, they don’t get uniformly better. It’s not all up to the right. You have some foreign element that comes in and instigates the change, and then you go through a period of chaos where your performance is worse, people are scared and they’re reluctant, and then eventually you got to find some transforming idea to bring you into the period of better performance. The way this connects back to this collaborative software discussion is. I think when we first introduced from a technological perspective, the ability to have real-time collaboration, that was a sort of foreign element where you have some of the things that you would expect with collaboration, like you can see what other typing, but you don’t have, for example, body language on facial expressions, you don’t have vocal intonation. And and so it feels like weird, like, basically you’re in the chaos of this Google Doc feels weird or something. But then we have things like, you know, emojis and so and so is typing and things like that and avatars that float around to show you where people are in the document. And so we’re building up the set of practices that will eventually allow people to have higher performances teams. 00:58:10 - Speaker 2: Even an initial negative reaction to why would you even want that. I remember when Google Docs came along, I actually used it when it was right before they were acquired, and that collaborative element, I said, wow, this is great that I can send a document to someone they don’t need to have Microsoft Word installed. We always know there’s the wrong latest version, and I tried to pitch people that I was working with on using it or saying, look, let’s use this tool because it seems so obvious to me this is A good way to do things and very often reaction was like, oh, like I don’t want people to be able to like see me typing or I don’t want other people to be able to edit my stuff, you know, I think maybe Figma relative to sketch actually had some of the same pushback as well. I don’t want people messing with. My designs that kind of a thing, and I think that’s quite natural, which is when you have existed in one paradigm in one set of capabilities, you take for granted that those capabilities or restrictions that that box is exactly the shape box that you want something new coming along offering new capabilities, you might even see those as anti-features. 00:59:16 - Speaker 1: 100%, yeah, I think that there’s there’s so much just push back and discovery we still need to do about people’s expectations in collaborative environments, and I think that there’s a delicate balance to be had to where
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: I do think there’s a distinction between velocity and virality that’s important to make, right? Like a good book can go viral, a podcast can go viral, it just will go viral slowly, be a slow spread, and I think that’s actually kind of a goal is to have potentially like a low velocity, a high virality. 00:00:21 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for thought on iPad. This podcast isn’t about Muse the product, it’s about Muse, the company, and the small team behind it. I’m Adam Wiggins here with my colleague Mark McGranaghan. Hey, Adam, and our guest, Tobias Rose Stockwell. Hey there. And Tobias, Mark and I just recently did an episode on video games and how Mark’s thesis that video games are where technologies kind of emerge first and later they make their way to productivity and enterprise software and that sort of thing, and I feel like our meeting, which was in an online game, a text-based. They called them back then in the 90s was a good example of this. We knew each other virtually before we ever met in person for, I don’t know, a year or more. And nowadays we take for granted that you meet people and even have great friendships, I think in, you know, your Slack channels or online conferences or colleagues you’ve only ever met through video calls, but I feel like that was quite unique for the time. 00:01:22 - Speaker 1: Truly, truly, I remember your characters on the mud, you had to. An amazing automation system in place for your characters, you just, yeah, you crushed that game. 00:01:32 - Speaker 2: That’s right, I totally forgot the mud world because it was all tech space, almost kind of had a Unix style in that sense, you would type commands and you would see these descriptions of what was happening with the action was very scriptable because you could make what were called triggers where you would essentially say, OK, if when you see the word you When you see someone’s name react in this way, when you see this happening, you could cause it to trigger another command. People would do in some cases very sophisticated scripting. I used a thing called Tintin. I think I was pretty simple with it, so I’m glad to hear it seems so impressive, but I think that did probably influence a lot of my thinking on kind of end user programming, personal scripting world of things. 00:02:12 - Speaker 1: Yeah, it was super impressive. Like this guy knows what he’s doing on here. 00:02:15 - Speaker 2: And Tobias, maybe you can tell us a bit about your background, what you’ve been doing kind of in the post mud time and then leading you up to what you’re working on now, which connects to our topic today. 00:02:25 - Speaker 1: Absolutely. Well, thanks for having me, guys. I really love what it is you’re working on and I always appreciate your Analytical and pragmatic perspectives on the world, understanding things in a more precise way. You know, we’ve known each other for quite a long time. I feel kind of honored that you have known me through several phases of my life, different chapters of my professional endeavor which have brought me here. But when I was really quite young, I went and lived and worked in Cambodia for ages of about 23 onwards for about 6.5 years. I lived and worked on the ground in Cambodia. Crazy wild story for how I got there, but essentially met a monk when I was traveling through Asia, who was looking for help in rebuilding this irrigation system. It had been destroyed during the Civil War there, got sucked into this project that I thought would take maybe 1 year, I ended up staying there for 6+ years, rebuilding this big reservoir that affected farmers and helped them rebuild after this very, very problematic time. And just was very, very interested in what I could do to most, help people figure out how to improve their own lives, and ended up rebuilding this irrigation system, getting interested in scale, interested in the motivations behind helping people help others more effectively. Which ended up, once I finished the project in Cambodia, I ended up coming back to Silicon Valley, where I grew up and started working on various projects to help people connect more effectively to humanitarian causes, and this was between 2009 and 2012, and it brought me to the world of online advocacy and really this is the earliest days of social media at scale, and I was part of this cohort of designers and technologists and Developers and documentarians that were really doing their best to try to motivate people to capture altruistic action from the largest possible audience, right? There was this promise around these tools that was very kind of intoxicating at the time, this kind of inherent goodness that could come from connecting humanity. And there was this thesis, this broader thesis, I think that was implicit at that moment, which is, you know, if you can connect the world, like we can solve the problems of the world, right? If you can just make people feel, if you can make people feel the poor people in India, the people that are struggling in Southeast Asia, if you can really just connect people to the feeling effectively, then you’re gonna come much closer to solving those problems, and that optimism was very real at that time. And it bled not just into the advocacy world, but I think it was very much a part of Silicon Valley at that time too. So I worked on a bunch of campaigns that were really trying to capture virality and maximize human attention and get people involved with causes, get people to feel, and that was its own very special era. I worked on a few campaigns that reached millions of people, it was very exciting time, and the tools enabled that in this very special way, and I was part of this cohort, you know, I’ve known. People similar to you have known many of the same people that were early at these companies that believed that these tools were fundamentally good for the world and, you know, in many ways they are, but I think that, you know, as we’re saying, there are questions about some of their byproducts. So fast forward a few years, I was working in New York doing design and management consulting, basically helping the executive teams of very large media organization that kind of storied in traditional journalistic institution that you would know if I named it, that was their executive team as the bottom was falling out of their business and they were trying to figure out how to Make money in this new media environment, and I was watching them as an institution begin to make decisions that reminded me fundamentally of types of attention capture tools that we had used. And the years previously, and they were making decisions that were very much based on trying to utilize this new media environment that many of my friends had built in such a way that I think we would recognize today as problematic, but at that moment in time we didn’t. They were really starting to change the editorial tenor of the stories that they were making, of the tools they were using to capture attention, and it was changing the editorial bent of stories of content and pushing it towards the extreme. And this was in 2014, 2015, you know, just the years leading up to, I think our great awakening to some of the problems associated with the stuff that came in 2016, but they were really fundamentally changing the tenor and the content of stories to capture more attention using these tools and these strategies. 00:07:16 - Speaker 2: This is what maybe nowadays we talk about is the classic clickbait titles and yeah, emotional activation that’s designed to in a very short time just get you riled up or activate some more primal part of your brain, and maybe that ties to your nonprofit work as well, which is also about emotional activation. But here you have this media environment where they have a very brief time to capture. Your attention and they’re just basically motivated to optimize for these headlines that push these buttons and activate you emotionally, even if that’s not sort of good journalism or really a healthy information ecosystem. 00:07:50 - Speaker 1: Definitely, yeah, and it’s not just headlines. The headlines are the most visible things. The stuff that tends to be a little bit more pernicious is the editorial decisions that are made around stories to cover like what to cover, right? Journalism is this kind of important function. I see it as having three different fundamental pieces to it. One is the basic verification of facts, right? It’s like, did something happen? Did the event happen, did it not happen, right? The next layer up is selective facts, like which facts are actually important for us to pay attention to in the world, right? And the top one is really like why does this matter? It’s editorialization, like why is this important for us to pay attention to? And what I felt like I was watching in real time was that the selective interpretation of facts that the sourcing pool that editors and journalists were using to start trying to kind of find nuggets of stories, they started to trend towards the outrageous, they were finding the stuff that would make people the most mad, right? You might see this in a headline and a story in which the headline will be, people are angry about X, right? You said, well, people are angry about X, wow, this is important, I should read why they. angry about X and then you look at what they’re actually sourcing for the quote unquote people that are angry about X, and it will be a Twitter user, maybe two, that have, you know, some 20 followers that a journalist was able to kind of go in and find they kind of spun a story out of almost nothing online and wrote a whole article about it, which is terrible if you’re you’re trying to get a proportional understanding of what people are actually angry about out there. And that’s just one strategy of many that are now available to every journalistic institution or traditionally journalistic institution. 00:09:36 - Speaker 2: For me, the first article of yours that I read that I think got a good bit of traction was titled This Is How Your Fear and Outrage are being sold for profit. Where you kind of broke a lot of this down, and I think nowadays as part of the mainstream discussion, especially with something like, for example, this Netflix documentary, the Social dilemma, yeah, I think we have more cultural awareness of this now, but at the time, for me it was a real eye opener, even being someone that was in technology that you were kind of breaking down the mechanisms, just sort of shining a light on exactly how You’re being emotionally activated or even emotionally manipulated and why that’s good for these media companies in this new era, and then you went from there on to a series of other articles including the dark psychology of social networks, which I think was a cover story in The Atlantic with Jonathan Hay, is that right? Getting to write with a high profile author, which is a whole other probably interesting topic to discuss. Your latest article, which is how to stop misinformation before it gets shared, collaboration with Renee Dresta Unwired, which talks a bit about this kind of friction and so to me these paint and you’ve written other stuff, but if you read the three of these, and of course we’ll link them in the show notes, they show a building up of what feels to me like a thesis or a sense of trying to understand or grapple with the societal effects of this new information technology that defines our world now. 00:10:58 - Speaker 1: Yeah, I feel like that’s right. So the second piece you mentioned, the piece with Jonathan Haidt at NYU, he’s a professor of moral psychology, and we did a almost a forensic unpacking of what happened between the years of 2009 and 2012 in terms of the feature sets that were implemented at these various companies, invented then copied, then propagated across our traditional social media kind of ecosystem. And what that did, what these specific features did, and it’s a few features that we very much understand today as being kind of core to our information exchange, but having a simple one click share to send a piece of information out to your entire network. Likes, right, like fundamental likes and visible metrics associated with that content. And then the ability to algorithmically sort of feed. There’s kind of three pieces of the puzzle have dramatically changed the types of information that we are now seeing on a regular basis. And like each one of these features in themselves are great. I appreciate both the ability to reach a massive audience. I appreciate the signal that comes from knowing whether or not people are liking a thing. And I appreciate the ability to curate the crazy massive stream of information that’s not coming my way, but each one of them has kind of conditional failure modes that I think we need to understand and reckon with because Having access to what’s essentially kind of the brain stem of humanity now, right? If anyone can put something out there and anyone can make something go viral, there are tendencies within the system now towards what Daniel Conman would call System one, right? System one thinking being this emotional, reactive, impulsive, kind of instantaneous, fast thinking. Right, which is one of these partitions in our brains, and the other being System 2, which is this more reflective, deliberative, slower processing and thinking, that the entirety of the architecture of the internet in its current form, it’s built for maximum speed and morality, it’s orienting towards system one. And that I think can be seen in so many institutions and so many changes and so much of the zeitgeist of our exchange now is in this kind of emotional space. 00:13:27 - Speaker 2: Yeah, and I think that’s a great tee up not only for our topic today, which is the promise and peril of social media, but also what the muse tie-in is because a lot of what we talk about on this podcast is product design, but it tends to be more tools for thought, productivity, kind of more private things versus these public sphere, you know, political and social discussions. But I think there is, when you talk about that System 1, System 2 brain, a big part of what we want to see Muse do or part of what our mission with our product and the company is, is to help us all activate our system two brains more reliably. Then when we realize there’s something important we need to think about whether it’s in life, work, social issues, what have you. that there’s a way to kind of remove yourself from that energy and those outrage circles or even just the heightened emotional, more primal state and go to a more thoughtful, reflective, slower thinking because we believe at least as complex as the world is today, you sort of need that in order to really make good decisions. 00:14:30 - Speaker 3: Yeah, in addition to the System one versus System 2 access, I think there’s an axis of de novo ideas versus remixed ideas, and I think basically all good ideas are social, they’re remixed, they’re transmitted from other people and developed that way. And obviously, social media is an incredibly powerful technology potentially for facilitating that. And so we use the product right now, it’s quite single player and it’s focused on developing content. You bring in content and you build from there, but I think if you look at the broader process of thinking and developing good ideas and coming to useful conclusions, the social ecosystem is so important. 00:15:09 - Speaker 2: Yeah, and I have my own, I think there’s a lot of creative people do. Twitter is certainly my social media of choice. I’ve heard it described as sort of the social network for ideas, and if you’re a person that’s, you know, looking to seed ideas in your work in your life, I think Twitter is the right place for that, but it has these two sides, which is it can be a source of incredible ideas. Inspiration, connections with new people. Certainly that’s where my professional network is. I’ve met many amazing people, including a lot of the guests for this podcast, but have just had the seeds of good ideas so often. I mean, there’s a reason why we want to add a lot of media cards to use, but one of the first ones we did was a Twitter card precisely because bringing in a thought provoking tweet. As a foundation for some deeper thinking is a very natural thing. But the flip side of this is what you’re talking about these loops for journalistic outlets and individuals as well, seeking that the sweet, sweet dopamine hit from those likes, right, and you discover that those controversial or outrage generating things or things that just do those emotional System one activations get you. More of that positive feedback and so then you’re sort of inclined to do that and it just creates a setting where you have these kind of information pathologies and negative loops and yeah, it sort of is very counter to the thoughtful, having good ideas, focusing on your work. So there’s this duality, there’s these two sides of it that I feel are equally strong. 00:16:39 - Speaker 1: Yeah, that’s really important. As you spoke about how the general zeitgeist has kind of absorbed some of these memes about the internet being a place that prioritizes outrage and the people tend to kind of understand. The problems associated with this now, there’s, you know, a lot of great content out there and a lot of talking heads that speak about the ills of technology. I do think that the hyperbole around it is actually kind of a big problem. I think that if you’re too hand wavy about what the problems are, then it actually doesn’t help us solve them. It doesn’t help us build better tools, doesn’t help us fix the tools we have. I think it actually just is pretty detrimental to the conversation as a whole. 00:17:21 - Speaker 2: Right, so there’s this progression where I don’t know in the Mid late 2000s, it was the sense that this up and coming new information world was unmitigated good, kind of a sort of exuberance that in hindsight seems naive. Then sometime around the time you’re writing these first articles, 2016, 2017, 2018, there’s a few folks like yourself that are kind of raising the flags and society struggling to figure out, wait, what happened here, things are changing, maybe in a way we don’t like, it seems related to this new technology, you know, what’s going on. And then you come to today, and again I do feel there is a more mainstream sense that OK, social media is this powerful technology, certainly these internet giants in general wield a lot of power. It does seem sometimes boiled down to uh Mark Zuckerberg is the devil, if we can get in from the front of Congress and slap enough regulations on him, then everything will be OK. It feels like a vast overciplication that feels like this is a to borrow one of Mark’s way of talking about things that Society needs to metabolize the change, and that’s going to take some time, and we need to thrash around and try some weird stuff, and maybe some of the solutions are governmental, some of them are technology product solutions, like some of these ones you’ve proposed in your various articles here, and some of them are personal, right, how we choose to cultivate our information diets and make good choices that will allow us to get the most out of this brave new world of information without being maybe sucked down its worst rabbit holes. 00:18:48 - Speaker 1: Yeah, I don’t know if either of you had a chance to catch the tech hearings that happened a couple of weeks ago. 00:18:54 - Speaker 3: I feel like there’s one of these every month, so I feel like, yeah, totally. 00:18:59 - Speaker 2: I’ve seen some of them, at least for understanding what happened there, I rely on people making dunk tweet jokes. 00:19:06 - Speaker 2: You’re part of the problematic, and then I extract what happened based on that, yes, yes I am. 00:19:09 - Speaker 1: What was very clear to me, and I took notes of how many different members of the house had their own personal grievance about technology. I’d made a distinct list of 18 different areas that were very much not related, other than the fact that they involved Facebook, just this whole kind of panopoly of different grievances that they had and what came to mind for me is this. This is not just technology’s fault, right? Like we’re just inhabiting technology more and so we’re bringing all of our problems with us, right? We’re now just living in these digital spaces more and more and more, so we’re bringing a huge portion of these problems with us. Now that doesn’t reduce the importance of focusing on the tools and the specifics of the tools, but I think it is important to remember that humans are complex and our problems are complex naturally. If we add a whole new layer of kind of virtual existence onto that, we’re going to end up with a bunch of new problems and also all of the old ones manifesting in a different way. So I think it’s just important to recognize that a lot of these issues are things that we’re bringing into the fore with us. 00:20:17 - Speaker 2: Yeah, part of the concern would be technology is an amplifier for some of our natural sort of bad traits. We’ve made the comparison before to food, for example, where we came to this realization that a lot of fast food is actually quite unhealthy and feeding into a lot of health problems in the modern world, but that’s because it was sort of optimized to push our sweet and savory and salty buttons because these are Tendencies we crave these things in our natural environment, but we’ve found a way to kind of like supercharge what you get in a way that has these negative effects. And I feel social media has a lot of that. For example, follower counts, I think is what I hear folks talk about, which is like we have this natural status seeking behavior and getting a certain number of followers shows that you’re, I don’t know, important, you have prestige, people care about you or something like that. And so then that turns into weird status games maybe of trying to game the system or just treating people differently based on their follower accounts or whatever and you know one question there is should we hide that because that basically just brings out some bad qualities in us. On the other hand, will people find other ways to seek that same because again it’s not the technology that’s something that’s inside us as humans is to kind of be status seeking. 00:21:31 - Speaker 3: And just to elaborate here and to further motivate, I think there are a couple other dynamics that are making it even more important. So there’s this baseline dynamic of there’s like a very high powered social technology and people have always talked to each other and written stuff down, but now just like a lot more of that with much sharp edges. OK, that’s kind of what we’ve talked about so far. There’s an additional dynamic that I would call the revolt of the public na. This is the, I think his name is Martin Gary thesis, he wrote an amazing book about how basically people able to talk to each other outside the confines of traditional hierarchical structures is highly threatening to those structures, and this would be like traditional journalism, bureaucracies, higher education. And those institutions correctly perceived this huge existential risk, so there’s some kind of fighting for their own lives happening there. And then another angle is a lot of the most contentious stuff has to deal with politics, and the reality is that politics, especially federal politics, play a much bigger role in people’s lives. Now than it has in the past, you know, government spending is what, 40% of the economy plus all the indirect impacts like people are correctly interested in what’s happening there. So these three things stacking on top of each other and creating huge stakes. So it’s not surprising to my mind that people have strong feelings about this stuff. 00:22:42 - Speaker 1: There’s a great article, a Paul Graham article from, it was 2007, 2008, the golden age of Paul Graham essays, 00:22:50 - Speaker 1: so to speak, yes. About how to have better arguments online. One of the anecdotes that he has in there is that people are now just accessing more information. There are more opportunities to collide online. There are more opinions that we’re being exposed to, and because of that, people are going to be arguing more, right? There’s this kind of natural trend towards increased opportunities to disagree in a public forum. And there are certain things that happen in a public forum when we’re disagreeing and the kind of ergonomics of that space or the design of that space online will push people towards a particular kind of disagreement or a particular kind of agreement potentially depending on how that space is designed. One of the things that we speak to in our Atlantic piece is this kind of idea of what’s called moral grandstanding. If you imagine us having this conversation right now, this is a great example. We’re having this conversation, this is over Zoom. I can actually like see your faces, we’re having interaction, right? There’s not an abstraction layer, you’re responding to me, I’m responding to you, I can see your eyes. If I say something mean to you, if I disagreement with you. There’s a desire that I have to reduce any kind of empathetic stress or sadness I might cause you. I’m not going to call you a name because I’m actually getting some kind of empathetic response from you in this physical stimulus that’s coming back to me, this visual stimulus is coming back to me. In the digital world that’s hidden from view, right? So you’re abstracted out into this profile pic, if you even have a profile pic, you’re just a kind of abstract creature out there. Make sure you’re even a creature in my mind, right? You might just be a thought in my mind that I’m angry about. But not only that, there is this additional layer in most of our social spaces online in which, I mean you can imagine us having this conversation live with An audience of people around us, right? And like an audience of people around us live that were rating us and there was a number attached to our faces that was going up or down depending on the quality of our arguments and what was actually happening in real time. 00:24:56 - Speaker 2: I already feel anxious with that description. 00:24:59 - Speaker 1: It would fundamentally. Change the content of our conversation in a drastic way, and it would not push us towards conclusions between us or attempting to find truth. It would actually push us towards the approval of the people watching us and that is what a large portion of our social media platforms are designed around right now. 00:25:19 - Speaker 3: Yeah, I mean, this kind of gets into the personal information, hygiene and personal information, gardening. 00:25:26 - Speaker 2: Yes, so Tobias, in your articles you often are speaking essentially to the platform creators, you’re saying, OK, Instagram or Facebook or Twitter, here are features you could build or maybe users could demand those features, but essentially change the tool in order to have better social dynamics, and absolutely I think the tool evolution, we’re seeing that happening already, you describe a lot of that in this kind of friction concept in your most recent Wired article, and I’m sure that’s going to be ongoing for a while. But for me there’s also this question of to what degree I’m not working on a social media tool, so therefore, what actions can I take in my life and I’m curious how you see the balance between what we need to do here is kind of demand changes from these tool creators versus we can make choices in our own life and for me, part of the value in your article. has been, I have a more critical eye or have more self-awareness about my own how I engage with social media and how those things trigger my primal emotions and with that awareness, I can then make maybe better choices about making sure I get what I want out of these tools and avoid the negative spirals. 00:26:36 - Speaker 1: Yeah, absolutely. There’s a really important balance, I think, to be made for, you know, with the designers of the space versus the things that we can do as individuals, and I, I do think there’s a lot of things that we can do as individuals, fortunately. It depends on the particular type of problem that you’re facing online, but in general, if we’re looking at it in the context of like the System One, System 2 dynamics. Usually, if I am triggered by something I see online, a good kind of mental model for me is to try to force myself in those moments where I feel the desire to basically like rage tweet back at someone or share a thing that I am incensed about, right? And that’s one of the big ones is just kind of propagating highly emotional content. And you know, not all emotional content is bad, right? Emotions have a purpose in our lives, right? I think it’s like important to recognize that they spur us to action and bring us passion. 00:27:22 - Speaker 2: I’m doing what I’m doing in my life because I’m passionate and have strong emotions about those things. 00:27:30 - Speaker 1: Exactly, exactly. So emotions have reasons and they’re kind of, you know, internal heuristics for us to determine what is important on a day to day basis. It’s like they’re helpful directors for what we should focus on, and you know, biologically and socially they have kind of foundational adaptive purposes in our lives. The problem is that in, you know, talking my application in these digital spaces, we’re actually taking some of these emotions which are kind of meant to pass through our bodies and just like and be noted and then direct us towards a specific action. We’re encapsulating those in little time capsules, right, we’re textualizing them. And then we’re sending them out on their way into a network to go on and kind of trigger other people and have a life of their own as they’re ping ponging around our networks and causing other people to be emotionally activated, and they kind of live in a semi-permanent state, even though initially an emotion is just kind of meant to pass through our system. 00:28:20 - Speaker 2: I hadn’t even thought about the sort of responsibility to others by passing on emotional content. I tend to think in terms of again how can tools be improved, but then how can I make changes to my own information tooling and sort of managing those processes in my life. Mark and I talked about this quite a bit in our previous podcast on what I call the information age. There, I think we were focused more on just the raw quantity of information that we’re attuned. Through most of human history, we lived in time where information was scarce and so we seek to get as much news, like even the word news implies, yeah, like what’s what’s the latest? I want to be in the know, I wanna be connected, it’s important to know what’s going on, and now we live in a time of it’s such incredible information abundance that actually the problem is curating and calling all that out, but Mark, I’m curious, you know, expanding on what we talked about there, I feel like you have a pretty good Set of approaches for cultivating your own information ecosystem, putting it together with some of what we’re talking about here, what are like techniques that work for you or you recommend for others. 00:29:25 - Speaker 3: Yeah, there’s a lot here. One quick thing on the like emotional front with weird things coming at you on Twitter and stuff, I adopted a simple practice of whenever something gives me bad vibes on Twitter, I just block, or, you know, turn off we tweets or mute or whatever is appropriate the situation. So I found like, you know, life’s too short for bad vibes coming through of your own choosing, right? You have total control of what you see on Twitter, just choose to close that stuff off. 00:29:49 - Speaker 2: I feel like the immediate devil’s advocate on that is there are bad things in the world and it’s not helpful to not be exposed to problems. 00:29:57 - Speaker 3: Yeah, it’s not like things that you disagree with or things that are bad that are happening, it’s things like bad faith and People being obnoxious and stuff like that. And it’s the default that you continue to see people that you’ve previously followed, and for a long time I just had this out for whatever reason, I wasn’t inclined to change that. I just kind of accrete followees over time, but then I took more responsibility for my timeline and things are much better now. And that in general is a big theme for me with personal information management. Like no one’s gonna save you. In particular, the algorithms are definitely not going to save you. If you just go to facebook.com and click on whatever’s at the top, you’re gonna have a bad time. Likewise, if you just go to like washingtonpost.com and read everything there, you’re not gonna be very well informed. So you need to take a lot of responsibility. For your own information ecosystem, and that’s why I like things like Twitter, podcasts, email newsletter, niche Discords and Reddits. These are places where you opt into individual small creators, curators, communities who you believe have good insights and relevance to you. By the way, I just realized, Tobias, when you were talking about the three like pathological features of social media, that podcasts are kind of uniquely resistant to them, so podcasts can’t be retweeted. They haven’t really been subjected to algorithmic feeding. 00:31:12 - Speaker 2: Spotify is working on it, I think, but yeah, so far. 00:31:15 - Speaker 3: Yeah, but mostly they’ve been quite resistant. I think that’s an important dynamic. 00:31:19 - Speaker 2: We see that on the side of being podcast creators or what have you, which is, it’s actually hard to market or spread a podcast and happily and quick aside, I’m very thankful for everyone who’s tweeted out links or referred us to their friends, but yeah, it’s just a podcast can’t go viral, that’s all there is to it. It can grow pretty slowly and steadily and organically over time. And it’s a downside in some ways, but actually really a benefit in the sense and probably why I’m drawn to podcasts often as a place to get more called System two inputs into my life. 00:31:52 - Speaker 1: Definitely. I do think there’s a distinction between velocity and virality that’s important to make, right? So like a good book can go viral, a podcast can go viral, it just will go viral slowly. spread and I think that’s actually kind of a goal is to have potentially like a low velocity, a high virality thing in which people are like, oh, you should listen to this, you know, like a word of mouth recommendation goes a long way, especially for something like podcasts. Mark, what you’re talking about, you know, your personal curation systems, I find that to be so critically important these days. I like to think about algorithms as kind of like a dog. It’s something that is like an intelligence that has a very simple understanding of what it’s trying to do for you, right? And it’s using limited inputs to determine what it is it’s trying to serve you on a regular basis, so the same way you might train a dog. I aggressively, for instance, train my YouTube algorithm. It’s constantly serving me up things on a regular basis and probably once a week I have to go through and say, I don’t like this, I don’t like this, I don’t like this. And as a result, I get, and I use this kind of personal heuristic, which is like, how do I feel after watching this video? How do I feel after going through my feed here and checking in with yourself, taking a moment to recognize, I think there’s. The regret test, very basic test. Like if you regret your experience on this tool, then you need to change the tool or get off the tool, right? Unfortunately, that is something that we can do. So I have aggressively called and trained my YouTube feed and now most of the time, you know, again, with this kind of weekly training regimen, it becomes a beautiful source of inspirational educational content that I really get a tremendous amount of value from. 00:33:35 - Speaker 3: Yeah, and I think on this personal curation stuff, you need to be really willing to go against the grain, because the grains in the wood here are leading down to places that are bad and in many cases just misinformed or wrong, especially with like the kind of complex topics of the day, for various systemic reasons, the stuff that you get in the prestige outlets isn’t very good. And so you really got to go around and crawl and find the weird Twitter accounts. I’ve joked that on many complex topics like the recent pandemic, a lot of the very best information on the internet came from cartoon Avy pseudonymous Twitter accounts. I mean that 100% seriously. So you need to be willing to embrace that kind of weirdness in your own personal information curation if you’re gonna want to have good outcomes, I think. 00:34:22 - Speaker 1: So what you’re speaking to there is really interesting because you’re absolutely right, there’s been both like a decline in trust of journalism at large, right, that’s a big, big problem kind of we’re facing right now is that we don’t feel like we can trust historical institutions that we used to rely upon for this basic validation of perspective and worldview that, you know, we used to have kind of the forced to feed, essentially, right, we had a forced algorithm, which was major news and media, that was our content. 00:34:47 - Speaker 2: There’s 3 channels. They all kind of say the same thing. You can pick one based on whether you like the color of the presenter’s tie, but they’re basically giving you the same information, like forced consensus essentially about what is factual and what is not, yeah. 00:34:56 - Speaker 1: And so as the internet has kind of detonated and exploded this traditional media hierarchy, it’s also along with it, detonated this trust network that we had, right, of trust and specific authorities, and for a lot of people, that’s laid bare and especially during the coronavirus, is this kind of proxy network of what I call reality anchors, right, we used to have kind of media anchors, which We looked for, we had the Walter Cronkites and the Dan Rathers who we looked to for specific points of reality, how this happened, this didn’t happen. Now everyone kind of has their own proxy network of reality anchors, right? It might be the follower on Instagram, there’s the anti-vaxxer, it might be the IDW intellectual dark web thought leader, you know, it could be any broader group of humans, but there’s a really tremendously on display because In a way that they weren’t previously I think that’s laid bare a lot of the problems of our epistemic environment now because we no longer have a specific kind of source of consensus that we can look at collectively. We instead have this decentralized individuated network of reality anchors that we point to. 00:36:07 - Speaker 3: Yeah, and it’s super messy, which I think circles back to a lot of your work because a lot of these so-called reality anchors, they’re not based in reality, and we’re asking every individual to come up with their own notion of reality and inevitably, most of them are wrong and all of them are at least different. And so what do you do with that? It’s an extraordinary mess, not an easy answer. 00:36:24 - Speaker 2: Right, yeah, I find myself conflicted about, on one hand, the centralized force consensus, as you called it, I think that left a lot of important viewpoints out in the dark and Living in a world where I do have access to much greater diversity of opinion and ideas and perspectives, I think I once heard the, it was Megan McCurle that described the internet as a quote freak liberation front. And I like that because I’m interested in lots of weird things and weird things were sort of hard to find when you did live in a world of broadcast media, there’s only a few channels, there’s only a few newspapers and what have you, and I’m basically much happier in a world where I do have access to much nichier things, but then yes, we lose that shared consensus, shared understanding of reality. And I would not have thought this previously, but I think in past years I’ve seen where in a way there is something to be said for whole society basically agreeing about the basic facts of reality, even if some of those facts are actually wrong, but if we agree together we can at least make decisions together, whereas if we have a totally different view of reality, we are paralyzed. And an action maybe is worse in some ways than taking action on a false understanding that that then perhaps in the future you can correct as you realize, I don’t know, for example, that the concept of the food pyramid is ridiculous. 00:37:48 - Speaker 1: Totally, you know, if you look at history and if you go back. Far enough, you can see there’s a correlation between our ability to organize in the larger and larger groups with our ability to kind of understand each other and share common cause, cooperate better, share good information together collectively, that kind of thing. Um, good information, qualified good share information together at all, right, share ideas and myths together and we kind of emerged from this fog of, we think about misinformation being a new problem, but we kind of emerged from this fog of misinformation that was actually really just kind of endemic in society, right? Like we used to believe crazy, crazy things, you just have to scratch the surface. of history, you don’t have to go back that far to see that there was just this kind of constant barrage of falsehoods or half truths that would pretty much become accepted truths, right, commonly accepted truths for a long period of time. You probably remember a handful of these from your childhood, maybe even, right, which like a Ouija board might summon the devil or a story about aliens or something, but we had this like really strong. Consensus forced consensus mechanism in place to kind of keep everyone on the same page, but I think the natural state of human exchange is much more oriented towards misinformation than it is towards fidelity and truth, and I think that’s important that what we’ve done with the internet is just kind of backspaced to a previous era in which misinformation was emergent and common, right? 00:39:17 - Speaker 2: Yeah, that brings to mind to me what they call the yellow journalism era. We talked about clickbait headline titles, but in fact there was a version of that for when they were selling sort of one off newspapers by the newspaper person, probably a young man standing on a corner just yelling the headline, and there were these patently. Ridiculous headlines about you know we’ve gone to war, other things have happened because they just wanted to sell papers basically and I think eventually journalism settled on a better model that was more kind of oriented around longer term useful truths rather than one off attention grabbing headlines. But yeah, to say that that’s new to this era would be quite incorrect. 00:39:56 - Speaker 1: I’ve been especially fascinated with that particular era of when we basically began to use advertising to propagate journalism, right? So the era of, it was actually the era before yellow journalism. There’s this whole century in the 1800s in which we kind of figured out that you could sell ads with newspapers. And in that process, you could also make a lot of money by making sensational claims. The New York Sun was the first paper to do this in the early 1800s, and they began their whole business in this whole kind of enterprise of ad-based journalism by literally making up fake stories and propagating fake stories on the corner with the guys hacking it and getting people riled up about stuff. There’s a story about animals escaping the zoo and marauding and killing people that they put in the stories, extremely irresponsible journalism. That like caused a mob to go out and try to find these animals and put them down because they read it in the paper and they thought it was real, which is literally just a falsehood, just an entirely made up story that they wrote to sell papers. And the years after that, there was a story about bat people on the moon that there was astronomical observations of bat people living on the moon, life on other planet, that was a sensation, sold a lot of papers and you know, kind of caused this crazy confusion about life on other planets that was a hugely popular hit. 00:41:15 - Speaker 2: Yeah, it also makes me think of George Orwell and the War of the Worlds broadcast and just yeah, the power of media, particularly when it’s new, I think maybe we build some, I don’t know if it’s resistance or just awareness, ability to separate and say like, well, because I hear something on the radio, doesn’t mean it’s true or because I see it on the TV doesn’t mean it’s true, and maybe we’re still in. era for a lot of these internet technologies where, well, certainly I hope people realize that when you see something on the internet, it may not be true, but maybe we haven’t yet developed these antibodies or coping techniques for you see an outrageous tweet and you immediately reach for the retweet or the reply button and we haven’t quite developed the better practices for managing that. 00:41:56 - Speaker 1: I think the word is antibodies. I think that’s a great way of thinking about it like a cultural antibody against the thing. The way that changed in that era in the mid 1800s, it was through this process of professionalization that was actually also market driven. It wasn’t like the government got together and was like, we’re going to tell you what is true, what is not true, but it was this process of consumers learning that they couldn’t really trust specific papers and they could trust other papers, right? So in the New York. Newspaper scene that was the sun and these other papers became kind of like trash papers, you know, you fool me once, I’ll believe you, you fool me twice. I’m definitely not going to buy you again, right? And one of the papers that tacked up the brainstem as opposed to down the brainstem was the New York Times, and they actually started to build a reputation around actually reporting. facts and being consistent about that and being trustworthy. If you think about it as a little bit like an iterated prisoner’s dilemma for us and accurate information, right, in a world in which there’s nothing but crazy outrageous headlines, month over month, you’re going to learn to try to focus on the things that are verifiable and reputations come to matter. They actually are built over time. 00:43:09 - Speaker 2: It does seem like the value of news is in it being true. It gives you information about how to navigate your world, you know, in the previous, more pre-civilization time news that there’s a dangerous bear prowling around outside the village is really useful for keeping yourself safe if it’s true, but if you’re spending much of time avoiding bears that aren’t there. You’re just draining energy on something that’s not valuable. Now I will argue that a lot of our news and information consumption is fundamentally entertainment nowadays. I think the degree to which political news is essentially a kind of entertainment kind of following your favorite sports team kind of thing, and I think that’s fine, but at least it seems like in theory, bad information. or incorrect information doesn’t help you navigate the world and has a maladaptive effect and pretty quickly you’re going to see, OK, I made decisions in my life based on this incorrect information, therefore my life went less well than it could otherwise and then eventually you’re going to want to turn that around and get true information. 00:44:09 - Speaker 1: Yeah, I think that’s an important point. 00:44:11 - Speaker 3: Yeah, I think that’s very much the case. Like, I don’t think we’re going back to the world of mainstream journalism as the purveyor of verified facts. Even entities like the New York Times are already on the train of entertainment and aligned analysis, let’s call it, and they’re moving even harder to that model now as they catch up with substack. And so the question then becomes, where are we actually gonna get these true facts, which are the sort of public good, and once the fact is out there, you can’t charge for it. So who’s actually going to provide it, and it’s a very tough question and right now the honest answer is that it’s almost no one, so you kind of have to do it for yourself. And we’re starting to see now people can fill this hole a little bit by becoming named individuals who have a secured. attached to them personally, and that way you can bootstrap up into something that you can trust in the way that you can’t trust a large institution because it can launder and transform reputations, right? So it’s pretty gnarly out there right now. And I think it’s important just to be honest about that and to expect that you’re going to have to navigate that. And furthermore, that the whatever new equilibrium we reach isn’t going to look like the old world. So be ready for that too. 00:45:15 - Speaker 1: Yeah, I think that’s a good point. The tools that we have now. And this might be a good moment to segue into my most recent article just quickly about friction, just like there are ways that we can potentially reorient the system to at least trend towards accurate information versus falsehoods, right? If you look at the trends of misinformation right now, it occupies the same reach as a traditional media broadcast, right? Some viral mistruths can go just as far and as fast. To a wide audience as traditional media broadcasts where they can reach millions of people, you know, Pandemic was a great example of that, 12 million people that saw it. So potentially there’s a concept of friction, which is basically throttling misinformation as it spreads through a network and kind of reducing just the inherent capacity for virality across the board, right? So WhatsApp did this, they reduced the net number of possible shares. They reduced the number of groups that you could actually share a specific message to, right, and they just throttled that down. I forgot what the final number was, but they basically just, I think it was, they throttled down to 5 groups from infinite groups essentially, so you could before just copy and paste a message into as many different WhatsApp groups as you wanted to be before. You wanted to get, to get your message into and they just throttled that down and that fundamentally improved the speed at which misinformation could potentially travel, can still travel, but it just travels more slowly and is less impactful. And so I think that shifting things towards a slightly slower propagation system can actually dramatically improve the types of misinformation we’re responding to on a regular basis. 00:46:55 - Speaker 3: Yeah, and I think as we’ve discussed, we’ve already seen some evidence for that in the different types of discussions you get in the different mediums. So again, the ones that I find most compelling these days are podcasts and email newsletters and small Twitter accounts that you can’t quote to a podcast, and that’s in many respects that feature or not a bug. I’m more optimistic about those types of structural approaches than content-based approaches, cause the content-based approaches is so fraught, and you’re back to the oracle problem of what’s actually true versus not, and I’m sure people are gonna try that and continue to try it, but yeah, I do think the structural approach is more promising. 00:47:27 - Speaker 1: Definitely, and there’s The problem of censorship and kind of the rights of saying what you could say, you know, Reneeres, my co-author on the most recent piece, she has this other article and this letter saying, which is the freedom of reach is not the same thing as freedom of speech, right, which I think is a really important distinction when we’re talking about this stuff, because, yes, like you do have the ability and the right to say whatever you want, but virality is not a right. OK, yeah, you don’t have the right to reach hundreds of millions of people with whatever you want. 00:47:57 - Speaker 2: Well, looking forward to the future, Tobias. What do you see the solutions potentially being? Is it individual information curation? Is it these companies that run these products, making these feature changes? Is it government regulation and involvement, or is it something else? Where does a happier future for our relationship with social media, with information spreading, with virality, how do we get there? 00:48:21 - Speaker 1: Yeah, I really think it’s a mix of both, it’s both thoughtful design changes on the platform side to help us make better decisions and better defaults, to have better defaults about the types of information we’re regularly exposed to. And then I think as we’re speaking, this kind of cultural antibodies piece of it, it’s like, it’s really important for us as individuals to be aware of the information ecosystem that we’re living within. And to approach stuff with good faith skepticism, if that makes sense, and to really try to make decisions about what we’re sharing consciously and to try to push ourselves, I think, to a more reflective state. As opposed to this more impulsive state, and I think that’s a big piece of it, you know, a quick anecdote about when I’m triggered by something online, I will invariably, if I feel the desire to reach for the retweet button or the rage tweet, I will take 4 deep breaths before I do anything. And in that moment, just that small act of taking. 4 deep breaths will usually allow for my emotional reaction to dissipate in such a way that it feels like a much more healthy thing I’m about to say or act I’m about to make online. I think that just for deep breaths would go a long way in improving the type of internet we inhabit if everyone can do something like that. 00:49:37 - Speaker 2: Couldn’t agree more. Well, let’s wrap it there. Thanks everyone for listening. If you have feedback, write to us on Twitter at @museapphq or via email, hello at museapp.com. You can help us out by leaving a review on Apple Podcasts. And Tobias, loving all the work you’re doing on this, and if I’m not mistaken, you’ve got a book coming down the pipe here somewhere. 00:49:59 - Speaker 1: Am I correct? That’s right, yes, book is due out next year. It’s about outrage on the internet, how to navigate this new strange digital world, and how to make our digital tools better stewards of our humanity.
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: Something I really admire about Tokyo is that they are able to, while it’s a very desirable place to live, the housing costs in Tokyo are actually not that high, and people are pretty liberal about tearing things down and building new things, and it seems almost like a cultural love of newness, and people are always excited to like rebuild and create a new thing in the place where an old thing stood. 00:00:29 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for thought on iPad. This podcast isn’t about Muse the product, it’s about Muse the company and the small team behind it. My name is Adam Wiggins. I’m here with my colleague Mark McGranaghan. Hey, Adam. And our guest Devon Zugal, hey. And Devin, not too long ago, I would have said, of GitHub, but I believe as of a few months ago, you are now a free agent. How’s life treating you? 00:00:54 - Speaker 1: It’s been great. I left GitHub about 2 months ago, and I also moved to Miami around the same time from San Francisco, and so I’ve been spending my time exploring the city, writing a number of blog posts about it, talking to people in the government and like housing developers and that sort of thing, just because that’s what I do in my free time is learn about cities. So it’s been really fun to explore my new home. 00:01:20 - Speaker 2: Yeah, typically when people think of Miami, the first thing they think of is speaking with members from government agencies to better understand how the infrastructure of the city works. So it makes perfect sense to me. Yeah. And can you tell us what your background is, how you came to GitHub, what came before that, and what might come after? 00:01:39 - Speaker 1: For sure. My background is computer science, which is probably not a big surprise. I studied that in school and then I worked as a software engineer at a number of San Francisco startups. And then most recently, I was a product manager at GitHub for the last 2.5+ years. I was leading the communities department where we built tools for open source. Communities. And so it ties in a lot with my interests and love of cities and economics, because they’re both about sort of what can you do to create an ecosystem and a platform where people thrive, but without defining it all in advance? How do you create those building blocks so people can live their lives, find opportunities, build really interesting things that you never would have dreamed of and help give them that platform so that they can put those plans together themselves. 00:02:28 - Speaker 2: It’s pretty easy to see the parallels between communities of different types, which includes open source, and then cities as well, which is you can’t really do a top down thing. I’m sure we’ll get into that a bit here, but unlike, for example, me, my experience in designing products or building software products is often that you sit down, you figure out what you want to make, and you make that thing, and it may or may not work out the way you want it in practice and you need to iterate on it and you need to get. Back, but it’s a very highly controlled experience, whereas something like a community can only be grown. It’s incredibly organic and I think at best you can kind of guide and obviously guidance matters a lot because that’s why we get some communities that thrive and others that don’t, but it’s just nowhere near as prescriptive as what at least I’m used to in product design. 00:03:21 - Speaker 1: Yeah, and I moved over to product management from software because I really enjoy what I call social technology. I think that that’s really a sweet spot for me where it’s thinking about the system in terms of how can you shape and encourage behavior that’s healthy, but also without mandating it, like, sort of more of a carrot than a stick perhaps, I’m not sure if even that’s like the right metaphor, but I think that cities are a really interesting lens to look at certain types of software because things like social networks, which I would consider GitHub a social network on some level, and certainly Twitter’s Facebook’s Instagrams of the world, they really are communities of people where you as the designer or the software engineer or whoever’s building it. Don’t really control what ends up actually on the screen completely, so you have to think about what are the affordances that you provide? What does the design language say about what you’re supposed to do here? Kind of like how restaurants will have a sense of the space. So if you walk into a really quiet classy restaurant with like piano playing in the background. Everything about the space is telling you like, don’t start yelling and like dancing and screaming and whatever. Like this is a place where you’re gonna have like a nice steak, you’re gonna sit down, you’re gonna listen to classical music, but then if you walk into, you know, a Miami club, it’s a very different vibe and it says like, you’re here to kind of go wild and have fun. So I think that cities do the same of like, how does this Encourage you to live your life and different cities do that very differently. And I would love for more software teams who are building places for people to congregate online to think about it in those terms because I think it’s been a little bit lacking in the past, and I think it can lead to problems for both the creators and the people who are trying to experience the space. 00:05:12 - Speaker 2: I think that pretty naturally points to our topic today, which is Order without Design, which in fact is a book about urban economics and urban planning, and you didn’t write the book, but you do have a podcast by the very same name in which you interview the author of the book. Certainly this is not necessarily about the book itself, although I think there’s lots to discuss there, but also about this larger question of exactly what you said, how do cities become the way that they are? Each city has its own different character, and some of that evolved organically, but some of it was active choices made by people governing and living in those cities, and this is a topic that Mark and I talked about more in the, let’s call it the user perspective in a Previous episode, I’ll link in the show notes where we talked about our respective decisions to depart San Francisco and why he landed in Seattle and I landed in Berlin, and when you’re in the position of working on an all remote team or a distributed team, and you can basically choose to live anywhere where you have the ability to think in terms of not just I’m going to the city because my employer, my school is there, but you’re thinking, what are the qualities of the city that I like, what would make it a good Place to live that would be creatively inspiring for me at least, that was the experience that got me interested in urban design as a topic, which is seeing the unique character of Berlin and what it was that spoke to me, spoke to my soul about that and then thinking, OK, well, how did it get to be that way? What were the series of decisions and who are the people, and I know how digital products come to be, but how does the city come to be? So maybe you can illuminate that for us a little bit. 00:06:45 - Speaker 1: Yeah, so this is one of my favorite books, and I read it several years ago when it first came out, and instantly just had to become friends with the author. His name is Alan Berto. And he and his wife Marie Agnes, they’re in, I believe their 80s now, and they’ve spent their life living in a bunch of different cities around the world, creating their master plans. They worked for the World Bank for sanitation systems, transportation systems. They’ve been in places really far flung, such like all over the world, really. They’ve lived in Bangkok, they lived in Sana’a. Yemen, they’ve lived in New York City. I’m missing another dozen or so places that they’ve lived. Some of these cities I hadn’t even heard of, to be honest. And so they’ve seen cities from a lot of different dimensions. They’ve experienced lots of different types of people who have different goals for their cities, and they’ve done their best to shape their work to fit those goals of the residents of those different places. They’ve been in Port au Prince, Haiti, where they have a lot of really interesting stories. And what you’re talking about here about remote work and how the way we think about cities differently now that more and more people are working remotely, really an interesting lens to think about this book, because one of Alan Berto’s main points is that historically, cities have been labor markets. That’s what brings them together. It’s what sort of is the sinew that holds it all together. And what he means by cities are labor markets is that people come to cities to find opportunities to make their life better. And certainly they come for a lot of other reasons too, but finding work and finding a way to pay for their life and to better their life is one of the biggest ones. 00:08:25 - Speaker 2: Yeah, at least the way I understood that argument of his was being a labor market is the root of everything else. If you don’t have that, the rest of it won’t come. The population density now leads into culture and, you know, art museums and Interesting cultural scenes emerging, but all of those are secondary effects. You have to start with the labor market. 00:08:45 - Speaker 1: Right. And I think he would point to places that are, let’s say, retirement towns and that sort of thing is somewhat exceptions to the rule, but those will never become massive cities. Those will never become engines for economic growth, for helping people’s lives get a lot better, pulling people out of. poverty. They serve a role, but they’re not really what he’s talking about. But I think it’s really interesting because we’re now going into a new era where more and more work can be done remotely. The labor market is in the cloud. So if cities no longer have to be the labor market, what does that look like? How do we now think about the places that we live? How does that change the decisions that we make? And so that change hasn’t completely happened. The vast majority of people still work in person, but there’s been a real inflection point, I’d say in the last 10 years and certainly with COVID that has made people really start to think about this new paradigm. 00:09:38 - Speaker 3: Yeah, and there’s sort of two dimensions of effects here. There’s the people are free to potentially move to different cities, so one can move from San Francisco to Seattle or Berlin or Miami, or you can move to not a city and participate in a sort of distributed labor market, and so there’s competition along both those axes essentially. 00:09:57 - Speaker 1: Totally, for a really long time choosing to live in a rural place dramatically reduced your opportunities, and some might argue that that’s still true. I personally think that face to face has a lot of really important things that you just can’t get via Zoom, but at the same time, there’s a whole new frontier opening up here, and people from all different countries can now. in labor markets that used to be centered in the United States primarily in the case of tech. For example, my boyfriend is from Argentina and he moved to the United States several years ago, but many of his friends and family were not able to get visas or weren’t interested in moving. They wanted to stay with their families. And so they’re now able to participate in Things that are happening in the United States and and vice versa in a way that they just couldn’t 10 years ago. So, in a really weird way, there’s people who are sitting in Buenos Aires but behind a microphone, who I feel are a closer part of my community than some people who are my neighbors, and that’s just a very different world and will really change the way that cities develop, I think, in the future. 00:11:04 - Speaker 3: Yeah, for sure. And perhaps the most exciting piece for me as you mentioned this idea of social technologies, I think we’re gonna see some of the benefits and consequences of cities move out to the cloud, if you will, things like aggregation effects, quote unquote population density, self sorting. These are all things that you really needed to have a city in a physical space until very recently to get, but now people can, you know, whatever, join the right Discord or something, it’ll be very interesting to see that all play out. 00:11:30 - Speaker 1: Yeah, I’m tentatively excited about it. I have some concerns. For example, I was talking to a friend who’s a venture capitalist a few days ago, and he was telling me about how in 2020, during COVID, roughly the same number of dollars went to venture capital investments in that year as the previous year, but it went to half as many companies. And his interpretation of this was that the business that VCs are in is to find people that they trust and that they think will take that money and do something amazing with it. And his theory here was that because they couldn’t meet people face to face, they couldn’t build that trust with new people on the network, and so all of the money was going to people who are already in network and already trusted. And he was a little sad about this because he was thinking like there’s all these people who would probably be amazing entrepreneurs, but because they didn’t have that access that they would have had an in-person world, they didn’t have that. So I’m not sure if that’s completely the right interpretation, to be honest, I think there’s a lot of ways to look at that data, but it did give me pause and think like, oh, that’s like not great if that is the right interpretation. 00:12:37 - Speaker 3: Yeah, and I think it’s still very early. You know, the world doesn’t owe it to us. There’s no particular reason this couldn’t become very messy and weird for the next 10 or 50 years as it all shakes out. We talk often on this podcast about how it takes some time to metabolize these big society level changes. I’d say that our technology and our social technology is still very early, like the communication bandwidth over Zoom as nice as it is versus what we had 5 years ago, it’s very poor compared to being in person and likewise our social technologies are mostly transliterations of stuff from our previous physical world. So I think we solve a lot in front of us to see how it all shakes out. 00:13:09 - Speaker 1: But I’m optimistic. I’m definitely optimistic, but it’s not a done deal for sure. 00:13:13 - Speaker 2: Yeah. So how would you answer the question that I sort of posed earlier or the question I posed myself, I suppose, on discovering a city that I liked really well and wanted to settle in just because I liked it rather than because an employer was there, which is how do cities become the way that they are and in particular who are the people that make that happen. 00:13:34 - Speaker 1: There’s a lot of components that go into that. I think of cities as an ecosystem, and so a lot of different pieces have to be in place for them to be the way they are, but like geography makes actually a really big difference in the way that people interact, and that’s not human made usually. But it has a huge difference. Like, for example, I live in Miami Beach, which is separated from mainland Miami, it’s on an island, and so I’m much more likely to spend time with people who are like on the island with me than I am to like drive into mainland just because there’s a body of water between us. And so that really shapes the way life and culture work in Miami and similar geographical features make a big difference in other cities as well. 00:14:18 - Speaker 2: Yeah, one I noted in my own city exploration is San Francisco and Amsterdam, two places I’d spent time, were both on these kind of fairly smallish peninsulas, and so they’re necessarily constrained on 3, I guess an island is 4 sides, but here you’re constrained on three sides. And so, there’s sort of a limit to how much they can grow or things get denser, they get more expensive, and by comparison to other places, Berlin is one example, but probably most places don’t have as much constraint and as the city grows, they can spread outward and in that way kind of create more relief for just more space for more people to be there. 00:14:53 - Speaker 1: Totally, and other factors can have a similar effect, so London and Paris are interesting to contrast to each other, where both of them are in England, they’re not on the peninsulas or islands. Well, I guess Britain is a very large island, but Paris is much denser than London, and a big part of that is because Paris was basically conquered and like overrun again and again, so they built these like city walls to protect it. And they wanted to keep as much of the buildings inside of those walls as possible, and the denser it is, the easier it is to defend. Whereas London being in Great Britain, which is separated by the channel, they just didn’t have those problems. They were much harder, much easier to defend, much harder to attack. And so London is much more sprawling than is Paris, and that’s sort of a I don’t know if it was a conscious decision by any person, but just the factors that they had to deal with resulted in a very different city form. So I guess those are two answers, geography and like sort of exogenous factors that just kind of force you into this shape for survival. I think another pieces, decisions that are made early on in a city’s history, there’s an immense path dependence in cities because it’s painful to tear things down, unlike in software where it’s like not. That costly and this kind of infinite space, you can always write more software for the most part. 00:16:16 - Speaker 2: Developers get excited when they see a huge number of red dashes in their pot, right? 00:16:21 - Speaker 1: Yeah, they love it because it simplifies things. Whereas in cities, you know, someone like Creative destruction, yeah, 00:16:27 - Speaker 1: they put up a bunch of bricks and like they paid money for them to go up and it’s a more zero-sum game in cities than it is in software because anytime you build something, that means someone else can’t build something there until they tear your thing down. And so it leads to very different dynamics and you get much more constrained. Like a concrete example of that is here in Miami Beach, there’s a lot of beautiful art deco buildings. Miami Beach is really famous for this. And so there are rules protecting the art deco because it’s a national treasure and, you know, I really love them. But what that means is that you can’t build something else there, and this is a beautiful place to live. It would be awesome if more people could live here, but because the art deco is there, we can’t do that. And it forces you to make different types of trade-offs. Do you value this architectural heritage, or do you value having many more people be able to live in a place and every community is going to make different choices there. 00:17:22 - Speaker 3: Yeah, and I think an important thread through everything you just described is that ultimately it’s individuals making personal choices in this sort of organic chaotic mess that ultimately bubbles up to the emergent order, if you will, that you see in cities. And I think it’s so easy, especially as software people to think about, you know, that the city does this or we should do that, but really it’s just a bunch of individual human beings ultimately have to make the decisions and take the actions. 00:17:47 - Speaker 2: Well, and this, the, I don’t know, subtitle or the part that goes after the colon in the order without design book title is how markets shape cities, and of course markets are very much, yeah, decentralized, you know, individual actors pursuing their own means, but then that forms into a larger, something that is uh greater than the sum of its parts. Also, if I’m not mistaken, one of the interesting things about the author’s experience is he had actually worked for a centrally planned economies, including, I believe, some Soviet work in the 1980s before the USSR ended, and then also for the Chinese government. And so he had the chance to even compare a situation where there is no kind of classic market forces like rent to figure out, you know, efficient land use. Instead, there is urban planners that do just sit there and say we should put houses over here and restaurants over here. 00:18:38 - Speaker 1: Yeah, and he also worked in China during the period where they were liberalizing economically and moving from a completely communist planned centrally planned government to trying to make things a little bit more free market from the economic side. And one of the things that he pointed out was that like, there are a lot of very strict rules that the Chinese government adhered to. So, for example, there was a rule imposed by the government said, Every single room in every building has to have at least one hour of sunlight throughout the whole year. Now, that sounds like a good idea, like, I wanna have sunlight in my house, sunlight is a nice thing, and even one hour almost seems kind of low. But the issue is that China is a really large country and goes very, very far north, where there’s actually just not that much sunlight at all during much of the year. And so there’s some cities in northern China that were forced to build the buildings extremely far apart, so that the angle of the sun would like properly hit the inside of the buildings for like the minimum number of hours a day. And what this meant was that cities in the north are much less densely populated and much more spread out than the ones in the south, and it correlates almost perfectly with this angle to the sun. And what it means is like, this has a lot of other implications for the cost of infrastructure and all these trickle down effects that, like, weren’t really conceived of before, you know, when they put this rule in place, they weren’t trying to say infrastructure in the north has to be extraordinarily expensive. They’re just trying to get everyone to have sunlight. And so he came in and sort of noted some of the rules and said like, this is actually hindering development in these places because this is a limit that is not gonna work out. 00:20:20 - Speaker 2: So in more market-based economies that probably most people nowadays are more likely to live in or be familiar with, what is the role of an urban planner? What do they actually do? 00:20:31 - Speaker 1: Well, I think Alan would say that historically urban planners in non centrally planned economies still think of themselves as central planners, even if they don’t explicitly say so. They still think that if they put a rule in place, it will be followed, and it’ll work out the way they’re imagining, as opposed to thinking of it as a dynamic system that will react to the rules and sort of mold itself in a way that has a lot of unintended consequences. So, I guess there are a lot of urban planners still that think of themselves as architects who can like shape a city in exactly The form they want something like a Disneyland, but I think Alan would say, and I would strongly agree that urban planners should think of themselves more as like protocol creators in the way that a software engineer might design a protocol, but not say everything on top. So TCP IP is a brilliant design because it’s not that opinionated. It’s only opinionated about the things that need to happen to help people coordinate. So, a city that I think has done this really well is New York City. And I believe it was 1811, the city put together a master plan that laid out the grid that we all know today of, you know, streets and avenues, and you can actually see which parts of the city were created before that plan was in place in the southern tip of Manhattan. They’re all this warren of streets that is, I think, beautiful, but also quite messy and like hard to get around. But then everything north of that is a grid, very, very precise, and something that the New York City plan did really well, I think, is make it very clear from the get-go what was public land and what was private land. So instead of saying we’re gonna control everything, or instead of saying we’re gonna let everyone just like be anarchists and do whatever they want. They said we needed to find rights of way because people need to be able to get around. We need to keep space for like sewage and other sanitation systems that we all need. Like no one wants poop in the streets, and we’re going to define spaces for public parks. That’s why Central Park is so big. They just carved it out before anyone actually started developing there. And then they left everything else to the market to decide. And I think this works really well because it enabled the key methods of coordination that people needed, while also leaving space for people to be creative and to make their own idea of what the city should be. 00:22:55 - Speaker 2: In New York, I think many would feel is the city, a cultural powerhouse, a place people love to visit, and many people love to live. Maybe it’s also incredibly dense and incredibly expensive and dirty, and all those negative things you associate with the collection of people, that is cities, but nevertheless, truly the prototype city in some ways. 00:23:16 - Speaker 1: And it’s been an engine to pull people out of poverty for hundreds of years. Like immigrants have landed in New York and poor Americans have ended up in New York. Black people ended up in New York after the Reconstruction, and they found this place where they had more opportunities and they were able to like build themselves up and like it has a lot of flaws, but it’s something that enabled both the coordination while also remain keeping space for people to make their own lives what they wanted it to be. And I think it’s just been one of like The greatest engines of progress in America, and I know that sounds really melodramatic, but I stand by it. 00:23:53 - Speaker 2: Absolutely. 00:23:54 - Speaker 3: No, for sure, all the more significant than that we’ve conducted this sort of quiet experiment on rolling back market dynamics in American cities over the past, I call it 60 or 70 years, you know, like you said, it used to be that you basically do whatever you want. If you had private property. Now the model is like in San Francisco, which we’re both familiar with, that you basically can’t do anything to a first approximation. Everything is set forever, don’t change it. And I think we’re only now starting to see the consequences of that experiment and to evaluate how well it did or didn’t work. 00:24:25 - Speaker 1: Totally, and it’s a very complicated issue. So, one of the reasons I left San Francisco was this growing feeling that you’re just like not allowed to do things there anymore. And for me, what that meant concretely was like, I was very active in housing policy because I wanted San Francisco to build more housing, so more people could move there and have access to the awesome opportunities that the tech industry has offered, and other industries as well, but tech being the primary one. And after several years of it, I just kind of got a little down about it and didn’t feel like we’re making much progress because San Francisco has very strict zoning laws. It has a very granular local control where neighbors can stop projects in their tracks that are near them or really anywhere in the city, but it has a really complex history because the place that it comes from. It’s actually a place I agree with, and then I think it’s just gone too far. So the place that that’s come from is in the 50s and 60s, American cities all over the country built many highways and the way they built these highways was they primarily tore down African American communities, other communities of color as well, but primarily African American communities. And they just did it without really asking. They would just bulldoze an entire neighborhood. 00:25:37 - Speaker 2: this eminent domain or? 00:25:39 - Speaker 1: It was through a variety of different methods. Some of it was eminent domain, yeah, and there were a number of different ways that they could do this and like each city had a slightly different approach. The effect was that like these highways would just cut through these communities and destroy them. So, there were these things called the highway revolts that started happening in the 60s, where people were saying, hey, you’re destroying my life. That’s not OK, you can’t do that. And one of the ways that San Francisco reacted was putting rules in place to make it easier for locals to defend their neighborhoods and to have a voice in the process, which I think is a very good goal to have. But where that has ended up is that today, one of the specific tools that was put in place is something called discretionary review. And discretionary review basically says that if you have an issue with a project as a resident of the city, you can like file a complaint and stop it, or at least force it to pause and like have a hearing about the project and In theory, that was supposed to be used by, you know, people who were getting their houses bulldozed so that a highway could go through or whatever, or, you know, someone’s putting up like a really loud factory next to you or something like that. But practically the way it’s used today is that like, really wealthy people who live in Pack Heights, Pacific Heights, which is a neighborhood in San Francisco, will like complain about how their neighbor who’s building a two-story house, is putting a shadow in their vegetable garden. And, you know, like, you don’t want a shadow in your vegetable garden, I get it, but my personal opinion is that making it possible for a family to move in next to you is like way more important than if your squash gets sunlight. So it’s this tool that ended up going so far as to give people local control that like completely blocked the system. And as a result, San Francisco has added far more jobs than it has housing for the last like 10 years straight. And the housing prices just have completely shot up. Anyway, I shouldn’t rant about that way too much, but the point is that it’s a really complex issue where it’s always a balance between local control and also maximizing sort of for the greater good, and for the greater good is like a really complicated concept to define. 00:27:47 - Speaker 2: Or as you mentioned earlier with the art deco buildings where there’s heritage to protect, you want to protect the character of a place that makes it unique and special and not just tear it all down and replace it with highways and strip malls, which maybe sometimes pure economic forces would take you in this homogenizing direction, which I think is also part of the argument against gentrification which There is a big, big talk back here in Berlin these days. A lot of demonstrations and things. There was a 5 year rent cap law that had been passed and then was struck down by the German Supreme Court. It’s a real huge point of debate between the people who are here already and want things to basically stay the way they are. They want to preserve the character of the city, which I agree is very special, but then Life has changed and the city should grow, just like all things, grow and change to be healthy. In addition to just the simple fact that we’re adding more humans to the planet, and if we’re gonna have more humans, then we also need more houses for those humans to be in, and just because you were there first doesn’t necessarily give you a special privileges for housing as opposed to the needs of others. 00:28:52 - Speaker 1: Yeah, the rent controls issues is a really interesting one, because I understand where it comes from, which is we don’t want people to get displaced when the place around them becomes more expensive, but at the same time, when you have rent control, I think it’s akin to aristocracy in the sense of saying like, you got here first, this is like your land, you have some special privilege over it. And newcomers who may also want to make their life better and may also want to have access to what that beautiful city has to offer, now don’t have access, and like sympathetic to the goal of locals, locals being in a position where they can stay in their home, and I think that is a problem to solve, but rent controls are a very blunt instrument that don’t actually quite do the thing that people say that it should do. Rent control is a tricky situation because it encourages things like landlords neglecting to actually take care of the building. I think there’s other ways to achieve the same results that are also not perfect, but result in fewer issues. One final thought on that is like, rent control also increases the price for other people who weren’t lucky enough to be in a rent controlled building. So, Berlin, for instance, has a lot of immigrants who are coming in, who I think they should have a home and should be welcomed, but because they weren’t in a building at the time of rent control, they’re now forced to the outskirts of the city, or they’re forced to pay a lot more for the remaining buildings that are not rent controlled because it’s rent controlled effectively removing supply from the market. It just sort of puts everything in stasis and people don’t want to move from places even if they need to upgrade and I’m sympathetic to the goal, but we have to look at like the outcome of what actually happens when you put something in place, not just say what you wish it did. 00:30:42 - Speaker 2: Some of that sounds like sort of understanding market dynamics or economics, and that reminds me of another thrust of order without design, which is, he’s basically talking about urban economists, which is essentially the academic study of cities. And then urban planners, which in fact was what his job is, which is people whose work for governments in some form to figure out things like zoning laws in an attempt to shepherd the city in whatever direction. The government would like it to go, and he talks about that at least at the time this book was written, they didn’t have good communication with each other. So planners might be not that aware of economics and kind of market dynamics generally, but then also the very specific dynamics of the role of markets in cities and of course vice versa as well. The academics are a little disconnected from the reality of the decisions that the planners need to make every day. 00:31:39 - Speaker 1: Totally, and some of those realities are political realities, like what we’re just talking about with rent control, people do not feel good when they see what they consider gentrification happening, or when they feel like they’re being priced out of the neighborhood that they’ve lived for their whole life, and so they get angry and they want something to be done. And the problem is that doing something doesn’t always make the problem better. Doing something sometimes actually makes the problem worse if you don’t understand the causal model of what’s gonna go on. And so there’s been a lot of actions that people take that I think actually worsen the situation to their own goals because they don’t appreciate the level of dynamicism that’s happening. So like a similar example, it’s not about cities, but is sort of a similar dynamic economic system is like taxes. Since moving to Florida, I’ve met a lot of people who have moved to Florida from New York to California because New York and California have been hiking up taxes for companies and for themselves individually. And I will not make any judgment about whether I agree or disagree with that, but just to make the point that like, when you increase taxes, people will find ways to not pay them often, not always, but it is a reality that you have to deal with, and you can’t just like moralize it. And say, oh well, they’re bad people for not paying the taxes that the society around them agreed upon. You have to actually deal with the problem. And so I think a lot of governments will raise taxes and then be shocked that like, they get a lot less revenue than they expect because people just move away. And so, cities often have similar issues. Like, for instance, there’s something called a privately owned public open space in San Francisco, and I believe New York and a number of other cities have this too. And the concept is, you’re a big developer, you’re building like an office building or a bunch of condos or apartments or something, and the privately owned public open spaces is POOS is the acronym. It’s a rule that says like if you build a development of a certain size, you have to build at least this much public space for people to enjoy in the building. Sounds like a really nice idea, and some of them actually are really nice. Like, there’s this really beautiful cafe in the LinkedIn building in San Francisco that is a popo, but there’s a lot of other popos that are sort of hidden because the developer sees the letter of the law and they say, ah, but they didn’t say like where it needs to be. And so sometimes they’ll put these popos on like the rooftop of the building and put like no signage. Whatsoever for people to find it. And so it’s effectively just a private space for the building. And, you know, it’s a nice amenity. Maybe the people who live in that building like it, whatever, but it’s not solving the problem that the government wanted to solve when they put that rule in place. And so something that complexifies this is that politicians and bureaucrats usually get points for starting something, but not for the actual. And so they say we did something to create more public space in San Francisco, people clap and like re-elect them. But then 5 years down the line, you realize like, oh, there is no extra public space really. These are really hard to get to and people have to put together like special maps. There’s all these like lists online that you can find, and there are all these like secret little nooks, which is, you know, fun in its own right, but really not what the city was going for. 00:34:53 - Speaker 2: I think accountability loops is one of the biggest things missing in public policy debate or politics, and I don’t necessarily think anyone’s quite to blame there. It’s a systematic thing, but it’s something where when a project like that is set up, we don’t even define what success is necessarily. We say we’re going to do a project to change our spaces somehow, more public space, more greenery, different transit options, but what will success be and how we measure that 5 years down the road and if it’s not working, we’ll pivot or transition or sunset the program, but that’s rarely the way the government works. 00:35:29 - Speaker 1: Yeah, I couldn’t agree more, and I think it’s doable. A lot of organizations do this all the time, and I’m sure that some government organizations do as well, but It doesn’t usually loop back to the voters, and I still don’t have a clear model of why that is, but I think it’s a really important problem to solve because in the situation that we’re in now, Without that accountability loop, politicians who even want to do the right thing will have a hard time doing it because they’ll spend all their time doing the right thing and not like doing the flashy things, and then they won’t get re-elected. And so they’ll only have their what, 2 or 4 year stints or whatever it is before they’re booted out, and you can only have so much impact in that time. So, building those loops is really important, and I think I’ve seen some cities like Singapore, for example, have like dashboards with certain statistics, which I think are An interesting start, but it’s definitely not normal, like a normal practice and not something that more people are aware of. And like, no person wants to create a system where they now have to be accountable cause now it only increases the chance that they won’t succeed at the goal. So something that has to be imposed. And actually, before that, even, it’s even hard to even agree what the goals should be, right? So like, in the instance of historical preservation, we are talking about different cities have made very different trade-offs, uh, but individuals within those cities all disagree really strongly. So like Paris, for example, has Effectively decided to be kind of like a living museum. There’s rules like you’re not allowed to build buildings that go above a particular line relative to sea level, so that you can have a good view of, can’t remember which church, but like a particular church on a hill that’s just gorgeous. 00:37:12 - Speaker 3: Is that Notre Dame or am I imagining that? 00:37:14 - Speaker 1: No, I don’t think it’s Notre Dame. I think it’s the one on the hill with a really beautiful view of like, uh, has like this like, I can picture in my head, but it’s not coming to me. But it’s gorgeous and you’re supposed to have a view of it from roughly everywhere in the city, and that’s a choice to make, you know, but the result is that Paris is extremely expensive, especially for Parisians, and a lot of people end up having to move to the outskirts, or similarly like, it’s tough to have a large headquarters for a business in Paris because there just aren’t that many big buildings. So they’ve created this whole new business district called La Defense, which is like way off. In the outskirts and like nowhere near the core of the city, which has big skyscrapers. And like there’s a tradeoff that Paris chose to make. And I think it has hurt their economy, but it has like preserved this gem of a city that I’m super happy exists and I’m like really glad that I can go and look at these beautiful views and beautiful architecture. So every city needs to make those choices itself and there will always be people who are benefiting and hurting from it, and it makes it really hard. 00:38:26 - Speaker 2: One example of kind of preserving what’s there, living museum, like you said, versus investing in the future, which sometimes means taking risks, was the building the Eiffel Tower. Uh, I read a great, uh, biography of Gustav Eiffel, who’s a pretty inspiring fellow, but did quite a lot of work, um, but if the Statue of Liberty and the, um, or the internals of the Statue of Liberty and the Eiffel Tower being two of us. More famous pieces, uh, but when, you know, when they put up plans to, to build that for I think it was the World’s Fair, the outrage in the city was, was huge and even immediately after it was built, the feeling was, it’s this eyesore, it dominates the the the skyline, it’s this super modern thing that doesn’t fit with our, um, you know, quaint, uh, quaint architectural vibe, um, and it took a long time before it became what it is. Now, which is this total icon that not only stands for Paris but in fact for France, and you couldn’t couldn’t even imagine it without that. But that was a bold move that a lot of people were um were against. And so in order to in order to build that next Eiffel Tower, whatever that’s going to be, you need to be willing to take risks, but then that comes at a cost. 00:39:39 - Speaker 1: Yeah, I think that’s such a good example. And I mean, I think I should probably express my bias here is I like building things and I like taking risks and like seeing other people take risks, and so I like to live in a place that allows that. That’s one of the reasons I moved to Miami from San Francisco is it it feels like it’s more welcome here and like, you know, Paris seems like an even more extreme version of San Francisco. But I also respect the idea of a community coming and making that decision to make the opposite choice, but it becomes really challenging to decide like, what does it mean for the community to make the decision, because it’s hard enough to even know what one individual wants, I think, let alone to capture the views of everyone. The most common form of voting, for instance, is like, first past the post or whoever gets the majority rule vote, and that works, it’s like better than a lot of things, but it has a number of really important flaws. Like, for example, what if the majority of people kind of like the Eiffel Tower, but a minority hates it, and I think it’s the worst thing ever. So there’s a majority that weekly would like it, but also they don’t care that much if you don’t have it. And they voted in, but then there’s a minority who’s like totally harmed by it. To me, like, if you had that distribution of preferences, I would actually prefer not to build it because like it’s harming people extremely in a way that no one is actually benefiting from that much. But you know, that’s the values question and like designing these systems is the values thing. And I think every single voting system has like some very valid criticism that you could have. So it’s not clear even how communities should make these choices, which brings us back to markets, which I think is like something I really like about having every city make decisions differently and having a little more decentralization. Where, you know, a central government, like a particular country isn’t making all the rules, because then every city can come to its own decision about how to make decisions, and you can end up like, leaving places and making choices for yourself if you disagree with that particular place. And so it By allowing diversity, it’s gonna create more situations that you personally disagree with, but it also create more situations that you really love and you can go live there. And so diversity is really crucial, I think, to solving this problem, and then the other pieces, people have to be able to actually move, and that’s really hard, you know, in a world with a lot of borders, there’s actually quite limited choices for most people in the world. 00:42:04 - Speaker 2: I’m a huge fan of Let 1000 flowers bloom, and then individual choice to kind of have a bottom up emergence of what’s working or what is into a natural sorting. You’re absolutely right. The world that we live in that’s built on nation states which sort of assume you’re born in a place and you probably live your entire life without going more than about 100 kilometers from that place and you have kids there and you die there. That’s what I think a lot of the sort of national systems and immigration and customs. Systems that we have now are kind of assuming, but I think that has not been the case for a while, and that’s going to become even more so with a lot of mass migration in the near future and certainly for those of us privileged enough to be in the tech world where we have disposable income and choice of where we want to work, perhaps because we’re on remote teams. It is really the case just as I decided to go to another country, not because I wanted to go to another country so specifically, but because the city I wanted happened to be located in that other country. I ran up against very much still do run up against all the challenges, the significant challenges of being an immigrant, and quite a lot of it is related to this assumption that people don’t move. 00:43:14 - Speaker 1: Yeah, and I think growing up in a country like the United States, you have a lot of options cause it’s a really big country, so you can move a lot of places, but honestly, even that is very limiting to grow up without a lot of money, it’s hard to move to San Francisco because it’s an expensive place and like, sure you might be able to get a job with a high salary once you’re there, but it’s gonna take time, and you don’t know, you haven’t been there, maybe you can’t get a job, who knows, so a lot of people are stopped by that as well. But in a smaller country, like again, Argentina is one that I know really well, there’s one really big city, it’s Buenos Aires, and a third of the country lives in that city. There’s a lot of other cool places to be too, but Buenos Aires is the place you want to go if you want to have like a really ambitious career. And, you know, if you don’t Like Buenos Aires, tough luck. Like it’s tough, you know, it’s a beautiful city. A lot of people do love it, but if you want something else from your life, you want to be a Hollywood movie star, you now have to get a visa. You have to like uproot your entire life and move to a whole another country on a different continent. And so I think it’s something that we’re going to have to find new models for it because what’s happening now locks a lot of people out of opportunities, and I think it’s honestly a moral issue. There’s people who live in places with very little opportunity, and they themselves have a lot of potential, but they’re stuck somewhere that has poorer systems of coordination, and they just can’t get out. And so we’re going to need to find new models for that, but I don’t have solutions. I’m just criticizing at this point. 00:44:42 - Speaker 3: Yeah, the mobility question is really tough. To what extent do governments have a heightened obligation to their current citizens versus future ones who might yet be born there or might move there? That’s a really tough question. I don’t know. I don’t think there’s an easy answer. But looking within an existing polity, I think our discussion of voting and markets was really circling around the crux of the issue. The reason I think cities are so hard and potentially so much more valuable. is you have this mix of public and private impact. So by public and private I mean a private good with something that you kind of you yourself purely consume and the effect only touches you, like if you consume a pencil or something, you know, by consume I mean like you write with it. That basically only affects you. It doesn’t really affect your neighbor. It’s a totally private good and a totally public good, an example might be national defense. It’s like everyone in the country gets it or no one gets it. That’s not exactly true, but that’s a good that’s basically purely for the benefit of the group as a whole. The thing about cities is you get this really messy mix. So to go back to your example, Devin, of building a two-story building in a previously one story lot. There’s a huge chunk of private benefit you get space for the family and there’s all kinds of other secondary public impacts like there’s shadow and there’s noise, and there’s traffic, and then you’re consuming some of this precious lumber off the market, it’s all this kind of stuff going on. And I think the issue we have with cities is we only have a few relatively primitive technologies for distributed decision making and coordination. We We have first past the post voting, we have corresponding representatives with that model, and we have called laissez-faire economics, and the pure economic model works really well for private goods, and the pure voting model can work well in cases where we have a single public good that everyone cares equally about, but we don’t really have the social technology to address this mess in the middle. And that’s why I feel like we end up with so much issues with cities, and then the flip side of that is that I think there’s enormous potential on the upside if we have a coordination technology that reflects that underlying reality better, we could get into a much better spot with cities. I’m so optimistic that we’ll figure something like that out. 00:46:49 - Speaker 1: I think that’s really well put, and that actually clarifies a lot for me, honestly. That space in the middle is really challenging, and I think right now we have these massive oversimplifications where we just pretend like they’re private goods, or we just pretend like they’re public goods, and they’re really not, they’re a mix. And so I think one of the reasons why we haven’t had more innovation in those sorts of coordination mechanisms for things in the middle is that there’s a limited amount of land and it’s really hard to Just start fresh. Like there’s kind of no frontier anymore on earth at least. And also in combination to that for the land that does exist, the people in power would have to agree that we should try a new system which would probably lessen their power. And so they I want to give it up. And like, you know, if I was in power, maybe I wouldn’t want to give it up either. I don’t know. Like, I think I have some pretty good ideas, so of course I should have the power, right? Like I think that a lot of people have that view. So it doesn’t make them bad people or selfish necessarily, but just, why would I give up control that I have? Some concepts that I’ve been really excited about that are a bit out there, but I think are really important for us to take seriously. the idea of building new cities, and 3 projects in particular have come to mind. One is seasteading, if you’ve heard of that, which is the concept of like building floating cities in the oceans, effectively creating new land. Where there wasn’t any before. A second one is charter cities, which is the idea of carving out land in a place that already exists, and creating sort of a special economic zone, much like how Shenzhen in China was a new experimental city. That ended up dramatically changing the way that all of China works ultimately because so some background, Shenzhen is this part of China where several decades ago, they carved out this place and they said, we’re going to like kind of experiment with capitalism here. We’re gonna like see if it works. And it works, like really well, according to the metrics that the Chinese government cared about. And so they started adopting those across the rest of China as well. So charter cities are kind of like taking that idea and scaling it to more places. And the third one is, a lot of people are really interested in the idea of going to space and going to Mars, and I don’t actually know a ton about that. That seems really hard, but I think that comes from this place of people saying, you know, there’s no blank slate anymore, and it’s really hard to change these kinds of things and systems that already exist. So, where are the places that we can create new land or create space to run these experiments? I think all of these are really far fetched, like, I’m not sure if any of these experiments will work. I mean, I mean charter cities have the most potential given that they worked in the past with places like Shenzhen or Dubai in some senses was a special economic zone, but I think the experimentation is where you get these new ideas and you develop confidence that they might work. 00:49:40 - Speaker 3: Yeah, and I have some optimism that we’ll see experimentation in those types of new cities. I’m also very bullish on experimentation with land like places in the non-physical world. So one example that I can kind of run through is spectrum. So electromagnetic spectrum, you need a slice of it to be able to communicate over the airwaves, basically things like radio and Wi Fi, go over this, and it’s kind of like land and that’s sliced up and it’s sold or licensed currently by the relevant regulatory authority. And that has a lot of the same challenges that we see with regular land, whereas if for example you have naive pure private property, you could, for example, say someone buys the slice of Spectrum for Wi Fi 100 years ago, and then someone else develops Wi Fi, well, the person who owns that Wi Fi slice just got massively rich by no. Work of their own, right? That’s really wealth that doesn’t in any way belong to them. And in fact, they could now not be a particularly good owner of it, but perhaps for financial or tax reasons, they don’t want to sell it, so on and so forth. So there’s all kinds of proposals for managing the allocation and taxation of land like things that we could try on something like Spectrum first. It could be that you have rolling auction or that you do a self-assessed value and get taxed based on that. There’s all kinds of experiments that I think are more palatable there and perhaps once we see their value, where value means like basically you’re unlocking a bunch of economic surplus and distributing it out to the citizens in some way, then there’ll be more eagerness to backport that into the physical cities where it’s higher risk. 00:51:12 - Speaker 1: Totally. Everything you said is very exciting to me. I think there have been some experiments run on things like land, like you’re talking about, and for the audience, I think the way I would characterize things that are like land are things that you cannot make yourself, like you technically can fill and like create islands and stuff, like, basically you can’t really make that much land. Or things that when you use them, you exclude other people from using them or you ruin their experience. So for example, if you use a plot of land, someone cannot build on it until you let them. And so that combination of those two factors of like, you didn’t. Make it. So anytime the value of it goes up, you’re not responsible for that value, but you’re actually going to capture it yourself. But then also you’re monopolizing it so that the rest of your community cannot use it. Those are things that are like land. So anything that’s like a natural resource basically falls in this category as opposed to something like an idea, which is not like land, an idea that is like infinitely copyable. 00:52:12 - Speaker 3: I think land has this property furthermore, where the pure raw land itself gets almost all of its value from the actions of other people. So a given acre of land in the United States, the value of that is almost entirely dependent on where it is. Therefore, the value comes from basically the people around it and all the activity that’s happening. So the reason that totally private ownership of land feels kind of weird from economic sense is basically all the value is made by other people, yet all the benefit is accruing to one individual. Now it’s not the case for like improved structures on the land, right, which should be treated differently. This reminds me of Georgisms, which was the kind of policy prescription to match this worldview about land. Devin just finally, maybe you’re familiar with this. 00:52:51 - Speaker 1: Oh yeah, I’m a big Henry George nerd. Go on though, I’m very excited about this, go ahead. 00:52:56 - Speaker 3: This was basically his belief about land was that the benefits to the pure raw land were developed by the citizens of a given polity and therefore those benefits were sort of owed to them. So what he advocated was basically you tax the raw value of the land. And use that to fund the government, and you don’t have income taxes or corporate taxes or whatever. 00:53:17 - Speaker 1: Yeah, like concretely, what that can look like is, my parents bought a house in Los Altos, about 35, 40 years ago, which is a town in San Francisco Bay Area, which is now a very expensive place to live. They bought it before, I mean, it was already kind of expensive, but now it’s like really, really expensive, one of the most like expensive places in the country. And while I love my parents and they’re very hardworking people who certainly contributed to the community, the vast majority of the increase in that piece of land that they bought decades ago is because a lot of awesome things happened around them, and people want to buy that land from them so that they can have access to those awesome things that other people created. Now, my parents also remodeled the house, which also increased its value, so that’s something they did. They put a little garden, it’s very nice. They themselves were contributing to the community through the work that they did, the volunteering that they did, you know, they volunteered in my schools, but the reason that property is so darn expensive is because it’s where it is. And if my parents had done all of that same. and all of that same community activity in like the middle of rural Missouri or something like that, their house would not have gained value much at all. And so that’s a situation where they’ve benefited from the system and, you know, indirectly I’ve benefited too, but it’s actually not really just like that value should actually go back to the community in the form of taxes, in my opinion. 00:54:41 - Speaker 3: Yeah, and to bring it back to our discussion about markets, the intuition here shouldn’t be that like, we should confiscate all the land or something, right? It’s more that we want to bring the dynamism and the distributed information processing and the efficiency, the experimentation that you get from markets and entrepreneurship to things that are more shaped like public goods or things that impact many people, because we have those incredible benefits in the pure private market. It’s, and it’s created an enormous amount of wealth and good in the world, right? We’ve had trouble with the more public domains, which by the way, now constitute most of our economy, you know, healthcare, education, so forth. We’ve had trouble with the dynamism and the efficiency in those spaces. So if we can find some way to bring those dynamics of the market to these more public spaces that could be really valuable. So thinking about the land thing, if you’ve ever been a homeowner, you know. So the incredible amount of pride and attention and care you place in your own private residence, right? Like you pay a lot of attention to it, you’re willing to invest in it. If we had a mechanism whereby you could get that same sort of care and attention to detail on public goods that were impacting others, perhaps because you got paid out a dividend or something, think of how powerful that could be, you know, how exactly you do it, that’s the social technology question, but I’m optimistic that there’s a way to make that happen. 00:55:53 - Speaker 1: Two ideas I’ve played around with, which might be terrible, I’ve, you know, no one’s ever tried them that I know of. So one, the simpler one is, what if people in San Francisco had shares in the city of San Francisco, like, equity, basically. And the reason I asked that question is like, right now, if you’re a homeowner in San Francisco and someone builds like a big condo building next to you or an office or something, you just lose out. Like, it’s just bad. It is actually just kind of bad for you for the most part. You know, don’t have as nice of a view, your vegetable garden has shade, like you have more rowdy neighbors or whatever. But if you had equity in the city, like maybe equity in the property taxes or so
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: The purpose of design is really to marry the kind of far out there crazy ideas with what can be practically achieved and serve some practical function. 00:00:16 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for thought on iPad. This podcast isn’t about Muse the product, it’s about Muse the company and the small team behind it. My name’s Adam Wiggins. I’m here today with my colleague Mark McGranaghan. Hey, Adam and Andy from Andy Works. 00:00:33 - Speaker 1: Hi guys, thanks for having me. 00:00:34 - Speaker 2: It’s great to have you on. I understand that uh you’re a woodworker. I was just looking at your clock project. 00:00:40 - Speaker 1: Yes, yeah, when I moved to Seattle, I finally had the space after moving from New York to open up a small woodworking shop here. 00:00:48 - Speaker 2: And how would you compare doing things with your hands where once you make a cut, you cannot take it back to the digital virtual space that is your day job, let’s say. 00:00:59 - Speaker 1: Yeah, it definitely requires a greater degree of thoughtfulness, I’d say, and the material is certainly a lot more expensive when you screw it up. But it’s been, you know, woodworking, I think has just been a great kind of like new creative field to get lost in and feel like a newbie again as someone who’s been in the design field now for 16 years or so. It’s great to just kind of get back to something and feel lost. 00:01:24 - Speaker 2: And maybe you can tell us just a little bit about your background. 00:01:27 - Speaker 1: Yeah, I came into design really through filmmaking first, and that was really sort of the first creative expression that I had sort of growing up in a, you know, small fishing village in Alaska and then found my way into design here in Seattle at the University of Washington, studied graphic design, and then started finding my way into this interaction field kind of combining filmmaking and storytelling with design and communication. This was definitely at the early years of product design, wasn’t wasn’t even called UX or product design at the time. And came through some different agencies, worked with Nike for a bit, worked at the big corporation Microsoft for a while on a project called Microsoft Courier, doing some ink and touch. 00:02:13 - Speaker 2: Courier, absolutely. That’s a, perhaps not a commercial success, but a um say a source of inspiration for future notebook computers, right? 00:02:22 - Speaker 1: Yeah. Well, we like to say it’s the new duo now, it just took 10 years or so to finally get out there. 00:02:29 - Speaker 2: Unfortunately, in this business, being early is the same as being wrong. Exactly. That’s a quote I often reference. 00:02:37 - Speaker 1: We used to joke at Microsoft that back in the Balmer era that they were either 5 years too early or 5 years too late with all their products. So in this case, maybe it was both. So 10 years off. But I did that for a while and that’s really what got me interested in tool making in the digital world and so left Microsoft and then ended up starting a company called 53 with some people from Microsoft. And that was really about taking that idea of building creative tools forward. And at the time, creativity wasn’t really a market that anyone was really looking at. The iPad had just come out and we started to see a lot of interesting opportunities with this mobile touch space on a larger screen and came up with a product called Paper and Paper was like a digital sketchbook and is still out there and doing well. 00:03:29 - Speaker 2: I suspect a lot of our audience knows paper and I certainly think of it as being one of the first apps that maybe really demonstrated the potential of the iPad, and especially back in those days, you know, there wasn’t an official stylus yet, and it was a much more nascent piece of. And yet if you saw an app like this and you thought, OK, now I can kind of picture what this might be for, how it could be more than just a big phone, not just a weaker computer. Right? 00:03:58 - Speaker 1: Yeah, that’s great because that was our intention. I think people forget when the iPad first came out, it was primarily marketed as a consumption device, you know, as Steve Jobs leaning back on a couch on the stage there. Reading books and watching movies. And, you know, we just always felt like that’s one view, but really technology for us really amplifies what makes us human, and a lot of that is creativity. So we just saw a lot of potential there. So we built paper, we built a stylus called Pencil before the Apple pencil, and really tried to kind of build out this ecosystem of creative tools. So we did that for a while and then ended up joining up with We Transfer and I worked there for a couple years heading up one of their products called Paste, and recently jumped away from that to start up this thing called Andy works. 00:04:54 - Speaker 2: And maybe that brings us to how we in fact got in touch, which is I came across here, let’s call it your uh initiating blog post. I don’t know, it’s the first article on your site in any case, uh, called No More boring Apps, and in fact, that’s our topic today, and maybe I can just scroll back in our, we have a slack inspiration channel here, and I posted the link when I first saw it a couple of months back or last month I guess. And I have a couple of quotes I pulled out here. One was, if you’re small, it’s to your advantage to be weird, you can build apps that the big tech companies never could. And secondly, when I use your app, I don’t want to see your company’s KPI that’s a key performance indicator. I want to see your point of view. And so those ideas being weird, particularly being weird and small, and not necessarily surfacing the business' needs, which I feel so much of technology today is something where they’re asking me for something because it helps their business, not because it helps. Me and the point of view, the perspective on the world, which could of course be wrong, but at least it can be unique and fit with your app and fit with your team’s vibe and dynamic, that sort of stuff is what I’m in this business for and hopefully is what we’re doing on the Muse team. I’ll link the article in the show notes, of course, but Andy, maybe you want to briefly summarize why you wrote that article or what you think the thesis is. 00:06:17 - Speaker 1: Yeah, I’ll try and summarize it as kind of succinctly as I can, but That statement, no more boring apps really was something of a rip off of the artist John Baldassari, who was a painter back in the 70s, who famously, you know, at the age of 39, well into his midcareer, done hundreds of paintings of landscapes, took all of his paintings, lit them ablaze. And took the cremations and made cookies out of them and it was a whole performance piece, but one thing that he did is he proclaimed, I will not make any more boring art and recorded a video of him writing that thousands of times over and over again. So I just loved that story, that sort of like epic moment of kind of renouncing your past and then going on to something else. And he went on to become one of the seminal conceptual artists of the 20th century. And sort of hesitate to put myself at that same sort of epic moment, but a few things kind of started coming together for me and one of those was simply kind of looking around at the industry. Again, I’ve been in this industry for a bit now and talking with friends, you know, I just wasn’t finding that much inspiration from the product industry itself. And the more I started to look at other design disciplines, you know, fashion, architecture, industrial design, furniture design, you see so many inspiring things there and when you talk to people from those fields, they have their heroes, they have like these amazing pieces that are coming out, people that are really pushing the boundaries of what can be done in that field, even though many of those fields are many decades if not hundreds of years older. Than product design. And at first kind of thought it was just me, you know, I was like, maybe I’m just reaching that age and I’m getting a little jaded, but the more I started asking others, the more I started to hear the same response, you know, people struggling to find interesting work in this field. 00:08:28 - Speaker 2: And I’ll add on to that point by it was actually just a couple episodes ago on this podcast that Mark and I were talking with Josh Miller from the browser company and we got onto this topic of architecture and buildings and how architecture we find inspiring both because it’s sort of an active. Creation that’s like art, but at the same time has these practical and functional elements, but notably there we all got excited about this. We knew the names of specific architects whose work we find inspiring. That’s exactly an illustration of your point. I think that we look for inspiration outside our field, not within it. 00:09:03 - Speaker 1: Exactly. And I think, you know, some of it is because it’s a younger field, like some of those titans are probably still yet to be really christened. But I think all the ingredients are there for great things to happen. You think about our field compared to these other fields, there’s so many people in product design today and building products, it’s an incredibly vast field. It’s one of the largest creative disciplines there is today, and there are many more product designers than there are furniture designers, for example, but you know, furniture designer doesn’t struggle to find inspiration within their own field. That was part of it, you know, part of it was just feeling that sort of frustration and some people have asked, does that mean I can’t have any boring apps, you know, does that mean, what about my bank app or something a lot more sort of cut and dry? Does everything have to be breakthrough and different? And that’s not really what it’s about. It was meant more as a kind of manifesto for Andy works itself. So what I’m trying to do with Andy Works is really push on this idea of design driven products, a truly sort of design differentiated software business. Because there really aren’t that many of those, I think when you actually strip it back. 00:10:25 - Speaker 2: Certainly a word that people use plenty in this world shaped by the Apple juggernaut, and that word went from being not really a part of the computer industry that I was part of 20 years back, let’s say, to being something that I feel like every company does talk about use that word in some way, but it sounds like you feel like they’re not getting quite right or at least it doesn’t push the button for you. 00:10:48 - Speaker 1: I mean, I think for sure design plays a role, but I think there’s a big difference between design, driving a business in something like fashion. I mean, fashion, it’s clothes. It just needs to be as functional as software. Like it still has a purpose and a function, and yet there’s an expressive element to it that’s very important. And there are fashion studios that wouldn’t exist. It’s entirely about the design, right? And same with architecture, there’s architectural studios that are entirely about the design, and it’s really the design that sells the product. And something that I’ve come to appreciate, I think more so over the last 5 years or so is, and this is not a knock on business, but how much business drives everything at a company. And it can be for kind of good or bad. And I think a lot of this is gonna sound either really obvious or maybe unintuitive, uh, depending on who you are, but business really drives everything in a company and it drives the goals and the objectives of what you’re trying to achieve as a company. And design serves that goal, just like anything else, just like legal development, everything else, all the other operations at a company. And that’s not always aligned with people or users. And so if that goal, it can be really be based on anything. And it can be based on some like core revenue metrics that you want to hit, but everyone sort of has a different pathway there to get to those goals. And it’s not always coming directly through design. A lot of products that we use today that we think are well designed, they may be well designed, but I contend that a lot of them aren’t actually design driven. Examples of things like, I mean, I love the design of something like Airbnb, great design, great design team, but I think the truth is that like, I don’t know if it’s truly a design choice that you’re making when you go there. I think it’s actually a number of other factors like price, maybe some other aspects of convenience. There was a time where Airbnb design was not so good, and they did pretty well, and they found a great foothold. It’s not to pick on Airbnbs. 00:13:16 - Speaker 2: Is that partially a function of the business you’re in or who your customers are, you know, maybe in the Airbnb case, you just want access to the inventory that they have to offer. Exactly as you can imagine something else where you mentioned the bank example before, and I do think there is, yeah, we can come to the best practices versus the more original. Approach, but I do choose banks based on whether they have a good user experience in the way that I interact with the services they’re providing me because lots of banks can hold my money, but being well designed is in fact a differentiator and a big one for me, a deciding one. 00:13:51 - Speaker 1: Yeah, so I think there are these key kind of companies like that that really, for me, it comes back to how much of it is what you’re doing and how much of it is how you’re doing it. And I think design really comes into that latter portion. It’s really about how you do it. So where everything else is equal and you’re offering sort of the same thing as someone else, design really comes in and helps differentiate it. You know, paper is a good example of this. Paper was not the first drawing out on the iPad. There were literally, you know, 40 or 50 others. That we looked very closely at and just felt like they weren’t capturing the right sort of spirit of creativity and weren’t executing on it very well. And we took all those insights and thought, well, let’s formulate it into something else, something that focuses really on some of the key things that we knew were really important to the creative process. So it took those sets of values applied to something that already exists and I, I mean if you looked at paper just from a bullet point standpoint. It would have looked very boring, you know, if you just had a feature list. It would have looked like nothing. I think it’s that really that approach that you take that really makes it driven by design. And I think there’s just so much happening today where people are trying to find new problems to solve. And I think that’s great, but for me, I’m at a place where I don’t feel like I need more or I don’t feel like I have a ton of new problems to solve. I kind of want better, you know, when I look at my phone, it’s full of hundreds of garbage apps, to be honest, stuff that I just kind of downloaded in the moment. And I’m just finding this desire to have like that well crafted thing just like as we are in our homes, you know, I think you look around and the things that you choose to put in your office or on your desk or in your kitchen, you want those things to be considered to reflect your values. There’s nothing revolutionary about a new tea kettle, but maybe you want something that just like really reflects your values and your aesthetics and maybe even be a little bit inspiring. 00:16:07 - Speaker 3: Yeah, totally. So my perspective on your post was that there’s potentially a lot of degrees of freedom that you have when you’re designing a business and a product, but it feels like design is often the last variable, so you end up fixing things because of the economics, because of your or structure, because of your product goals, or because of just, um, assumptions or constraints that you impose on yourself. And then after you’ve done all of that, you don’t have a lot of room, basically. On the design, so everything ends up looking the same, right? And when I think of when I hear no more bad apps, it’s like break out of those constraints, let design be a more free variable, give yourself more degrees of freedom, so you can make different choices and not take on so many of these assumptions and premises and see what comes out of that. Yeah. And I think that speaks both to, by the way, the product in terms of where you end up with the design, but also speaks to you as a designer, right? It’s not super fun to be the last free variable where you’re very constrained. You want to be actually to have more agency over how the thing works in the broadest sense. 00:17:06 - Speaker 1: Yeah, and I think we’ve kind of seen this sort of central premise of like user centered design. We’ve seen its flaws now, we’ve seen where it can fall short. 00:17:17 - Speaker 2: So here you’re talking about user centered as in more driven by kind of user research, as opposed to, I don’t know, a designer’s internal sense of what’s interesting, special and good. 00:17:31 - Speaker 1: Yeah, in a sense, I mean, again, it’s one of those things that can sound very obvious, but as people like we’re we’re terrible at knowing. What it is that we really need, right? You know, you can kind of ask us what we want, but we’re pretty bad at knowing what we really need. So that’s kind of a direct hit on the idea of user centered design. Now, there’s a lot of good with user centered design, but I think with anything, you know, once it becomes a dogma, it can go too far and we can start to see its flaws. You mentioned architecture earlier. I’m a fan of America’s greatest architect really, Frank Lloyd Wright, and His household name back in the first half of the 20th century. I think he was on the cover of Time Magazine like twice. Like everybody knew him. He was like a superstar back in the day and really shaped American architecture in the first half of the 20th century and even beyond that really. But, you know, his last work was the Guggenheim in New York and It’s a weird building. It’s not quite in line with much of what else he’s done. But when it first came out, it was super controversial. You know, now we think of it as this great pillar of architecture. It was very controversial at the time. People were complaining about how it was very disrespectful of the art. I don’t know if you know it, it’s a building that’s basically a giant spiral. So you walk along the outside on a slope. So you’re walking around this large atrium on the exterior around the slope, spiraling upward, and then you walk back down, spiraling down. And it’s kind of antagonistic to users in a way. It’s not very conducive to appreciating the art, but it’s become like one of the best places to build installations because it has become its own kind of unique place that has created its own sort of unique artwork. So artists will sometimes create paintings that follow the curvature of the floor and have this slight bend to it. And I think about that sometimes because I think, again, that wasn’t listening necessarily to what an art museum should be. It was creating this new vision and then having other people jump in and react to it. And that’s something that I think again is kind of missing like user centered design can be this great kind of iterative approach. It can get you kind of to this local maxima. But if you really want to step into new territory and see some new vista, you know, sometimes that takes some crazy leap of faith by like individual minds, right? 00:20:16 - Speaker 3: To look at another art form, Keith Raboy makes this point with movies. You don’t make a movie by surveying 100 people and then taking the average of what everyone said and then filming that, right? If someone has a vision for a movie that should exist and they pull together all the pieces to make that happen. They find the actors, they find the photographer, and so on, and then you test it, and you see, OK, people do where they don’t take that up, but you have to work backwards from a vision. 00:20:41 - Speaker 2: Which once again seeking inspiration from other fields, and actually that strikes square on one of my favorite books in this kind of maker biography category is called Making Movies. I can’t remember the author’s name, but it’s a pretty successful Hollywood director who basically wrote a, here’s how I make movies, he just kind of like walks through the whole process giving specific examples from his work. And the director is this sort of the visionary CEO type of the thing, he, she or they are doing some kind of artistic expression, but they also have all this practical management stuff of just getting the right people there and the technical stuff with the camera and Dealing with weather and dealing with municipalities and zoning and permits and you gotta sort of pull all that together while at the same time keeping the line of sight of the vision that you’re here to make a piece of art and make something that moves people and you do that by having a unique idea and sticking with it through all those practicalities. 00:21:39 - Speaker 1: Yeah, I love, as I mentioned, my first creative outlet was filmmaking, and I loved those as So I tend to use filmmaking as references quite a bit. And one thing that I love that a lot of great directors, Tarantino, Scorsese, the advice that they’ll give to up and coming directors is really to make the movie that you wanna watch, you know, find something that you want to see, that you want to exist, and make that. And if you’re lucky, there’s probably other people like you out there that are really gonna connect with it. But that’s really the only way to make a great story, is to really, you know, feel something personal about it. And I don’t really say it in that piece, maybe I hint at it, but Part of my hope is that the product design and products in general can actually be this vector for interesting culture to emerge. Again, our products are used by billions of people every day, and there’s so much time and so much attention put into these products that I think it’s just this great medium that we haven’t really fully explored in terms of creative expression. 00:22:55 - Speaker 2: Can you think of some examples of digital products as vectors for culture? 00:23:01 - Speaker 1: Yeah, I can, believe it or not. But it doesn’t come from the product world, it comes from gaming. 00:23:10 - Speaker 2: Yeah, Mark and I reference games and both technology inspiration and design and otherwise more often than you might think for a productivity tool. 00:23:19 - Speaker 1: I think gaming is amazing, and I hadn’t sadly really been following it that closely. You know, you’d think someone in UX design and filmmaking, like the intersection of that is gaming. But I hadn’t really been following it. So this last year I’ve really jumped in and kind of immersed myself in gaming, and it’s just fascinating. I mean, yeah, if you’re talking about ways to really connect with individuals at a brand or an emotional scale in the digital world, I think it’s gaming and so, yeah, I mean, a lot of work from Play Dead Studio like inside. Limbo. Yeah, I love Limbo. There’s a Swedish game designer, Oscar Stolberg. I don’t know if you guys have heard of him. He did a game called Bad North, uh maybe a couple years ago, but he just came out with a game, you know, it’s, it’s hard to even call it a game, it’s almost a creative toy. But it’s called Townscaper. 00:24:20 - Speaker 3: Oh, that guy, yeah, I just know him as the townscraper guy, yeah. 00:24:24 - Speaker 1: It is fascinating. I mean, the execution on it and the thought put into something, again, like to explain to people like you literally just click. Like a sort of empty grid and you create these little like cubes of a town and so you build a town. That’s kind of all you do. So it’s almost like digital Legos in a way where you’re like building structures, but just the thought and attention that goes into how these things are built and how they connect and how one connects with another. He has lighting, he has just amazing sense of polish and execution. On something that’s really just so simple. So those are the things that I tend to look at more and more these days. 00:25:08 - Speaker 3: Yeah, it’s interesting when I was thinking about inspiring digital creators, the first big category that I came to was these maverick game designers, and often it’s just one person who somehow builds the whole game end to end. A few examples that came to mind for me was Jonathan Blow with Braid, Notch and Minecraft, Jordan, I think that’s Bechner on Prince of Persia, and oftentimes they did not only the idea and the story, but the programming, the graphics, they composed the music, sometimes they record it. It’s an amazing breath, but going back to this idea of degrees of freedom, that gives me the ability to have this vision and to build it up using all of those different angles and aspects to the way that they want it to exist. So you get these very unified, polished, inspiring experiences from it. And they’re able to do things that are really out there, because when you have this new idea for how a game should work, you really need to change all those other aspects at the same time. And it’s hard to convince a bunch of other people to do that. So by having everything under your own control, you can often make that happen. 00:26:06 - Speaker 1: Yeah, and wouldn’t it be great to have some of that seep more into our everyday lives? That’s kind of my dream, I guess. And what we’re trying to pursue with Andy works is like, can you take some of that playfulness, that fun. That challenge it at times and bring that into everyday experiences, maybe. 00:26:26 - Speaker 2: Now games and film both are probably more on the, there’s obviously many practical aspects to implementing them, but the output really is art and it’s more pure form. It’s designed to give you an experience or show you a perspective on the world that doesn’t really serve a practical purpose, whereas the clothing and architecture examples we used earlier, those maybe are closer to something like digital tools, productivity tools in the sense that, On one hand, they can be inspiring. They can express an artistic vision and in the best cases they do, but they also need to do practical things. They need to stay on your body and keep you warm. They need to house humans or in the case of productivity tools, they need to solve a specific problem that a person has and is willing to pay for. How do either of you think about that trade-off between the express something original or inspiring or playful or soulful versus solve a problem such that someone wants to pay you for the product? 00:27:25 - Speaker 3: Yeah, I’m not sure there needs to be a trade-off. actually, as I was thinking about other examples of inspiring creators, I came up with this category of like the vertical integrators, this would be again Raboy with and team with Open Door, Ryan Johnson at Cul de sac, obviously Elon Musk and everything that he’s doing. These are people who like, in the case of cul de sac, for example, it’s like, I want a more walkable neighborhood. So do that. I’m just going to go to, I think it’s Arizona, buy a bunch of land and like build an entire neighborhood from scratch. OK, that’s a lot of real stuff to achieve a real end. And likewise, of course, with, you know, Elon sending stuff to Mars and so on. So I think you can get both of those and actually I think when you undertake a more ambitious and inspiring mission, you can often attract more talent, resources, and so on to your venture. 00:28:04 - Speaker 1: Yeah, I’ll even go a step further. I honestly think that is kind of the purpose of design, is really to marry that the kind of far out there crazy ideas with what can be practically achieved and serve some practical function. And I think without those two ends, it sort of gets lost or the design falls a bit flat or loses touch if it goes too far and the kind of playful. I mean, I’d be tempted to just build a game myself, but something in me, I think growing up in Alaska, feels like everything I do has to have some practical purpose to it. And so I like this idea of trying to bring those two together and again like I think we see it in so many other aspects of our lives, you know, the furniture that we buy to the items that we use every day. We use them, they serve a practical purpose, but we don’t just buy any chair, you know, we buy a chair that speaks to us, fits within our surroundings, maybe reflects something that we think is interesting. And so it’s always kind of this combination of the two, and again, yeah, you see it in fashion, you see it in architecture. We just haven’t really seen that much in the digital product space. 00:29:19 - Speaker 2: I like your connecting items in our daily life, physical items in our daily life to some of these digital products. And for me, this is why I like using the word tools. For me, my bike is a tool for me to get around the city. And my kitchen knife is a tool to help me do a better job at making healthy food, and the furniture, for example, a chair is a tool for me to sit on either to do productive work at a desk or relaxing chair to sit and read or feel cozy. These are all tools that serve a purpose, but also can make me feel inspired or make me have certain kinds of positive feelings and digital tools are no different. The apps on my phone, the software on my computer, the services I use for email and calendar and all these other relatively prosaic things, but in the same way that sitting and cutting and writing are all prosaic everyday things, so too are these digital things. I mean they can’t be inspired and that they can’t, as you say, marry together the practical function that they fulfill with something extra, something special. 00:30:21 - Speaker 1: Especially because we’re spending more and more of our lives in the digital world now, and we expect to spend much more of it over time. I mean, especially now, of course, with the quarantine, but we’re spending so much of our time here. And that was another thing. I just started to see where this was going. It’s like, oh man. This world needs to look a little better and be a little bit more inspiring if this is, you know, where we’re gonna be spending the majority of our time down the road, you know, where we meet people, where we connect with people, where we get our work done. And I’m really drawn to these everyday things. 00:30:59 - Speaker 2: So when we think about everyday physical items in our life, one that comes to mind for me is this clock project that I saw you document on Twitter. How does that fit into what we’re talking about here? 00:31:10 - Speaker 1: Yeah, so that really came about through one this interest in furniture making and just really like, again, getting really deep and lost in like a brand new field. As soon as you get that new talent and that new ability, I feel like you start to see everything around you as something that can be rebuilt or redesigned or or recreated. And one thing that I had my eye on for a long time was a clock. And the reason for that is that my kids, I have two young kids ages 3 and 5, and they would constantly ask me, as young kids do, is it time for bed yet? Is it bedtime yet? Is it time for lunch? Is it time for dinner? They didn’t know how to read an analog clock, and at first my thought was, well, let’s just teach them how to read a clock, but then the design brain kind of kicks in and you’re like, well, maybe the problem isn’t the kids, but it’s the clock, not the user’s fault. 00:32:10 - Speaker 1: Exactly. So you start digging into it and you start to realize how many of the conventions that have really been set. You know, how arbitrary many of them really are like the sort of twice around 12 hour dial clock that we think of as the analog clock, was more of a mechanical limitation at the time, and it’s just kind of hung around for a few 100 years. So I started to think about what a clock could be. It turns out like an analog clock is really hard to read actually. It sounds simple cause we’ve learned it and we looked at it all the time. But if you’re a young kid, or if you’re, you know, it’s even used as mental aptitude test for people that may have like early onset dementia. And so it’s actually quite a complex abstract test. You know, you have to think of which hand is what, you know, there are multiple hands, they represent different increments of time, and you have to know which direction they’re moving. You have to know that like the large hand pointing at a 3, multiply by 5, that means it’s 15, that’s a fraction of 60. There’s a bit going on, and that’s just too much for a 3 year old to really grasp. But it’s silly like they understand time, in a sense, they understand that things take time and that something isn’t now or it’s later. They understand the concepts. 00:33:33 - Speaker 2: They just can’t the cyclical aspect of the day as well that there is a dinner time every day that is at the same time and it’s the day that changes, uh, even though there’s a, there’s a, there’s a new day, but maybe the only thing they understand is that there is a schedule. 00:33:45 - Speaker 1: But I started looking at that and just going down a rabbit hole of like questioning every assumption and actually ended up coming back to the first clocks, which were sundials. And that was the first goal was to fix the model rather than spinning twice. We see the sun move around the earth, or that’s how we perceive it, once a day. So, OK, let’s have a 24 hour clock rather than 12. And then I got rid of the hands that was clearly like just too much information. And the truth is, if you’re a kid is at 1253 or 1255, like that level of precision doesn’t really matter typically. So I replaced it with just a single hand that moves around a 24 hour clock, and then I painted half of it dark and half of it light. So the dark half was nighttime, the light half was daytime. And then probably the best move was just, I did this right at the end. I just slapped a sticker next to bedtime on the clock. So just a little red dot. So the hand is like a nice bright red and this red dot. So all they have to know is like, has that hand hit that dot yet or not? That’s when they know it’s bedtime. And kind of, you know, whenever you make something, you don’t know if it’s gonna work. This like surprisingly worked really well. Like, they immediately got it, didn’t have to really be taught it. And now they can read it and they can tell me the time, they could tell me if it’s bedtime or not. And so it’s really kind of changed their abilities and really like opened up their own sense of agency. But probably the most interesting thing is I found that for me, it was also a little bit easier. I didn’t quite realize just how those micro moments of kind of looking at an analog clock to kind of compute the time. How much that was really in the way. It’s kind of like uh uh it’s hard to explain, but it’s almost like screen refresh rates, you know, once you jump to 120 from 60, suddenly like, you notice it, you feel it, and it’s hard to go back. It’s that same kind of like mental exercise that suddenly it feels easier. And the other thing is that I noticed that of all the things I built, I mean, paper’s been downloaded 50 million times and I use it every week, but I don’t use it as much as this clock. This clock I use 20 times a day at least, and it’s just like making those small moments better and easier and more delightful. And that really got me on this path and what we’re trying to do with Andy works around taking that idea of like, no more boring apps and the everyday, and you make these everyday moments. Marry them with great design and build something that’s truly like design differentiated. So all these little digital moments that touch our lives throughout the day, you know, I wake up, I check the weather, I set a timer, these things like this, can you elevate those to something interesting, inspiring, maybe even simpler. 00:37:01 - Speaker 3: I think it’s such an interesting example because it shows. How often bad design or boring design is really directly downstream from the wrong assumptions or constraints. So yes, if you assume your clock needs to go around once every 12 hours, it needs to have second accuracy, it needs to have two hands, it needs to have 12 at the top, it can’t have any other markings. Like you basically back yourself into the boring old clock, but when you break free of those constraints, when you allow yourself to analyze the problem from first principles, there’s a lot more you can do. That’s a power and I see a lot with things that end up being boring apps. 00:37:33 - Speaker 1: Well you guys are doing this too. I feel like testing some of the assumptions around navigation, input, creativity. 00:37:40 - Speaker 3: Yeah, totally. And not only assumptions on the design, the solution that is, but also on assumptions on the sort of problem or the inputs. So for example, a big one for us is we broke the assumption that you need to be flexible to people having a stylus or not. Basically, Muse requires the Apple pencil to. substantially and a lot of apps, they just would never accept or even consider that being a possibility. We realized, hey, actually, basically, everyone has a stylus, the people who don’t, they’re happy to buy one, so let’s just roll with it. And that gives us a lot more degrees of freedom to use that as an input modality in a more powerful way. 00:38:12 - Speaker 2: Thinking about established conventions like 24 hours on a clock or do the hands go around twice and thinking about Muse and where we’ve tried to sort of challenge the status quo because we think things can be improved, such as requiring a pencil versus places where we just go with what people know and expect. I feel like with apps and software, you have the platform conventions and in many cases even rules, right? Apple and their human interface guidelines and the the app store rules and the review process and there’s a different but similar set of conventions for say web software, desktop software and so forth and. I think part of the hard part of the journey we’ve been on building this particular product and I expect it’s the same for anyone that wants to do something a little bit original, is trying to decide where to take your weird thing and just really take that all the way and just double down. on the fact that you’re breaking on what’s expected or even breaking the rules of the platform and in other places, you just want to be as simple and standard and boring and exactly what’s expected on the platform as possible because that’s not where you’re really innovating. How do you navigate the trade-off between those two things? 00:39:22 - Speaker 1: Yeah, you can’t really play either extreme, obviously, and you see that happen sometimes, especially with younger product makers or designers trying to reinvent everything in their experience or their app, and you can very quickly go down a path of just everything’s too new. Everything’s like, look at me. I mean, you’re really calling attention to something when you are rethinking it. And so just like with, you know, a great piece of graphic design, you kind of know how to control someone’s attention. You can’t make the whole thing loud. You have to know where to put white space and where to draw attention. And that’s really the trick is kind of finding what’s unique about you. That’s usually where you want to put the innovation. I don’t know if you guys have heard this before, but sometimes we in the past talked about things like an innovation budget, you know, you have a certain amount of innovation that you can plug into your app that people are willing to kind of learn because there’s something new and unique and interesting behind it or that is unlocked by it. And so you have to really, I think, know what’s unique, you know, like what is it that you’re bringing that’s unique, and that’s where you focus on what becomes, you know, unique and interesting and rethinking common conventions. But honestly, like most of an app, oftentimes or any sort of product is convention, and that’s important because you need the important stuff, the truly innovative stuff to pop out, to jump out at you. And you can’t have it all jump out. So there are places where you kind of need it to recede a bit, and the best way to do that is to follow some convention. There’s nothing wrong with conventions, like they’re there for a good reason. But they become the sort of like receding sort of principle. 00:41:12 - Speaker 3: This actually reminds me of another great blog post called funnily enough, Choose Boring Technology, which seems contradictory to your blog post title, but it’s actually making a similar point to what you just said, which is, I think he called them innovation tokens, if I remember correctly, this idea you have like 3 to spend in your entire business and so choose wisely what you invest your novelty in. 00:41:32 - Speaker 2: Maybe that one is on the implementation side. And Andy’s talking about sort of the user side, users only have so much willingness to kind of struggle through figuring out something new, so you want to spend that call attention to the things that really matter and everything else kind of follows conventions and on the implementation side, such as technology. It’s just your team is going to need to push hard and invest more and spend more time to get the weird stuff right, to get it good or get it interesting versus following conventions. It’s kind of almost mindless. You just do what is known to be the best practice and that’s it, you can move on. 00:42:08 - Speaker 1: Yeah, and I think one of the challenges or shortcomings that I see today is that there are a lot of products that are almost all convention and you sort of struggle to find it, at least again from a design standpoint. I see a lot of companies innovating on business models or distribution or various services, but in terms of design, execution or a user experience, there are very few that I think that are really kind of pushing the innovation button there, but there are things like design systems are great, but again, that’s like a tool you’re establishing a convention, and if your entire design. It’s just kind of hinged upon pulling components from existing design systems. Then, you know, your index experience is gonna look pretty conventional. 00:42:56 - Speaker 3: Yeah, and ultimately, well, I think it’s important to have a sense of how you’re going to navigate this tradeoff of convention versus originality, I think you ultimately need to go back to first principles and just make a great design. I think some people sometimes get lost in how they’re relating to the convention or whatever. You gotta ask yourself, is it good? I sometimes joke with our designer Leonard, like, Leonard, you can design this however you want as long as it’s good. And I’m only half joking when I say that. 00:43:18 - Speaker 1: Yeah, to go a little further, I, I, you have to realize, like, why do these conventions exist? I mean, the truth is a lot of conventions exist. A lot of the guidelines for these things exist. Like think of who is building an app like Google has to build these guidelines for everyone. Like somebody that knows nothing about design. They’re kind of building a base layer and also one size fits all, right? 00:43:40 - Speaker 2: So it’s not just the skill level of people implementing, but just all very different kinds of apps or in some cases weighted towards just where their existing customers or revenue bases, right? That’s part of what we run into with Muse, which is so much of the iOS platform and design conventions are based around phone used with one finger or small screen. And so those conventions are basically good there for consumer apps on the phone, but they become quite restricting and even very counterproductive on the iPad for a professional tool. 00:44:11 - Speaker 1: Yeah. So in many cases, the conventions are just that, they’re conventional, like they’re not going to get you to something interesting because they’re not really designed that way. These guidelines are put in place to provide some very base common denominator experience for everyone. Like you’re not gonna be able to kind of push above the noise and achieve something truly great by following those alone. 00:44:38 - Speaker 2: I’m also reminded of a lesson that my high school English teacher taught me, which is I was complaining that we were taught all these rules of good writing and even grammatical rules, and then we would read these classics who were held up as these amazing works, and I would point out all the ways that these authors broke the rules. I said, why are we learning these rules if these great works break them? And her answer was, well, you have to know the rules first because then you can break them in interesting ways. 00:45:03 - Speaker 1: Yeah, I agree. Thumbs up. I’m curious for you guys, what you think your most controversial belief is. Hm. 00:45:14 - Speaker 3: It was very interesting. 00:45:16 - Speaker 2: Yeah, for me, and part of the premise of MS is that I believe that computers can help us think, not just author, but think our thoughts. And actually maybe with some of the tools for thought stuff that’s breaking into the zeitgeist a little bit this year, that’s slightly less controversial, but the counterpoint to that is everything about the way that they’re created now, particularly when you get to the realm of web and mobile platforms, which is essentially where all the action is, let’s say, is designed really specifically to keep you from thinking. There’s literally a bible of user experience design titled Don’t Make me Think. And my view is, no, please, make me think and actually help me think. 00:46:02 - Speaker 1: Yeah, that’s related to my belief as well, which is, well, I guess I have 2. Maybe I’ll throw 2 out there. But they sort of formed some of the the backbone of Andy works and what we’re doing. So the first is that a product can challenge its user. So at times maybe even be antagonistic or seem to be antagonistic towards the user, but again it’s something that you see in other aspects and so many other experiences that we experience in the physical world in other areas, you know, again, films, if it doesn’t challenge you, it’s not interesting, right? And so, I really think that design can challenge, it doesn’t have to be invisible. It can kind of be right up there in your face. And we just have yet to see it. That’s one. The other one is around pushing back against the idea of scale in software, and it really kind of cuts against, I think, what is just natural in the software world, or, you know, software just naturally wants to be high volume, low margin, but thinking about, you know, is there a way to flip that around where it’s, you’re talking about very low volume, high margin value though, and Ship something and create products that are only for a few people, but really deliver a ton of value to them in the consumer space, not just in the like specialized professional space, but in a consumer space. I don’t even know if that’s possible, but I’m really interested in it. And like we’ve been trying some things with Andy works to do some of that, but it’s really cutting against the grain of software. Everything about software wants to be completely open and available to everyone, you know, we’ve been exploring ideas around like making limited edition versions of software. That’s something that is just like, you wouldn’t have to think twice about that in the physical world. It would just come naturally. But like in the software world, you have to do extra work to limit it, you know, you have to like track quantities and things like that. But I’m really interested in that sort of sense of exclusivity and personalization and having this like high impact on fewer people. 00:48:16 - Speaker 3: Nice. I like that a lot. And that also resonates with what I was thinking about from my controversial opinion, and it connects back to this idea of design is related to everything else in the business. It’s related to your work structure, it’s related to your business model, it’s related to the economics, it’s related to your users and your protocols. So I think the flip side of that is that if you really want to do something innovative with design, you have to grapple with those other aspects. I actually saw, there was a tweet from Patrick Colson yesterday about people who are doing interesting work on desktop designs. And to me, that’s, you actually can’t tackle that without tackling the whole problem of funding that work and getting it distributed. So I think the most interesting design problems are really these system problems of how do you organize people over time to come to this future that you want. And I’m excited that people are now starting to try that a little bit, like in your case with software, I’d like to see a lot more of that experimentation. So before we close out here, I want to bring it back to where we started, which is working with your hands and woodworking. So Andy, I have a sort of pet theory about woodworking in particular, and I’m curious if it resonates with you as a woodworker. And I developed this theory because a lot of my programmer friends and acquaintances have wandered into the field of woodworking. So I think there’s some particular attraction for people who work in technology. And here’s my theory. So, There’s the kind of obvious piece of it’s a new and different creative endeavor. In the same way that I, you know, play the piano, and that’s a creative thing, woodworking is also a creative thing. But I think there’s more factors at work. One is, it’s a very physical undertaking where you use your whole body and also the work product is something you can, for example, sit in or lie in. And so that is something that I think a lot of people who work in technology are missing because it is very digital, unsubstantiated work products. But the thing that I think is most important with woodworking is you have a lot of agency. As a woodworker, you can go all the way from the tree to the end product yourself. You have control over the exact wood use, you can choose your tools, you can choose what you build. You’re so much creative freedom and agency as an individual woodworker, whereas with Modern programmers, it’s like, OK, you basically got to use iOS and you got to use Swift, and if you don’t like that, too bad, you know, find another job. And I think people are increasingly grinding up against that as developers and when they see woodworking, they see all those ideal qualities as a creative person. So I’m just curious if that resonates with you. 00:50:33 - Speaker 1: Yeah, actually, that does. And like you said, I think it’s a common feeling. I think even outside of woodworking, you know, you see a lot of people baking their own bread during the pandemic, right? I mean, to the point where it’s almost becoming a joke. But look, if you’re gonna go out and make something, I’m not gonna make fun of you. I think there is something about, yeah, going back to some very fundamental materials and being able to shape it into something again that you can use and you can use every day. And that was definitely part of it for me. Another part for me personally was I’ve always been interested in 3D and getting deeper into 3D. But you know, like, uh, when I left we transfers at the start of the year, I’d just been kind of burned out on digital things and just needed to like step away. But a great way to get into 3D is not actually through the 3D software. 3D software is like some of the most complicated software in the world. I mean, uh, the modeling, the rigging, animation, texture, I mean, like building a game is pretty sophisticated stuff, and it can really be a beast to try and get into. So the way that I kind of wanted to break into it wasn’t actually through the software, it was through like playing around with 3D form and thinking about three dimensional form. I mean, again, I come more from a graphic background. So for me, it was a great way to just start thinking and playing in 3D, getting back to basics. I feel like I learned a lot actually about product design now that comes from woodworking that I’m sort of bringing back into product. But yeah, wordwork is great. I mean, it’s amazingly deep. It can seem so simple, but I mean you could spend a long, long time just trying to figure out the right finish for your desk or your bench or whatever it is, because there’s so much history there, so there’s so much depth, so much history. To dig into and you can never really reach the bottom of it. I feel like you talk with super experienced woodworkers and they’ll all still say like, uh, I don’t really know what I’m doing, you know, like, there’s someone who’s a better expert out there than me. And so I really love that, the sorts of combinations of things, the depth of it, like you’re saying, the kind of like elemental nature of it to take something very primitive and transform it into something that you can use every day. And then again, personally for me, it was partly just like Getting my hands into something 3 dimensional. Hm. 00:53:09 - Speaker 3: Very interesting. 00:53:11 - Speaker 1: Do you guys do woodworking? 00:53:13 - Speaker 3: I had dabbled in it a little bit. I actually took some courses here in the Seattle area, and then when I was younger, I did a lot of model working, which is like, you know, balsa wood type stuff, and I had a lot of those properties of you have agency over what you’re building and what you end up with is something very physical and potentially interesting, if not, you know, useful in the classical sense. 00:53:31 - Speaker 1: Yeah, I mean, I think the reason a lot of us, like a lot of people from our generation got into this sort of like digital product world. It was partly because of how open it was. Back when I got into this 20 years ago, there were no tools to design this stuff. There wasn’t a software application to design software, you know, you had to use photo editing software or like, you had to hack Flash, you know, which was meant for animation to build something with scripting. And so we kind of got into this, I think, because of its ambiguity and its openness and now over time as it. That open field is like slowly started to pave pathways. And then lay down the asphalt. Now things are very set in many ways. And so, yeah, moving something to a discipline like woodworking or metalsmithing. I know some folks jumping into that. That’s just kind of going back to this idea of like, well, now anything’s possible again, kind of going back to something that’s very elemental that you can really shape in any way that you want. I personally think that there’s still room in the digital world. Oh yeah, totally. And we just haven’t, maybe to your point, haven’t set up the businesses and the sort of fundamentals right to make it possible yet. I’ll stop there, cause I’ll probably keep going. 00:55:00 - Speaker 2: I think that’s a great note to end on because it leaves me feeling inspired. Great. Well, if any of our listeners out there have feedback, feel free to reach out to us at @museapphq on Twitter or use email with hello at museapp.com. We’d love to hear your comments and ideas for future episodes. And Andy, this was really inspiring discussion. Thanks for coming on and thanks for pushing us all to not be boring. Thanks for having me, guys. All right, see you both later. Bye. 00:55:26 - Speaker 3: See you, Adam.
© 2020-2025 Ivy Podcast Discovery LLC
