Transcript

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.