Transcript

00:00:00 - Speaker 1: One of the things that’s really important, whether you’re talking about product principles or company values, is you have to be able to negate them, cause otherwise you don’t use them to resolve conflict.

00:00:14 - Speaker 2: 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 the product, it’s about Muse the company and the small team behind it. I’m here today with my colleague Mark McGranaghan.

Hey Adam, and my former colleague, now friend Max Schoening. Hey, Adam.

Max, great to have you here. So, Max has an impressive career in the tech world, both as an indie developer making cloud app years back. The 3 of us worked together at Hiroku and now you’re leading the design team at GitHub. More importantly, for our purposes, you are an early user, you are our very first customer for Muse, and you’re also an advisor, so we get to bombard you with our half-finished ideas once a month, and you can tell them, tell us why they’re bad.

00:00:59 - Speaker 1: Uh, thank you for that very generous introduction, and it’s, it’s quite the privilege to be a part of the Muse creation process, even if it’s on the sidelines.

00:01:07 - Speaker 2: Now I understand you just got back from a camping trip. That sounded pretty fun.

00:01:10 - Speaker 1: Uh, yeah, I did. I spent The last week completely off the grid, my wife and I with the dog went and drove up to the Tahoe National Forest in a 4x4 sprinter van and did nothing but hike and sort of be in nature, which at this moment in time feels or is an immense privilege, right? But it was good to disconnect a little.

00:01:35 - Speaker 2: Now our topic today is principled products. Now this is your idea, Max. So maybe you can explain what this is all about.

00:01:41 - Speaker 1: Yeah, I think it might be interesting to to start at the beginning of how I was introduced to Muse because I think we had talked, we share lots of interest, sort of end user programming, end user computing, and also tools for thought and and making tools for people who make stuff. And so naturally, when you started Muse, you shared it with me and I think my first, I don’t quite remember, so please, please correct me here, Adam, but I think my first reaction was, OK, well, why would I use this? This is not letting me draw the way that I want to draw.

00:02:12 - Speaker 2: Yeah, I remember giving you a quick uh just in person demo. I think you were visiting your mom here in Berlin. You stopped by my place. I said, hey, I’m working on this new thing and just showed you, you know, a pretty early version and you I think you liked, you had a positive reaction to the zooming kind of spatial interface, uh, but then when you went off to try it on your own a little bit, you said, well, yeah, the ink’s kind of ugly and I have a better sketchbook app. using notability at the time and yeah, for purely for sketching, that’s true today as well. Notability is a better choice.

00:02:38 - Speaker 1: I think I narrowed in on the on the ink engine very quickly versus acknowledging the principles that Muse kind of stands for.

And I think that’s what triggered this entire thought process in me of to actually consider to make Muse work for you, you have to consider the principles that the creators in this case, the two of you and the rest of the team sort of put into the process.

And that’s where I think the train of thought of, OK, what are principled products sort of came from, as I tried to define what a principle what we mean by principled, I kind of came to the to the realization of it’s just a set of rules or laws that guide the behavior of the people who make the thing, but then there is even a secondary layer which I think is much more interesting, which is a set of rules or laws that guide the behavior of the people using the thing. And I think Muse is you framed it, Mark or Adam, I don’t remember, but as a as a tool for thought and a tool for rumination. The moment that you gave me, this is obviously not a very scalable process, but you gave me this onboarding onto the muse philosophy after I initially rejected the app and then it clicked.

00:03:46 - Speaker 2: Yeah, well, that’s great to hear.

Now we just need to figure out how to kind of replicate and scale up. That process, I guess, but in the near term happy to to do the one off, uh, one-off on boardings, I guess. Now, I’d be curious to hear from, from both of you, both of you guys, what are other principal products.

And I assume that many, many products are driven by mission or they have a purpose or uniting set of values, but I assume that when we, when we say when we really say principal products in the way you just described Max, that’s, that’s not many or even, that’s not. or even maybe many products that are out there.

So what are, what are some examples? I don’t know, Mark, do you have any that come to mind?

00:04:20 - Speaker 3: One that comes to mind for me is SQL light. This is a classic database that has this principle of being super reliable and running everywhere. Actually, the homepage is hilarious. It looks like it’s from the 90s and it says SQL light, it does not give problems. It just works. I think importantly, it’s a trade-off that they’re making. For example, it makes it harder and slower and more laborious to develop the product, but that’s a principle that they’re really committed to and that you can expect from them as developers and you can expect as users of the product.

00:04:48 - Speaker 2: And I think we um pointed out and maybe it was the local first article that SQL Light is now listed by the US Library of Congress as an accepted archival format alongside other formats like PDF or PNG being this very Long term hasn’t changed much. The developers are really committed and show that they’re committed through the already, I don’t know what it is, decades of maintenance that they put into it.

00:05:13 - Speaker 1: I think if you think about products that apply principles very thoroughly, you kind of have to distinguish between the products that are just very thorough at applying the principles that the team sort of believes in. And I think one example is the original iPhone, like it’s very clear. When you use the original iPhone, you kind of feel almost what the team behind uh the iPhone stood for, like what they believed in and what they wouldn’t sacrifice, and like what their principal stack is. And that creates a very distilled experience and it’s also a great sort of um tool for wrangling complexity. Like if you smash the iPhone home button enough times, you will return to safety and then like that’s just it’s it’s a very, very cool design.

But uh I’m actually more interested in products that or I, I think we have that covered, like you touched on, on this in, in your, uh, I’ll plug your own show, but uh you touched on it in the, in the manual um episode for the Muse podcast where iOS development mobile development in general has created this structure of, OK, let’s just make the products as simple as possible. Let’s just make them as intuitive as possible, they shouldn’t even require a manual. Why are you shipping a manual with the product like the iPhone comes with 3 pages. And I think adhering to principles is necessary to deliver those kind of experiences for, you know, very approachable, very simple products, but it’s also necessary if you want to deliver products with any kind of like, I think you said any kind of depth.

