TopPodcast.com
Menu
  • Home
  • Top Charts
  • Top Networks
  • Top Apps
  • Top Independents
  • Top Podfluencers
  • Top Picks
    • Top Business Podcasts
    • Top True Crime Podcasts
    • Top Finance Podcasts
    • Top Comedy Podcasts
    • Top Music Podcasts
    • Top Womens Podcasts
    • Top Kids Podcasts
    • Top Sports Podcasts
    • Top News Podcasts
    • Top Tech Podcasts
    • Top Crypto Podcasts
    • Top Entrepreneurial Podcasts
    • Top Fantasy Sports Podcasts
    • Top Political Podcasts
    • Top Science Podcasts
    • Top Self Help Podcasts
    • Top Sports Betting Podcasts
    • Top Stocks Podcasts
  • Podcast News
  • About Us
  • Podcast Advertising
  • Contact
Not in our directory?
Add Show Here
Podcast Equipment
Center

toppodcastlogoOur TOPPODCAST Picks

  • Comedy
  • Crypto
  • Sports
  • News
  • Politics
  • True Crime
  • Business
  • Finance

Follow Us

toppodcastlogoStay Connected

    View Top 200 Chart
    Back to Rankings Page
    Technology

    Metamuse

    Tools for thought, product design, and how to have good ideas.

    Advertise
    • Apple Podcasts
    • Google Play
    • Spotify

    Latest Episodes:
    https://museapp.com/podcast/transcripts/51-personal-brand/ Oct 05, 2023
    Show notes

    Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: What I look for when I’m hiring designers or what’s the experience of encountering a stranger on the internet. I like this phrase proof of curiosity. Is this person curious about the world, but curious in a way where they take action on that curiosity, and that can manifest itself in lots of ways. One way is, you tweet about it, right? Like you learn something, you tweet about it. 00:00:32 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for thought on iPad and Mac, but this podcast isn’t about Muse the product, it’s about Muse the company and the small team behind it. I’m Adam Wiggins here today with Mark McGranaghan. Hey, Adam. And joined by Brian Lovin. Hello. Brian, you are a designer at GitHub, a prolific podcaster with design details, but before we talk about all that, I know you made a move recently and you’re getting to design a new home office space. What are some of your goals in building out that workspace? 00:01:06 - Speaker 1: Yeah, well, where we’re moving from, my girlfriend and I, we both work from home and we were in separate rooms, and it always felt pretty isolating. Where, you know, you’re working for most of the day, so you’re in separate rooms most of the day, but also those rooms were the bedroom and the living room, so the office and living space and sleeping space always felt intermingled. So, with our new home office, it’s actually a bigger room where we decided to put both of our desks, which is great cause we see each other throughout the day. The problem is You have video calls and you’re always interrupting each other, so we’re swapping in and out. So one of the big goals that I have for the space is there’s like this tiny little closet off the edge of the office space, and we want to convert that into like a little phone booth, you know, soundproof it, put a little monitor in there so you can just carry your laptop in, plug in and go. So I’d say that’s the biggest goal, but honestly, we haven’t even started cause I don’t know about you both, but post move, you get unpacked and you’re motivated to fix stuff, and then as soon as you’re settled in, you’re like, yeah, it is what it is. You just got to live with it for a while, you know. 00:02:18 - Speaker 3: Yeah, there’s a dangerous valley in there where you have unpacked enough to live, but you’re not fully unpacked and settled, and sure enough people have boxes for months and years, if they’re not careful. 00:02:30 - Speaker 1: Which is also a useful little rule, you know, it’s like whatever is in the box for more than a month, you probably can just get rid of. So just take that box away, don’t even open it. 00:02:41 - Speaker 3: Yeah, I call this moves as copying garbage collectors, you know, and copy everything once and some stuff goes. 00:02:47 - Speaker 2: Yeah, when I first started seriously doing work from home, remote work, and lots of video calls and so forth, I didn’t move, but I realized how important it was to have a separate space. I think I had a desk kind of shoved off the corner of my living room, which was fine when I had an office, but once I was working from home, there wasn’t enough separation for me between those spaces. But actually the insight that someone gave me was I had sort of a very small room and a big beautiful one with big windows and you naturally think of the big room as well, that’s the master bedroom, but actually you don’t spend that much time in there. And eventually I converted the biggest room in the house with the nicest windows and all that into a home office. And that was an absolute game changer. I had a big workbench where I could do kind of stand up and do kind of more physical tasks with the hands and I had a big desk. I had a Pin board on the wall for keeping all my stuff up, could also even think about and now always in my mind is what’s going to be behind me on video calls and what lighting is going to be in there. So for example, my current space, I kind of arranged it so that there’s some nice windows right in front of me, so I’ll get, you know, sunlight on the face and then behind me is not facing, I don’t know, out over the whole house so that when the partner walks by, she like suddenly panics because she realized she’s, you know, on camera in the background on the camera, yeah. 00:04:03 - Speaker 1: I did the exact same thing as you. So when we moved this big office space was staged as the primary bedroom cause it has the big windows, it’s the most beautifully lit. And then there’s this other room which was intended to be the office, which isn’t well lit, it’s a lot smaller. We’re like, you know what, we just sleep in the bedroom. 99% of the time the lights are off, so we might as well take the space where we’re gonna spend most of our time and make that the most beautiful and inviting and warm. And enjoyable, right? Like this is where we’re gonna spend all of our time. So yeah, very much with you on that idea, swap the bedroom in the office to match time spent, I suppose. 00:04:44 - Speaker 2: Absolutely. And I also take a bit of inspiration from there’s a couple of subreddits, one that I like is Battle stations, yeah, slash slash battle stations where people do these beautiful setups. It’s obviously their computing devices and desks and things, but they also get the aesthetic element and yeah, the carpet and the chair and all this sort of thing and. I don’t quite have the time or inclination to go to that level, but we do spend so much of our lives now in a home office in front of one or more computing devices, spending some time to make that aesthetic and pleasing and good vibes just seems to make sense. 00:05:20 - Speaker 1: Yeah, you know, the last thing I really want to get in here at some point is the couch. I’ve never had a couch in an office and there’s something very attractive to me about. Going and having a sit or a lie down in the middle of the day, where you might be sketching or reading a blog post or catching up on email, but just having that short break from, you know, sitting upright in your office chair. Sounds really attractive. I don’t know, we’ll see. I don’t know if I’d actually end up spending time on it, but there’s an idea of kind of mixing the feeling of what kind of work can be done in there, right? It doesn’t just have to be upright desk keyboard kind of thing. It could also be a little bit more lounging, reading, that kind of stuff. 00:06:02 - Speaker 2: Relaxed posture, reading and thinking. Now you’re very on brand for me. Thank you for that. 00:06:07 - Speaker 1: Yeah, there you go. 00:06:09 - Speaker 2: Well, tell us a little bit about your background. 00:06:13 - Speaker 1: So like you mentioned, I’m a product designer. I’m currently working at GitHub. I’m working on the mobile apps there, and GitHubb is an interesting place because there’s a lot of different kinds of jobs that it solves for people in the world, you know, you have, of course, developers who come there to code and review code and merge code, and there’s the whole DevOpsy side of things. Then there’s this whole other side, which is like the social productivity side, organizing work and in my case, like taking work on the go. And so I’m interested in that part, that’s what I’m working on and get with the mobile apps. On the side I podcast, I host the Design Details podcast. I’ve been doing that for, I think, 7.5, almost 8 years. So that’s the thing. 00:06:58 - Speaker 2: Yeah you something 400 some odd episodes in. 00:07:02 - Speaker 1: 429. 00:07:03 - Speaker 2: Wow, yeah, and then you were nice enough to invite Mark and I on there recently. I’ll link that episode in the show notes. Very interesting to be on the other side of the conversation there, but it definitely provides me inspiration, which is, I worry sometimes that we’ll sort of run out of things to say, you know, we’re 50 some odd episodes in here, but you’ve managed to keep going this long, keep it fresh and relevant, so maybe there’s hope for us too. 00:07:26 - Speaker 1: Yeah, well, the nice thing about what you’re doing is if you do interviews most weeks, you’ll never run out of people to talk to. There’s just too many interesting people in the world to learn from. 00:07:37 - Speaker 2: We’re outsourcing the problem of being interesting to someone else. 00:07:40 - Speaker 1: Yeah, exactly, like, yeah, just extract that from other people. Our problem is we stopped interviewing, you know, my co-hosts and I just chat back and forth every week and try and mix it up with things like listener questions or talk about industry news. But there are weeks where we just look at each other like, have we talked about this? Have we answered this exact question already and you just can’t really remember, so you answer it again. So I do worry about that, like going in circles a little bit. So that’s the podcast, I guess before that, I started a company it was called Spectrum.chat, and that was myself and two other people, Bryn Jackson and Max Stoiber. The three of us were trying to build large public asynchronous forum software, really ended up gravitating towards like open source communities and design communities. That company was acquired by GitHub, which is how I ended up at GitHub. And before that, I was a product designer at Facebook, and before that at a company called Buffer. And then I guess throughout all of this, I’m a side project, tinkerer kind of person. I like writing, I like building websites, I like the podcast. I really enjoy interviewing people. I’ve launched a couple of interview projects. And I would say my most long lasting side project besides the podcast now has just been my personal website where I have all these random subpages that tickle my brain in different ways. So one of them is like a security checklist, how to be safe online, and the other is A better, more readable version of hacker news, and another is my personal bookmarks and an AMA and my blog and on and on and on. And so that’s really where I find a lot of joy and fun outside of my day job. 00:09:27 - Speaker 2: We’ll link that site in the show notes. I think it is an inspiration. We’ll talk about personal websites here a little, a little later on, but I think Mark and I, for example, both have incredibly minimalist personal websites that we update pretty infrequently. I think you have a pretty comprehensive design. It’s, I think it’s a full web app you wrote about the technology stack there, you use it to kind of. Explore interesting new front end and back end technologies, yeah, tons of writing, that’s obviously the podcast, you’ve got a newsletter now, so yeah, really, I don’t know how you find the time, but I guess the answer is that these are your hobbies and as you say, they tickle your brain, so it’s less of uh finding the time and more of a following your nose to your interests. 00:10:06 - Speaker 1: Yeah, hobbies and many, many years, you know, I think there is an incorrect perception that I work all the time. People like, how do you have time for all these different things like, I don’t, these have just accumulated in the dustbin over, you know, a decade. And so with a decade in hindsight, it looks like a lot and it looks like I’m busy, but really it’s quite incremental. 00:10:31 - Speaker 2: That leads nicely to our topic today, which is personal brand. So, I’ll ask first what that means for both of you. Actually, Mark, maybe you wanna start us off there. 00:10:41 - Speaker 3: So two things come to mind when I think of personal brand. The first is the brand in the more pervasive, thicker sense like Coca-Cola is a brand, and I think that some people have such a personal brand, they invest a lot in building it up, and the other more general sense is like information theoretic in the sense of people having Knowledge about other people on the internet or being able to obtain that knowledge if they if they want to, versus the base prior of you’re a random person on the internet and could be, you know, a dog or whatever. I think both of those are interesting and we can talk about them. 00:11:17 - Speaker 2: And I’ll note on the company brand side we did an episode on that some time back because some I have pretty strong feelings about about how to kind of intentionally build a company brand. We ended up describing it as the character and what you know the company for, and you know, if the company has a personality, what is that personality? And so you can imagine that mapping to a person as well, not in the real sense of a fully fledged human with many interests and many dimensions and so forth, but maybe a little bit more narrowly defined as how you’re representing yourself to a field or on the internet or to some target audience. 00:11:54 - Speaker 1: Yeah, I suppose my personal definition of personal brand maybe skews that direction. I’m stealing this. I can’t remember who said this, but at one point I heard someone say that a personal brand was really just how someone would describe you if you weren’t in the room, which I guess could apply to a company, but for a person, I think you get to capture a little bit more of the nuance there. Like, how would somebody describe you? And the thing is, you’ll never really know. I think that’s kind of the ideas. You can try and influence that, but really people will describe you however they want to describe you and when you’re not in the room, they can be a little bit more open in that description. So that’s how I’ve thought about personal brand and I don’t know, adjectives come to mind like curious, fun, kind, excited, and then maybe some negative personal brand characteristics would be like complains a lot or rants a lot, or is an asshole, right? Like those all fit under the personal brand vibe for me is those kinds of adjectives. 00:12:59 - Speaker 2: Yeah, well, I guess there’s also the, you know, if I think of looking at your website, for example, to get a feel, you know, let’s say I had somehow come across you and was interested in learning who is this Brian fellow, maybe in the context of I’d like to hire you, maybe in the context of like to have you on my podcast, or maybe something a little more general, which is just you said something interesting, and I’m just curious to know the person behind that. And there’s the very practical element of, you know, you say off the bat, I’m a designer, podcaster, writer, and even the order there, I think tells me something. It’s like you may have a long running and a pretty successful podcast, but that’s not the first thing you list, you consider yourself a designer first. So, you know, there’s that sort of pragmatic aspect of just what do you want to be known for in your career, but then yeah, you’re talking about maybe the softer side of it as well. I think aesthetic conveys a lot, maybe this is a medium is the message sort of thing, but right, you have a website that says you are a person that likes clean, modern design, whereas you can imagine there’s this, what is it called, the professor style website. Just these kind of like very bare bones, HTML, you know, not only is it not responsive design, but it’s like barely even styled at all, but you come to associate it with often busy and successful professors who are very erudite and accomplished in their field, and they do have a representation online, but it would almost be confusing or maybe feel wrong in some way. had a sleek, well designed site like a designer would that conveys maybe the wrong idea. 00:14:32 - Speaker 1: Yeah, yeah, it would feel like they were trying to sell you something. 00:14:36 - Speaker 2: Yeah, there’s an aesthetic, maybe some of that is almost like tribal affiliation to some degree, you know, you go to the punk rock band’s website and there’s going to be a very different color palette, for example, then you go to the designer’s websi…

    Full show notes at the publisher

    https://museapp.com/podcast/transcripts/52-product-launches/ Oct 05, 2023
    Show notes

    Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: A product launch needs to prepare and calibrate the potential user for how much the world is going to get shaken up by this thing. So Muse 2, it’s still muse, but it’s a major version change, so prepare for a moderate amount of novelty in your life. 00:00:21 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for thought on iPad and Mac. This podcast isn’t about Muse the product, it’s about the company and the small team behind it. I’m Adam Wiggins here as ever with my colleague Mark McGranaghan. Hey, Adam. And there’s a little bit of excitement in the air here. Uh, those who’ve been following the Muse story know we’ve been in a pretty deep maker cave for a while working on our 2.0 product. And I think we’ve talked a little bit before about the sort of big releases versus incremental, and I think there’s much to be said for both. Incremental has a certain momentum, velocity, you feel more in touch with the people that you’re serving, your users and customers, but of course the big releases are where you can really kind of reinvent the universe and there’s the feeling that anything’s possible, something like that. And of course we’re undertaking something pretty ambitious here, at least for our small team with Basically adding a whole new platform, which is the Mac, in addition to iPad, and then on top of that is this local first syncing technology that we’re trying to take from the research lab and bring it into our product is a pretty big bet here. So we’ve been grinding away at that for a few months, but very happy to say that the Beta is now available to prom members, so we think it’s, we’ve been using it internally for a little while, you and I both have used it quite a bit as our kind of daily driver in our work, and it is nowhere near bug-free or glitch-free or even total feature parity with Muse one, but it all does work, and it’s quite a thing to see, I think, but I’m really excited to share it with everyone and see the reaction. 00:02:02 - Speaker 1: Yeah, very exciting times for me, actually, the multi-device and local first sync capability was perhaps the thing I was most excited about with the original Muse vision, and it’s taken a few years to get up to that point, so I’m really excited to be releasing this capability into beta. 00:02:20 - Speaker 2: And I’ll link the memo in the show notes for those that are interested, we do a little bit of a, a walkthrough, particularly on the Mac side, but also take a little look at the sync side of things, although that will certainly bear much more explanation in the future. But with that be kind of out the door and baking, as we sometimes say, so folks will be trying it out and sending us bug reports and feedback of all kinds, and while we let that sit for a while, we can start to think forward to the product launch, the Muse 2.0 release. Which is very exciting for me. I get excitement from shipping things in general, even something like a beta, but doing a full product launch is quite its own wild ride, I think, and we haven’t done one for a year and a half since Ms 1.0 came out, so I’m kind of looking forward to that, and indeed, that will be our topic today, which is launching products. 00:03:11 - Speaker 1: Nice. And now Adam, I’m gonna turn the tables on you. You usually ask me to define these nouns that we talk about, so I’m gonna ask you what does a product launch mean? 00:03:22 - Speaker 2: Yeah, I see now being the other see why that’s difficult, because it seems like everyone knows, right? And you go to kind of actually define it and realize you don’t have a real good crisp definition. And I probably like you, have been involved in product releases of many different kinds over the course of my career, and I think it was really only the Muse 1.0 launch where I really sat down to try to more deeply understand what is the anatomy of a product launch and what even is it, because if you’re sort of iteratively releasing improvements and features all the time, what is it that makes kind of a launch? And I think one of the descriptions that I saw someplace is the idea that you’re creating a moment. You’re creating kind of a feeling of an event, and you can think, of course, of the really dramatic examples like Apple, right, they do these just completely huge events, you know, back when they were in person, but even now with the kind of virtual stuff, hugely produced, all these, you know, press are lined up, you know, all the product review people had their stuff ready to go, and so it’s this big event, big moment. But I think you can equally as well do that on a much smaller scale, right? Even if you’re just like, for example, making a little app to share with your 10 friends, if there’s a moment where you release that and everyone feels excited about it and they’re kind of talking about it with each other or sharing the link with each other or something like that, I think that serves it just as well. And then the other part of it is just like, what actually are you launching? So the moment of the event is an announcement, something exists, something that is truly new. And I think here we get into a more subjective definition for sure and product hunt, which is an interesting piece of this puzzle, we’ll come back to a little later, but they actually do have some rules around. They don’t want you to launch just new features, but new products. Of course, that begs the question, well, what actually is a product launch was a feature launch? It’s not really that clear and there’s a few guidelines there. Being on a new platform, having a totally redesigned interface if you’re covering some new use case, but I think there is just an implicit feeling or sort of subjective feeling just like we’re talking about here with Muse 2. This is something that feels really new and different, even if it shares a lot of the fundamental qualities of what we’ve been building all along. 00:05:40 - Speaker 1: Yeah, I actually quite like this definition of product launch is creating a moment cause it’s user centered. It describes it from their perspective. When we’re talking about product management, we often say that you should describe the benefit or the capability and not the functionality, like at least think in terms of what the user is getting. And when I was thinking of launches, I was thinking of like a marketing push or you turn the thing on, right? It’s these things that we’re doing versus the moment that the user is experiencing, so it’s a great lens. 00:06:09 - Speaker 2: I may have gotten that from uh there’s a series of posts on the site, launch notes. They have one that I’ll link to in the show notes that I quite liked about a launch Mailchimp did a couple of years back, and they’re obviously a huge company, so what a launch for them means is quite different than what it means, for example, us, but I think again, those concepts. Your channels are different, the scale is different, the quantity and quality of the materials you can create are different, but the basic idea I think is in there. And by the way, you can also launch a product that has yet to be built. So I think the landing page with a waitlist is absolutely a thing you can launch. And in fact, we did this, that was basically the first Muse launch. We kind of call it the soft. internally, but, you know, we had come to the point where the team was working on it. We had made a Slack channel named Muse, we’d registered a domain, you know, we had incorporated new software, Inc. and we said, you know, we should tell people we’re working on this. So we made a little one pager landing page with just a little place you can sign up and it would just kind of store the email, and we weren’t sure what we were going to do with it quite yet. And our launch was just, we all tweeted it, and maybe the incode Switch account tweeted it. But that actually got us, I don’t know, first few 100 signups and some energy on the team in the sense that like, OK, something exists now that didn’t exist before, when it’s just a one-page website with an email sign up, but that indeed is a launch. 00:07:33 - Speaker 1: Yeah, indeed, one of the first lessons that I learned about product launches from you and from Hiroku was that you can and should separate delivering the product, turning it on from doing the launch. You can do the launch before you ship the product, you can do it afterwards, you can do multiple launches, you know, you have all kinds of flexibility and you should take advantage of that. 00:07:52 - Speaker 2: Yeah, I think that’s key in thinking about the when part of things. I am big on decoupling a product release from a launch, a marketing launch or a storytelling launch, whatever you want to call that. And so, the Muse 1.0 launch was a good example. We went live in the App Store, I don’t know what, 5 or 6 months before we launched, and we had turned on payments, and we had migrated our beta, a good portion of our beta users over from test flight, but we had a new website, and we had A chance to say, hey, everybody, we exist now. And so the MS 1.0 release wasn’t necessarily something that you couldn’t get before. It was just something you didn’t know about because we hadn’t really publicized it beyond our little internal circles. And we may have pushed some kind of release that had something or other in it, you know, maybe a 1.0 version on it. But really there was no big change to the product, and I think that becomes even more important, you know, there’s obviously things like getting through app review, but if you’re doing infrastructure, you don’t want to be doing big changes to your systems exactly the moment you’re getting hit by a bunch of new traffic and a bunch of new people. I think it’s very tempting to feel like you need to do that, that wait a minute, you know, if I could have tried this product a week ago, what am I actually launching? And again, I think it’s really about you’re telling people that didn’t know about it before, or that maybe had heard about it, but you’re saying, hey, this is ready, it’s reached some new milestone. It’s 1.0, it’s 2.0, whatever that is. 00:09:23 - Speaker 1: Right. And this is a good example of where the user lens is so helpful from our internal lens, it’s this product that’s been released for a while and hasn’t undergone a big change in the past few weeks. This is at the time of the 1.0 launch, but the reality is, approximately everyone in the world has never heard of it. So you can’t think of this thing. Already existed or people already know about. In fact, people are hearing about it from the first time. And this is part of why creating a moment is important and valuable because you’re signaling to the market that there’s something important happening here. They can’t read every app store update to decipher when you’ve undergone a big step change in capability. You need to signal that to the market with your marketing. As an aside, this separation of product release from marketing launch reminds me of what we do in infrastructure engineering with gradual rollouts, so that the obvious thing to do with shipping code is you code up the feature and then you deploy the code and then the code is active and the feature is active. In fact, what you do with infrastructure engineering, once you get beyond any small scale, is you completely separate the coding and the shipping of the code from activating the code. So you’ll have a new code path behind a feature flag and you’ll ship that code up to production dark where it’s not running, and you’re very slowly in the case of infrastru. you do it slowly, you turn the knob to activate this code 1%, 2%, 10%, eventually up to 100%. And of course you can also flip it back without deploying the old version of the code. So it’s sort of isomorphic with this idea of separating product releases from marketing launches. 00:10:53 - Speaker 2: Gradual and iterative is essentially always better, but in the sense of doing a thing or making changes and being in the business of software and technology is essentially a change business first and foremost, but the point of a good launch is to make a little bit of a splash, and to do that, it should feel like there’s kind of a lot coming all at once, rather than being dripped out. But again, you can do that exactly like the feature flagging on the infrastructure side. One trick that we used on the 1.0 launch that hopefully I’ll get the chance to use here is we actually had our new website on a subdomain, like some preview URL, and then we can share it, for example, with press. So someone that has, for example, reviewed news in the past and we say, hey, you know, we got this new product coming, we’d like to give you early access. Here’s what our new website is going to look like. And that’s really important because if they’re trying your new product but reading your old website and then they’re trying to make sense of that for some review video, they might make, it will be a little bit incoherent. But on the other hand, you want to push out that website again, feel like there’s something big and new the day you’re announcing something. And so that’s kind of a way to do it again incrementally and a little bit iteratively. And I think that gets harder to do is for a small team like ours, it’s easier to do, certainly our 1.0 launch where, as you said, approximately every in the world had never heard of us. Um, as you get bigger, it gets harder, people actually want to, but that’s a nice, that’s a whole other set of problems to have, which is that like you worry about leaks and people getting early access. But when you’re at that size, in a way it’s a nice problem to have, but it’s sort of a whole other domain that I’m talking less about here, and then you need new techniques to kind of keep your secrecy or the press embargoes and all that stuff, but even so, I think that iterative and doing things in a gradual way, so that you’re not just flipping a bunch of switches and then everything collapses right in the moment you most need it to really be stable. 00:12:49 - Speaker 1: Right. I think there’s a theme here where if you execute a product launch, well, it should mostly be not surprising to you. It’s going to be news and therefore sort of surprising to a lot of the broad market, but you can basically understand what’s going to happen along a lot of these dimensions. So for example, you’ve already released. the product, you know, that it works. You should, by the way, be observing the rate that new bugs are coming in and that should be hopefully decreasing and reaching some acceptable moderate level, because the bugs aren’t gonna suddenly stop coming the day you release, right? So you got to anticipate that. Also, you were alluding to this, you can Basically beta test a lot of the marketing and messaging with the press. You can also do this with the users. You can say, here’s how we’re proposing to talk about the products and see if that resonates, if they’re nodding their head up and down, and if so, you can anticipate that will catch it will stick when you eventually do your marketing launch. I think people have in this mind as users of products that marketing is like big like basically frenzy where everything’s super uncertain and everyone’s figuring stuff out and who knows if it’s gonna work or not. That should be only the perspective from the outside, from the inside, you should have a lot of data about how this is going to unfold. Now that also speaks a little bit to, I think our bias, which is like B2B that is business to business and prosumer software and those domains, like especially with B2B, you have like 1000 customers, you just call up Amy, hey Amy, you know, you paid us $100,000 last year for a B2B software. What do you think about, you know, B2? Of course they’re go…

    Full show notes at the publisher

    https://museapp.com/podcast/transcripts/53-career/ Oct 05, 2023
    Show notes

    Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: People are drawn to you for your specific skill set that only you can fill. There’s a U-shaped hole in the universe and you’ve created that gravitational pull that people find you. And I think as far as careers go, the more unique you are, the more unsubstitutable you are, the better compensated you will be and the more you enjoy your job, to be honest. 00:00:23 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for thought on iPad and Mac. This podcast isn’t about Muse the product, it’s about Muse the company and the small team behind it. I’m Adam Wiggins here with my colleague Mark McGranaghan. 00:00:37 - Speaker 1: Hey Adam. 00:00:38 - Speaker 2: And joined today by Sean Wang, who goes by Swxs. 00:00:41 - Speaker 1: Hey, happy to be here. 00:00:43 - Speaker 2: And Sean, I understand you’re a former competitive tennis player. Tell me about that. 00:00:49 - Speaker 1: It was kind of my high school thing. When I was growing up, my mom trained me on table tennis back home, which is recreationally. 00:00:57 - Speaker 2: Maybe she sensed that you might someday have a career in startups and knew that this would be a critical break room activity. 00:01:04 - Speaker 1: Yeah, actually, actually it does really help in the old days when we had offices, remember those days. Now we had just had like Wii tennis or VR tennis. No, then, you know, when it came to high school, I upgraded to tennis. I was on my tennis school team, high school team, and then when I served in the military, because every Singaporean has to serve 2 years in the army, I represented my battalion at our tennis championships and we actually won, which is fun. Although I was kind of the bench person, so I didn’t actually play, but I was on the team. So I guess to say we won. 00:01:40 - Speaker 2: And you’re the author of a book on career, you run a community that’s going to tie into our topic today, but I’d love to hear about your full background and in particular the work you do on developer experience with Temporal. 00:01:54 - Speaker 1: Sure, I basically got the bit by the finance bug in college because I saw the Asian financial crisis and then the tech slump and I realized that a lot of people in finance seem to be like masters of the universe. They seem to always know what’s going on. And also they seem to be, at least in the hedge fund world, capable of being independent of the economic cycle. In other words, if you see a recession coming, you can actually position yourself to profit from it. Rather than just be tied to the general cycles of the economy. So I set myself a goal of working at a hedge fund, went to college for that. And then finally, after a long sequence of events, arrived at a hedge fund, and then realized I didn’t like it. I didn’t like the people I worked with and for, and I was OK. I was sort of middling in my analyst rankings, but I wasn’t going to be great. And while I was doing my finance stuff, I learned to code and basically every junior finance person that comes up through the ranks these days becomes a self-taught programmer because you have to. 00:02:53 - Speaker 2: Is that sort of like an Excel kind of automation thing or is there something further than that? 00:03:00 - Speaker 1: Do you get into data science, starts with Excel and then VBA Python. And then for me, because I did option pricing, Haskell, because that was the company I worked at Standard Chartered where there was the house language and I just didn’t have a choice. It was only after I left Standard Charter that I had any idea that Haskell was this sort of revered language of functional programmers. Yeah, and so I decided to kind of go in on that. I also read the writing on the wall in terms of public market investing versus private markets. Like it seemed like companies were staying private for longer and more wealth was being created in the private markets, as opposed to the chumps like me in hedge funds trying to trade public stock, where there was comparatively less growth, obviously not no growth, but less growth. So I did a transition at age 30 from finance to tech, and that was a pretty scary one because just starting over at 0 from, you know, my previous career, I sort of strived for 10+ years to get there, to get where I got and then having to start over and not know anything. It was pretty scary. 00:03:59 - Speaker 2: It also sounds like something that maybe in a way takes more courage because it’s not that you didn’t have a career, you actually did have one. You worked hard, you found yourself that place, it’s probably something that Definitely pay the bills and then some I would imagine. So you know it’s one thing when you’re forced out of a career due to changing economic circumstances or age or some other thing and then you have to restart. That’s pretty hard to do, but maybe the decision has sort of been made for you by circumstance. But here you made a much more active choice to say like I don’t think this is where the future is. 00:04:33 - Speaker 1: For me, yeah, it was a very personal choice. Obviously, I think the people that do extremely well still in finance and I keep in touch with some of them. But I am pretty open about what I left on the table. So my first year as a hedge fund analyst, I made 350K and there was a path from that to seven digits, you know, which I would probably be there by now if I had stayed in finance. But I think actually having had a prior career, I think actually reduces that risk, at least because I had a standing offer to go back to my previous bank if I wanted to. So I knew that like, all right, I could give myself a couple of years or so, try this transition out. If it didn’t work out, I could just go back to my old job, which I loved, and I had a lot of fun with. At least just to pay as well as the hedge fund. But yeah, I think it wasn’t that risky. Plus, it actually helps me get a job when I came out the other side of the transition because I did a boot camp in New York, the Full stack Academy, and the first employer that I sat down with was Two Sigma, which is a well known quantitative hedge fund in New York. And they liked my story. They liked that I was a former trader and then I now knew how to code. So they hired me based on that and then continued on to completely disregard my finance side and just only use the tech stuff. But it’s a story you can tell in career change. So the way I talk about it is that you take your used experience and you know you sort of trade it in for $1 credit at the store. And it’s kind of like GameStop in the sense that they kind of rip you off in terms of how much credit they give you, but you get to at least tell a story to get your foot in the door in a more compelling way than a lot of other people who don’t have as much of a good story to tell. You know, I had people who were with me in that boot camp that were former chefs. So that guy actually got a job at Blue Apron. Wasn’t that great, you know, didn’t turn out that well, but like It helps. I think for a lot of career transitioners, that’s kind of the advice I try to give them, like, try to make use of your unfair advantages because the cards will be stacked against you. You’re up against people who have coded since they were like 12 and have CS degrees and stuff. You got to find your way to make it in this industry. And once you get that first job, everything else is relevant, you know. So that’s kind of what I say for that. So I spent some time at Two Sigma and then started really getting active in the New York tech scene, which is a huge part of my story. I attended and spoke at every single meetup in New York and I blogged about JavaScript and React, and that got me notice. So if I reached out and I joined them for a really good 2 years, where I started to build my sort of public profile as a developer advocate and also an engineer on their CLI and the surless node ecosystem there. That led into a job at AWS where I did kind of the same thing, but bigger because AWS Amplify is kind of like their NetLify cologne with more services attached to it. So with DiMODB and with graphfuo, with location services and mobile testing services, a bunch of really good stuff. And then I wrote a blog post about what I thought was missing in the service ecosystem and that eventually led to my job at Temporo because I concluded that Servius was really good at short-lived compute that scales to zero and scales to infinity, but it’s terrible at long running jobs. It’s terrible at asynchronous tasks and the solutions that were available today, namely AW that functions and you know other equivalents out there, weren’t really good. Like they presented too much friction for me to effectively express the kind of business logic that I saw out there that was actually worth so much money. So yeah, just essentially blogging got me the job I have today, which is pretty cool and also helped me transition from a front end career to serveless to a backend focus career now, and it’s been a wild ride. 00:08:17 - Speaker 2: You know, what you described there, the building a public presence and certainly the learning something and then turning around and sharing that is something that we’ve touched on. Actually, I realized we’re kind of inadvertently doing a small miniseries here. We did an episode on building in Public. Our last one here was on sort of personal brand. And so I’m going to go ahead and say that this is 3 of 3 in a series where the career topic helps bring it all together, but yeah, sort of learn something and write about it or share it in that moment when you kind of can see both that you remember what it’s like to not know the thing, but now you know the thing and you can, you know, pass that kind of mental diff on to others is pretty powerful and seems like you got the sort of maximum leverage out of doing exactly that. 00:09:04 - Speaker 1: So I’m known for this essay that I wrote on learning in public, and that’s actually a piece that I wrote as an advice for my fellow boot camp grads when I was asked to go back and give a speech. And it was pretty funny because I think it’s a reflection on the diff between my finance and my tech career. So in finance, everything is zero sum. If you get a trade idea, you should try not to leak it before you’ve established a position and once you’ve established a position, sure, go ahead and pop your bags. But in tech, we share our code. We get up on stage and we share our failures and outage stories. It’s just so fundamentally open because it’s such a blue ocean field. It’s still expanding so much that we don’t actually care that we’re giving up some of our trade secrets because the hope is that other people who receive that benefit will reciprocate in some way or form. But I found that just much more fitting to my natural inclination. But also, I think I found that my career grew much better in a healthier way, in a sense that I wasn’t trying to get one up on my peers. I was working with them and sharing what I know or did not know helped them to teach me or correct me or whatever. And that improved me at my pace of learning. So I always call it Not an act of altruism, you’re not giving back to the community so much as like this is actually, even if you’re totally self-interested, this is legitimately the fastest way to learn, which is to learn in public. 00:10:24 - Speaker 2: And tell me about Timoral. 00:10:26 - Speaker 1: Temporo is an open source workflow engine and I try to categorize this piece of software in relation to other engines, which are effectively custom purpose databases. So if you think about a search engine, you could do full tech search on a database just by yourself, but you probably wouldn’t because search is such a well defined custom problem in the way. That you should probably adopt some custom solution like Elastic Search or Type sensor, whatever else is cool these days on it. And similarly, like an analytics engine, yeah, it’s a form of database, but it’s a very focused database for analytics workloads which are high input and sort of a lot of aggregate reads. And so similarly, I think workflow engines are an underexplored area of custom database that have until now been typically mostly hand rolled. But I think people are finding that there’s just so many opportunities to use these workflows, which is what we call them in a variety of situations. And so just to explain a little bit more about what that means, a workflow is kind of a long running durable function. Imagine if to write a monthly billing subscription, all you had to do was have an infinite loop, charge your credit card and then sleep until the next month, and that’s it. So you don’t have to set a separate cron job, like the cron job is effectively automatically provisioned when you call that API for sleeping to the next period. 00:11:53 - Speaker 2: So Sean, when we were speaking before you mentioned some use cases that kind of made it concrete for me, you know, on the consumer side, you have something like anything delivery oriented or rideshare ordering something from the moment you say, OK, bring this vehicle or package or whatever it is to me, or even something like check out like e-commerce, you know, when you hit that, OK, buy this thing button on Amazon or wherever else you have essentially opened a very long running real world transaction. And it may last days until that package comes to you or even longer if it gets lost or something like that. And so during this whole time, there is a sense that that’s an open activity, but it’s not open in the sense that I have the app open on my phone or that it’s open on my computer. It’s the sense that it’s sort of running and the system needs to keep trying to converge that again. Some completion where the completion is the delivered order or the car shows up or the things imported somehow, and then at that point, you know, then the transaction is completed more and more, I think as we have more and more of these kinds of services on the consumer side at least, maybe we see more and more of these long running asynchronous kind of user interfaces you might call them. 00:13:00 - Speaker 1: Yeah, I think so too. Our CEO was actually at Amazon when they implemented the one click buy button, which is essentially, if you think about it, turning the purchase process from a synchronous process of right, add to shopping cart and then go to shopping cart and then enter your details for checkout to, all right, click this and then register that there’s a purchase intent and let people cancel if they change their minds within the next 30 seconds, if they made a mistake or if they just changed their minds. And after that 32nd timer, can continue to proceed with that order, but you’ve just reduced the number of clicks and you know shopping cart abandonment rates are like 60, 70%. So it’s just better user experience, at least on the surface, obviously, there are other issues with one click check out, which is a ital spies. But that happens to be in the favor of Amazon. But that’s my pitch for a lot of non-technical sort of UX type people. I think there are a lot of user experiences that can be improved by turning sync to async. Another example that I often like to bring up is this script, which is actually a customer of ours. And so this script is an audio editing tool, which takes transcriptions of your audio podcasts and turns it into sort of like an editable Google Doc, where they sync up your audio clips with the words that are on the transcripts and you can just delete words or add words like you would a standard Google Doc. All of that is powered by tempora in the back end because it starts Farm out work that might potentially be long running. The script surprisingly, if you’ve ever tried to throw in like a 3 hour podcast into the scrip…

    Full show notes at the publisher

    https://museapp.com/podcast/transcripts/54-support/ Oct 05, 2023
    Show notes

    Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: Support is one important way that you’re understanding how customers are experiencing the product and what you should be doing differently going forward. And at a more human and personal level, I think it’s important for motivating the product work, hearing from individual people about their desires for the product is quite motivating. 00:00:24 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for thought on iPad and Mac. This podcast isn’t about Muse the product, it’s about Muse the company and the small team behind it. I’m Adam Wiggins here today with my colleague Mark McGranaghan. 00:00:38 - Speaker 1: Hey, Adam, now you’re a bit into the fatherhood journey. How’s that treating you? 00:00:45 - Speaker 2: Well, I love it. I love being a father. It’s extremely rewarding to care for a small and cute creature who basically depends on you for their every need. Also very hard work, really hard work, but we recently crossed into toddlerhood, so toddler, I think, is defined as one year and up, and actually that was a big transition because the Under one year, essentially the needs of the kid, especially as you get close to the early side of that one year, is completely different from adults, right? They’re drinking milk, maybe from a bottle, maybe from mom, how you bathe them, even when they are eating semi-s solid food, their needs are just utterly different from that of an adult, how they sleep, everything like that. But now that we’re into the toddler age, I’m finding it’s more like a very small and non-capable and gets tired easily and has a limited palate adult, but in a sense, you know, they can eat a lot of the same food, they kind of need to sleep at kind of somewhat similar times, so that’s actually quite nice and you add in the walking. And then you know potentially the talking and now yeah it’s less of a guessing game trying to fulfill the mostly physical needs of this creature and starts to advance into fulfilling their emotional needs and eventually their intellectual needs. So I’m finding that at a minimum sort of easier and less stressful, but also in a lot of ways a lot more fun. So yeah, it’s been really nice and it’s also a place where I think I really appreciate the very flexible work environment we’ve created for you, even though I did take off some parental leave time. I just assumed at some point I would need to take a bigger chunk, but that hasn’t actually really happened because I’ve been able to interleave childcare with my work. Now part of that is a lot of my colleagues are based in the states and so those meetings happen in the evening and So my daughter’s in bed then, but this is a good example I feel of where the flexible working environment that we’ve take quite a bit of effort to craft really starts to pay off. 00:02:42 - Speaker 1: That’s perhaps the most important testament to the flexible schedule we’ve heard yet. It’s awesome. 00:02:48 - Speaker 2: Well we can jump straight into our topic today, which is support. Now, of course, it’s always good to start with a little bit of a definition, and support is something I feel strongly about. I guess I feel strongly about all the pieces of what makes up a good company, or from my perspective, what makes a strong technology company, all these different functions that need to work together, engineering, design, marketing, and so on. But I feel like support is one that maybe doesn’t get its Do or doesn’t quite have the prestige of the others or something like that. Everyone agrees it’s really important, but you don’t think of working for a company in a support role necessarily as cool, maybe as being, I don’t know, a designer or something, and I find that a little bit unfortunate. 00:03:34 - Speaker 1: Yeah, I do think support is often underestimated, and I’m glad we’ll be digging into it today. So Adam, what does support mean for you exactly? 00:03:43 - Speaker 2: Yeah, I would define support as getting help with a specific problem you have with the product or maybe getting a question answered, but it’s something where you can’t do that through the sort of more automated means and you need to go to a call it a human interaction, you’re sort of contacting the company and maybe that line gets blurred a little bit with AI chatbot support thingies, but I think it’s you’re in this state where you have a problem to solve, you can’t figure out how to do it, and probably for every person that moment where you Give up and contact support happens at a different point. I’m more of an exhaust every other option, read all the documentation, Google about it, try to figure it out on my own before I usually reach for that, whereas others maybe go a little sooner. But yeah, you have a customer or a potential customer who is in a moment of need, and that’s an opportunity for the company to rise to that challenge and hopefully solve their problem. But I think the tricky thing, as I think through the different support requests that I’ve handled over the years at the many companies I’ve worked at, including our work at Muse, is that you have quite a lot of different categories, right? It might be a request for information. How do I turn the pen from blue to red? And maybe that’s actually in the documentation and they just didn’t find it, so you can essentially just send them the documentation or just copy paste or whatever. It might also be a request for undocumented information. So for example, we added safe mode to Muse, which is sort of protects you against a crash loop, kind of an unusual situation, but that occurs occasionally. But there is a way to manually invoke it and at least initially we didn’t have that documented or maybe outside of just the memo where we released it, so someone writes in needing access to this information and reasonably they haven’t been able to find it. And that’s kind of the simple thing, but then you go from there to, OK, it’s actually a bug report. I’ve had a crash, you know, I’m getting this very unexpected or undefined behavior, but it could also be a feature request and often I think all four of those I’ve named like. I want to learn something about how to use your thing or there’s a bug or I want a new feature. They may actually not even know which one it is as they write in. So the person on the support side, on the company side, you know, me in this kind of hypothetical example is sitting there saying, OK, the pen color blue to red, yes, that exists, here’s how to do it. But it might also be, well, we don’t have that capability yet, but we want to in the future or we don’t have that capability yet, but that’s an interesting idea. Let me put it on the stack or think about that, or maybe that actually you can do it and this person for whatever reason is just like the software is not working properly for them and so this is actually a bug report. So it really could be from their perspective they want to solve this problem they have, which is do a thing that they haven’t been able to figure out to do, but which of those four it is they may actually not know when they’re writing in. 00:06:32 - Speaker 1: Yeah, and if it’s that I might add here is a service request. This is when someone writes in and requests that you do something basically manually, either because you’ve deliberately not included an automated path for that or just because it’s nothing you thought of before. So for example, sometimes we get requests about deleting all the users’ data and that’s not exactly a bug or a feature, but it’s still something you need to handle the support. 00:06:56 - Speaker 2: There’s a couple of related areas I’d love to talk about here today, and one of those is what you might call service or customer service, which I think that does overlap or maybe is even a super set of support if you like, but I think in the software business or with digital products, support and service are not that different. Maybe there’s occasionally things that A human operator working at the company can handle that you can’t handle, so you have to write to request that. But there are a lot of businesses, particularly those that deal in more kind of physical world things, that is to say non software companies that customer service is a huge part of what they do because there’s so many things the customer can’t do, like the service department at a car dealership, it’s like after business. 00:07:37 - Speaker 2: Yes, exactly, and I think some of the best examples of companies that really differentiate on support or kind of a role model for this are companies that have a business more like that. So Zappos. You know, they have their core value of this deliver wow through service idea, and if you kind of dig into that and what that means for them, particularly if you think back to 10 or 12 years ago when they were really pioneering this, they did things like free shipping on returns. So if you don’t like it, you can return it, it doesn’t cost you anything, no questions asked. And maybe nowadays that’s been copied more, you know, you got Amazon and Zalando and others that do the same thing, but at the time that was a really kind of Surprising and impressive bit of customer service. Yeah, so it’s a similar thing with anything where there’s going to be exactly car dealership, travel related things, that sort of stuff. It’s just you have to call in or email or whatever it is to get something done, and that’s just the nature of that business and I think for us, except for those very kind of rare and occasional things, for the most part, if we haven’t made a way to do it in app yet, that’s not quite a gap, I call a gap in the product, I would say. Now, how do we go about handling support at Muse? 00:08:50 - Speaker 1: Well, in preparation for this episode, I was trying to go back and recall our original discussions on setting up support. And the thing that I remember most strongly is what I didn’t want to happen, which is that typical experience where you, first of all, you go to the support page and it’s like this mechanism to prevent them from emailing you. You know, all the FAQs and there’s a little tiny button with email us. So I didn’t want that. And I also didn’t want that feeling that you were being fed into a huge apersonal machine. You know, you fill in the form and it It gives you like ticket number 7,042, and there’s all this like support machinery stuff around it. The experience that I wanted was basically like you’re emailing the founding team and they’re emailing you back. And it literally just looks like a regular email. And that’s pretty similar to what we ended up with. You can email us at hello at and one of the five partners will read and respond and We use a tool Front app, which is great for basically multiplexing the email inbox, which works well for us. 00:09:51 - Speaker 2: Yeah, I also agree that the impersonal feel like you’re being fed into the machine thing is just to me one of my least favorite parts of contacting support, and one feature that is a default, I think in a lot of these helpdesk pieces of software, maybe like a Zendesk, for example, is that they email you back right away with exactly as you said, the ticket number. Your request is very important to us. You have request number 7000, and to me that actually is. Anti reassuring. Now I guess the downside there is it can happen if you email the muse team and our current set up if you do it on a, I don’t know, Friday afternoon your time, but actually it was a person in Europe that was on duty that day and so they’ve already kind of signed off and we do have someone scanning the request over the weekend, but if it’s non-critical, you know, maybe you go 3 or 4 days in a worst case scenario without getting a reply and maybe that’s not very reassuring. And so the idea is that that sense that like at least they received my email. I have this kind of receipt. But yeah, it just feels like noise and it feels like you’re in a machine. And so, yeah, that was when we did set this up, it was Adam Wulf, who set up front for us, and we’d already kind of had this helloadme app.com catch all kind of the entry point to contacting us, but it kind of went to one person, which I think was me for a while, or maybe it was you, I can’t remember, but then when it became the report requests became too much. or unreasonable for one person to handle and kind of route, well then you want to add other people to the list, but now who’s going to answer each particular one? And that’s where, as you said, the multiplexing part comes in that it comes in and then the way that we end up multiplexing the assignments is essentially just day of the week because we have a number of team members that’s Less than equal to 7, so it’s pretty easy to just have each person take sort of one day, and that may not scale in the longer term, and actually one question for us would be whether we would hire dedicated support people at some point. Do you have a feeling on that, as you said, you feel like you’re emailing the founders versus the benefits of having people who are really good at support because that’s their expertise. 00:11:53 - Speaker 1: Yeah, it’s tough. I feel like it varies by support requests type. So there are some things that I think could actually be handled better by a dedicated support person because it would be more responsive and they would have their full attention. Things like these service requests, basic product feedback, ideas, product ideas, questions that are already answerable, like, you know, how do I access something that you can in fact do in the product, it just wasn’t clear to the user how to do that. That stuff I think would all be better served by a dedicated support person. But then there’s a lot of the stuff that we currently get is stuff that actually needs to find its way to the person who’s working on that particular feature. So someone writes in with some weird sync behavior, for example, one of the engineers needs to look at that. And there, if you have a person in the middle can just add an extra step and make it slower and less crisp, and a lot of stuff that we currently get is of that form, so I think it’s kind of tough, and I wouldn’t be surprised if eventually we have a mix. 00:12:49 - Speaker 2: Yeah, sometimes the way that gets handled is you have the support levels and kind of level one should be focused on really common questions and could be answered quickly, and you use a lot of templates and that sort of thing, and then for things that are not in that category, they can, so to speak, escalate. And hopefully in that kind of a set up it would be something that’s done seamlessly that whoever is on the front lines there, one of the skills they would have would be triage, sometimes it’s the word that’s used, but they would have the ability to triage and really be able to sort out. OK, this is a feature request. We have 100 others just like it. We want to file it in our feature database and maybe we want some aggregate. Reported that, but maybe there isn’t a lot of deep info there or as you said, just a question they want answered that there’s an easy answer to, whereas here is like a really interesting reflection on a use case that we kind of haven’t heard before and how that interacts with the feature that was currently in beta. OK, this seems like worth getting in front of someone for deeper consideration. 00:13:47 - Speaker 1: Yeah, and to be clear, going back to our motivation for setting up support this way, there’s some value perhaps that you have as a user if you are communicating directly with the founder, but I think a lot of the value is just having a very clear, simple line of communication. We don’t feel like you’re getting bounced around, you’re getting shuffled around. And so this triage could be totally transparent. It’s like you send…

    Full show notes at the publisher

    https://museapp.com/podcast/transcripts/55-mac-app-design/ Oct 05, 2023
    Show notes

    Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: The iPad is the perfect device of being able to immerse yourself and just being able to explore versus the Mac is all about getting things done and about speed and efficiency. If we embrace that, we naturally end up with apps that are quite different. 00:00:24 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for thought on iPad and Mac, but this podcast isn’t about Muse the product. It’s about the company and the small team behind it. I’m Adam Wiggins here today with my colleagues Julia Rogats. 00:00:38 - Speaker 3: Hi, Adam, nice to be back. 00:00:40 - Speaker 2: And Leonard Sursky. Hi. And Yuli, I know you often spend winters traveling in sunnier places, and you recently returned from Panama. How was the experience of working remotely and during sort of travel holiday activities this time around? 00:00:56 - Speaker 3: Yeah, it was fantastic as always. And in this case, on my winter trip, I actually got to indulge even more in the traveling part since I switched, I think about half a year ago to working only 4 days a week. So I had 3 days off at a time. Sometimes I took an extra day here and there, so I had a lot of time to travel around. Discover the country and then yeah, spend a few days a week working on news actually often interweaving this with long distance travel. I’m often stuck in, you know, 6 to 8 hour cross country bus rides and those actually ended up being perfect opportunities to just have a deep focus day and kill a lot of time doing that. 00:01:39 - Speaker 2: We could usually tell when you reconnected to the internet because a whole bunch of commit messages and like pull request, things would kind of stream into the Slack channel simultaneously. 00:01:51 - Speaker 3: Yeah, that’s right. I do have the advantage that a lot of the stuff that I’ve been working on actually I can work on offline, so we were kind of in a phase where We didn’t have to do a lot of design decision discussions. It was more fixing bugs, implementing little features, so I would just make sure that I had at least, you know, 10 of those small things queued up for the trip and then would just work through those while offline, then connect back online and yeah, have a nice new update for everyone that was waiting for it. 00:02:20 - Speaker 1: Yeah, and I’m quite impressed by how you’re able to do that. Julia, both combining sort of vacation and work. Like whenever I’ve tried to do that, I both got nothing done and had a bad time, basically. And so I think it’s especially impressive with the launch we are working on. 00:02:36 - Speaker 2: Well, it certainly seems like a skill you’ve developed Julia, which is the ability to be really focused when you need it and then switch out of that and go fully into OK. Now in this interesting place, I want to explore have adventures be fully present in my environment for a day. A few days, whatever it is, and when you have that work block, whether it’s on the bus or just days you set aside sitting in the hotel or whatever. So I think a lot of that is, at least it seems to me like a skill you’ve built up over quite a lot of years because this is just the lifestyle that you want to lead and so you’ve spent the time to create your mental discipline around that. 00:03:14 - Speaker 3: Yeah, it surely does require some discipline, I would say, but it’s, yeah, it’s something that I’ve cultivated over the years and being able to. Shut out work when it’s not time to work and really enjoy life is something that’s really important to me and then that’s actually where I draw the energy to then be going back to the computer and be productive. 00:03:35 - Speaker 2: So our topic today is the design and implementation of our Mac app, that’s Muse for Mac, and those following our story now we’ve had the Muse 2.0 product has been in beta for a little while. We’re coming up on a launch, and one of the key features, probably the most notable feature for users and customers, is the Mac app. And I thought it would be really great to get both of you on here to talk about this while it’s still fresh in your minds, because I think this really is, while other folks on the team maybe have been deeper on things like the sync engine, for example, you two have been really the mind melded dynamic. The duo that is making the Mac app come to life and I’m more of a user, an avid user of it, but I also get to follow along all your design discussions in the Slack channel. I find it just really fascinating and I hope we can dive into a bunch of those things today. Yeah. And maybe we could start with kind of an overall design approach. So obviously Muse 1. X was an iPad only app and we have a lot of unique concepts in there, this open canvas, the nested boards, the different types of media cards and Then when we’re thinking, OK, we want to add this additional platform because we know the desktop is such an important place for doing work, but we don’t necessarily just want to do what Mark would call the transliteration just porting it straight across without a lot of thought because the desktop is not only a different. Set of hardware, but it’s actually I think you’re in a different almost mindset when you’re sitting at your desk at your keyboard in this focused posture. You probably have a different almost approach to your work than you do when you’re leaning back, for example, on a sofa or reading chair with your iPad and pencil. So I’d be curious to start off with kind of what’s the overall design approach? How do we think about bringing new to this new platform? 00:05:27 - Speaker 1: Yeah, I think it’s all about the balance. So on one hand, we have this iPad app already. Um, we have news on the iPad, and we have a lot of users for it and we sort of have established a certain design there. We have made a lot of design decisions and now we are bringing that to a completely new platform that, you know, in some ways is connected to the Mac, but it still has its own set of sort of rules and conventions and also its own set of users that have different expectations than iPad users. And so we are trying to balance building really this native Mac app from the ground up, like what, what would it look like if Muse on iPad didn’t exist and now we are building Muse just for the Mac. With sort of the existing iPad app and trying to make it into one coherent model. 00:06:15 - Speaker 2: And I think that’s a really unique piece of our approach. We’ve talked a bit before, perhaps maybe on the native apps podcast episode, where we said that many and most apps kind of tend to have a home in one place like a platform like they originally. Instagram was a phone app and then maybe there’s a web version, but it’s kind of a companion or an add-on or just an additional thing or similarly, maybe have a lot of Sass tools, notion might be a good example. It’s really native to the web, it feels most natural and It’s the baseline to be in a web browser on a desktop computer, and so when they make an iOS app, it feels like a little bit of a bolt on, it maybe doesn’t follow a lot of the platform conventions you expect. It’s often lagging behind, you know, the features that are in kind of the main platform, and I think the The idea of something where we want to, like you said, bring it to this new platform, design it as if it was a new app there while also sharing a lot of primitives and concepts and of course actually the data because it syncs between them. So actually it has to share all that exact data set. I think that’s an unusual thing. 00:07:23 - Speaker 3: And I think also kind of sharing some of the core values of news. So one of the things that we had in mind designing the iPad app is that we wanted it to feel really fast and fluid. And one of the things we did to achieve that is to have this quite sophisticated gesture system where you can use all of your fingers, you can move cards around, you flick them off the screen to delete them, and it is a bit of a learning curve there, but if you really do learn this design language, then you are able to work with a tool really quickly and efficiently. And obviously we couldn’t just bring that 1 to 1 to the Mac because you can’t use all your 10 fingers on the Mac, at least not currently. But we still want users to be able to work quickly and efficiently with the app. So thinking about how to bring the app to a new platform, keeping this value of making it feel very fast and fluid, but using other tools such as really good cursor support, keyboard shortcuts. I’m sure we’re gonna talk about that in more detail, but yeah, those were some of the thoughts for sure. 00:08:25 - Speaker 1: And in a way, it’s taking something that’s traditionally seen as a weakness of native apps, like you have to build a new app for every platform, you know, that’s terrible. Let’s do a web app and you have one app, it runs on everything. But I think we’re sort of trying to take that and turn it into a strength by saying, OK, we have a chance to build an app for each platform and, you know, it can be different and we can leverage the sort of system strengths for each. And I think if we get it right like that can be a really big advantage for native apps and sort of what it needs to. You can compete with web apps. 00:08:58 - Speaker 2: Yeah, that is a lot of the appeal. It obviously is not a user benefit other than I suppose, being more universal or being available on more platforms, but it is a benefit to the company to have less code to maintain or just a smaller engineering team or less work to do to keep everything in sync in the sense of features, you know, if you have a native Android app and a native iOS app versus if they share a code base with I don’t know, React Native or something like that. So notably here, you know, when we come to the technical side, we are indeed sharing a code base between the two with only a 5 person team and only 3 of those are actually engineers, you know, that’d be pretty tough to do 2 full complete apps with the team that size, but we are getting leverage from the shared code base, right? 00:09:42 - Speaker 3: Yeah, we’re definitely there, and I would say I’m even quite surprised by how much code we were able to use or reuse across both platforms. You know, the very first time we flipped that switch, so maybe for some context, the app is built in Mac Catalyst, which is a framework that Apple released a few years ago. That lets iOS apps be ported to the Mac and basically just clicking a checkbox, making it run, and then see what it’s like, and news was actually quite usable from the very first build, but then I guess it’s the classic 80/20 rule of, you know, most of it works really well, but to get to that really polished state that I hope people feel the Mac gap is in. You’ll actually spend a long, long time in our case, several months polishing it and improving it, but most of the basic logic in the app is just the same between both apps and notably also the sync layer that we were working on in parallel that lets users use their data on both devices. That’s all just shared across all platforms, and that means a lot less code to maintain, fewer bugs to fix. If we want to introduce a new feature, we can do it on both platforms simultaneously. Yeah, less testing to do. So it’s really a great advantage. And there’s, of course, a few downsides like you end up sprinkling your coat quite a bit with if I’m on the Mac, have this component look like this. If I’m on the iPad, should look a little bit differently, but it’s really quite manageable, at least at the moment. 00:11:16 - Speaker 1: And maybe Muse is even in a bit of a unique position there and that we have this what we call the Muse canvas, which is basically on the iPad, it’s most of the app, right? We don’t even have any visible UI Chrome by default, but you have the canvas where you place all your content and we don’t really want to mess with that at all. Like we don’t want to move your content around or change how it looks on different platforms. So I think that was one of the first things we were able to more or less set in stone for bringing news to the Mac that, OK, the canvas is going to look the same. We just have to make sure it works and adapts to the system conventions and like that’s already 90% of the app logic, right? And so then we have all this UI Chrome around it where on the Mac, I think we actually have a bit more since, you know, you have the menu bar and you have sort of a bit more of an established system UI that every app needs to provide. 00:12:09 - Speaker 3: But at least as you said, these interface elements, the menu bar are actually perceived by the user of belonging more to the operating system around it, so not necessarily Chrome off the app itself. And on the Mac we were even able to remove some of the Chrome that we have on the iOS app where on the iPad, when you tap on the canvas and the action bar pops up that lets you do all kinds of actions. We just moved all of that into the menu bar or into keyboard shortcuts. So in a way, the Mac app is even more focused on your content now and doesn’t have any buttons that get in the way. 00:12:46 - Speaker 1: And for me, that was actually a really nice positive difference from designing for the iPad. That a lot of the time when on the iPad, we would have to build our own interaction or our own interface element for the user to see. On the Mac, there’s already an established standard for that. There’s maybe even already like a view that Apple built that you can plug into. And yeah, there were just a lot of times where basically we could have something on the Mac without having to rebuild it from the iPad just because Apple already provides that. 00:13:18 - Speaker 3: Yeah, definitely rediscovered my love for right click contexts menus. Yeah. 00:13:23 - Speaker 2: Same, yeah, I do a lot with the right click stuff on the Mac. Yeah, it’s interesting because you know we have such a, I don’t know if you call it quite an internal culture, but just a basically a pattern of needing to always reinvent everything in some way as we’re building for the iPad because there is so much less precedent for productivity software there. And it was almost kind of relaxing to realize that, yeah, the Mac has such a rich and long history of great productivity software, and there’s obviously specific documentation like the Apple Hig, but there’s also just a lot of great apps that you can look at and basically say, oh, folks have already figured this out and it works great, we don’t need to be that original, we can just do. What others do, you know, adapt it to our situation and try to find the best possibility that fits with our, again with the open canvas and the cards and all that sort of thing, but we can draw from that rather than needing to always be inventing everything kind of from scratch. To that point, I’d be curious to hear the apps that we kind of took for inspiration or reference. I know I saw very often, you know, referencing, for example, the behavior finder as a bit of a kind of benchmark for here’s the baseline of what all Mac users are going to expect in terms of how basic interactions work. Yeah, what are some examples that we drew from. 00:14:53 - Speaker 1: Yeah, there were a lot of them. And I think part of it is that Muse cannot really be put into one category where we can just look at the other apps in that category and see how they do it. So yeah, we looked at the finder because Muse has a lot of sort of file browser style parts to it as well. We also looked at Sketch or Figma, sort of some of classic design apps, which have really set many new UI conventions over the last few years, I think. 00:15:20 - Speaker 2: Well, and importantly, they also pioneered the infinite canvas stuff. I guess even going back to like Adobe Illustrator, f…

    Full show notes at the publisher

    https://museapp.com/podcast/transcripts/56-sync/ Oct 05, 2023
    Show notes

    Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: But this totally changes how the data is persisted, and I think that’s important because the only way you get good results on sync systems, especially when you’re talking about offline versus online and partially online, it has to be the one system that you use all the time. You can’t have some second path that’s like the offline cache or offline mode that never works. It needs to be the one true data synchronization persistence layer. 00:00:29 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for thought on iPad and Mac, but this podcast isn’t about Muse the product, it’s about me as the company and the small team behind it. I’m here today with two of my colleagues, Mark McGranaghan. 00:00:43 - Speaker 3: Hey, Adam. 00:00:44 - Speaker 2: And Adam Wulf. 00:00:46 - Speaker 3: Yeah, happy to be here. 00:00:48 - Speaker 2: Now Wulf, you are not at all new to the Muse team, I think you’ve been with us for coming up on 2 years now, but it is your first appearance here on this podcast, a long overdue one I would say. So we’d love to hear a little bit about your background and how you came to the team. 00:01:03 - Speaker 3: Yeah, thanks, it’s exciting. Before Muse, I worked for a number of years with Flexits on their calendar app, Fantastical, both on the Mac and the iPhone and iPad. Really enjoyed that. At the same time, I was also working on an iPad app called Luose Leaf, which was an open source just paper inking app, kind of note taking app of sorts, really enjoyed that as well. 00:01:28 - Speaker 2: And I’ll know when we came across your profile, let’s say, and I was astonished to see loose leaf. It felt to me like a sort of the same core vision or a lot of the same ideas as Muse, this kind of like open-ended scratch pad, multimedia inking fluid environment, but I think you started in what, 2013 or something like that, the Apple pencil didn’t even exist, and you were doing it all yourself and, you know, in a way maybe too early and too much for one person to do, but astonishing to me when I saw the similarity, the vision there. 00:02:03 - Speaker 3: Yeah, thanks. I think the vision really is extremely similar. I really wanted something that felt physical, where you could just quickly and easily get to a new page of paper and just ink, and the, the app itself got out of your way, and it could just be you and your content, very similar to you sitting at your desk with some pad of paper in front of you. But yeah, it was, I think I started when the iPad 2 was almost released. And so the hardware capabilities at the time were dramatically less, and the engineering problems were exponentially harder as a result of that, and it was definitely too early, but it was a lot of fun at the time. 00:02:42 - Speaker 2: And I think one of the things that came out of that, if I remember correctly, is this open source work you did on ink engines, which is how we came across you. Tell us what you did there. 00:02:52 - Speaker 3: Yeah, there’s a few different libraries I ended up open sourcing from that work. One was the ink canvas itself, which that was the most difficult piece for me. The only way to get high performance ink on the iPad at the time was through OpenGL, which is a very low level. Usually 3D rendering pipeline. I had no background in that, and so it was extremely difficult to get something up and running with that low level of an architecture. And so, once I had it, I was excited to open source it and hopefully let other people use it without having to go through the same pain and horror that I did to make it work. But then one of the other things that was very useful that came out of loose leaf was a clipping algorithm for Bezier curves, which are just fancy ways to define ink strokes, basically, or fancy ways to describe long curvy, self-intersecting lines. And that work has also been extremely important for Muse as well. We use that same library and that same algorithm to implement our eraser and our selection algorithms. 00:04:05 - Speaker 2: And when you’re not deep in the bowels of inking engines, or as we’ll talk about soon sinking engines, what do you do with your time? 00:04:13 - Speaker 3: Oh, I live up in northwest Houston in Texas with my wife Christie and my daughter Kaylin. And she is in high school now, which is a little terrifying, and learning to drive and we’re starting that whole adventure, so that’s been fun for us. I try and get outside as much as I can. I’ll go backpacking or hiking a little bit. That can be fun, and the Houston summer, it’s rather painful, but the springs and the falls, we have nice weather for outdoors and so. 00:04:42 - Speaker 2: What’s the terrain like in the day trip kind of range for you? Is it deserty? Are there mountainous or at least hilly areas, or is it pretty flat? 00:04:52 - Speaker 3: It is extremely flat and lots and lots of pine trees, and that’s pretty much it. Just pine trees and flat land. Sometimes I’ll drive a few hours north. We have some state parks that are nice and have a bit of variety compared to what’s immediately around Houston, so that’s a good backup plan when I have the time. 00:05:14 - Speaker 2: Flat with a lot of trees sounds surprisingly similar to the immediate vicinity of Berlin. I would not have expected Texas and northern Germany to have the commonality there. It gave me a lot of appreciation for the San Francisco Bay Area, while that city didn’t quite suit. Me, as we’ve discussed in the past, one thing that was quite amazing was the nature nearby and a lot of that ends up being less the foliage or whatever, but more just elevation change. Elevation change makes hikes interesting and views interesting and I think itself leads to, yeah, just landscape elements that engage you in a way that flatness does not. 00:05:55 - Speaker 3: Yeah, absolutely. I lived in the Pacific Northwest for a while, and the trees there are enormous, and the amount of green and elevation change there is also enormous. And so when we moved back to Houston, it was a bit of a shock almost to see what I used to think were tall trees in Houston are really not very tall compared to what I lived around up in Portland, Oregon. 00:06:21 - Speaker 2: So our topic today is sync. Now Muse 2.0 is coming out very soon. We’ve got a launch date May 24th. Feels like tomorrow for our team scrambling to get all the pieces together here, but the biggest investment by far, even though we have the Mac app and we have text blocks are a part of it, the biggest kind of time, resource, energy, life force investment by far has been the local first sinking engine. And we’ve spoken before about local first sync as a philosophy generally in our episode with Martin Klapman, but I thought it would be good to get really into the details here now that we have not only built out this whole system, both the client side piece and the server piece. But also that we’ve been running it in, won’t quite call it production, but we’ve been running it for our beta for a few months now, and we have quite a number of people using that, some for pretty serious data sizes, and so we’ve gotten a little glimpse of what it’s like to run a system like this in production. So first, maybe Mark, can you describe a little bit how the responsibilities breakdown works in terms of between the two of you on the implementation? 00:07:32 - Speaker 1: Yeah, so I’ve been developing the back end or the server component of our sync system, and Wulf has been developing our iOS client that is the core of the actual app. 00:07:45 - Speaker 2: Yeah, on that side, I kind of think of the client persistence or storage layer as being the back end of the front end. So that is to say it’s in the client, which obviously is a user interface heavy and oriented thing, but then it persists the user data to this persistence layer which in the past was core data, is that right? Well the kind of standard iOS storage library thing. 00:08:08 - Speaker 3: Yeah, that’s exactly right. Yeah, we used core data, which is Apple’s fancy wrapper on top of a SQL light database. And that just stores everything locally on the iPad, like you were saying, so that way the actual interface that people see, that’s what it talks to. 00:08:25 - Speaker 2: And then that persistence layer within the client can talk to this back in the mark has created. And much more to say about that, I think, but I thought it would be nice to start with a little bit of history here, a little bit of motivation. I’ll be curious to hear both of your stories, but mine actually goes back to using my smartphone on the U-Bah, so that’s the subway system here in Berlin, when I was first working with some startups in the city back in, I guess it would have been 2014, so, 8 years ago I had this experience of using different apps and seeing how they handled both the offline state but actually the kind of unstable state because you have this thing where the train car goes in and out of stations and when you’re in the station, you usually have reception, weak reception, and you leave the station that fades off to you essentially fully offline, and so you’re in this kind of unreliable network state all the time. And two that I remember really well because they were really dramatic, was one was pocket, which is the relator tool I was using at the time, and it handled that state really well. If it couldn’t load an article, it would just say you’re offline, you need to come back later, but the things it had saved, you could just read. The other one I was using was the Facebook mobile app, and there I was amazed how many errors and weird spinners, and you go to load a thing and it would get half of it, but not the rest of it, and the app just seemed to lose its mind because the network was unreliable, and I found myself thinking, what would make it possible to make more apps to work the way the pocket does and less the way that Facebook works. And I also had the opportunity to work with some startups here, including Clue and Wunderlust and some others that had their own. Essentially everyone needs this. Everyone needs syncing because they want either one, the user to be able to access their stuff from different devices, or 2, they want some kind of sharing, and I think Vonunderlust was an interesting case because they built out this crack engineering team. To develop really good real-time syncing for a very simple case. It’s just a to do list, and the common case that people use it for, I think was, you know, a couple that’s grocery shopping and they want to like, make sure they don’t overlap and pick the same things in the cart. But it worked really well, but they built this huge, I think it was like a 15 person engineering team that spent years of effort to make really good real-time sin, and it seemed strange to me that you need this big engineering team to do what seems like a simple thing that every app needs. We went down this road of trying CouchDB and Firebase and a bunch of others, and all were pretty unsatisfying. And then that further led in, you know, that kind of idea, the sync problem lodged in my mind and then when we got started at ink and Switch, some of our early user studies there were on sync and how people thought about it. And one thing that stuck with me from those was we looked into just kind of syncing on. And note taking apps and talked to a whole bunch of people about this, and we didn’t have a product at the time, so it was just kind of a user research study, but we went and talked to a bunch of folks, most of whom were using Evernote was kind of the gold standard at the time. And almost everyone we talked to, when I asked what’s your number one most important feature from your notes app, they said sync and said, OK, so that’s why you chose Evernote, and they said, yeah, and they said, how well does it work? And they said terribly, it fails all the time. You know, I write a note on my computer, I close the lid, I go to lunch. Half an hour later, I go to pull it up on my phone. It’s not there. I have no idea why. And so some combination of those experiences sort of lodged this thing in my mind of the technology industry can just do so much better, and this is important and everyone needs it. What’s the missing piece. And I wasn’t really sure, but that led into once I met up with folks in the research world who indeed had been working on this problem for a while, and I got excited about the technologies they had to offer. 00:12:15 - Speaker 1: Yeah, and then I guess I was downstream of that because I got introduced to space by Peter Van Hartenburg with time was a principal at the Inn Switch Research Lab, and it’s now the director of the lab. And he showed me a demo of the Pixel pusher project, and we can link to the article on this, but essentially this is a Pixel art editing tool that was peer to peer collaborative, and the app itself is very standard, but was amazing to me was he had implemented this app and he had 2 devices or 2 windows on the same device, and they were doing real-time collaboration, but there was no server. And I had come from this world of wherever you add a feature to an app, you gotta write the front end and then you gotta write the back end, you gotta make sure they line up whenever anything changes, it’s a whole mess, and it was just magical to me that you could just type up this JavaScript app and have it collaborating with another client in real time. So I went down that rabbit hole, and there was the obvious attractions of the austere locations and, you know, minimal network connectivity and things like that. And also at the time the research was very oriented around P2P, so there was this notion of the user having more control of their data and perhaps not even requiring a central server, but a couple of things became even more appealing to me as I researched it more. One was that Potential of higher performance. And I ended up writing a whole article about software performance that we can link to. But one of the key insights was that it’s not physically possible to have acceptably fast software if you have to go anywhere beyond the local SSD. Now, certainly if you’re going to a data center in Virginia or whatever, you’re totally hosed. So it was very important to incorporate this performance capability into Muse. 00:13:49 - Speaker 2: Yeah, that article was eye opening for me and that you connected the research around human factors, things that looked at what level of latency you needed for something to feel snappy and responsive, and then separately the speed of light, which is how sort of the maximum possible speed that information can travel, and if you add those together or do very simple arithmetic on that, you can instantly see it’s not about having a faster network connection. You literally cannot make something that will feel fast in the way that we’re talking about if you have to make a network round trip. 00:14:21 - Speaker 1: Yeah, and the one other thing that was really interesting to me about this space was the developer experience. I alluded to this earlier with the Pixel Pusher demo, but in the before times there were two ways to develop apps. You had the local model where you were typically programming against the SQL database, and everything was right there and it sort of made perfect sense. You would query for what you need and you write when you have new information and so on. And then there was the remote model of you would make rest calls, for example, out to some service like admit this edit or add a new post or whatever. But then these two worlds were colliding where we always wanted to be adding sync and collaborative capabilities to our apps, we would try to kind of jam one into the other, like you would try to patch some rest onto the database or you try to patch some database on yours and…

    Full show notes at the publisher

    https://museapp.com/podcast/transcripts/57-messaging/ Oct 05, 2023
    Show notes

    Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: Titles of books are probably one of the best sources of inspiration for messaging. Book covers are so inspiring to me because it’s a visual and a title and the title’s so short and it captures the entire thesis of the book. 00:00:22 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for deep work on iPad and Mac. This podcast isn’t about Muse the product, it’s about the small team and the big ideas behind it. I’m Adam Wiggins here with my colleague, Mark McGranaghan. Hey, Adam. Joined today by Hilary Maloney. Hi. And Hillary, we on the Muse team often like to work from interesting, inspiring nature locations with sometimes limited internet connectivity. Hui in particular is famous for this, at least on our team. I understand that while you were working with us recently on a project, you got to do a little work in the less connected parts of California. 00:01:01 - Speaker 1: Yeah, so I spent a lot of my time climbing and traveling around California in a camper van and got to do quite a bit of this project, traveling down in Bishop and I’d work in the mornings out of the van and then kind of go about my day. So it’s really cool to work, you know, flexibly with this team and see that you guys have that as part of your working style. 00:01:24 - Speaker 2: Now, how do you fit together your day kind of interleaving, obviously these very different activities of going out into, I guess bouldering is the, the official term for it. Yeah, exactly. Sort of going out and doing that, which I’m just gonna assume in my head that it’s like this documentary Free Solo that you look exactly like that guy climbing up the side of the mountain there in Yosemite, but do you do that kind of like you like to work early and then do the physical stuff later or the inverse? How do you put it together? 00:01:54 - Speaker 1: Yeah, I’m definitely a morning person, so I like to get up really early, especially when I’m camping, you know, if you’ve ever been camping, you naturally wake up at like 5 a.m. And so I like to get a few hours of work in the morning when my brain is fresh and then kind of go about my day and being really physical and active, I think is almost part of my process. We can talk about that more, but I think, you know, being in your body is so important to doing creative work and having ideas. And so yeah, I tend to kind of start in the morning and then that physical experience is really important for me. 00:02:32 - Speaker 2: Yeah, same here, and I think I didn’t realize that and I don’t know, my twenties maybe when I was, you know, get my career started and was more about being at the computer and being focused, but later, yeah, that in your body, as well as maybe almost paint that as the inverse, which is actually getting out of your head, which is when you do very intellectual work all the time and you’re almost unaware of your body, almost to the detriment of your physical health. But if you go do something particularly that’s really demanding, whether it’s something like bouldering, for me, a really intensive hike, for example, with a lot of elevation change or run, anything like that, it sort of forces you to leave the higher plane of your mind and go to a more primal state, but I think that actually is better for when you return to your mind, somehow your ideas and your creativity has rearranged itself. I don’t know, it’s like, there’s something to it there. 00:03:26 - Speaker 1: Yeah, absolutely. I feel very seen by that. It’s kind of a necessary part of the life, you know, and doing hard complex work, and I’m definitely drawn to, as you described, those very intense experiences as well. Even sometimes walking isn’t enough. I need to run or surf or climb or something that’s like very physically demanding, and you’re exactly right. It’s really about getting out of your mind as much as it is getting into your body. 00:03:56 - Speaker 2: And tell us about your background and in particular, maybe even how you would label what you do. I think I’ve heard you refer to yourself as a strategist. Tell us what you do and how you came to do that. 00:04:08 - Speaker 1: Yeah, so I’m a brand strategist and researcher. My background is really in kind of classical brand marketing and advertising. So I’ve spent a lot of my career working in advertising agencies, but I also really love working with startups, so I do a lot of side projects as well. And I really think of myself as a marketing generalist. Maybe you guys feel this in software, but I think a lot of fields are becoming super super specialized and there’s routes you kind of take to specialize in your career and I’ve tried to stay really broad, so I do quite a lot of of marketing work and like to do messaging, which we’re going to talk about, but I also do a lot of advertising and different skills within the discipline. Yeah, so how did I start in marketing? I actually studied journalism and that just got me really interested in storytelling, but found pretty early on, I liked applying that to brands, and I like being at the intersection of communication and really business and business strategy and kind of the why behind it. 00:05:14 - Speaker 2: Now, is this a, you tried your hand at, I don’t know, when I think of journalism, I maybe I’m thinking of investigative journalism, but going out into the field, researching a story and then writing. You know, a medium form piece about that. And did you try that and find it didn’t work for you and then you somehow stumbled into this brand thing or was it just more like, I don’t know, there’s certainly probably more commercial opportunity, not journalism is not known these days for being like a growth industry in particular. 00:05:40 - Speaker 1: Yeah, for sure. For me, it was in school. I was in a pretty good journalism program and we did a lot of field work as part of our program. I studied photojournalism specifically, so I was doing a lot of photo stories and reporting and coming back into, we had critiques, almost like art school style critiques with our photojournalism program and My professor just recognized in my work that I was drawn to telling stories about businesses in our community and in particular in a documentary style journalism class, I was producing a lot of work that was like going behind these businesses and telling their stories, and my professor actually kind of pulled me aside and he was like, I think you need to go into more of like an advertising path with your kind of natural. Interests. So actually in school, I made that pivot and started taking some marketing and advertising classes and then started working in the marketing field at a startup actually is my first job. 00:06:46 - Speaker 2: Anything we’ve heard of? 00:06:48 - Speaker 1: Probably not. It was called Parlour. It was an interior design app, so actually kind of interesting. I’ve had this red thread in my experience of creative tools and creative communities, but it was a workflow and e-commerce app for interior designers, so very specific, but we made it into beta and then we just didn’t find enough scale kind of in the right amount of time. But it was a really, really fun marketing experience and a really fun brand to build. So it was really exciting and, you know, you learn a lot in startups and not finding market fit, and I definitely learned a lot. So it’s a fun fun place to start my career for sure. 00:07:31 - Speaker 2: Well, that’s good you took the positive lesson from that. I feel you could take the negative one, which is, boy, these startups are unstable and uncertain, and it kind of sucks to pour a bunch of creative energy into a thing that ultimately falls flat in the marketplace, but it seems you took it more as learning experience and just a chance to try something that’s kind of high risk, but high risk means sometimes it doesn’t work out in the end. 00:07:53 - Speaker 1: Yeah, for sure. 00:07:55 - Speaker 2: So I’m very pleased to say that Muse 2.0 is out. We launched a couple of days ago and I’ll link the launch memo in the show notes. You can read that for all the goodies, MacAs, sync, text blocks, etc. Now, as part of that, we have an all new website, and if you go look at the homepage, you can already see we’re talking about the product quite differently, the Muse 2 product quite differently to how we talked about Muse one. So that naturally leads to our topic today, which is messaging. Now the project you did with us, Hillary, was working on our messaging. And where we landed is sort of 3 parts. The first is dive into big ideas. So this is our brand messaging, it’s aspirational, it’s why you might want to use the product without telling you what it is. And then we have two more product level descriptions. One is a very short one, that’s tool for deep work, and then there’s a slightly longer one, which is flexible boards for note taking, whiteboarding, and connecting the dots. And we’ll try to use those on our website, but also on our App Store page and our Twitter bio. You even heard it in the podcast intro, especially anytime someone, especially new comes across our product or company and they just want to know really briefly, what are these folks about, what is this product about? So congratulations Hillary on the successful result. 00:09:11 - Speaker 1: Yeah, I’m super happy with where we landed, and it’s exciting to start seeing it coming to life across the site and different places that we’re using that marketing language. 00:09:22 - Speaker 2: So if we go to the definitional element here, tell us maybe for someone who’s a designer, engineer, founder, someone who’s in the tech world but maybe doesn’t necessarily know what that term means. 00:09:35 - Speaker 1: I define messaging as a system of communication that’s rooted in strategy. So, you know, it sounds like it might be limited to just like copywriting or headlines or that kind of thing. I think the most important thing is that it has a strong point of view and that it’s maybe rooted in a moment in time for your business. So maybe you’re thinking about a particular audience that’s critical to your growth kind of right now. A new product is a very, you know, common reason why you would revisit your messaging and really thinking about your positioning relative to the category. So there’s a lot of that research and context that goes into creating that system of messaging. And I think that’s something Adam, you and I spoke about pretty early on when you were kind of running into this problem of how do we articulate news in this really simple way. The solution is really to create a system of brand, product, taglines, just longer descriptions that you can use, so it’s much more than kind of one line, it’s that system and the reason behind it. 00:10:47 - Speaker 2: And one of the exercises we did in the kind of early part of the project was to look at some comparable products, either, yeah, competitors or pseudo competitors, but others that are just in the creative tools space or the sorts of products that people who also use Muse or might use Muse would also use. And that was illuminating to me and talking about that point in time element you mentioned that I think is important, which is, you gave the example of notion. And I think their website a couple of years ago said something like, your team’s source of truth, and I remember when I saw that, that really clicked for me, that resonated. I said, ah, OK, this is like a modern team wiki, it’s a place to put all your kind of internal documentation about your company. OK, I got it. But I think at that point in their existence, they were targeting people like me, basically startup people at small and medium sized companies. Now, you pointed out and looking at their current messaging and you had some screenshots of their website, you’re guessing, paraphrasing here, correct me if I’m wrong, but from the outside it seems like they’ve transitioned to trying to message to the enterprise. They’re moving to these larger companies because they basically have completely owned the startup market. Everyone knows what notion is and uses it, they don’t need to convince anyone through. Website. So now this new category that they’re expanding to, which is these larger, more kind of traditional or conservative companies, and they need different messaging. And so for me, I look at the notion’s website now and the stuff they say there doesn’t speak to me at all. I’m like why do they are messaging worse, but it’s not worse, it’s just different for a new audience. Is that the right interpretation? 00:12:22 - Speaker 1: Yeah, exactly, and I think they have right now a line around for every team, and so when I see that, I can see that their strategy is really about moving beyond technical teams in the organization. And if I had to guess, Notion might be experiencing a ton of love for the product among just technical teams where they have a really strong brand, and now they need to build that same sort of traction within more teams in the organization so that there is that enterprise value. That’s just my total assumption based on the messaging, but I do tend to do that like you said, you know, in our discovery process, we Looked at a lot of different companies in the space and at this point in my career, I kind of go through the world just interpreting strategies and problems brands are trying to solve based on their commercial or some kind of ad that I see or something, so. Yeah. 00:13:24 - Speaker 3: Yeah, I also appreciated this idea of identifying a point in time for the messaging, because I feel like one of the challenges we had before was it just felt so daunting to think about the messaging from Us, which is this product that we aspire to be working on for many years, and we have huge ambitions for, and how do you summarize that all in one word or even one sentence. But this project, I feel like we’ve cut scope, as Adam would say, when in doubt cut scope and say, OK, for this product and this launch, what’s the message that we want to communicate to these new users? And that seems much more doable. 00:13:55 - Speaker 2: Yeah, maybe to that point in time element, while we were less strategic perhaps about choosing kind of our muse 1. X messaging. So there we identified that we’re a tool for thought, and we have this second level message, deep thinking doesn’t happen in front of a computer. And so that was kind of the core, and then we also described the product as a spatial canvas, that’s kind of the product description, and then the more aspirational, the category is tool for thought. And I think that did work really well for us at a point in time, which was that term was maybe on the rise, particularly among a particular niche audience of people, and because we were early on, that worked really well, but I look at it now and I go, OK, well, we want to be a little more accessible, and so our website is kind of like, if you don’t know exactly what is a tool for thought, If you’re not one of those very small, you know, number of people on that inside club, it doesn’t really give you a lot of information, it sort of pushes you away. And again, I think that’s fine when you’re early on and you need to build a smaller audience, and it’s OK if it’s sort of niche, and so one of the goals for this project was to be slightly more accessible. Now, it’s not mainstream by any sense, I don’t think news would ever be that, but we wanted to go a step further into making it comprehensible. You don’t necessarily need to know who Doug Engelbart is in order to get benefit from use as one example. I think that’ll still always be our core community. We certainly will use tool for Though in a lot of contexts, including in describing this podcast, and so on, but it’s a chance to, and so if you think of that point in time and the p…

    Full show notes at the publisher

    https://museapp.com/podcast/transcripts/58-product-decisions/ Oct 05, 2023
    Show notes

    Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: It’s part of the foundational history of sketch of like facing this enormous monopolistic late 2000s Adobe, and now that the sketch success and define the category in the market, which then in turn attract more players and then because we chose a different path in the business and in growth, now there’s new juggernauts again. 00:00:27 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for deep work on iPad and Mac, but this podcast isn’t about Muse product. It’s about the small team and the big ideas behind it. I’m Adam Wiggins here with my colleague Mark McGranaghan. 00:00:41 - Speaker 1: Hey, Adam. 00:00:42 - Speaker 2: And joined today by our guest, Paolo Pereira of Sketch. 00:00:46 - Speaker 1: Hello, Adam, Mark. 00:00:48 - Speaker 2: And a topic we’ve spoken about a number of times is YouTube and its importance for learning skills in the modern world, but Paolo, I understand that you’ve found a way to sort of escape nature through YouTube. 00:01:01 - Speaker 1: Yeah, that is true. I’ve taken to watching camping and bush crafting and canoeing videos on YouTube. It’s someone that’s never done a lot of outdoor stuff, it is actually surprisingly relaxing. 00:01:15 - Speaker 2: One that I’m familiar with is this channel Primitive Technology where this fellow goes into the woods and builds, I don’t know, a hut or something using whatever he finds around sticks, mud, rocks, and of course the entire time doesn’t say a word, but it sort of has this meditative quality while at the same time you’re watching someone who is great at their craft do something that maybe you didn’t know how it was done. 00:01:42 - Speaker 1: I’m also a big fan of in that vein, there’s a Japanese woodworker who goes by Ishitani furniture and also the same thing, it does not say a single words and it’s just like long shots of him doing things over and over. And also, it does help that his furniture is absolutely beautiful, but the meditative aspect to it is a big part of the appeal to me. 00:02:06 - Speaker 2: And tell us a little bit about your background. 00:02:09 - Speaker 1: So, I have been a lifelong website maker from being an lobbyist when I was 14, then to being a student in university for software engineering, then on to a job, and I’ve mostly been a freelancer most of my career. 00:02:29 - Speaker 2: And I noticed looking at your portfolio from that kind of earlier time, a lot of your websites seems like you were specialized on event websites and especially design forward design focused events so I could only imagine those clients were enjoyable to work with, or at least the subject matter was close to your heart. 00:02:47 - Speaker 1: Oh yeah, absolutely. That was for mostly XOXO and my friend Andy and his friend Andy put together and also uh building and other events that my friend Andy organized and of course it was a big pleasure because he didn’t have to sell the value of, of putting effort into the design and also then the people that looked at the work were more appreciative of it, which is, I mean, it’s always good when that happens, when there’s an appreciation from both the client and the audience about the work that you do. 00:03:16 - Speaker 2: And then what brought you the sketch? 00:03:19 - Speaker 1: So it was also in that capacity as designer and developer, web designer, and web developer specifically. I joined in late 2019 after a project had ended, I wasn’t really sure what to do. And in retrospect, I could see that I was a bit bored of like, you know, starting a project from scratch every time, which is very good things going for it, but you know, as you know, you can only see the things that you didn’t get to do right after your ship and the problem with working on small freelance projects like that is well, you rarely get a chance to fix those, so they are going to live there just staring at you in perpetuity. So I joined Sketch in the marketing team as a hybrid designer and developer. You know, what was at the time a very small marketing team, so like to get to do, you know, the things that I like to do, which is have a handy design and development and a broad perspective of the website. But now in a situation where, you know, I didn’t have to do everything and there were much more competent people doing all the things that I didn’t like to do or frankly was not very good at, right? So we had great people doing. I can design illustration, you know, video production, copywriting, strategy, and it was great to be in that situation and I perform my strengths and other people bring their strengths and the end result is also much better for it. 00:04:46 - Speaker 2: And maybe it’s worth briefly here mentioning what sketch is. I think of it as being a pretty foundational design tool. In fact, it sort of kicked off the modern design tools revolution, I think in the last 10 years, but we don’t want to make any assumptions, so maybe you can briefly tell us what is this product and who uses it. 00:05:03 - Speaker 1: So, Sketch is now an all in one platform for design, both for design teams, teams of designers or individuals. And it has 3 main building blocks. It’s got the workspace, which is a place for all your documents, your projects, your design system, and also for all the people managing people. You get the thing that brought sketch to the limelight, which is a native Mac app for creating and editing designs and prototypes, and unbeknownst to many, we have a very powerful web app that works on any browser or any device. This is not an app for editing. It is an app for browsing documents, for viewing documents with a full canvas, inspecting, commenting, playing prototypes, and even browsing symbols and all your styles of your design system in a components view, including, you know, exporting color variables as token that can use directly in web development. So these three pieces make what’s sketchiest today. I guess as you as you mentioned to this audience, people might know sketch more as like, it’s that Mac, it’s the design Ma app and to that I would say like it’s still that, but it’s so much more now and it’s, I think, worth the bias here, of course, worth a second look. 00:06:19 - Speaker 2: And I’ll just briefly mention Sketch to me is one of my favorite tools, not just in the utility sense, but in the sense of inspiring what software could be. I think it really redefined what a design tool could be, particularly coming from this kind of small independent team which I think will Talk about later in a time when in this market that was saturated by Adobe as the giant that dominates the creative tools design tool space, still does, of course, but Sketch came up with this product that sort of sliced the problem in a different way and yeah, remains, I think, sort of an industry defining tool even in this time of an explosion of new and interesting design tools. 00:07:00 - Speaker 1: First, thank you for saying that. I agree for what you said. I know I worked as sketch, but I’ve only been here 2 years and a half and the product is much, much older than that. I used it before. It’s definitely a category defining product, right? There’s just definitely, at least in the white design world, there’s a pre-sketch and a post sketch, and we’ll get to talk more about that later on by the end. But it is an immense privilege and responsibility to work on something like this, of course, that has it, you know, so beloved and it was such an important piece in the history of design tools. 00:07:36 - Speaker 2: And you work on the editor component. You talked about those three major pieces of the sort of larger sketch product or platform. What is the editor and what is your role with that? 00:07:46 - Speaker 1: Yeah, so I, despite having joined in the marketing team as a website design and developer, I, since a year now work as a product manager on the editor team. The editor team is the most primary and foundational level of the editing experience at sketch and ed sketch that is on the Mac app. And so we work on the little day to day things you do over and over, so much to become second nature, right? So this is things like selecting and moving and rescising, and lining, layout, editing texts, add new shapes, but also the sort of the home, sort of the building blocks of the UI, right? So you got the canvas, the toolbar, the list, and so on. So in a way the writer is the place and the tools where all your design comes together, where you bring in pieces from your design system and you connect their prototypes and then you go and play and so on, but all these things converge and come into the editor is where you knowingly or not spend most of your time. 00:08:50 - Speaker 2: And those primitives make up the core and everything else is built on top of that. So to me that feels like a big responsibility. 00:08:59 - Speaker 1: Yeah, it is because I mean, so much of this becomes second nature muscle memory that if you disrupt something like this, people immediately know, right? Like something does not feel right, maybe you might know, you might not know what it is, but it definitely does not feel right because it gets to that level of closeness to the way you work, you can tell where the bounds are. And I think that’s a You know there’s simply a characteristic of the creative tools in general, where there is like fast input environment and very, very, very short feedback loop environment and they are quite nonlinear, right? And so it’s a bigger responsibility to work in such a place. the user flow can just go really anywhere, right? So you can do almost anything at any time and as quickly as something starts, it ends right away. So you do all these small things really quickly over and over, you get feedback right away and so if the flow breaks, it doesn’t feel good to use the tool. 00:10:01 - Speaker 2: So our topic today is how to make product decisions and especially for creative tools or on a team that has a very strong design culture and you mentioned there briefly Paula, that your role is in product management or you are a product manager, but I think you come from this design background, not necessarily it’s called a classic product management background. And I think also working on a product like Sketch that is so mature and as you said so beloved and has so many use cases, you know, one thing I’ve seen that seems almost counterintuitive is the longer a product has been around and the more it can do, the more things people will ask for. You would think that eventually you would build everything and it would stop asking for new stuff, but it’s almost the opposite. We’ve seen that with our recent launch here of Muse 2.0 and just the number of Different kinds of features people are asking for I feel is far bigger than prior to that, even though we just added a bunch of new stuff that people have been asking for. So there’s always more and then you’ve got a large organization. There’s a lot of different stakeholders, customers, but people in the company vision comes from different places. I think it’s a challenging area. So I’d love to hear how your team makes decisions and especially within the context of sort of your larger company. 00:11:12 - Speaker 1: You’re absolutely right, and I think it’s defining aspect of product that there’s always more to do than there is time or resources to do. I think that’s never gonna change and definitely took some learning and adapting to. So, one of the key aspects of working a sketch that is Emma’s privilege is that most people on sketch use sketch. So having found its footing in the UI design market, sketch at its core is a vector editing. Design software. And so at Sketch we have a lot of people using Sketch in a lot of different ways and get a lot of feedback through them. So obviously we got designers and both product designers, which is sort of the core market, but also illustrators, icon designers, even motion designers that storyboard and sketch, which gives us a very different perspective on, you know, the same tool that product designers would use, but also this extends to engineers. That’s, you know, do diagrams in the editor and things back in the web app, product talks, retrospectives are often conducted in sketch with real-time corroboration, again, making diagrams, even anyone in a leadership position that when rarely they have to do presentations to do with them in sketch and really this is kind of where we live, right, like everyone browse documents, sends links around to sketch documents and Then a lot of folks in customer support and customer success are designers themselves, so there’s a big like design culture permeating every part of the company, and this is huge because it does shorten the feedback loop, you know, someone has an ID you can quickly Jump on it and understand better where they’re coming from, why the current approach is working for them, you know, and contrast to the perspective of someone else that has different needs and you use the same idea in a different way. And of course, it goes beyond our team, we suffer from everywhere from us and customer support, social slack workspaces, we have a few groups of people, events, testing programs and research programs that we run, and so on and so forth. So this obviously creates a huge amount of input and ideas and information that we have to process and digest, but that is, I think, ultimately a very good thing. 00:13:26 - Speaker 2: Yeah, it’s a lot of different sources, a giant fire hose of inputs and ideas and complaints and problems and excitement for things you’ve just released or might release and certainly finding a way to find patterns and all that, I’m sure is part of the job. It is interesting to me to categorize or to look at the difference between what I call internal feedback, that’s the dog fooding, sometimes they call it the team using the product and then external, your customers that are not working on it. And I think there’s a trade-off to be aware of there, which is on one hand, you know, it’s often, especially for early startups, they say the wisdom is build for yourself, and as you said, it’s about the feedback loop which is that if you build a new thing before you even show it to any customers, you already know if the team internally is excited or is using it for themselves. That’s a really good sign. And if you’re not building for yourself, that makes it a lot harder. It makes the feedback loop a lot longer. But the flip side of that is if you do start to totally index on what is desired internally, and that’s easy to do because these are people you see every day, you know, if it’s a physical office, you see them in the hallway, if it’s a slack channel or whatever, it’s people you know, you know, certainly company leadership. And you know if they say I have this little feature request and obviously you’re just going to be naturally inclined to respond to that, but then that can lead to or I have seen the failure case of overemphasizing internal usage and there may be a wider audience of customers who are not as well represented on the team. So I think you know both of those have their place, but it sounds like you found the balance there. 00:14:57 - Speaker 1: Yes, you’re right. I’d like to think that we did find that right balance, but I think that balance kind of changes between teams that balance between external and internal feedback in a product team, such as our design systems or workspace system that deal a lot with The way teams organize their work in process, you know, getting that input from the way other companies and teams work is extremely valuable. I think for us on the editor, we tilt the balance or, you know, shift the knob a little bit more toward the internal side because, you know, on one hand, we do not get. That many requests of people poin…

    Full show notes at the publisher

    https://museapp.com/podcast/transcripts/59-infinite-canvases/ Oct 05, 2023
    Show notes

    Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: Infinite canvases are essentially like a different document format. The screen represents a camera that’s floating above a surface, and there are things on that surface, and those things can be anything. You can move them, you can duplicate them or resize them, and that each one of these types of thing on the canvas also has its own rules about how it can be changed. 00:00:26 - Speaker 2: Hello and welcome to Meta Muse. Us as a tool for deep work on iPad and Mac, but this podcast isn’t about muse product, it’s about the small team and the big ideas behind it. I’m Adam Wiggins here with my colleague Mark McCrannigan. Hey, Adam. And our guest today is Steve Ruiz of TL Draw. Hello. And Steve, I understand you’re a little bit ahead of me on the fatherhood journey. You’ve got a 315 year old. What do I have to look forward to in the coming couple of years? 00:00:55 - Speaker 1: Oh man, a kid is what, like 1.5? 00:00:58 - Speaker 2: That’s right. 00:00:59 - Speaker 1: Eventually they will start drawing, they’ll start playing with words, and they will grow ever more interested in iPads, and also, everything will be an iPad, every computer, every device, everything with the screen will be an iPad. That’s my prediction, yep. 00:01:17 - Speaker 2: Yeah, that makes sense. Yeah, already is the case that trying to keep screen time limited is a challenge. Now, of course, we can also look forward to having built in beta testers for our software. You got a chance to do that yet? 00:01:29 - Speaker 1: Yeah, actually, my daughter has probably spent more time with tealra than anyone else, and I’ve learned quite a lot by watching her kind of poke around and try and draw, try and make different things. She really likes arrows, but the touch targets are too small and mobile. That’s one thing that I need to work on. 00:01:46 - Speaker 2: I’m reminded of a scene in one of these Steve Jobs biography movies where I believe it’s his daughter comes in and tries out Mac Paint, and they sort of show this maybe hypothetical idea that he was sort of inspired to make software and a computer generally that was easy enough that a young person could be creative with it. 00:02:04 - Speaker 1: Yeah, I mean, if you have, uh, they’re kind of hard to schedule or bring into the office. I don’t think the agencies do 3 year olds, but toddlers are excellent beta testers. They won’t tell you what’s wrong, but you’ll definitely see it. 00:02:19 - Speaker 2: So you’re working on TLDraw. Tell us about that project and your background that brought you there. 00:02:24 - Speaker 1: Yeah, so Tal Draw it started out as like an open source project, I guess it still is an open source project. It grew out of kind of earlier open source work that I did with a library called Perfect Freehand, which is an algorithm for creating like digital ink, so pressure sensitive or variable width lines, takes a whole bunch of input points, and comes up with a whole bunch of output points that kind of describe a shape that surrounds the input points. So, perfect freehand, I kind of started working on it pretty publicly on Twitter. So posting all these in progress GIFs and talking about the different ways that I was trying to solve this problem of doing pressure sensitive slash variable width lines. You can’t really do that in the browser, like it doesn’t have any primitives for like lines that change their width. So, hence the whole like journey into trying to figure out how to do that kind of programmatically myself. It works, it works super good. I would recommend it if you have anything to do with the browser that needs to have a kind of a cool ink. And it’s being used all over the place. It’s used in Draw.io, it’s used in Excali Draw, it’s used on, I think NextGS Live uses it in their product. It was one of these situations where The status quo for like a pencil tool or a pen tool was like so poor on the internet or on the browser especially. That any improvement sort of would have been well timed and perfect freehand just happens to be an improvement that is pretty good. You should use it. That’s what I say. So, I’d been working on perfect freehand, I’d been doing some integrations with like other diagramming tools like cala Draw and I guess in along the way of making perfect freehand, I built a couple of these. Canvas playgrounds almost, places where I could test this thing out or try out the different algorithms, see where it was going right or wrong. And I’ve done that a couple of times for Perfect Freehand, also for like a kind of an offshoot of this project called Globs. But anyway, I just made enough of these sort of infinite canvas editors that once Perfect Freehand was pretty much done, I started working on that kind of a framework. Originally it was gonna be like a programmable design tool that I could use both together with direct manipulation, but also with like, you know, programming, in order to help me figure out problems like perfect forehand or problems like cool arrows or something. And once I started posting that, On Twitter, saying like, oh cool, I’m looking, I’m kind of making almost like a figma that you can program, or a figma that you can put anything on the canvas that you want, and I’m doing it in React. That story suddenly got pretty popular. Like I had folks reaching out to me and saying like, hey, we’re building something that kind of needs this kind of canvas. Can you open source this or can you share this or can I hire you? So based on that attention, I was like, all right, well, maybe this is worth proceeding with. I took some time off between jobs. I was gonna start a job actually at Adobe, and I thought, OK, I’ll take some time off in between and I’m just gonna work on this project, make it open source, spend 6 months on it, and then, yeah, see what happens. Worst case scenario is that I’ve made something really cool open source, worked on something interesting in this space, and I should say there’s really very, very few open source kind of canvas UI type of tools out there. And none of them that were using this kind of react driven canvas. 00:06:04 - Speaker 2: It’s interesting that you got that initial demand, you might say a product manager lingo might be it’s sort of market validation, you know, don’t build it until you already know people want it. Even before you got into the project itself, did you have a sense of why people wanted it or had they tried to build it themselves and discovered it was hard? Had they not built it and they just hoped someone else would do it for them? It just they liked your other work and they just thought if you did a good job on this other library, maybe you do a good job on this library too. What was the core of their demand, I guess. 00:06:36 - Speaker 1: Yeah, my theory about this or my guess about this is that this was 2021, so not too long ago, 18 months ago maybe. We were still middle of the pandemic, seemed like everyone had started using these apps like Miro or Mural or I think Fig Jam had just been released and The place for online collaboration was starting to just be the sort of the whiteboard, you know, abstractly like this 2D kind of surface that you could move around on and interact with people and co-create this type of surface. And the tools in that space were pretty mature, like again mural fig jam was new, but it was already, you know, built on good bones of FIMA itself. And so, As normally happens with like successful general products, like you start seeing different teams wanna carve off verticals for that, say, like, OK, cool, Mirro is great. Mirro is for everyone, Miro is for everything. What if it was just Mirro for project managers? What would that look like? Can we steal a billion dollars off of Canva? Can we, you know, take a little bit of that giant market from FIMA or something? The issue there is that all of these tools, pretty much anything. That wants to use that kind of canvas UI, it’s a tough engineering problem. And there’s like a ton of uh functionality maybe of like a canvas like that that is like, it’s almost like a text editor that it just has to be there in order for it to feel complete. And if it’s not complete, it’ll feel broken. But if it is complete, if it has those like table sticks features and all that, then congratulations, no one will notice because they expected them to be there from the beginning. And maybe you ran into some of this with Muse as well like. Selection should just work, like Undo reader should just work, the cloud stuff should just work. And some like really gnarly, like logic puzzles involved in these type of things that we take for granted in something like Mirro or fig jam. Yeah, like they’re they’re just gnarly problems. Never mind the whole like, how do I render this thing. So when I started saying like, look, this is something that you can use as like a starting point, where all those problems are gonna be solved. Now it’s just about picking like, what do you want to put on the canvas, how do you want these things to interact with each other. I think that story of giving someone like good open source starting place, that was like the compelling story. It’s just like the same with maybe like prose mirror or a code mirror. Text editors are super hard, no one wants to build one themselves. I mean, I don’t want to build a text editor myself ever. But I do want to make apps that include them, and I do want to do stuff with them, and if I can do that on open source work, then all the better. So, I think that’s where the validation started clicking in, or like pre-validation. I didn’t have an idea really, but I did notice that there was a demand for this kind of thing, because, yeah, it was becoming more of like what software looks like, especially around collaboration, like it looks like a canvas. 00:09:30 - Speaker 2: Fun little parallel story there from the Hiroki days, which is a very early version of Hiroki that was mid-2000s, 2007, 2008, had a text editor in it, but yeah, we had to implement that from scratch in the browser and you know, pretty quickly you exactly as you said, all these table stakes things you just expect to work, particularly in programming editors, you know, we had to implement it and that’s not the differentiated or wasn’t the differentiated part of the product at the time. But it wasn’t long after that that the AC editor, I believe it was, was kind of the first really solid open source in the browser code editor, and that seemed to unlock a kind of explosion of people seeing that. I mean, I know GitHub used it in the early days for some of their stuff, but lots of other projects did as well. Suddenly people saw, oh, there’s a really good code editor that covers that table stakes stuff. Now I can build this weird project idea that I had that I haven’t been doing because I don’t want to have to build a whole, you know, fully functional text editor first. That’s just too hard and isn’t the core of the idea. So maybe there’s, if your hypothesis that the canvas is a foundational type of some kind, as you said, how software is just starting to be, then maybe there’s a similar explosion that could be unlocked with the right canvas tool kits. 00:10:52 - Speaker 1: I hope so. I released this thing in November of 2021, so after, I think I started working on it full time in like July, so not too much time. It got pretty popular, the initial usage. 00:11:07 - Speaker 2: You talking about the open source or because I know, I guess I should describe that. 00:11:09 - Speaker 1: While I was developing this, I was posting about it on Twitter a lot. You’re gonna hear me say Twitter a lot, probably during this interview. 00:11:19 - Speaker 2: I think we could have done a build in public episode with you if we already did it with the maker of Canopio Club. Yes, so it’s a similar kind of concept which is showing your work in progress as you go and obviously it’s a very visual domain and yeah, people like that. They like those little bite sized pieces and they like to see the journey. 00:11:39 - Speaker 1: Yeah, I’d started thinking like, this was right when GitHub sponsors had come up, and I guess the media that I was consuming was largely like sponsor driven. Podcasts, YouTube channels, etc. And I was really interested to see if that kind of model could work for programming. Programming does not lend itself well to YouTube streams or videos, even like the educational stuff, I think it can work, but it’s not like a sponsor model that kills, it’s like a course model or something. 00:12:10 - Speaker 2: Yeah, from what I’ve seen that typically people who have programming YouTube channels, then you have an upsell into buy my course, so they put the more basic stuff online, you find it, you watch it, you get to the end and you like the teacher, quote unquote, and then you think, well, I want more, I want the intermediate level stuff, then you go buy their course that’s behind some paywall. 00:12:29 - Speaker 1: Yeah, which is great, and I’ve certainly bought, you know, courses and books as well, and especially if you have an education budget, you know, consider spreading that around, don’t let it go to waste. But I was kind of thinking about the type of content that I could post every day almost, or the or the type of content that required like a very low level of engagement with, like, much lower than by my course, and even like a level of engagement where just clicking like was like the correct. Appreciation for this type of content. You know, I’ve seen folks who are making like really amazing involved educational material, not just in programming, but in other stuff too, and it always feels bad where like all I can do is just click a little heart, you know, it’s like, oh man, like this is worth way more than that, kind of feels awkward. So anyway, I kind of made user content, educational content when I worked at a company called Framer. So that was all very involved as well, very kind of produced. Took a lot of time to make, and I didn’t want to do that anymore. So, the kind of the place where I settled in terms of like the kind of content that I would use to drive interest around Tealro before I had released it, like, while it was under development, was just like these eight second gifts. These gifts that maybe had like, you know, were at 150% speed, didn’t take very long to make at all, and certainly didn’t take very long to consume and just be done with, and, you know, just clicking that little like button was, what more could you do? Like, it was perfect. And so I was posting this a lot as I was working on Tealraw and at the same time, I had made the like TealDraw.com a kind of sponsorware. So the only way to access this was to be a GitHub sponsor. And there really wasn’t any like floor for that. You could give me a $1 and, you know, have full access. It wasn’t even like a $1 a month. It was just like, give me something and you can come in. And that worked pretty well. I got like a couple 100 sponsors, which certainly wasn’t enough for like a tech salary or anything like that. But it did show that people were interested in this and it was like a good thing to come back to as I was developing it. I was also a good motivator for making that content. 00:14:46 - Speaker 2: And to come back to that product manager style validation, here’s the next step. People parting with money any amount, the number doesn’t even matter that much, is just such a hugely higher bar and saying they like it, clicking a like button. Telling you they think it’s cool, even using it. Parting with your hard earned cash is just the ultimate measure of validation. So I don’t know if this was intentional, but it seemed you’re following the product management playbook kind of market discovery in this journey. 00:15:18 - Speaker 1: It was not very inte…

    Full show notes at the publisher

    https://museapp.com/podcast/transcripts/6-human-computer-interaction/ Oct 05, 2023
    Show notes

    Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: On the academic side, you’re very limited by your work has to fit in the box of like a peer reviewed quantifiable research paper and in the commercial world, it needs to be commercializable in the next, you know, probably a year or two, maybe, maybe 3, but all the good ideas don’t fit in one of those two boxes. 00:00:27 - Speaker 2: Hello and welcome to Meta Muse. We use the software for your iPad that helps you with ideation and problem solving. But this podcast isn’t about Muse the product, it’s about Muse the company, the small team behind it. I’m Adam Wiggins. I’m here today with my colleague, Mark McGranaghan. Mark, you reading anything good lately? 00:00:43 - Speaker 1: Yeah, just last night, I actually reread an ultra classic, you and your Research by Hamming, who’s a famous scientist, and it’s about how you build a really impactful research program over the course of your career, and I was inspired to reread it because it’s one of the chapters in the classic book, The Art and Science of Doing Engineering, which is about to be republished by Stripe Press. 00:01:05 - Speaker 2: Stripe Press is really on a tear these days. 00:01:09 - Speaker 1: Yeah, for sure, highly recommended. 00:01:10 - Speaker 2: And also perhaps relevant to our topic today, and I’m happy to say that our topic today was requested by a listener. So Fetta Sanchez wrote in to ask us, how do you get into the HCI slash interaction slash new gestures research field. So probably we need to start at the top there. Maybe you want to tell us what HCI is. 00:01:32 - Speaker 1: Sure, so HCI stands for human-computer interaction, and this is things like the way humans interface with computers, and also the way they use computers as a tool in their lives, how they get things done, how they learn. To use them, how they accomplish their goals, things like that. 00:01:48 - Speaker 2: And I did a couple of years of a computer science undergraduate degree that I did not finish. And during that time, I really remember everything in the curriculum was algorithms, databases, compilers, maybe some network type of things. And I only learned about HCI as a field a couple of years ago. And to me it was a bit of a revelation because this concept of How the user interacts with the computer and that being a whole field of study. Well, I was very excited about, but stood for me in very stark contrast to the System the algorithms oriented computer science that I sort of knew from my brief time in academia. 00:02:29 - Speaker 1: Yeah, likewise, it was pretty new to me, and it’s a whole huge world, you know, there’s conferences and papers and many professors who’ve dedicated their entire careers to it. 00:02:37 - Speaker 2: It was fun for me to dive in and learn about that world a little bit, and you and I were both part of this independent research lab called Inot Switch. Uh, and through that process, we began publishing and then made some connections with folks in this field, and then you and I went to a conference called Kai last year that I think really kind of opened the door for us there. Maybe one thing that would be worth doing is um categorizing here a little bit. There’s Human-computer interaction as a branch of computer science in the academic tradition, that is say mostly done in universities, sort of the the pure sciences. Then there’s corporate R&D which is more associated with for profit businesses, but actually it’s where a lot of the HCI innovations that are maybe the most famous, uh, we think of places like Bell Labs or Xerox PARC, maybe today, Microsoft Research. And then there’s a small but growing space of called them independent computer science labs, independent HCI researchers, of which I think we we had some contact with. How would you define the difference between those three categories? 00:03:39 - Speaker 1: Yeah, well, like you said, the academic side is grounded in these research universities, and this is often directed by a professor or graduate students, and there the values are really around evidence, rigor, review, publication and communication, and creating knowledge over time, which is a whole thing we should talk about. And then on the industrial side, it’s often more integrative because you need to consider. Not only the the pure HTI elements, but the business elements and the hardware constraints and the how easy the thing is to learn for the user and practice and things like that. And then on the indie side, this is a smaller domain, but that’s tends to be more experimental, free form. People can bring their own wild ideas to it and just try stuff. So it’s a nice injector of new ideas. 00:04:22 - Speaker 2: One way we can maybe make this concrete is to describe the path from let’s say the lab to commercial product. And I’ve I’ve struggled to find full stories on this in many cases, I think this is something that happens behind closed doors a little bit, even though science does have open publishing, the exact story of how something went from basic research or early um HCI research to a product that’s in the hands of end users is not well understood or well or written down anywhere. Um, I think the Xerox PARC case is one that has a lot of um, Fame and certainly in the tech circles that we run in, there’s there’s some books about it. There, they invented things like the modern GUI, uh, as well as what you see is what you get word processing, and was really a pretty special place. And notably there was a branch of Xerox, the copier company, and they were looking for innovations. I think their theme was the Office of the Future. And they were looking for innovations around that and, and clearly, you know, this is the 1970s, they knew that would have to do with computers, personal computing was, didn’t really exist yet or was, you know, still just an emerging idea. So that’s one famous example. Uh, maybe more recently, you have something like Microsoft Research, and I think, you know, I don’t 100% know what the path is for some, you know, for example, interesting innovations that emerged from Microsoft, to what degree were those laboratory projects versus some other path. Uh, one that I find quite interesting is what we now on the Apple platform, we talk about face ID on the Apple platform we use face ID rather. And that uses stereoscopic cameras and infrared, and infrared camera, which gives you depth sensing, right? So this is why you can’t fool your iPad into unlocking by holding up a picture of your face, because it can actually sense the the shape of it. And that idea was first in Windows Hello, which sort of was the Microsoft implementation of facial recognition. And that in turn, the technology there, I think came from the Microsoft Kinect, which is actually a gaming. Device, um, and I’ve tried to like dig into the history on this. I don’t know if it came out of a Microsoft lab. I think it may have come out of some other independent place. So you often have these very winding paths where a promising technology like stereoscopic cameras emerges, but you’re still trying to figure out the application of it. And it’s actually quite a long distance between when these early researchers are doing the work, and it’s in the hands of consumers as a usable product. 00:07:00 - Speaker 1: Yeah, and I think honestly, that’s the best case that you have this long winding path, but it does eventually find its way into commercialization. I think one of the ideas we had originally behind the lab was these two domains are kind of spinning in circles. So it’s a lot of good ideas from the academic world that are getting stuck or don’t have the appropriate context from the commercial world, so they’re not transferring over. And on the flip side, the commercial world isn’t tapping into the academic tradition and the way that it should be. So you have a lot of like the, the Microsoft research and the, the Googles and so on, they do a lot of internal research. 00:07:36 - Speaker 1: Google X maybe is their, their internal lab, or they have a bunch of computer science just doing research on, you know, search and stuff like that, uh, some of which gets thrown out as papers and some of which doesn’t, but the kind of the classic path from uh academic labs through commercialization I hypothesize is actually weaker than it, it should be or could be and perhaps was in the, in the past. And one of our ideas with the lab was to help bridge that gap with something that was kind of in between with the with the so-called industrial research lab. 00:08:01 - Speaker 2: Actually, Google search is another case. It’s not an HCI thing, it’s more of an algorithms thing, but the founders of Google, they were doing academic research work at Stanford, if I’m not mistaken, came up with this page rank algorithm, which was a science paper published like any other. At some point, I’m not super knowledgeable about the story, but at some point they decided to turn that into a working prototype. They set up this search engine, they found it worked way better than anything else out there, and they realized they could spin that out into a commercial. Entity. And so those two individuals took it from that early lab work all the way through to a commercially viable product, but it takes pretty extraordinary individuals and probably extraordinary circumstances or at least serendipitous circumstances for that to happen. And so what you’re alluding to there with the the gap between The academic researchers who are exploring wild new ways we can interact with computers and commercial companies that can bring these to people in their everyday lives. Um, that’s, you know, in the Google case, these, these extraordinary individuals took it across that threshold, but what can we do to create more movement there? 00:09:12 - Speaker 1: Yeah, exactly. I think We’ll see as we get more into HCI specifically here, that the HCI domain isn’t as obviously susceptible to the academic tactics as other domains, so things like algorithms are very quantifiable, they’re very repeatable, they’re very discreet, and those are things that work well in the the traditional academic model of of measurement and confidence intervals and so on, whereas HCI is often much more multi-dimensional, maybe case based, maybe hard to quantify. 00:09:39 - Speaker 2: Yeah, for sure, I think how it feels is like a huge dimension of making interfaces, but that is something that is very hard for science to evaluate. Uh, it’s something that is more of a taste or judgment call, but then science is and should be about rigor and the academic tradition and fitting into these and and sometimes I think that does mean from what I’ve seen of the HCI field. Sometimes I read these papers where, I don’t know, one example was, um, I think it was also a Microsoft research project. They did an interesting thing where they rigged up some projectors where you could essentially put windows from your computer, uh, individual windows, whether it’s like a document app or something else up on the wall and they had projectors, so basically all the walls. We were 100% turned into these screens, but it was collaborative. So I could put up one window, and it’s not like, while I’m, you know, screen sharing, no one else can, someone else could put up their window and you had this shared space that was very spatial and that sort of thing. This sort of stuff was, was, you know, part of what was inspiring us and we were thinking about the new opportunity. But notably there. It’s a really interesting prototype, you can look at their video and look at what they’ve done and read the paper and think about how this might be applied in the real world, but they have to, it’s not enough to just build the thing and say, hey, we liked it or we didn’t like it, then you need to go and do some kind of quantifiable test. And they did a usability test or user test, which is as near as I could tell was just grabbing 7 random people that happened to be walking by in the office and having them use it for 2 minutes and then, you know, giving them a little survey and writing it down. And it seems like, OK, well, I guess that makes it science because you’re measuring a thing. But that’s not where we make great breakthrough new interfaces, but it’s very difficult because you just leave it to, well, did you like the thing you built? People always are attached to the things they built. They always like the thing they built. How do we, how do we measure that? That’s probably an unsolved problem a little bit for the academic side. 00:11:34 - Speaker 1: Yeah, I think so. Thinking about things that do work well in this space, reflecting on my own journey. I started not so much with the HCI as like proposing a certain windowing system or a specific gesture model. I started more on the fundamental side. So we think about human computer interaction, you need to understand the human body, like biomechanics and things like that. You need to understand the human mind, like cognition, and then you need to understand the computer science fundamentals, things like the graphics pipeline. So I found it very useful to go and study those fundamentals, both within. And outside the HCI literature, and there again, that area is much more susceptible to traditional scientific methods, so it’s very good information. um, and then you really understand that the fundamentals, the ground truth. 00:12:21 - Speaker 2: You know, the point about humans and computers are equal participants in this. And I think there is a tendency for computer people to focus on the computer. Maybe one thing that HCI tries to do, or at least um some of the HCI teams that I’ve had chance to interact with, including this team out of UCSD that we met at this conference we went to, they try to have maybe a cognitive science person or behavioral sciences person on the team, and they are concerned more with that, how does the human mind work, how does our attention work? How does our how do our bodies work, and then, but you also have to connect that. Together with what’s possible with the technology, both in the moment and of course, also in the future where we think technology might go. And I think, you know, for example, VR AR stuff is maybe in some ways a hot or buzzy space or maybe was, maybe that’s died down a little bit. But if you go read a lot of research about that, you see that for example, one of the biggest problems with that is just a simple case of, OK, if you got these controllers, you’re waving around in the air as the main way you interact with it, your arms just get tired. And it’s, it’s like they, they’ve measured this, right? They, they put people in situations where they’re using these kinds of controllers for long lasting tasks and they see that after an hour, you got to take a rest and they’re they’re, they’ve tried lots of different things to try to make that to be able to let you do a full work day the way you would at a standard desktop computer or whatever, and they haven’t found a solution. And so if you’re coming in, if you’re a commercial company that’s coming in and wants to do something with this space, you probably want to read that literature and keep those, uh, keep that challenge, that unsolved problem in mind. Yeah, one place to fill in more of the picture on the academic side, for me, the big eye opener was going to, uh, the biggest conference in the space, which is Kai last year, you and I kind of spontaneously both decided to go. This is when we were still within the lab, but thinking about the use. Idea and that was a really great experience because we both got to meet a lot of the professors and researchers that were working in this space, got to see how many people were there. I, I don’t know, it was 2000, 3000 people, there’s hundreds of papers submitted, many, many tra…

    Full show notes at the publisher

    Previous 1 12 13 14 15 16 17 Next

    Related Podcasts

    Reply All

    1

    Reply All Games & Hobbies
    Inside VR & AR

    2

    Inside VR & AR Gadgets
    Note to Self

    3

    Note to Self News
    BrainStuff

    4

    BrainStuff Natural Sciences
    This Week in Tech (Audio)

    5

    This Week in Tech (Audio) News
    Hands-On Tech (Audio)

    6

    Hands-On Tech (Audio) Technology
    footer-logo

    Contact Us

    Toll Free: 844-670-7747

    Links

    • Home
    • Top Charts
    • Networks
    • Apps
    • Independents Podcasts
    • Podcast Advertising
    • Podcast News
    • Contact Us
    • About Us
    • Analytics & Insights

    Stay Connected

      Privacy, Terms of Use & Our Code of Ethics Protecting Content Creators Copyrights