And so I’m more interested in principles or products where they’re almost actively confusing or like they seem like they’re poorly designed on the surface, unless you read the manual, unless you read the philosophy of the creators.

And so I think they’re an example is clearlyIM, right? If you, if you use them for the first time, you’re like, how does this even make sense if you’ve never heard of the principles, right? If you want to use the mouse to use them, you’re going to have a really hard time. And in comparison, sort of to pick in the same domain, Microsoft Word is very much a product that tries to adapt to users' needs and offers flexibility, but in a sense of go use it however you want it, it’ll do that for you. And Vim says, no, no, it’s very composable, but you’re going to have to buy into our methodology and I think the latter is sort of really interesting. Muse fits into that category. I would say that. Uh, we all have a shared background here with with Hiroku, and the twelvefactor app. I think that falls into the same category as in if you’re going to consistently want to write to the file system on Hioku with these ephemeral dinos, you’re gonna, it’s not possible, right? And so if you don’t change your mind, you will have a miserable experience using this product. And so I’m, I’m wondering if there’s other products that come to mind for the two of you that sort of very much like if you don’t buy into it, it just feels like the people didn’t know what they were doing designing the product versus if you read the manual, something clicks and then you’re like, I get it now.

00:08:13 - Speaker 3: I think Git might be in this category for me. So Git, if you approach it and you just look at the porcelain, that is the commands that you do to you use to do common stuff, it’s.

Really confusing. So if I want to send you a change to my code, it’s like, check out a branch and then stage your commit and then push it to a remote over at like what? But if you take a step back and see that Git is a system for tracking content, immutable content over time, everything makes perfect sense in light of that. And so you have to have that underlying knowledge and model of it’s this tag of code without it, it’s just very confusing.

00:08:43 - Speaker 2: Talking about the uh the Hiroku example, of course, there’s sort of what, what came first, the principles or the product. You know, I think it’s, it is a chicken and egg thing they developed together and notably their 12 factor app, we wrote well into the existence of the product. It had existed for 4 plus years. And so we, we sort of discovered these patterns and these things that made application. Development easier, particularly in the context of continuous deployment and agile development and all that sort of stuff.

Eventually, we wrote them into this manifesto to make it easier to comprehend the product, but the product already existed and already had these principles that we had over time.

So I wonder for other uh products maybe that some of us have worked on. I know, Max, you talked about GitHub actions, you know, that was when you, you drove um early in your year run of GitHub and and you mentioned that that kind of was also driven by the same set of core principles, uh, like that kind of these building blocks. But did that start in that example, or other, others you’ve worked on, did you start With a list of products that are enumerated and written down that the team can understand and build against, or do you only realize the products afterwards that they sort of emerge from the crafting of the product itself?

00:09:57 - Speaker 1: I think in the, in the case of GitHub Actions, it’s worth pointing out that GitHub was a 12 or definitely a decade old company, I think 12 years and so it already had Ingrained principles in what it believed in.

So I think in that case, you have the luxury of sort of building on top of them. What we did with GitHub Actions is is actually at the root of what GitHub believes in, right? Like GitHub is about multiplayer software development. It’s about saying, OK, how can I reuse and remake the work of others? How can I stand on the shoulders of giants, basically, that’s sort of the whole ethos of open source as well.

And so when we looked at Git have actions and workflows for software automation, CI, CD, and so on, we realized that for the most part, that principle is largely lacking, right? Like nobody is actually saying, instead of having one monolithic pipeline that you know, the team that’s building the app built from scratch with some bash scripts, there are very few reusable components. And so from day one, we decided, OK, that’s this has to be part of the uh ethos or the principles that we have. Applied it to design this.

But then I think, uh, only it, it really only turns into a true principle once you’ve proven it almost in the market, or when you’re like, OK, this is just not just a hypothesis. This is truly a guiding principle where if we continue to double down on this, then good things will happen. Otherwise, you kind of have to reevaluate it and say, well, are we wrong about this? And so I think the conviction and the principle grew stronger as we went along, but it didn’t start from day one.

00:11:26 - Speaker 2: Yeah, the idea that principles are something that don’t just come out of the ivory tower, the stone tablets from on high or whatever metaphor you want to use, but are something an idea you have a hunch you have, but then they need to be validated, just like any other part of building a thing. Uh, that, that really resonates strongly with me right now because that’s a lot of the process we have been going through with Muse. For example, the modelessness was a pretty core principle early on that if if you want to make this fast tool and you have all the screen space given over to, um, you know, no chrome, all your screen space is given over to your content that you want to move really fast, like a powerful.

On the desktop, then that implies that you, uh, shouldn’t have a bunch of toolbars and stuff, but in fact, you should have these gestures and things and early versions of the product had that say a version of that principle, but often the implementation of it, which involved holding stylus in undiscoverable ways and and other things like that, uh we we found just didn’t validate with users. We couldn’t, people didn’t get it. It didn’t strike a chord, and then we we had to adapt that over time. And I guess that core principle of modelessness or the core principle of try to leave all the screen space for the users' content, uh, we did ultimately, as you say, build conviction in that over time, but the implementation of how we actually achieved that changed a lot.

00:12:47 - Speaker 3: And now I’m realizing that a lot of the most interesting principled products, the principles aren’t these opinions that come from nowhere, they’re actually understandings about reality that you’ve kind of uniquely grasped.

So in the case of GitHub is this idea that basically all software is developed by multiple people, yet our tools initially were very single node based and it had a sort of similar story, um, likewise with, with Git is this idea that code is a, is a. Of content that changes over time and everything kind of follows from that. Um, so as I think about these principles that we have in Muse, they often come back to these fundamental understandings about the human body, the human mind, how, how the creative process actually works and a lot of stuff flows from that.

00:13:24 - Speaker 1: Probably also not a coincidence that you already have fairly strongly formed principles with uh I don’t know how long you, you sort of think of Muse as existing.

But the work that you did at Ik and Switch was this cultivation of these principles and the things that you believe in and like that was a very largely like research driven and I think now with Muse you’re sort of putting those to the test, but that still means that they’re much stronger than, I don’t know if you, if you look at obviously the next door neighbor to principles is something like company values.

One of the things that’s really frustrating when looking at company values. is you could actually kind of just take all the startups in Silicon Valley and overlay their company values and I think there would be so much overlap that they lack sort of they’re almost meaningless, right? Like everybody says, hey, customers first or empathy with the customer or build and delight. One of the things that’s really important, whether you’re talking about product principles or company values is you have to be able to negate them because otherwise you don’t use them to resolve conflict.

00:14:23 - Speaker 3: Another way to look at that is principles should be of the form, given to plausibly good choices. This principle says we choose A instead of B, where B would also have been a potentially reasonable choice, but it’s not a principle to do so.

00:14:35 - Speaker 1: Uh, the, I don’t know if you remember when when Trello Trello launched this feature called Card aging a while back, and you could even like switch it to a pirate uh sort of uh scrolls.

And the idea behind it is that if you didn’t update a card on your Trello board for a period of time, it would sort of fade into the background. And I actually believe that the principles for your products should have a similar aging mechanism, which is, uh, let’s just assume that you have an internal tool that lists out all your company principles and values or or product values.

If people don’t reference the uniquely attributable like URLs for each of these things often enough, they just start fading into the background and then only the most in the the ones that actually truly help you make decisions, right? Like you said, picking between two very plausible solutions. Pick A instead of B because of this principle, that’s how they stay alive, right? Like they have to have a shelf life by default.

00:15:32 - Speaker 2: How important is it do you think, to write what I’ll call an explainer? So the 12 factor was an explainer for a lot of the Hiroku philosophies. There’s something like the Zen of Palm is a great design document, developer guide for the original Palm pilot that enumerates a lot of their principles. But many of these other cases we’ve listed maybe don’t necessarily have that written down or at least not in a public form, and you can glean it a little bit from their marketing material on their website or from following them on Twitter or just from using the product. Is that important or is it more of a nice to have?

00:16:04 - Speaker 1: It depends on the product, so. For example, I don’t think that the iPhone design principles are sort of coherently written down somewhere, at least not in the way that the 1st 20 people who were part in shaping this extraordinary product, but it shines through the product, right? So that’s it’s a, it’s a place where you, you know that there is an amount of finite amount of principles that this team has applied. And it’s sort of distilled and crystallized into the product that is the iPhone.

For the products that are actively confusing if you don’t understand the principles though, which is usually I think it’s products with a lot more depth and complexity, you kind of have to write it down because otherwise you never get to the adoption, right? Like you never get to the the sort of enough critical mass to say I have figured out how to translate the principle.

Goals and values that the team making the product believes in, so that it can be absorbed by thousands, hundreds of thousands of people in a very sort of scalable way, right? Like that’s presumably, I would assume that’s why you’re investing so much energy into the manual and the documentation and the videos that you’re recording for for Muse is because you want to take the ideas that you’ve spent years now developing. And crystallizing them in a way that now people can just onboard and benefit from that.

It’s, it’s not unlike a syllabus for any given subject in a college or or when you’re studying. Of, OK, I’ve learned this thing and now I’m compressing the timeline so that you can learn it twice as fast.

00:17:29 - Speaker 3: This reminds me of the comic book that they wrote to introduce Google Chrome. Oh yeah, and this was, uh, is in the classic comic format and it was explained that it was this new browser that was meant to be fast and secure and it was motivating that. And I think that’s also an example of how these explainers, they don’t need to reach out to all of the potential users. It could be just that you’re empowering the. users, the evangelists, the early adopters versus trying to make a manual that everyone’s going to read because as we all know, that’s quite an uphill battle.

00:17:57 - Speaker 2: Notably on the Google Chrome comic, I happened to be on the artist’s website that made that recently, they specified that it was originally intended only for journalists.

They were going to give it out as kind of a cool press release thing, and they only made printed copies to give out to them in this format, like you had to come to the press briefing or something like that. And then for whatever reason, this uh got so much attention, they ended up eventually taking the digital and spreading it more widely, but it was precisely that purpose was to create.

Excitement and enthusiasm among tech journalists who are going to go spread the word and help them understand it well enough that they could write about it in their own voice. And maybe some amount of shared vocabulary giving some naming to, I don’t know, maybe the sandboxing on the tabs and trying to, you know, something that was very deep technical topic, but surfacing why they this deep technical work, what the user facing benefits were and how you could talk about that and how you could see that that was I think the the thing that comes to mind, especially right now when we’re thinking about this is sort of you said evangelists and the super users.

00:18:52 - Speaker 1: And you can have the cynical view of saying, oh, the influencers, right, like Instagram influencers who are sort of just, you know, so into your product, they’re gonna and eventually they, it becomes part of their identity, but I think there is actually some truth to uh all of the products that we are listing today um tend to create super fans very quickly. And they tend to create it in a way where the super fans themselves understand a significant majority of the principles, and then they go out into the world and they share those principles because they have adopted them and they’ve changed their perspective, their view of the world.

I think that is actually a really important part of these principles which goes back to writing them down or preserving them somehow is really important.

If we listed out more of them, this is probably going to be a constant of there are always people who believe almost um irrationally in these principles and carry them forward.

One great example would be the entire GTD.

00:19:59 - Speaker 2: A market GTD is David Allen’s getting things done. Yeah.

00:20:03 - Speaker 1: Yes, with GTD it originally shipped as a product in the sense of it was a book and you can consider that a manual. And then the product was just so trivial because it was a bunch of manila folders and index cards.

00:20:14 - Speaker 2: He he advocated you carry index cards around in your pocket to write down ideas that you had throughout the day.

00:20:20 - Speaker 1: And by now I think.

Index cards are, well, some people still really love index cards and they’re still a good medium.

But if you look at most of the GTD conversations, they have evolved from that product, the principles still stand for people. And then now if you use those GTD design products and think like things, um, omnifocus, if you don’t know what GTD stands for, at some point those, those topics or the the the The concepts that they’ve introduced in the application seem kind of awkward. It’s like, why am I doing this? Why am I not just making a list of to do’s that is very straightforward? Why are you telling me to annotate this with projects and contexts and all this stuff that GTD goes into? And so if you’re not familiar with it, then it seems like awkward product design choices or unenetrable sort of product design choices. But once you actually use them, and if The system works for you. If you, if you share the same principles, it’s almost like it’s giving you superpowers.

00:21:15 - Speaker 2: Here you’re talking about subscribing to a particular methodology about how you organize your information life in order to find value in one of these to do this task keeper type products. But I guess we’re saying on one hand, we think it’s a good thing that you adopt cloud native or a particular perspective to use something like get them or the iPhone or Omnifocus.

But on the other hand, there’s the rigid, I think we all really like composable, make it your own products have a lot of flexibility, small sharp tools can be combined in different ways and adapted to different uses and scenarios and different people’s needs. So it’s. interesting to think about that tension or I’d be curious to hear how you both think about the tension of on one hand, opinionated, principled, if you use it and if you subscribe to a particular methodology or particular way of approaching your work or um then this product will be a good fit for you and otherwise awkward. But then there’s also, I definitely used, I don’t know, like project management tools to prescribe a very specific process. And if you do that exact process, it’s great, but if you don’t, it’s, yeah, really uncomfortable and I end up not using those because of their rigidity. Yeah, how’s that resolved?

00:22:25 - Speaker 3: I come back to this idea that the principles need to be true. So you can have very specific ideas about how a product should work and how the workflow should be, but that doesn’t reflect the reality of what I’m trying to do, of course, I’m not gonna like it. And on the flip side, if you’re suggesting a structure that exactly reflects, you know, how the world works, then great, everything fits into place.

00:22:43 - Speaker 1: There was this episode on the exponent podcast. Uh, from Mr. Ben Thompson, where they talk about principle stacks, and in particular they point out that yes, you can make a list of principles that you believe in, but they have to kind of come in a certain order, because at some 0.2 principles will kind of be at odds with one another, no matter what, right? Like and In order to resolve the conflict between the two, you’re going to have to pick one that you believe in more strongly than the other.

And I think with designing products that you have that same dynamic, and I believe that the establishing the order of principles is a little bit like sediment. Over time, the ones that you’ve applied more frequently in designing products sort of go to the bottom and end up being the really solid foundation versus the ones that You are still experimenting with, they’re still floating at the top and like you’re not fully committed and you’re like, OK, let’s try this a couple more times. And then once you get to more conviction, then they sort of get compressed further down and you start believing them in in the more.

And you mentioned an interesting one because you said, OK, do you want to be opinionated, opinionated products, like a lot of times, you know, we say good design is opinion. At the same time, the three of us are very much frustrated with the inflexibility of modern software and the fact that it’s not composable, and we believe in the Unix philosophy of saying you have tools that work really well together, but they’re special purpose.

So we also want like we want opinionated but flexible, or maybe flexible is the wrong word, opinionated but composable, and we have two principles that in theory will come in conflict with one another as you’re developing something.

And I think there this, this is where the principal stack comes in it’s OK, which one is more important.

00:24:24 - Speaker 3: And one potential resolution of that in the case of Unix is the underlying principle is everything is a text stream. So insofar as you do that, you can have these different tools that might have different opinions, but they can be composed and recombined in text editing. Now, the other thing I would say there is everything is a text stream is like only sort of right. There are things that are obviously not text, and that’s where Unix starts to break down and that’s an example of how the principles are only as good as they are a reflection of reality.

00:24:47 - Speaker 2: Maybe that’s notable because reality is something that changes as technology and society evolve.

So Unix was absolutely the core of all of my computing workflows for a pretty long time, that included not just server and development work, but Things like recording a note or a personal to do. I had command line tools for all that stuff. And then as the phone became a bigger and bigger part of my computing life, and the command line interface just doesn’t Uh, have the same utility there, and then increasingly that approach that Unix put to such good work and it’s still amazing for, you know, servers and but when it comes to my daily computing, it basically is much less central and that’s because my reality has changed.

I think most of the products we’ve talked about so far Unix, Hiroku, GitHub Actions, Palm Pilot, the iPhone with its single purpose, or multi-purpose home button. These all feel like the the principles we’re talking about are things that are say how the product works.

But I wonder, do we, another kind of list of examples I made when I was thinking about this is products that are more, maybe it’s more tied to the mission or the kind of world that they want to see exist.

So there, for example, Overcast comes to mind player that I use, and a lot of the principles come more through listening to Marco Armand, who’s the kind of solo indie developer and he blogs and has his own podcasts and stuff, but he’s always talking about a free and open podcast publishing world where instead of having the massive aggregation like you have with other platforms like YouTube and Video, for example, that podcasts are these RSS feeds that anyone can publish and there’s no central arbitrator and so on, and that obviously ties. Very well to his business interests, but it’s, they, they go hand in hand, maybe he’s making the podcast player that fits with the world that has free and open podcast publishing based on the RSS standard. If that world exists, his product does well. And I also think of like all these increasing number of privacy oriented tools like the Brave web browser, which Mark got me used a little while back on my desktop or messaging apps like Signal and Telegram, or we use uh Fathom Analytics on the Muse website which is privacy oriented. Kind of alternative to Google Analytics? Or do we count uh those kinds of things in this principled product category or is that more, more like a mission?

00:27:13 - Speaker 1: I think they you have to count them as part of these principles because it’s all the users of those products are making trade-offs because they believe in the mission, right? Like, so for example, in the, in the case of Overcast, you are Explicitly saying I believe in the open podcast environment enough that I’m willing to maybe sacrifice some features that other podcast players like Spotify and so on can build because of the aggregation, like commenting systems, rating and so on.

Sure, you could kind of build those in a distributed fashion as well, but it just tends to not happen. So As a user, I happen to use Overcast as well because I believe in this. I am making the trade-off of saying it is more important to me that we preserve the openness of the ecosystem than getting some other feature like bells and whistles. Imagine if you, if you used signal, signal is probably in many ways harder to get people to adopt it than Facebook Messenger because Facebook Messenger is ubiquitous, right? And so, uh, you, without the security implications or without the privacy implications of Signal, if you don’t know about them, why would you make that choice?

00:28:22 - Speaker 2: I can see something similar for a lot of these open orientation communities, Linux, I was a pretty heavy Linux on the desktop user for a number of years.

Uh, there’s things around, people who build their own PCs or maker, uh, maker communities, things like 3D printing and and so on, and in many cases they are accepting worse user experiences.

I don’t know, Linux famously trying to get your laptop to wake from sleep reliably or connect to the Wi Fi. As just always this struggle, but if you really believe in the openness, and you don’t like the walled garden and you want the freedom and flexibility and the hackability, that’s a, that’s a very, that is a tradeoff you’re willing to make.

00:29:00 - Speaker 1: The joke always next year is Linux on the desktop here and for sure are the products like Linux less approachable by default for for people maybe than like iOS or Android or whatever.

And so people who like, again, they make trade-offs and say, OK, my Wi Fi will not work reliably or my trackpad will not work as reliably as I would like it to, but at the same time, I’m getting this other benefit.

And then we get into these, it’s almost very publicly, I guess you used to call them flame wars, but like there’s these public debates that are just deeply rooted in principles and I like to me, I think the actual thing that matters is that you, if you zoom out, there is a application of different principles of makers around in the world that are creating things so that you can find the tool that you believe fits your principal stack as close as possible.

And of course there’s you can divide any distance, you know, enough times and eventually something will not fit with your principle, but broad enough, you’re like, OK, I believe in 90% of this, right? And I think that’s where the the the one underlying principle I think that we’re arguing for here implicitly is if we believe that software needs to be principled and needs to show the principles on the front like sort of like talk about them almost in a virtuous way, then we need enough variety in software so that uh people can sort of find the principal stack that they buy into, versus if you only have one choice, then you’re then you’re kind of either as a as a maker, as a creator, you are forced to build a thing that is just uh khaki pants, like it’s just that like nobody’s going to get angry about anything, any choices that you’ve made. And I think that just makes an inferior solution and experience for each person individually. And so I think variety is one of the guiding principles here.

I think that you need to apply and that’s why sort of encouraging people to make things and to be creative is almost the base principle that sort of underlies everything.

If you don’t have that, then the entire notion of principled products just doesn’t work.

00:31:07 - Speaker 2: Let 1000 flowers bloom.

And people can find their, find their tribe or find what they gravitate to find what reflects what they stand for, including how the product works today, but probably also how you want the world to be.

So in the, in the overcast example, you’re using that partially because you want free and open podcasts when you use use Telegram, you’re using that because you want messaging between individuals to be fully private, not snoop by government entities or anyone else.

I think. There’s very much a similar thing with Muse, and certainly the people I think that are buying the product in these early days when we’re still in the process of building up the features, part of what they’re saying with with those dollars is, I want things like this to exist. I want computing to be more like this.

And when when Mark and I came into it, for example, one of Mark’s say access to grind is just software being too slow all the time. Waiting on them, spinners, things to open and we just really are incredibly tight about that on the team. We, we want everything to be instantaneous all the time, and a huge amount of engineering effort and and design effort to a lesser degree goes into making that happen, but that’s just, we believe that’s possible with computers, the incredible computing hardware that we have at our disposal today, and we feel sad that we spent so much humans spend so much time waiting on computers. Even today, and so that’s something we’re really willing to stand up for and fight for and invest in, and people who choose Muse, particularly if they choose to support it financially, are saying, I want software to be more like this, not just this thing, but I want software like this to exist in the world.

00:32:44 - Speaker 1: In the context of Muse, it might be a good idea to also explicitly point out that in applying the principles that you all stand for the kind of software that you want to make and even further the kind of business that you’re building. You’re explicitly saying we are cutting out a huge user base because we are not going for the top of the funnel like most amount of people on board it and then let’s make sure that everybody draws at least once.

You’re basically saying this is a professional tool, we’re charging money for it. And we want this to only be a tool that people who actually derive the exact amount of value out of it as you charge for it, right? Like, obviously this is an incrementally correct approach to finding out what that dollar value is. Um, and I think you believe that software should really drive the creativity of that. I shouldn’t put words in your mouth, but like from the conversations we’ve had, the creativity of the individual, right? So you’re making trade-offs and saying other things will happen either at a later point, but for now we’re doing paid software for professional people who want to do deep work, and that sort of cuts out like most of the pie and to some degree, but at least the the thing that Uh is is left like the people who are now diehard fans and you can sort of call me uh part of that, they are also more likely to make up for that by infusing more energy into the music equation, right? Like either by sharing it or by just spending more money on software than they would before. Kind of brings us back to the the question you asked earlier of writing things down. Like, is it important to write these product principles down? If you don’t write the product principles down for Muse, for example, you will just have sort of the, you’ll have the app in the app store and you’ll have the price point of the app, and then people will just bring their own assumptions to the experience of the product and layer them on incredibly quickly, right? Like they will judge the book by its cover. Then discarded almost immediately. So then you have to go and by articulating your thought process over the years of why these things are important to you to actually capture those people, you have to write it down or you have to sort of distill it. And I think that is something that by definition of how you started the company and how you’re working, you kind of have to do. And I wonder if there is actually like Hiroku had like it felt very similar. It’s unless you explain it. It just seems completely irrational. It doesn’t make any sense, and the people who are working there are all just bananas, right? Like the, so I think writing things down, if you find yourself not having to write it down, maybe you’re not exerting enough of the principles that you actually think you stand for.

00:35:22 - Speaker 2: Yeah, and that’s definitely an active project in many ways. I mean, we have done some of that work in the research lab and the Muse design article, which now is pretty dated because that’s describing a prototype long before we even had a commercial product.

But we did try to articulate and I think did successfully articulate some of these things around 120 frames per second, or else, you know, you use both hands in the stylus, all that kind of stuff. And that’s continued to be a guiding principle for us as we, as we build the product and also as, as people come in to try it and they’ve seen maybe they’ve read that article and they have those ideas in their head and so they’re more primed to get over that hump of understanding how this thing works.

Um, but then in the meantime, I think we’ve developed and honed. That quite a lot.

And yeah, could, could really stand further writing down, although Similar to, I guess the experience I had at um at Hiroki with 12 factor and we had a similar thing with I can switch, in fact, where we really didn’t do the writing until the very end, we had been doing these research projects for 3+ years and many folks, including within the team and externally wanted, you know, basically said like we really got to write this down, and we would go to try to do it and would basically get stuck. We couldn’t. Do it. We didn’t have the words and you know, if you’re in a group of people and you’re talking about it and you’re waving your hands and you’re scribbling on a whiteboard and there’s a lot of words flying around, but boiling that down into a synced legible thing that an external person can just click through on and read and get a powerful, you know, have it effectively convey what, what in fact are the principles here.

That’s something that’s hard to do.

Upfront, in fact, it’s, it’s in all of these cases, I’ve always done it retroactively.

And so I’m gonna try to see here if on Muse we can do it more in the, in the middle of it or while we’re still, you know, still in the very active early days of development, but my um work on that so far, and plus, trust me, I have a lot of half-finished drafts, uh, is, you know, it’s hard, it’s really hard because there are not words for it yet.

00:37:28 - Speaker 1: That’s actually a question that I was gonna ask the the two of you.

As you’re developing the principles, there’s always more to do when you’re building a product than you have time for.

Everything you choose to do by definition means you’re not doing something else, and it’s a very real trade-off.

And if you think about startups and how do you make the argument that it is OK to slow down the process of product and feature development a little bit to capture all the deep thoughts that are happening as you’re building it so that you can hone those principles versus uh Following the lure of just, you know, ship very quickly just go through and like build stuff, um, versus deeply considering it and like, are you making that trade off?

00:38:07 - Speaker 3: Well, I think that’s really important as we were saying before, it leads into your marketing effort. Now you need this communication for people to be able to understand what your principles are and therefore to adopt your product. So we’ve set up maybe 40-60% time, 40% on marketing and communicating these principles and what we’re trying to do and how to use the product and 60% time developing. It feels like a pretty good balance. I think if you just build something and no one can understand it and therefore no one adopts it, that’s not particularly helpful.

00:38:34 - Speaker 1: It’s it’s really interesting to me to actually frame this work, not just as a place so that you build better products, but it’s also a thing that when done right, attracts more people. And so it’s a very real marketing.

00:38:46 - Speaker 3: I go back to this thing about reality and truth. What we’re trying to do is rely align reality, our product and what people understand. And if any of those three things aren’t matched up, you’re going to have a bad time and so you have to do both product development and marketing to get them all together.

00:39:01 - Speaker 1: So this sort of goes towards an area that I think we can all say we’ve struggled quite a bit with um uh marketing at some point of scale, like when you, you know, you’re the 1st 5 to 10 people, you’re a small company, you’re effectively the marketing team, right? There’s no one who has a title that says I own marketing and I’m doing marketing.

But at some point, once you get to, you know, 50 people, I don’t remember exactly at what point in time at Hiroka we started sort of cultivating a marketing team, but what happens is the people making the product, and the people thinking deeply about the product and the people who are theoretically supposed to bridge the gap of saying, hey, these are the philosophies and this is like we’re sort of creating the bridge between reality and like the product as you mentioned. Um, are no longer the ones making it, right, like they’re further apart. And so now you have to figure out how to bridge that gap, and I personally have at least 4.

Deep, sort of deeply technical products, never been able to figure out how to do that, uh, versus obviously for consumer products, it’s slightly easier for more or or even products that that are sort of more readily understandable by any sort of uh knowledge worker versus then, OK, how do I truly explain the virtues and the trade-offs of a particular database, for example, you brought up databases earlier, if I don’t actually build it and And, and that’s a really interesting challenge in scaling principle product principles is is is something that I think is is is really difficult.

00:40:37 - Speaker 3: Yeah, for sure. I actually think that the problem of marketing early growth stage developer software products is like an unsolved problem in Silicon Valley. Everyone I’ve seen tries and really struggles. I think eventually companies figure out something, but there’s there’s no playbook in the way that there is for product development and customer support and finance, for example. The closest thing I have to an answer here is I think the head of the company and the leadership generally needs to respect the problem and respect the problem domain and invest a lot of energy in marketing, which I do think we’re seeing with with MS because Adam is uh taking a lead there.

00:41:12 - Speaker 2: Definitely a skill development opportunity for me as someone who’s always been very product focused, um, but yeah, it’s been definitely expanding my My horizons. Now, maybe we’re almost on a different topic here, but it’s an interesting one. So I want to pull the thread. Max, you and I were talking a bit about, um, yeah, marketing, uh, and, and to Mark, Mark’s point about there’s no playbook, you were actually saying that what it takes to do authentic marketing for an early product is to not follow a playbook, that in fact, uh, you were giving the cloud app example and so that was just you and one other person, right?

00:41:48 - Speaker 1: Depending on when we did this, I think we were 3 people. And we started out with something that I would very much frown upon right now, which is early on when when Cloud A started to join the public beta, you actually had to tweet about it.

And at that time, no one had ever done it. So it was novel and people were kind of excited and that sort of, you know, spread incredibly quickly. But then the more you do, and I really don’t want to take credit for maybe I hadn’t seen it before, but I’m I’m sure someone else in the world figured out how to use that uh sort of spread as well. The more you do that, the more it just becomes noise, right? Like it’s the same as like the first couple of emails were never spam. But at some point, once you want to stretch that system, eventually like it gets indistinguishable whether there’s, hey, I’m reaching out if in case you need someone, email becomes spam versus not, depending on how often they they follow up.

And I think with marketing and how you market, how you choose to market is actually very close to how you choose to build products. The best marketing is always the one that is most authentic.

How do you know whether uh marketing is authentic? It’s when the person who actually explains it. is truly a believer in the principles that the folks who are building the product are building and like when you feel that sort of viscerally that that’s what they stand for and like almost to a fault.

The further you go away from that, the less effective the marketing becomes. And that this happens both very small scale.

So if you look at something that is somewhat of a contentious uh domain in general, but online advertising. If you go back and look at the deck network, I think it was and and how daring Fireball and so on used to do ads, they had these little tiny squares of products that almost all of them kind of believed in, like they would never advertise for something. And so that was like sort of the almost Original influencer marketing, all the way to tricks that people exploit now by saying, look, we used to have display out ads on the right hand side or on the left hand side of Facebook, and instead we figured out, no, by putting them into the feed and making them look like content.

We’re kind of tricking you into thinking that this is also reputable. And so you can obviously take it to the extreme at scale, but the principle remains the same of saying you want to make sure that the marketing feels as honest as possible. And honestly, the only morally in my opinion, right way to do it is if it is as honest as possible, right? Like if you’re not trying to trick anyone. And so I’ve seen great uh applications of this for uh in teams of of your size, and even sort of small to medium companies, but it gets much larger when you’re trying to market at scale, right? Like, at some point, someone is going to just try and tweak the world. it’s just enough so that someone else gets tricked and clicking the and clicking the link.

00:44:34 - Speaker 2: I also think of marketing as being not just the outbound communication, let us talk to you in this podcast or send you an email newsletter or tweet something, but also the receiving information from the market that it’s it’s a conversation.

Um, and in some cases, that’s a very much a literal conversation. I think I’ve done for all of us on the team, but probably me. Um, most of all have done, certainly I’ve done dozens of video chats and in-person user interviews early on, and then, uh, nowadays tend to do stuff over email.

I get into email back and forth, you know, if you reply to our email newsletter, it goes straight to me. If you email the hello at newapp.com, I think that’s going to mark right now if I’m not mistaken, and we try to respond to every single person.

I often get into some pretty long email back and forth and really nice ones, um.

And that’s kind of coming back to that point of testing these principles against reality or validating them. Uh, you’re often someone says, why does it work like that? That’s weird. And then you kind of come back with a, you know, an answer, well, we kind of did it this way because of X, but tell me, tell me about how you use it or show me, you know, show me a screenshot if you’re comfortable with that, and then they, they can kind of explain that and we can explore it. And it’s that process that’s often for some of our principles really cause us to double down. On that and essentially feel like we validated it and sharpened it based on these many, many conversations and others that maybe we softened on or feel like didn’t hold up as much and we, we dialed back on a little bit and it it is really these um these conversations with the market, but they’re individual people, but people that for some reason are drawn to either thinking they want a tool like this or the values resonate with them. Um, and then that convergence over time against what we’re trying to do and what it is that people that we think are in our demographics seem to need or want or get excited by.

00:46:28 - Speaker 1: I think with this worldview, you can kind of describe marketing just as a function of generating principle overlap, whether You are the customer that you’re trying to talk to is further away from those principles and so you exert, like in your example with emails, you exert more energy to like personalize the email and then actually like try and have an open conversation. Maybe your mind changes, maybe the customer’s mind change, but essentially what you’re generating is more overlap in the principles of the worldview that you have.

And so as long as to Mark’s point earlier, as long as the principles are in to the largest degree possible, true, then uh you are generating, uh I think uh um value because you’re basically saying, now one more person sees the world the way that I see the world and as long as that is a good thing, then marketing. is essentially not the way that we now sort of view it as the, it’s almost like advertising and so on is all about tricking people into something or like sort of exploiting weaknesses instead of saying, turn it around, if you have really strong principles that you believe in, then sharing those with the world, marketing is just about the, the overlap generation of that.

So you talked about Adam, you talked about the the outbound um like marketing sort of we are talking to customers and trying to generate overlap with the the company to the principles the company believes in uh with a customer, but you can also uh look inwardly in a company and say by having strong principles, we are creating overlap in what the employees believe in and in what the employees stand for. And if you ask me like what’s the one thing that is really important in terms of of leadership, it’s creating clarity and so principles, if they’re good and true tend to create clarity. So I’m wondering how often and like so this is full circle, how often do you reference these principles internally and actually make decisions at Muse and even sort of from from how you hire, how you uh sort of try to mentor and grow people and so on, like I’m curious how how that’s working for you.

00:48:29 - Speaker 3: Yeah, I think they’re quite important internally. For example, my old favorite, no spinners, I invoke that all the time. I think principles in general, they help you make decisions faster, crisper, more consistently with less thrashing and noise. I think that’s all very good.

00:48:44 - Speaker 1: The no spinner one is probably an example because it’s very concrete.

You can kind of say, hey, if I am designing UI that has a spinner, an alarm bell should go off and I should reconsider my choices. And at the same time, If you start really deeply thinking about it, like it works on the surface level because you’re basically just telling everybody who works on the product, hey, no spinners, and then the product is better.

But there is even an undercurrent, which is if I am a mindful uh maker that is part of building new, I will try and evaluate, but why do we care about no spinners? And suddenly you start going to the next one, which is, hey, software needs to be fast if it’s not uh fast, it’s not fully shipped or whatever, it’s actually an old GitHub in. And so it it it makes you. A better contributor to the product because you now intrinsically get it. And so you might augment it and say, hey, no spinners, and at the same time also, oh, by the way, I saw this API call didn’t return in the whatever milliseconds that we expected to return, and so you learned something new as an employee as part of the cabal or the co op or whoever you’re working um because someone shared that principle and said this is something we believe in, right? Like, so there’s this transference of skills that happens over time. Um, if you adhere to principles. Right.

00:49:54 - Speaker 3: And then once you’ve derived that result for yourself, you can cash it in a way and you don’t need to re-derive it every time you have the discussion, so you can make the decision much faster, which I think is important, not just in terms of speed, but in terms of emotional energy, which is very limited in the world of a startup and you need to invest that towards making your customer successful and not making decisions internally.

00:50:14 - Speaker 1: I really like the framing of caching. Um, I don’t know if you you two have this well, I actually do know because you send it over.

But there are certain kind of blog posts that are just inherently linkable and you’re having a conversation and you’re just writing some text and then you link a blog post.

That blog post usually has really strong principles and what you’re essentially conjuring up is a cache of saying, you know, we have this shared worldview. I’m referencing this cache object over there, this blog post, Clay Shirky is situated. Software is something that I think there’s no conversation between the three of us that we don’t reference it. And suddenly we’ve created enough context and saying, OK, we know we’re talking about the same thing. We don’t have to go down that that that decision tree anymore. Now let’s navigate and go towards the new stuff. And so I really like the framing of caching. I think that’s a very nice parallel.

00:51:03 - Speaker 2: And I like there that it also gives you both a name. So this shared vocabulary, uh, which was one of my goals at 12 Factor.

I think it was also one of our goals, we wrote Local first, which is another kind of manifesto piece, and the idea of attaching this name to a thing that people within a company or a team or even within an industry, you can use this word to describe the set of ideas that might might have a very deep be a web of nested ideas or a deep stack of ideas.

And in addition to that name, whether it’s situated software, local first or 12 factor, uh, you can also, you have the URL, you have the canonical URL that’s that’s very linkable. So when someone says, what is that, you’ve got the, the citation.

And that was one of my motivations with 12 factor and one reason I broke out each of the factors is their own page is I wanted to be able to, when I was in the 1000th conversation with someone about, well, wait, why do I have to specify my dependencies? I could just basically drop the URL and say, read this.

Um, and so I think that’s another thing you need out of these canonical, these canonical sources for defining a principle that we can discuss and, and build on. It’s not necessarily a question of whether you agree or not. It’s more of, here’s a neat package that has a name and a URL and we can either use this as a basis to say yes, we both know this is a starting place and as you said, Max, go on to the, go on to the new stuff or say, actually, I don’t agree with that. Set of principles and so therefore, you say, OK, well, now we have a more fundamental conversation we need to have before we can move forward on whatever we’re trying to collaborate on.

00:52:35 - Speaker 1: One way in which I’ve started thinking about this is taking aside sort of the monetary incentives or the intrinsic we like to make things.

Muse, for example, wants to encourage people to see the world in a certain way, right? Like that’s why it’s a principled product.

If you think about it, you don’t necessarily actually have to build a product to make that happen. You could theoretically think of a metaphorical like I have a bucket of links. So what is the most distilled bucket of links, smallest bucket of links that I can just dump on a on a meeting room table and then leave, and the people in the meeting room will read all of those links and internalize that and suddenly they have that worldview, right? And uh you can kind of think of a product as that bucket of of links or references and so on, but in an even more distilled form than a bunch of articles. And I think that is sort of the feeling of uh that uh you get where Hioku or 12 factor, my my bet here and this time will tell. I believe that the principles of 12 factor will outlive Hioku in the same way that I think that the principles in Muse will very likely outlive the application muses, and they will live on and get remixed and so on, which by the way, another good reason to write them down and sort of try and separate them a little bit from the product. But it is not such that the most effective way is to try and distill it into a product so someone can use it on a daily basis versus sort of saying, yes, I am going to care about the exact same things you care about. I’m going to read all of this, do all the research that you’ve done. No, I’m just going to use the product, read the distilled version that you say I need to to understand the product and then slowly my worldview sort of shifts. Um, and I think that another reason why I think principal products is just such a powerful framing for for product development.

00:54:19 - Speaker 3: I think reifying your principles into a product is also important because it’s an existence proof for the set of principles. Really the only way that you can know that these ideas match reality and all of its complexity and nuance is if you actually make something that has all those things working together at the same time. That was a big motivation, I think, for doing the lab and then Muse. We suspected the world could work this way. We couldn’t be sure until it physically existed.

00:54:45 - Speaker 1: I like that you bridge the gap there between Um, sort of research and observation of other products and saying, OK, look, these are the things that we found in other people and and and sort of in in using them, but then it’s like, OK, well, but now let’s put this to the to the test and build one with those principles to see how well does this actually turn out, right? And so. Uh, yeah, a very worthwhile endeavor if you ask me.

00:55:08 - Speaker 2: I think that’s a nice way to wrap on the topic of principled products. If any of our listeners out there have feedback, feel free to reach out to us at UAHQ on Twitter or hello at Newsapp.com by email. We always love to hear your comments and we’d love to hear ideas for future episodes. And Max, thanks for coming on and chatting with us, and thanks so much for being a user, a customer, helping us along this journey. It was a little rough in the beginning, I know, but hopefully it’s starting to pay off for you now.

00:55:37 - Speaker 1: Yeah, thank you for having me and for letting me be a part of the creation process of Muse. It’s really, really fun.