Metamuse

Metamuse

By Adam Wiggins, Mark McGranaghanTechnology
Download on the App Store

Metamuse episodes

  • 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 pointing out or
    asking for new ways to say select things or align things and those
    things are not the top most people’s minds, but also because we want to
    make the editor a place that’s perhaps more agnostic, right, where we
    don’t want to push towards one way. Necessarily of working or
    organizing work or you don’t have to account so much for like, you
    know, very specific ways of working, but more have a place where we
    really optimize for directness, we have experience for efficiency and
    most of all for flexibility. So we want to have like a wide variety of
    things that you can do and try to think, you know, can most people make
    use of this? And so in that way, try to design a tool, you know, or set
    of tools or actions that’s for everyone.

    00:16:21 - Speaker 2: Yeah, that makes sense. Now another trade-off to

    think about is these feature requests and prioritizing your work just
    based on sort of the popularity of what it is that people want next, but
    then there’s what I might call vision or new concepts and ideas. How do
    you balance which of those you work on?

    00:16:41 - Speaker 1: That’s absolutely true, and we do try to balance

    this and we don’t have properly, you know, a formula other than do it
    by we’re listening to and try to, you know, not to veer towards one
    side fully or the other, as you say, which is I think a very good
    approach.

    I think on one hand, we do like know what are the requests or more like

    people’s pain points, right, because we always want to look underneath
    the request and see what the pain points are.

    And so we try to mix those a bit with things that introduce novel ideas

    and these can be Improving on problems or pain points that people might
    have gotten accustomed to, right? So I think this is quite specific
    perhaps to graphical editors because these are tools that have been
    around forever. Photoshop and Illustrator are very old tools and their
    concepts still carry over quite a lot, even though Sketch was this
    category defining tool that’s introduced a new way of working compared
    to the Adobe Photoshop or Illustrator.

    Many of these conflicts carry over, right, and they’ve been around us

    for long.

    And at the same time, I think people are highly adaptable, right? People

    get used to a certain level of annoying or even people start working in
    the industry and some things are just the way they’ve always been,
    right? And Another way why we might do this introduce novel ideas is to
    prepare the way for the future, right, so it can be strange to see an
    update and it’s like, well, why would they do this? And often, you
    know, this is to prepare for something that’s going to come later.

    We’re preparing the way we’re addressing something, perhaps, perhaps

    minor but become much more evident in the future.

    And so we have worked on a couple of projects recently that are in these

    two camps.

    On one hand, here’s our Pain points that the people have or parts of

    the app that are not very good compared to other tools and at the same
    time, we worked on things like, hey, here’s something’s always been
    done a certain way, but we had an idea.

    About, you know, improving this a little bit and so we try to either

    work on those at the same time or balance and I think this is something
    with the rich traditional sketch, right? We’ve mentioned a couple of
    times how it’s defined much of the category that it still sits in.

    And it did so, I think by doing both things, both of these things for,

    hey, here’s some things that we should be doing much better, and hey,
    here’s things that persist to this day because there are problems that
    people want and it’s kind of, you know, in retrospect obviously how to
    solve them.

    00:19:24 - Speaker 2: Now can you give us some examples of something

    that might go in the more direct response to a feature request versus
    something that nobody really asked for but maybe sets up a foundation
    for the future?

    00:19:35 - Speaker 1: Yeah, so one project that we worked on, which is

    on the face of it, very boring, very obvious, was a much improved corner
    radius controls.

    So, Up until then it’s sketch, if you want to adjust the corner radius

    on a rectangle, which is the most common scenario, you would just go
    over to the inspector and you just like the slider, you control for
    them, or you have one input that represents all four corners. So you
    can’t do it on the canvas and also you want the corners not to be the
    same. It’s kind of awkward to do. Like you expect to use to see my
    columns in the canvas, you have to go into vector editing mode just for
    this, which is so common. And so it wasn’t great, obviously it wasn’t
    great. And at the same time, we were pretty late to the party, right?
    Every tool out there has this and they all solve it in a pretty similar
    way. And saying this, I think this is a case of like we did respond to a
    pain point, but we also like looked at what’s out there and we’re
    like, OK, I think that there’s a little step above that we can go
    towards.

    00:20:38 - Speaker 2: Yeah, that’s true that a lot of times feature

    requests come in the context not just of I have a problem and I need a
    solution.

    But that people do use lots of tools. That’s the nature of the world we

    live in now, that you can easily sample a lot of different ones.

    Some people enjoy doing that just generally, but also just that you’re

    looking for the right things to fit your workflow and then as you’re
    exposed to the way other tools do things, you think, oh this is great.
    I’d like to have it in this tool over here, so certainly. Quite a lot
    of the feature requests we get from you do come from, for example, other
    tools for thought, particularly the more text-based ones, as well as
    design tools, as well as whiteboarding apps and so on, and someone likes
    a feature someplace else, and then they come and say, you know, I’d
    like to have this in you, so what else is out there matters a lot.

    00:21:24 - Speaker 1: Absolutely, and I think in a project like this,

    this is actually great, right? Having all of these other tools in the
    same space as yours affords you a way to just go and try it out and see
    what you like about it, see what it lacks, right? It would be so much
    more trouble if you actually had to go and build all of these other
    ways. and then look for yourself, you can just go and try it out. And
    even if it’s in a tool that’s not exactly, you know, as you said, in
    case of music, it’s maybe the ideas that come from more text-based
    tools, there can be something lurking beneath like I want this exact
    feature by name exactly like this. There’s something lurking in there
    and what is the needs that made the person ask for this. I think that’s
    extremely valuable.

    00:22:09 - Speaker 2: A small side note on corner radius is that I think

    of that as one of the features when I did use sketch the first time that
    struck me as, ah, this is a very different interface paradigm because
    when I would try to do rounding of corners, which is something designers
    like to do quite a lot, it turns out, particularly UI designers in
    Photoshop or other tools, they are often It wasn’t a very direct way to
    do it. It was more like a multi-step process of refining a selection or
    maybe there’s a plugin or something.

    And so having that just kind of built right in as a core idea, I think

    was, I don’t know if sketch was the first to do it, but it was the
    first place I encountered it, and it seemed to imply a kind of a more
    modern paradigm.

    So now if others have picked. That up and taking it further or given

    more flexibility. Now you’re getting the requests from your users, Hey,
    can you basically, you know, advance to sort of catch up to the state of
    the art but in a way this is the way that lots of competition in an
    industry, we all make each other better because someone picks up your
    ideas, they run with it, maybe they improve it a little bit, and then
    you in some ways need to follow on from that.

    00:23:15 - Speaker 1: Totally, it’s a great perspective and I

    absolutely agree with the idea that we all make each other better. And I
    think in that tradition with these projects, we of course came pretty
    early to the party in terms of say direct manipulation here, and it was
    easy to go like, oh, this is whole problem, right? Like let’s just do
    what everyone else does. After all, I don’t see people complaining
    about it, do I? Which is, you know, in this case, you go to the canvas,
    you dry a control to change all the corners, maybe you will hold the key
    to just change one, and the inspector has all four corners like little
    inputs in a row with little labels, and that’s just the way it is, you
    know, ship it. But I mean, there’s a long standing suggest that’s
    catch up. Looking, you know, what could this really be and what are you
    really trying to do? Like, in this case, like, what if you only want to
    do 2 or 3 corners to be around? What if you zoomed all the way in,
    right? So, of course, we saw the needs because, you know, people ask us
    for it and because we could see very well that hey, all these tools are
    doing it better, but we didn’t want to settle for parity, right? And at
    the same time, in terms of like the approach, the design. In this and
    any other project, we looked at it and it’s like, OK, how can we
    achieve what we want to achieve by making the most out of our existing
    UI? Maybe, maybe we take it like a little step further here or there,
    but in a way, let’s say we build as little UI as possible, fewer
    labels, and particularly like no, you know. Single purpose solutions,
    like in the kitchen tool where no unit taskers, right? How can we solve
    this with all the tools and pieces that we have, maybe we honed them a
    little bit, but how can we, you know, combine that puzzle to solve this
    problem?

    00:25:01 - Speaker 2: Nice. And then when you think about examples of

    something that lays a foundation, what would be an example on that
    front?

    00:25:08 - Speaker 1: Yeah, so, another project that we worked on is a

    project called Foresight. So what foresight is, is a way to preview the
    outcome of actions that you take that are not direct manipulation before
    you do them or as you do them.

    To make this more concrete, so far we’ve applied to alignment control,

    so when you light layers to the left or to the bottom, or when you enter
    new values for layers with height, or X or Y positions.

    So when you do that, or as you’re doing that, or hovering the control

    or typing a new value, we will draw a little projection of where your
    layer will end up or which shape it will have. So this brings the
    Immediate feedback loop of direct manipulation to operations that are
    more quick and precise, but are not direct manipulation. I will bring
    this beneficial aspect of one way of interacting with your design to the
    other way of interacting with design.

    And this is something that we hadn’t seen a lot out there, but it turns

    out when you use it, it becomes immediately obvious exactly what it’s
    doing and exactly why it’s doing that. And so we saw here both a way to
    improve these operations without having to, oh, it’s not exactly what I
    wanted and do. But also a way to compare, like, hey, if I do this, by
    the way, here’s how it’s going to be and I can see still in my eyes
    how it is right now. And at the same time, we want to introduce more
    powerful operators for these input values, we want to introduce more
    flexible and more powerful alignment controls. We could say, hey, you
    know, if we make this more powerful, but also more complex, it will be
    good to have that immediate feedback if I’m doing the right thing, if
    I’m using the right operator, if I’m using the right modifier key, and
    so, shortening that feedback loop through foresight brings you that much
    closer to that.

    00:27:13 - Speaker 2: Yeah, one of the things I like about foresight is

    that so much of design work is kind of like when you go to the eye
    doctor and they do the, what do you like better, A or B? OK, now how
    about C or D, and you’re sort of doing that continuously of trying
    different small ideas to iterate your way towards something that
    hopefully is the best one and obviously a sort of folk practice you
    might say, or a method you can do that is to do the action, then press
    undo, then do.

    Next action, then press undo and maybe even going back and forth. But

    here, for example, if you just wanted to try out a couple of different
    alignments, you basically just move your mouse back and forth across
    those buttons and you get to get a sense of what those are going to be
    like without that sort of undue step and that gives you a faster
    feedback loop and that in turn lets you get to your desired end state in
    a quicker and smoother way.

    00:28:07 - Speaker 3: Yeah, it’s tough to come up with general rules

    for product design. It’s often case by case, but there are a small
    handful of things that users are gonna want to do in every tool, and
    this is one of them, the sort of like fast feedback slash compare, I
    mean they’re kind of two sides of the same coin. So it’s nice to see
    that you have such a strong support for that and sketch.

    00:28:27 - Speaker 1: And we very much hope to bring that over to more

    things where it makes sense.

    We see this really as a system for previewing the outcome of these

    actions.

    I think most of these projects here, I think are on foresight and on

    corner radius, you know, in the end, they Double down on, you know,
    aspects of the application, both in terms of interaction, both in terms
    of UI, both in terms of foundational concepts and primitives, where we
    just took all the pieces that we had and we dialed them up a little bit,
    right? And so, For example, in the case of foresight, we took our
    overlay system that you had for hovering over layers to get feedback of
    what you’re gonna select and we brought it over to outcomes of actions
    and different types of interactions with the keyboard and mouse-based.

    And then corner radius, for example, we took, you know, pieces that we

    had like our heads up display system that gives you Back next to your
    mouse or things like our handles, you know, little dragon resigns
    handles or in this case corner with these handles, and we, you know, not
    to get into too much detail now can easily respond to a keyboard
    modifier so they can be contextual to the type of shape or properties of
    the shape.

    And so now we have taken the pieces that we had. And we enrich them

    slightly and now next time around that we reach for these pieces, now
    they can do so much more and we have, you know, made our sort of
    multitaskers even more powerful than they were before and while still
    fitting in the language of the app both in terms of interaction and UI.

    00:30:13 - Speaker 2: Yeah, that makes sense. And the small sharp tools,

    you know, a set of primitives that are very flexible and can be combined
    in different ways rather than making a million individual concepts that
    don’t really fit together is, well, something Mark and I are big fans
    of kind of from the Unix philosophy and so forth. You’ve mentioned a
    few different ways that you repurpose these primitives and use them in
    different contexts. Do you have another example of using primitives and
    enhancing them in this way and applying them in new scenarios?

    00:30:43 - Speaker 1: I do. We are working on something new, which are

    artboard templates, so to contextualize a little bit in sketch and the
    tools when you go to insert an art board on your canvas. You have a list
    of presets, right? And these are things like iPhone 13, medium tablets,
    or even like, you know, slide deck or something like this, which are
    really just uh within the height for a certain artboard.

    And we’ve had this in sketch for a long time and we update them when it

    makes sense and people can create their custom ones, but they stay local
    to their application, which is not very, you know, helpful for teams.
    And so, We looked at how can we make this way more flexible, right? And
    so we just reached towards our existing art boards. So the solution
    there was we taken art boards and You know, we have the check box and
    you say this art board is now a template. And now, by virtue of this, if
    that art board is in a library document that’s distributed to all your
    team, now when you go to insert art board, we surface all of those
    artboard templates that are in all the libraries you have in your
    application, so they can be distributed in teams. So By doing that, we
    solve the problem, hey, how do we make this easier for people and for
    teams to create and distribute their set of templates that they work
    with, but by virtue of doing this with existing art boards and now not
    with this like, you know, single purpose concept that we currently, you
    know, still have of artboard presets, along with that we brought over
    everything that our boards already do. So, you know, Presets have been
    so far empty, but they don’t need to be anymore, right? You can have
    them empty, but you can have them with things, you can have them ready
    for, you know, the home screen of your app or for like a wire framing
    template, and with that came over things like, well, you can have grids
    and rulers and layout. Grids set to the art board that come over. So by
    enhancing this, we had effectively, you know, big air quotes here for
    free. Everything that was good around art ports already by virtue of
    like reaching to them, bringing over to other existing concepts that we
    have like library distribution. So in turn, this means that when we work
    on featured enhanced art boards, we enhancing art boards and templates
    at once. So our team recently. Added support for locking the proportions
    of an art board. Well, now you can do this for individually art boards,
    but for the preset. So for example, our preset for slide decks or for
    photography aspect ratios will come with these, but you can also do
    them, you know, on just art boards that are not templates. And so in
    this process, eliminated this single purpose concept of a preset that
    had quite a few limitations. And by reaching to an existing primitive of
    the application that’s so foundational to sketch, we have improved the
    primitive in all of its use cases and so in a way it has this
    multiplying effect, right? Or whereby improving the primitive, you get
    potential in every way in use case where this primitive is represented.

    00:33:59 - Speaker 2: Yeah, I love that.

    I think the obvious thing to do if you’re tasked with designing a piece

    of a product, particularly maybe if you’re not looking at the holistic
    capabilities and instead just at what you and your team has to do is you
    say, OK, we need to make templates.

    Great, we’ll make a template editor. First we’ll start with width and

    height, and then maybe, oh, people want to change the background, color
    will do that. Oh, now someone says, you know, this is for an iPhone, can
    you Fall to an iPhone frame, we’ll add that and pretty soon you’re
    making a duplicate but much worse version of the existing ability to
    edit art boards in the main product. And so if you are thinking
    holistically in that way and you can find good ways to repurpose these
    in this way, that’s very powerful in building products.

    00:34:41 - Speaker 3: This also reminds me of the closure, closure of

    the programming language, the closure philosophy of having as many
    operations as possible on few data types.

    Typical way, especially in object oriented programming languages, is

    that you have, you know, a class for animals and a class for books, you
    know, a class for all the things to your domain, then you write specific
    methods and you do those, whereas in closure.

    The idea is that you only have a small number of very generic data types

    like a map and a list and a set and so on, and then you just pile on
    functions all the way from the core library all the way up to your own
    application code against those very generic types, and it’s kind of
    tough to get started, but once you get in that habit, it keeps
    compounding because you’re adding more and more capabilities to the
    small number of data types.

    00:35:28 - Speaker 2: Another way to make, let’s say very zoomed out

    product decisions or perhaps product decisions that are based on zoom.
    criteria might be something like KPIs, that’s key performance
    indicators or OKRs, that’s a system that I think is best known for its
    relation with Google where it’s the sort of the idea that you set goals
    and you attach metrics to that, and then there’s usually some kind of
    cascade that goes down through the company. But maybe there’s also
    decisions based on just company values or brand values. What are some
    examples of decision making at sketch that is kind of in that sort of
    category?

    00:36:05 - Speaker 1: So the editor is not a place where this could

    creep in, in theory, but in features of the products or even marketing
    websites or business oriented or closer to the business, this could
    certainly be the fact.

    So at the end of the day, sketch is a business, obviously, and we wanted

    to keep it a sustainable, healthy business that’s very important to the
    company and its culture, but we could look at an example that was even
    from back from my time on the website where we were redesigning the
    pricing page and So you got your very standard pricing page, you got a
    standard plan, you got your business plan, and you got your monthly and
    yearly price. So, when we came to this, when we looked at our price,
    which is like $9 per month, when billed monthly or $99 per year billed
    yearly. We looked at this and we felt pretty strongly that, hey, you
    know, you pay party here, that’s the number on the bill, it should say
    99, right? It shouldn’t say 8.25 because that’s the divided by 12
    price. And it wasn’t really much of a question really. It was just like
    it’s the right thing to do, it’s The transparent thing for people,
    that’s the number that you see on the bill. This is, I feel very
    strongly, personally, this is the way it should be everywhere, right?
    Doing anything less, I understand it’s become a bit of an industry
    standard, definitely in the world, but it feels, you know, I’m not
    gonna say proposedly, but it does feel misleading. And so this is where,
    you know, if you were completely like KPI growth driven. The call would
    have been made. Now we’re gonna go with a lower number, right, cause
    that makes us look better. But, you know, all the way from the top it’s
    like, no, let’s not do this, right? Like, let’s put the number that
    people really do pay because it’s just the right thing to do.

    00:37:57 - Speaker 2: Yeah, that sounds to me like almost a moral

    decision, but obviously it fits with company values, and you call it an
    obvious decision, but it isn’t or apparently isn’t because it is very
    common that pricing pages show you a price per month and in much smaller
    font and maybe lighter color.

    You know this is billed annually, and I think this does come to, yeah,

    the KPI driven and I like KPIs we use them on the muse team to help just
    drive our work and make sure we keep focus on what’s important to us,
    but it does lead to this long thread of, OK, we have all these numbers
    we’re trying to optimize for the person that’s working on the pricing
    page. They may not be sitting there and saying, Hey, hey, hey, I’m
    going to trick users with a dark. Pattern they’re sitting there and
    thinking my boss has tasked me with making this one particular number go
    up by 5% next month and I’ve tested a few different ways to do that and
    it turns out that one way to do that is to show the lower numbers, you
    know, it’s not a lie, it’s just a little bit misleading and it helps
    me accomplish that. It’s that accumulation of very small decisions
    driven completely by growth and KPIs that lead you to maybe an overall
    product and even industry, I would argue a technology industry that
    people are starting to sort of ask questions about like are these folks
    really the good guys and sometimes I think that’s overblown, but I see
    that thread that takes you all the way from, you know, very simple
    decision like how to show the monthly or yearly price all the way to,
    you know, big tech is the bad guy.

    00:39:31 - Speaker 1: You’re right, this is about a system of

    incentives that the company has put in place and that is more often than
    not, yeah, not down to one individual decision, right, but about the
    path that you put the company and the organization on.

    You are on this track and with this track comes a way of making

    decisions and a way of defining priorities that follow from like a
    fundamental and often irreversible decision about, you know, what type
    of business do you want to run.

    And what matters, at which pace do you want to go, how much control do

    you want to give, how much control do you want to keep, all these
    decisions and then like it is a very big domino effect that then comes
    down to effect, possibly what appeared to be very, very small decisions.

    00:40:19 - Speaker 2: Well, maybe that’s a good moment to transition to

    talking a little bit about sketch, the company. I was really fascinated
    to ask you a little bit about this, and particularly your perspective as
    a relative newcomer, because it’s a company that I think we at Muse
    take as a bit of a role model. We have this kind of small giants concept
    of a company that does want to have a big impact but is not necessarily.
    maximizing for growth at all costs is about making a statement as well
    as making a business that can earn its keep, and I think sketch was kind
    of always in this, I don’t know if you call it like in the bootstrap
    quite thing, but basically just started selling to customers and Built a
    business based on that, and I thought it was really interesting that you
    joined right after they did a Series A venture raise a few years back,
    and I remember even seeing that in the news and kind of thinking, huh,
    that’s sort of funny because you know I had them slotted in my mind as
    sort of maybe anti-VC and that they didn’t need it. So tell me about
    joining the company and how you perceived what it was like then and how
    it is now.

    00:41:23 - Speaker 1: Yeah, so to go a little bit back in history, just

    for contextualizing the audience, sketch has been around the in internet
    years, I’d say a very long time. So in 2010, there’s like one
    programmer founder, one designer founder, and then, you know, we’ll go
    to 2014, that’s when version 3.0 sketch comes in, you know, arguably
    like the single biggest version number possibly in the history of the
    company. Only 10 people there at the company 4 years after its
    inception, 4 years later on, the web app is 2 years old already. This
    was only 4 years ago, right? So this, we’re getting much closer to our
    current day.

    Now in 2022, we’re slightly over 200 people and as you mentioned, in

    between there in 2019, this was before I joined, the company took a
    Series A investment round. And so, I will Like, very honestly say that I
    wasn’t particularly thrilled about this, right? Coming in and I was
    like, you know, same questions here, huh, right, like, hm, didn’t peg
    the company for a company that wanted to do this, and because we’ve
    seen over and over what happens in this scenario, right, this very
    common playbook and The tech industry, where you do this, and now you
    are on a particular track, right? In your episode about com companies,
    Mark mentioned how like, you know, once you get into that rat race, like
    now we have 5 or 6 decisions that you make over 10 years. Things can
    vary, but you’re very much on like a quite fixed track. But I think
    there’s a couple of things that are quite specific to sketch in the way
    and why this was done. Which definitely assuaged my fears when I joined,
    you know, so shortly after that. One is that, of course, this investment
    round comes at almost 10 years of a sustainable, profitable business. So
    it’s a very different circumstance to be in as someone that negotiates
    that, then why you do this?

    00:43:25 - Speaker 2: And I’ll note just briefly that some other

    companies have followed a similar path.

    GitHub is one that comes to mind where they started charging for their

    product and they were pretty scrappy. Small team and they managed to
    make it to some kind of ramen profitability pretty early on, but then
    later they had the opportunity to take venture money to sort of go
    bigger and you can argue whether or not that was the right decision for
    them, but I think it is a very different story to start with the company
    being on that VC train and the assumption that you can get to a certain
    level of size that will justify that investment and if you don’t
    fulfill those. Assumptions to get to that next funding round, you’re
    done, you’re out of business. You get to a place of some kind of being
    customer funded, even in not completely but in majority, that gives you
    a foundation for OK, now we can add some kind of investment money,
    including venture money on top to grow bigger or reach further or go to
    a bigger audience. We don’t need that to live. We want it to be able to
    reach a wider audience.

    00:44:28 - Speaker 1: This ties back to like how the company was

    started, right? So it’s one programmer, one designer that, you know,
    don’t necessarily sit around like, yeah, let’s start a business and
    seek for money or whatever. They look around and they see the people
    that they know in the industry using tools that are not quite right for
    this very new fields of digital design.

    And that’s what they start by doing, right? Like it’s the focus then

    and now throughout was the same.

    And so, You know, the founder’s still involved day to day and the

    majority control and the focus is still like, you know, let’s improve
    the product, let’s do it sustainably and let’s sell it at a fair
    price, like we always have, you know, there’s no free plan except for
    educational institutions that is a 30 day trial, so you know, you can
    get your feet in the water, see if it’s right for you.

    And so, you know, While this changed, like, of course, the size of the

    company has changed, the structure in the company has changed, we have a
    much more powerful web app. The focus has been pretty much the same and
    it’s like many years ago, it still is the point right now it’s like we
    don’t really want to go anywhere, right? This is a very, very, very
    long marathon that we keep on doing and I think this. Different
    perspective on longevity and growth and what does it mean to be
    successful that’s different than most of our peers, I think is
    something like really, really important and to the company and something
    that possibly doesn’t transpire all that much to the outside world.

    00:46:01 - Speaker 2: Yeah, a lot of themes there that are familiar,

    certainly to the com companies that you referenced there, but also for
    us on the Muse team here, which is Yeah, a sense of sustainability and a
    sense of an even pace and a little bit longer term thinking and
    contrasting that against the rocket ship is often the terminology
    that’s used for a lot of startups and it’s all about get as big as you
    can as fast as you can and then either go bust or get the acquisition or
    go to IPO and I think that’s also tied with a lot of the what I would
    call like winner take all or almost conquering the market style, almost
    like war.

    Metaphors for kind of a capitalistic perspective, which you don’t get

    me wrong, I think capitalism is great, but there is this kind of extreme
    version of it and then that in turn can be tied to a kind of hype
    machine, you know, we’re changing the whatever, we’re building the
    future of whatever, changing the world, that whole routine versus, hey,
    we just want to make a good product, sell it for a fair price, be proud
    of what we’re making and sleep well at night knowing that we’ve done a
    good job serving our customers.

    00:47:04 - Speaker 1: Yeah, you’re absolutely right, and I very much

    agree with that perspective. In this day that there’s like so many
    options, which is what a place to be really as a designer. People can
    get pretty tribal about it and there’s this silly win-lose narrative,
    right? And I and I think we as sketch. are profoundly uninterested in
    the narrative, right? So, you know, the sketch had for a while there
    when it proved the markets in the Adobe dominated world, sketch it like
    more of the pie or a bigger share of the pie to itself, right? And
    people see that, you know, there’s a lot more tools and companies
    sharing the pie. That doesn’t mean that we have less pie, right?
    There’s a lot of designers out there and design got its seat at the
    table and now the pie is getting bigger all the time and there’s space
    for a lot of tools. You know, look at a much more mature markets, you
    know, things like project management, people aren’t saying like, oh, a
    son of one that’s it done, right? There’s a mature market with key
    players being healthy and they can thrive and they can thrive because
    there’s more than one reason to choose a product and even companies
    that build like really close and tight ecosystems. Like, you know,
    interchangeable lenses cameras where it’s like you buy into a camera,
    you buy into a system really, and it’s kind of hard to leave, like that
    market is as healthy as it’s ever been, right? There’s definitely like
    at least in the digital camera market. So we do not yet subscribe to the
    narrative, right? Like now it’s the goal was to do, as you said, it’s
    a product that we’re proud of, right? It’s kind of paraphrasing a
    little bit. It’s not like making software to make money, is, you know,
    having a healthy business to allow us to keep on doing software, right?
    So, and in a way, like it’s kind of interesting that I think we’ve
    come full circle. I mean, we like sketch. I wasn’t there in the
    beginning, where it’s part of the foundational history of sketch of
    like facing this enormous monopole. 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. And so we
    come to a full circle where it’s like in the Key tools that are left
    because this market sort of matures a little bit, we come back to being
    the small one again, which I find is quite interesting, right? Like even
    at 200 people, which is, wow, so many, right? Like I was person 50, I
    feel, wow, it was so many, and when I joined people like, wow, 50, I
    remember when we were 10. And so it is a lot for us. I think we could
    still fit that idea of like the small giant, it’s just that the scale
    of the market and the industry changed so much around us, right, like
    the seat at the table got really big and now companies get like to our
    size when they’re like 3 years old. I think people don’t realize how
    fast like a different path like the VC rat race makes you go and so. I
    find it kind of interesting that we’re back to the idea of like having
    still an underdog fierceness and pride in the team, like, hey, there’s
    a lot of us, but we’re still, you know, having to do a lot with a lot
    less than other products, you know, more directly near us in the market.
    And at the same time, that’s a great feeling to stay through, through
    time like to these principles and You know, if we’re a bit smaller and
    we can’t match 1 to 1 what other products are doing, you know, that’s
    OK with us, like, if our slice is smaller, it’s enough for us and
    we’re proud of what it is and as you said, we sleep well at night, I
    think that’s really enough and that’s, I think success.

    00:51:14 - Speaker 2: I think the pie getting bigger, which includes not

    only design having more seats at the table, having more respect
    industrywide, but also I think you mentioned this earlier and talking
    about other teams, for example, the web viewer for Sketch, and maybe
    that’s intended, for example, engineers that want to take a design and
    implement it or there are other Parts of the product and other people
    who are not designers per se but who might be using a design tool and I
    think that’s one of the things that the evolution of design tools over
    the past 5 to 10 years has helped accomplish and so it makes a better
    collaboration between these different functions more respect for design
    as a discipline.

    Which is good because everyone can work more effectively and then in the

    meantime, yes, there are more designers, more products to design, more
    people who are adjacent to design need to work with design tools and
    hence that market just grows and grows.

    00:52:09 - Speaker 1: And in this fields, I think we’re a very

    interesting time and design tools industry because I feel, you know,
    that there’s these are the Adobe years, there’s the nascent years
    where like sketch, defined the category. Now there’s now like the last
    few years, there was like, wow, it seems like there’s a new design tool
    every other week, that’s for sure.

    And I think we end now a phase where there’s a little bit more

    consolidation and maturity, right, you see, on one hand, different tools
    and companies sort of like finding different niches, pivoting to
    slightly different space and at the same time you see sort of the
    thresholds of like what the design tools. Do do match a lot, and I think
    that’s inevitable, right? Like people have the same problems
    everywhere, right? Like a designer that uses Tool A versus Tool B, like
    a program is code editor A, code editor B, you know, a little bit
    different here, but assume you’re working on the same language systems,
    like your problems are relatively similar.

    And so I think we might now be entering a very interesting phase where I

    think it’s beneficial to us where the differentiation comes through the
    experience, right, to the depth and duration of experience through the
    design principles and that they’re manifested in. The app pros or even
    like company principles, cultural principles, moral decisions. So you
    see this in tools that have been around for so much longer, for example,
    code editors, right? Like people that are choosing them are choosing
    them for a reason, right? They’re not choosing films like, oh, it does
    less than this, like that’s fine. I want to use it because it’s closer
    to the way. I think to the way I operate, the way I express myself, and
    I think that’s very interesting when you have a space for tools to have
    their own distinct personality, their own distinctive appeal, and
    through that give people reasons to choose them that are not simply like
    the race for doing the most.

    00:54:19 - Speaker 2: Yeah, that’s a great point. A diversity of tools

    to choose from where it’s not just about does it fulfill the function,
    you know, the very utilitarian need that I have, but can I choose
    something that just fits my vibe or I just like how it feels, you know,
    you mentioned code editors for me I like sublime texts because it’s
    very minimal and fast and that suits me.

    I know other folks who are incredibly productive with really full.

    Featured IDEs with refactoring support and all these fancy features and
    for me that doesn’t feel great. It gets I feel like it gets in my way
    and I want something simpler, but I totally respect that other people
    are more productive with something more full featured and there’s room
    for that.

    There are dozens of code editors and even among the most popular ones,

    Vim and Emacs and VS Code and XCode, you can even name. Irish sects that
    are in the top area and that’s true in most places in the economy,
    right? That’s part of the abundance of capitalism. You go to any store
    and the number of different brands of shoe and types of soda you can
    buy, there’s a lot, and they may all serve the same basic purpose of
    covering your foot and so on, that you can choose based on style, based
    on aesthetic, based on what you think about the company that’s behind
    it. And I think we had this sense in the recent past or maybe currently
    that there was a more of a winner take all dynamic in software, but I
    think that might have been a bit of a red herring. There was a couple of
    dramatic historical examples, Microsoft Windows and Intel, the sort of
    Wintel dominance a couple of decades back might be one example, but in
    fact, I think that even Any kind of like pseudo monopolistic, you know,
    giant you can think of, OK, there’s Facebook, but there’s also
    Snapchat and TikTok and Twitter. What about Amazon? Well, you’ve also
    got Shopify managed to build a huge business out of an e-commerce
    platform. So I think there was this sense that there can only be one
    product and therefore you have to race to take the whole market, but I
    don’t think that’s true anywhere else in the economy and I think
    we’re also starting to see that in technology.

    00:56:23 - Speaker 3: Yeah, and on this topic of abundance and a

    diversity of options, I think it’s especially important for these
    professional tools like a design platform or a code editor, because if
    you are respectively a designer or a programmer, you’re going to spend
    468 hours a day. On this tool. I mean, this is a big chunk of your moral
    life.

    So using a tool that you feel good about that has good vibes is actually

    really important.

    It’s not just a cosmetic thing, it’s not a trivial thing. It’s where

    you’re spending a lot of your professional time and energy. So I think
    it is really important that people have the ability to choose a tool
    that feels good to them, and we’re lucky that we have that in at least
    these two domains.

    00:57:04 - Speaker 1: It really is an incredible field to be in. I think

    for all the evolution the design tools have had over the past 10 years,
    it feels like there’s so much more to go, and being able to like have
    an active hand in That evolution and particularly in an organization and
    the products that places emphasis on, you know, a different way of doing
    business, a different way of approaching product, a different time
    horizon and track. I think that’s immense privilege and a really
    exciting thing and I mean fortunately, being able to do that on this
    team on the editor and working day to day.

    On the Mac app, which you know, one could say maybe a dying art,

    definitely amongst bigger tools because the web affords you, and I’ve
    long worked on the web on my career has been on the web, but the web
    affords you so much more accessibility and such a lower barrier of
    entry. I feel personally it’s like a huge privilege and it’s a really,
    a really exciting thing to do every day.

    00:58:12 - Speaker 2: Well, let’s wrap it there. Thanks everyone for

    listening. If you have feedback, write us on Twitter at MAHQ or you can
    write us on email [email protected]. And Paolo, thank you so much to you and
    your broader company for inspiring all of us as a small giant for
    helping bring the design tools category into its full and current
    abundance and for making sure all our corners are rounded.

    00:58:38 - Speaker 1: Thank you so much and thanks for having me.

    0 min
  • 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 problem that we’re trying to solve, it is, how do we take what
    we think is a great product and make it a little bit more accessible
    while still staying true to what we’re all about. So Hillary, I
    mentioned earlier, this kind of brand or aspirational message versus,
    you know, what is your product, what category you were in practically,
    what does it do? You talked about that quite a bit and the difference
    between the brand message and the product message as we work together.
    How do you think about that, broadly?

    00:16:01 - Speaker 1: So brand messaging is really about creating a

    feeling or an emotional pull toward your brand and product is much more
    functional, leaning into the features and benefits of using the
    product.

    And as companies get really big, even, you know, like Fortune 100 type

    companies which I tend to work on more in my full-time job, brand gets
    really far away from product where in many cases it’s not even rooted
    in the product.

    That happens in categories where products are really commodities, so

    that doesn’t happen as much in tech, but a good example of this if you
    think about candy. A lot of candy is the same. You’re not going to
    really talk about the benefits of the product. It’s sweet. Exactly.
    Even that, like, you know, gummy worm commercials that are just about
    like crazy, you know, fun, these brands tend to create a mood or some
    kind of character, something that just helps it be relevant to people
    and just be liked, and then there’s not really anything they could say
    about the product that’s compelling.

    00:17:14 - Speaker 2: You know, in our brand episode we talked about

    Coca-Cola, maybe as one of the purest brands they’ve invested for, I
    don’t know, over a century now, I think in associating with Americana
    and Santa Claus and friends and family and good vibes and I don’t know,
    support the war effort during World War 2, yeah, happiness, but it’s
    sugar water in the end, and yeah, it’s got a certain flavor to it, but
    you know, it’s sort of the ultimate commodity, but they built this
    incredible brand around that. They don’t need to spend a lot of time
    talking about. This is a beverage you can drink that tastes sweet and
    also has caffeine in it.

    00:17:49 - Speaker 1: Exactly. So I kind of come to tech with this

    extremely broad lens on brands, and I think this category requires a lot
    more respect for product communication than you typically see in like
    marketing. So I tend to be among my like marketing community, a little
    bit of an outsider on that, like when I get the chance to work on, you
    know, more tech brands like I’ve worked on Dropbox in the past and we
    transfer in many cases in a more traditional agency setting, you know,
    I’m the one asking like, what does the product do and how do we turn
    that into something. So I think when I started this Muse project, We
    want to, of course, have brand messaging because Muse has a really strong
    brand, but I think just coming into where you guys are as a product,
    there’s so much education to do on just what the product is that it was
    like fairly clear to me that that was where we needed to start. And
    where we landed and kind of the messaging hierarchy, and that’s really,
    I think, what can be helpful is how do you think about brand and product
    messaging relative to one another, which one should you lead with? And
    we landed with. big ideas as the lead message on the website, but
    there’s so much more focus, you know, if you think of the total kind of
    share of messaging in the hierarchy that we landed with, there’s a lot
    of product messaging there and product education there. And then as
    people go deeper, they get into those, you know, what are the principles
    behind the product, who’s the team, what’s your background and the
    research perspective, and that starts to really build a lot of that more
    emotional pull to muse. So it’s definitely both. It’s just like how do
    you get into the details of working out.

    Again, your point in time as a brand and what’s the most important

    thing you need to do. And I think for us, it’s a little bit of
    category, creation, right? Like this is kind of a new kind of product
    and also just education. So we definitely think over the course of the
    project started going more into focusing on product communication, but
    I’d be curious, Adam, what you thought about this too because I know
    this is something we debated quite a bit.

    00:20:10 - Speaker 2: We did, and coming back to those comparables,

    again, one of the early pieces of kind of research you did was just
    looking at, you know, I gave you a list of what I thought of as being,
    again, competitor is the wrong word for it, but sort of tools that are
    in our sphere somehow, because they are again, other ones that people
    who are customers and users use, they’re just ones we like, we just
    think they are a good team or have good brand or whatever.

    So one example of a smaller team we talked about a bit was My Mind. So

    if you look at their website, they are very heavy on the brand
    messaging, right, which is, I think the opposite of most technical
    products, particularly apps, you know, if you go look at Bear notes or
    Obsidian or one of these many kind of text oriented note taking tools
    that really lead with, here’s what this thing is and what you can do
    and here’s a screenshot. And then the brand stuff, you know, what’s
    our manifesto tends to come later. Whereas my mind really leads very
    heavily with a visual style, with a, you know, reclaim your mind, and
    here’s all the things we’re sort of fighting against in the world, and
    you have to really scroll quite a bit before you find out what actually
    is this thing? What, what do I use it for, what platforms even run on?
    And it was kind of nice to have that as a bracketing thing. Here’s a
    very extreme investment in brand, that’s a technical, you know,
    productivity software tool that’s in our kind of world, and then we had
    others that were on the other extreme, which again tends to be most, but
    I think especially a lot of iOS apps that are especially if it’s just
    made by a small, you know, one or two developers where they don’t have
    some big highfalutin thing, they’re just like, hey, here’s an app that
    Lets you do X and then here’s a screenshot, and hope you like it, click
    here to download it. And so having that spectrum.

    And I think for us, one of the things we were trying to incorporate into

    this project is what we’ve learned over the last several years of
    trying to explain.

    This weird product. And one of the things I’ve learned is that we’ve

    tried lots of different things we can kind of put on a website or on an
    app store page or whatever, and none of it quite seems to capture it
    well, and maybe it’s because we haven’t quite found the right words.
    Some of it is that we’re trying to do something that’s pretty new, and
    so therefore, there isn’t just a brief summary, but I do think a big
    part of it is what you ended up calling the brand messaging. Which is,
    we know that someone who, for example, listens to a couple of episodes
    of the podcast first and then tries the product, is much more likely to
    find success, not because we explain in any way how the product works,
    it’s more that you know how we’re thinking about it. And what our
    values are, what our culture is, and sort of if you’re drawn to that or
    you just like it, but you have it in your mind, and then you go to use
    the product, you know this is something different. There’s a different
    set of values that go into it, and so you’re not likely to bring the
    same preconceived notions that you might expect from another, I don’t
    know, iPad app. So with that kind of top of mind for me, I came in and
    said, and you started to talk about this difference, and so my
    perspective was maybe we should lead with the brand messaging. Maybe,
    you know, it doesn’t necessarily need to be pages and pages’ worth,
    but maybe that first above the fold thing should really be about.
    Here’s how we think about having good ideas. Independent of the product
    we’re building, and then you read that, and if it resonates with you,
    you scroll a little further and then we explain, by the way, we have
    this product, and I think we explored some of those ideas, but you
    ultimately were on the side of, actually, we really should lead with the
    product messaging and the brand stuff goes a little later.

    00:23:41 - Speaker 1: I think one other great example to think about is

    Apple as a brand, you know, we talked about Coke and I think sometimes
    these big brands that we all have so much experience with can help us
    just add a little more context to these very esoteric ideas of, you
    know, product and brand, and I think Apple is one that we might assume
    really leads with a lot of brand messaging, right, because they just
    have such a strong brand, we’ve actually combed through. All of their
    marketing, especially their website, but even their marketing
    commercials, their events, all of these things, most of what they
    actually say is about the product. And that’s something I’ve started
    talking a lot with my team of strategists at work is Apple is really a
    product marketer, and it’s really interesting when you look at that in
    detail, because the way that they actually express all these brand ideas
    that we have extremely strong associations with like creativity, right,
    design. Those things are all implicit. They’re in the style of
    everything they do, the actual design of their products, right? They
    never really say those words, and I think that that really gets into
    strategy and brand, even messaging kind of can push you toward how do we
    express this implicitly, right? And not everything needs to be in
    explicit terms. So that’s something that I think we started to talk
    about actually at the end of this project. That is really important for
    people to think about as they think about how do they want to express
    all of these things, right, about you as a company, when your audience
    has so little time, a lot of it needs to come through in that more
    implicit communication style.

    00:25:31 - Speaker 3: Yeah, Hillary, it’s a very astute observation.

    I’m scrolling through Apple.com now and it’s just completely about
    products and they actually get very detailed, you know, they’re
    bragging about their chips and their cameras and their batteries and
    everything, and there’s nothing about design even though of course the
    design is beautiful.

    00:25:46 - Speaker 1: Right. Yeah, design is one of those things, right?

    You can’t really say I’m good at design and have someone trust that,
    you have to demonstrate that your design is excellent, you know, right.

    00:25:58 - Speaker 2: Yeah. Thinking about Apple’s kind of marketing

    and brand and whatever also makes me think of their pretty famous.

    I think Steve Jobs led campaign Think Different, and that would be pure

    brand marketing, right? It’s doesn’t show their product at all. It
    shows these.

    Great thinkers from history, but many of whom were maybe counter to the

    status quo of their time, and coming back to your point in time thing,
    that wouldn’t work for Apple now because they are the computing
    monopoly, but back when they were the very small David to the Microsoft
    Intel PC Goliath, that was great messaging.

    It basically said, being not in the majority being one of this kind of

    smaller group is something desirable. You stand apart. You don’t stand
    apart by using an iPhone these days, so that messaging would not work
    for them now.

    00:26:54 - Speaker 1: Right, exactly, that’s when they were kind of

    they had this challenger brand strategy and another good example more
    recently that I think just is a great example of what we’re saying here
    is that campaign they did behind the Mac. And the only thing they said
    was behind the Mac, and then the actual imagery was what communicated
    like this is something people use for certain kinds of work, but they
    never, you know, described it in any more detail than that. So, yeah,
    another recent example. They definitely do a lot of brand marketing for
    sure. It’s just something that I think we don’t always really realize
    is how much product they talk about because their brand is so strong.

    00:27:38 - Speaker 2: So I think one thing you learned working with us

    is we’re very about creative process. I’d love to dig in and see how
    creative people do what they do, and you had a pretty kind of specific
    process that we went through together. Tell us broadly what that is.

    00:27:52 - Speaker 1: For this project, we had 4 phases. So we started

    with discovery and then we did a phase of strategy work and that
    involved what do we want our positioning to be. We talked about our
    persona, our kind of this inspiring ideal customer that could help us
    think about the messaging that would resonate with them. Then we
    actually went into the writing and then finally we did some user testing
    at the end.

    I think this process for me really reflects my approach as a strategist,

    maybe would be different for someone who’s primarily a writer that also
    has some strategy process. So, you know, actually thinking about it now,
    maybe it’s a bit. Scientific. I like to really have a lot of research
    and discovery that allows me to say, here are a few possible ways in or
    hypotheses, and even ultimately, we had, I think, 3 different versions
    of the messaging that we put into testing with new customers and we
    wanted to validate that it kind of landed on their ears in the same way
    that it did on ours, and that testing is, you know, really important and
    something I’ve just learned. In my career and come to really value in
    the process.

    00:29:10 - Speaker 3: Yeah, I really appreciated the structure that you

    introduced for this project.

    Again, with marketing, it’s so easy, I think, to sit down and start

    typing stuff, you know, like tool for thought, big ideas, you know, HTML
    mockups, and I really appreciate that we started with, OK, first, let’s
    like understand reality with discovery, and then it was defining the
    problem, what are we trying to do here? And then it was coming up with
    multiple options and you can’t actually have a design decision unless
    you’re choosing among multiple options and then we picked one and
    validated with testing. So, I thought that was a great strategy.

    And on the discovery front, one thing that I really enjoyed was the

    industry survey that you did. We’ve alluded to it a little bit, but I
    think that would actually be worth talking about in and of itself, just
    because I think it’ll be interesting to our listeners who are in this
    space.

    00:29:54 - Speaker 2: Yeah, that’s right.

    So I guess that first discovery phase was really immersing yourself in

    our world, which included listening to a bunch of the podcasts and
    reading all the memos and so on, but also kind of, you know, maybe
    snooping around our Twitter sphere and all that sort of thing.

    And I think one reason that was useful actually was. You’re an outside

    perspective, but you also do know creative tools, as you said, you’ve
    worked on things like Dropbox and we transfer and so on. So you know the
    space very broadly, but the niche tools for thought, community, all that
    stuff was basically new to you, so you had fresh eyes, so there was
    quite a bit of time where you were doing that. But then, yeah, you kind
    of went on from there to this, basically came up with some sort of slide
    decks and documents for us that tried to roll up how you saw. The
    industry we were in and the customers that we could choose to try to
    address and what order we might want to go after them. And I think one
    piece of this was, Mark, are you thinking of the two axis grid here?
    Yeah. You know, maybe you want to describe that for the listeners, of
    course, visual thinking things doesn’t translate super well to a
    podcast.

    00:31:01 - Speaker 1: I’d be curious actually, Mark, to hear what you

    recall now and what has landed with you and then I can go into a little
    bit more of the process behind that.

    00:31:11 - Speaker 3: Well I think one of the axes was individual versus

    team.

    And that makes a lot of sense to me, because we’ve long identified

    since before we started the company, that there was this critical pull
    over time towards teams because of how software pricing works, is
    something we talked about in the podcast a lot.

    And I think there are different ways we might have cut the other axis,

    but it was something like early stage, late stage, creative process, you
    know, informal versus formal, that sort of thing. I’m not sure actually
    what we ended up with. OK, we’ve pulled it up here. How close was I?
    Yes, personal and teams and knowledge management versus creative
    process, which I think is sort of the flip of that of what I just
    described.

    00:31:54 - Speaker 1: Yeah, so this is what we call in strategy, like a

    4 box and we use these for all kinds of things, but this in particular
    we used for the category landscape. So we wanted to look at, you know,
    here we’re looking at, I think, call it 25 brands and we looked at
    quite a few. This is just kind of a good number to get a general lay of
    the land.

    00:32:17 - Speaker 2: Just to give a feel for that, that’s sort of

    notion, air table, it’s things like Rome and Kraft, it also includes
    something like Mirro, fig jam, so, these are all probably not
    necessarily our listener knows every one of these, but they’ll probably
    be familiar to a lot of folks who are in our sphere.

    00:32:35 - Speaker 1: Yeah, exactly. So we kind of first created that

    list of, you know, all of these brands in the category or maybe slightly
    adjacent to it, to understand. We looked at all of these brands in a lot
    of detail, really going through their websites, and it kind of goes back
    to what we were speaking about with Apple, right? With notion, you might
    have a sense of notions brand or messaging.

    It’s really important to actually take that step and go through their

    site and say, oh, they’re not actually saying what I expected them to
    be saying. And so that’s a really important part of the process and not
    making assumptions based on your own experience with the product or your
    history with the product.

    So, I went through websites of all of these brands and then saw kind of

    what naturally are the axes that emerge, and what are the kind of themes
    that we’re seeing across their messaging.

    And so the big thing that I found and Mark, to your point, this is

    really Because of a natural dynamic in the category around pricing,
    personal versus team is kind of the most apparent one. And then maybe
    the less obvious one was that some products really position themselves
    for what we’re calling knowledge management, and a lot of them even say
    that explicitly.

    I think knowledge management or second brain, this kind of language is a

    little bit of a niche, but definitely growing, and we all have talked a
    lot about that.

    And then the other side, and I think what we got a lot more interested

    in for ourselves was. These tools that are really more for like just a
    day of work, you know, your creative process and helping you dive into a
    really rich hour of thinking. And that was a lot more interesting and
    that started to present a white space that we could have some messaging
    that would be more unique and ultimately, I think dive into big ideas
    really does that. Right? That’s so different from messaging that’s
    like, organize your notes forever. You know, we don’t really want to
    say anything like that.

    00:34:39 - Speaker 2: For sure. That was a big insight, I think, which

    is it’s very easy to naturally align ourselves with, again, the Romes
    and obsidians and crafts of the world, or even some of these more nichey
    products like Devon Think that I take a lot of inspiration from, or my
    mind as we mentioned earlier, but even though some of those are fairly
    recent. I think Evernote is a mainstay in this space. They’ve been
    around quite a while now. It is all about remembering.

    Like Evernote’s logo is an elephant, which is, or, you know, we’re

    supposed to have long memories or whatever. And yeah, I think Obsidian
    has a similar thing, what do they say, like, notes you’ll pass on to
    your grandkids or something like that. It’s all about this longevity.

    And that you create this big knowledge base and you keep it over time,

    and the fact you can still find and pull up a note you wrote 5 years ago
    is the argument, and that really is the opposite of how people use Muse
    and where we think the value is, which is really about this active
    thinking, this point in time, it’s your desk, it’s where you make a
    mess for the thing you’re doing right now. And you know, I like to have
    and I think many of our users and customers like to have their boards as
    a kind of artifact or almost a memento of your thinking, but the
    thinking you did a couple of years ago, it’s just interesting for
    historical reasons, it’s not an active part of what you’re doing. And
    so when you look at that, you say, well, we, especially with our
    messaging around tool for thought. But also I think just generally
    people would naturally kind of put us in that sphere, but that gives you
    totally the wrong idea. We’re not about organizing, we’re not about
    long haul, long term, we’re about that active thinking that in a way is
    almost a little more transient.

    00:36:21 - Speaker 3: I also just love, by the way, this as a general

    intellectual technique. We’ve talked about it on the podcast before
    where you generate a list of items and then you come up with two axes
    for them. So you get 4 boxes or maybe 9 boxes, and then you see which
    boxes are blank, and you sort of suppose that there must be interesting
    things you could do there. And sure enough, we have this literal white
    space for muse positioning, where in this creative process and personal
    square we suppose that you should be able to have a really great
    products. So I just find that a useful technique in general.

    00:36:50 - Speaker 1: One other thing that we did in that discovery

    phase, and maybe it’s worth mentioning kind of my process there is
    really to look at what’s sometimes in the strategy world we call the
    four Cs.

    So the company, and Adam you mentioned, I had my own kind of podcast

    binge of metause and reading all the memos.

    The competitors, so we just described that in the category, which is

    closely related to competitors, but it’s more of that broader picture.

    And then the fourth one is the customer and there I did a lot of, you

    know, reading customer feedback and quotes and tweets and kind of
    pulling them out there.

    And in fact, one of the words that emerged that people use a lot

    naturally to talk about news is flexible. And flexible is a word that
    kind of made it all the way through our process into the final user
    facing copy in the end. So, a lot of things from that discovery phase
    informed ultimately the messaging.

    00:37:55 - Speaker 2: And maybe we can speak to that, what was it, the

    2nd or 3rd C, I guess the 3rd C which is category, because this is one
    we’ve perpetually struggled with, which is I think it’s really
    important to put yourself in a category because it’s how people know
    right off the bat what you are, and then you can go from there to
    differentiation, but everything we’ve sort of ever tried has just been
    wrong, and to some degree it’s maybe we need to kind of create a
    category which is sort of digital ideation tools.

    Traditionally, people do their kind of thinking, externalizing their

    thinking on sketchbooks and whiteboards and things, and so doing that
    through computing tools is relatively new. There isn’t a very
    established category for that.

    And we did end up with, yeah, you mentioned the flexible boards, which

    is part of what I was thinking with this, so this longer description of
    the product, which is flexible boards for note taking, whiteboarding,
    and connecting the dots.

    The last one’s interesting, we can come back to that, but the other two

    actually kind of imply category, right? Note taking is, and I’ve got
    mixed feelings about that for various reasons, because, you know, when
    you think of note taking, you can think of a lot of different things,
    many of which don’t necessarily give you an accurate.

    Picture, but it is the closest thing to a category that we fit a well

    established category that most people would know that we fit into. And I
    think whiteboarding, either that’s putting us in a category of physical
    whiteboards, but I think also it sort of works because we do have this
    emerging category of mirro, Millanote, fig jam, mural, basically digital
    whiteboarding, and especially collaborative whiteboarding has become a
    thing in the last couple of years, and that was not the case, you know,
    a year and a half ago when we were coming up with the Muse one
    messaging. So yeah, tell me about how you generally think about
    category, and then how you thought about trying to help us solve that
    problem.

    00:39:44 - Speaker 1: Yeah, I think it was very apparent to me when I

    started working on this project that Muse is creating a new category or
    it’s part of a few brands who are creating a new category of product.
    And I think that’s why messaging has been challenging because there are
    a lot of things you need to do. You need to tell people what world are
    you even in, you know, like, where am I?

    00:40:10 - Speaker 2: Yeah, exactly. Is this a hat? Right, a restaurant,

    exactly. Is it a hotel?

    00:40:17 - Speaker 1: Yes, so where am I? You know, what is this? What

    makes it different or when should I use it? Is it for me? There are a
    lot of questions to answer, and I think something that’s really
    exciting is the category is becoming a little more established. You
    mentioned a lot of products and we’ve, even as we were continuing to
    work on this project, we would see new things launching and new sites
    that we were kind of sharing with each other as a team and I love seeing
    more kind of competitors, so to speak, because it starts to alleviate
    how much work you need to do to describe to people what this category
    is.

    00:40:56 - Speaker 2: So that’s part of this concept of positioning

    which I think Mark and I talked about in the episode, which is you’re
    positioning yourself relative to other things that people may already
    know.

    So there’s a bunch of companies that are doing a roughly similar thing.

    Actually, we even talked about this with Puran who’s doing kind of
    spatial canvas type thing that in many ways is Similar to Muse in terms
    of category or in terms of like what the product is, and he’s got the
    same, yeah, messaging challenges. How do you explain what this thing is,
    but it’s almost like the more of these kind of open canvases for
    thinking exist, then the more likely someone is to have stumbled across
    one or two of them.

    And then the more likely it is that they can, oh, it’s one of these,

    it’s kind of their mindset, and then you can go from there to, OK, so
    what makes your special or different. Exactly. And that’s like a way
    easier problem than let me explain to you from scratch a thing that you
    don’t know what it is or why it needs to exist or whether it’s
    something you’re interested in.

    00:41:53 - Speaker 1: Yeah, exactly. And I think the spatial canvas

    category is kind of formalizing and taking shape, and I think that’s a
    really good thing for Muse, and the note taking whiteboarding and
    connecting the dots, the intention there isn’t so much to say like
    that’s our category as it is to say like, hey, if you’re a person that
    has these needs, this is what you can do with Muse and note taking and
    whiteboarding are more kind of Approachable and familiar ways people
    might understand this need that they’re starting to observe, you know,
    as they shift to working more virtually or just needing to be more
    organized and having tools that support that part of their process, they
    might start to understand that need through words like that. And that’s
    again something we just saw in reading how people talk about news.

    00:42:49 - Speaker 2: Yeah, and I think part of what works about it is

    that if you read note taking and you immediately think, so this is a
    competitor to Apple notes, you know, that’s probably not quite right,
    but at least it does tell you again, kind of what corner of the universe
    you’re in at least, and then you read whiteboarding and that might also
    lead you to think, OK, this is a competitor with, you know, one of these
    more collaborative oriented.

    Whiteboards like a fig jam or a mural, and that’s also not quite right,

    but you put those two things together and you’re kind of, you know, in
    the right county, I guess, um, and then you can go from there into the
    details, and hopefully the details actually will help you narrow in, but
    you hopefully start from a place that, again, is roughly in the
    ballpark, I guess.

    00:43:32 - Speaker 1: Yeah.

    00:43:33 - Speaker 2: Mixing my metaphors here.

    00:43:35 - Speaker 1: To me, something in that description that alluded

    to the powerful text features was important. I think that is a
    differentiator for Muse. It’s not just something where you can kind of
    like scatter around cards and look at them, right? You can do some
    pretty powerful things with text too, and I thought that was important
    to represent in the high level description of the product.

    00:44:01 - Speaker 2: And connect the dots is an interesting one as

    well, because that’s probably one of the most frequent phrases we hear
    from customers when they talk about how they use Muse, which is, yeah, I
    guess it implies this.

    You sort of lay everything out and you’re trying to find the pattern,

    and you’re trying to find the people often jokingly refer to the, is it
    always sunny in Philadelphia meme with the like serial killer board
    thing with like yarn connecting, whatever. It’s kind of the Hollywood
    version of this, but it’s a literal connecting of the dots when you see
    this sort of thing, which is like some kind of thing that’s up on a
    wall, that has all the things you know, and you’re trying to put the
    pieces together to solve the case, it’s usually how it is. So, for
    whatever reason, that’s a phrase that people use a lot. So, our hope at
    least would be that we put that right on the front page of the website,
    and again, it’s not that that’s going to completely 100% tell you what
    this thing is, or whether it’s for you, or whether you would want it,
    but if connecting the dots in your work sounds like a thing you would
    like to be able to do, or there’s a thing you do do, or there’s
    something you need to do, now, you know, we’re narrowing in on the
    right kind of person for this product. The last piece I think is worth
    uh mentioning there, we sort of diverted from the creative process a
    little bit, but I was interested to pursue this all the way. So we spoke
    about dive into big ideas, we spoke about the flexible boards, then we
    have tool for deep work. Now, how’s that different from a tool for
    thought and what caused you to think that that would be a good sort of
    medium length or short descriptor for the product?

    00:45:39 - Speaker 1: Deep work is an expression that kind of came to

    me, you know, and I, I really liked that it was something that already
    exists in culture, but to me deep work also, we’re using it to describe
    the product, but It has kind of like an emotional appeal to me. I think
    that’s, you know, in Cal Newport’s book, why the title is so salient
    and actually just as an aside, I think titles of books are probably one
    of the best kind of sources of inspiration for messaging.

    There was actually a moment in the Muse project where I was just like

    feeling a little stuck and Just went to a bookstore and was just reading
    all the titles, and book covers are so inspiring to me because it’s a
    visual and a title and the titles so short, and it captures like the
    entire thesis of the book. And I just think that is like the coolest
    thing. So that’s kind of a go to source of inspiration for me, and I
    think that book has been around for a long time now, the deep work book,
    but I think it really created an understanding of a big gap in modern
    work and, you know, in many ways my interest in deep work was also very
    much informed or maybe validated by the brand persona that we wrote. And
    we can talk a little bit more about that, but the work idealist is kind
    of the brand persona that we created for Muse as part of this project.
    And one of the things that we have in that is that this person who we
    really want to build our messaging for, right? Their work requires
    strategic skills, creativity, intellect, and they actively design their
    day around that focus work.

    There’s also an old Paul Graham essay about the manager’s work versus

    the maker’s work. A classic, classic, right? And I only started reading
    Paul Graham recently, but I remember kind of coming to that insight
    articulated and nowhere near as nice of a way. But when we first shifted
    to remote work in 2020. And I was working with a lot of, you know,
    project managers and, you know, me as a strategist creating so much
    work, I was feeling this tension of like all these people who just
    needed me to be in meetings all the time to kind of report out updates
    and it felt so personal. I was like, I need time to work, you know, and
    so that deep work idea, I just think is really a deep, deep emotional
    desire of people that we want to build this product for.

    And I think it’s also, you know, similar to big ideas, quite universal,

    you know, we have a point of view on different customer sets that are
    good for you, but we also know that tons of different kinds of
    professions. need this tool. And so we wanted to use language that had a
    kind of universal nature to it. And I think deep work does that. And the
    last thing I’ll say is, I think there was a little bit of a choice we
    made intentionally to position Muse for kind of cognitively demanding
    work, so to speak, or complex work. And that’s actually how I got to
    big ideas. I was like writing. I’m like, Muse is for complex ideas, you
    know, it’s like, we don’t want to say that complex, but That really is
    what it’s for. It’s most useful for like big hard problems that
    you’re trying to work out, and I felt like deep work and big ideas were
    two interesting ways to articulate that while still being fairly
    accessible.

    00:49:28 - Speaker 2: The pairing there is interesting, which is big

    ideas might be what you’re working on, right? You’re working on your
    product that you think is going to change the world, you’re working on
    your nonprofit that you think is going to do great good, you’re
    thinking about impact, etc. and then the deep work is how is that you
    feel that you need to do these cognitively demanding things and We live
    in this world of distraction and what have you, and yeah, being pulled
    into meetings among other things, just to pick a small example, and that
    you need to really take control of your own time and your own process,
    and your own work life in order to do the top line thing that you want
    to do, which is have that impact your big ideas, bring your big ideas to
    life, that sort of thing.

    00:50:09 - Speaker 3: I also think these are really important because

    they connote things like being immersed, even being engulfed,
    consequential, creating, and I think it’s a subtle but important
    contrast to collecting, categorizing, cross-linking, organizing, which
    is the mode of a lot of traditional other tools for thought, and I think
    it’s a really important difference with what we’re trying to do with
    Muse.

    00:50:32 - Speaker 1: Absolutely.

    00:50:34 - Speaker 2: The other thing I’ll note there is, so deep work

    obviously is a not only a relatively new idea, there was this book,
    although I suspect a lot of folks know the term, or at least can intuit
    it, but I think a lot of folks have probably picked up through osmosis
    what that term means, even if they haven’t read the book or even are
    aware that there’s a book.

    But it’s interesting to note that I think deep work and Tool for

    Thought are both Let’s say nichey terms, but I think deep work is much
    less niche.

    Yes, for example, if you just do a Google Trends search, dual thought

    doesn’t even show up, doesn’t even, uh, doesn’t even rate, or as deep
    work does.

    As just one example.

    So, maybe this, again, coming back to the point in time theme a little

    bit here, which is, you know, we were very early on really getting
    started, very, very niche audience of people, particularly coming out of
    the independent research world, you know, that was absolutely The right
    way to categorize ourselves and talk about what we’re doing. Now, we
    need something that is still niche, but maybe a layer up the
    accessibility chain, or a layer up the, kind of how likely is it that
    this term will be known to someone or resonate with them. So, I think
    it’s still a niche term, but just less niche.

    00:51:47 - Speaker 1: Yeah, and Adam, one thing you spoke about early in

    the project, and I think we kept coming back to this is it’s very
    important that as we try to be more accessible, we don’t land in a
    place that feels very generic.

    And so I think we wanted to negotiate between the two and kind of land

    in a really nice middle ground and I think I feel like we’ve done that
    and Landed on something that still reflects kind of the aspiration and
    and really inspires you to use Muse, but it keeps it as a product
    that’s really designed for a certain kind of work, and it has a strong
    point of view and we’re not trying to be everything.

    We’re just trying to communicate like one very specific part of, you

    know, kind of your process and your work life that can happen here and
    can probably happen here better than anywhere else.

    00:52:42 - Speaker 2: Yeah, that’s right, I almost forgot about that,

    but when it comes to those really generic or what to me seem like really
    generic ways to market productivity software, it’s tough. Productivity
    software is very abstract, screenshots of it often look like just kind
    of white rectangles on the screen, and it’s hard to tell them apart
    maybe at first glance.

    But there are some tropes that I think that productivity software

    marketers reach for without realizing it for listeners who are thinking
    about, you know, writing some messaging for your productivity app,
    here’s some things that I would encourage you to avoid.

    One is organize your thoughts. I don’t know why everyone reaches for

    that. Even, you know, reviewers talking about Muse or whatever, but I
    can’t count the number of apps that I’ve seen describe themselves that
    way. And it may be a good term or it might make sense, but when everyone
    says it, it no longer has any meaning. It’s a cliche.

    Another one that’s in that category is the everything in one place,

    which we’re just talking about the, maybe notion has a little of that
    going on, maybe that works OK for them because they’ve broken out of
    the mainstream enough, or I’m not really sure, but I feel like so many,
    uh, whether it’s project management tools, notes, knowledge bases. I
    don’t know, enterprise, storage solutions, whatever, it’s everything
    in one place. You’re tired of like switching between all these
    different apps, just put everything into our app, and then we’ll take
    care of it all for you, and you won’t need to switch apps anymore. And
    of course that sort of thing is actually the opposite of what we like to
    do, which is like, just be one tool in your tool chain, and then we
    think great creators, you know, put together a lot of different tools to
    make their custom workflows. But putting that aside, I think even if you
    do strive to be a kind of everything app or put it all in one place,
    that term or that approach to speaking about a product then used so
    much, to me it just your eyes just roll over it because you’ve seen it
    so many times.

    00:54:35 - Speaker 1: One I would add to that is unleash your

    creativity. Oh yeah, I know, yeah. Yeah. That one’s pretty common and,
    you know, it’s not wrong. It’s just exactly like you said, it’s like,
    once too many people have said that, it’s just not unique enough. A lot
    of this is, it’s an art and a science, and the process for sure is
    helpful. And Mark, you made a great point that adding the process to it
    really adds like a degree of rigor, I think, and like, I really need
    that. Process around the creativity, cause otherwise it can just grow
    into this huge thing that’s hard to really push it through into
    something really clean at the end. But at the same time, there’s a
    degree of intuition and how does it feel when you hear it, that’s
    extremely important to this process. So I think that kind of art and
    science piece is important.

    00:55:39 - Speaker 3: Yeah, which, by the way, reflects how we’ve often

    talked about the creative process on the podcast, which is not that you
    have a series of steps that linearly follow from each other. It’s more
    like you collect up all this raw material and you chew on it and you go
    sleep and you go rock climbing and you come back two weeks later, it’s
    like, oh, now I realize we should say is X.

    00:55:57 - Speaker 1: Yes, it’s definitely so interesting how similar

    that is across all different kinds of creative work, kind of moving
    between. Structure, getting out of structure and the structure can
    really help, and then you also have to get outside of it um to kind of
    get to creative and fresh ideas.

    00:56:17 - Speaker 2: I think you briefly mentioned there this persona,

    which I know there’s some discussion in the design world about the
    usefulness of personas as kind of a generic stand-in for the person
    you’re designing for your target user, target customer.

    He, I think it was really helpful to try to describe in general terms,

    the kind of person that muses for. And so, as I mentioned, there’s the
    category struggles that we’ve had over the years. Another struggle
    we’ve had is the clear description of who is this product for.

    And, you know, it’s nice when you go to, I believe the jargon for it is

    verticals, so that is to say if your product is for writers or
    architects or academics or software engineers, that makes it pretty easy
    because on on your website, you can say, we are the best thinking
    workspace for interior designers. And it’s just people know pretty
    instantly if they consider themselves an interior designer or not, and
    if you’re not, well, you close your web browser and everyone saves some
    time, and if you are in that category, you go, OK, well, I’m one of
    those, so I’m gonna keep reading this is for me. And our various
    attempts to try to do that around vertical really doesn’t work.

    So for example, we have a pretty big, I would say probably maybe the

    biggest category of people that use our product to tend to be product,
    people of some kind, product designers, product managers, founders or
    other kind of like product oriented CEOs or whatever. So that’s a big
    category, but honestly it doesn’t make up probably more than 5%.

    So we have a very diverse set of architects, writers, doctors,

    attorneys. Game designers on and on, so we can’t use that easy
    shorthand, then you do still need to have some way to know who you’re
    trying to speak to.

    And so you came up with this work idealist persona, and I really like

    this, or I find it useful, and we don’t specifically talk about this,
    for example, on our website, it’s more a tool for us to understand. Who
    we’re trying to speak to, so that then we do, for example, write copy
    for the website or for the app store or something, we can write it with
    that person in mind.

    00:58:28 - Speaker 3: Yes, and another aspect of Hillary’s research

    that I really appreciated here was this notion of change over time. So
    it’s the personas and the user segments that we had previously had good
    success with, who were now looking to connect with and who we might
    address in the future. There’s a Particular diagram and one of the PDFs
    that really stood out to me, which is a series of concentric circles.
    And I think the innermost one was like people who follow Adam and Mark
    on Twitter and tweet about Doug Engelbart, and the outermost is everyone
    who uses an iPad and a Mac, and we’re, you know, somewhere in the
    middle there, right, but it’s a progression over time.

    00:59:03 - Speaker 1: Yeah, exactly. So the work idealist, you know, we

    spoke a little bit about There’s someone who actively kind of designs
    their day around this deep work idea.

    And one thing that I thought was important is that we think about like,

    they do actually hold quite progressive ideals toward work in general,
    and I think that gives us permission to have these kind of aspirational
    ideas kind of embedded in how we communicate. And in many ways it’s
    sort of built into what the product is, what you guys are building,
    right? It’s like you have this kind of core belief that there is a much
    better way to work on ideas that hasn’t been served yet in the market.
    So I thought like the work idealist and even the name of them like.
    It’s important that we sort of ground ourselves in something that’s a
    bit kind of idealist and aspirational as we start going to a broader
    market, because we don’t want to lose that kind of belief that is so
    important to who Muse is.

    01:00:12 - Speaker 3: I’m also now remembering, I forget what they call

    this, but there’s this phases of adoption. Is that relevant at all to
    where there’s like pioneers and laggards and stuff like this? Does this
    sound familiar?

    01:00:23 - Speaker 2: You might be thinking of the crossing the chasm,

    kind of there’s the early adopters and then the pragmatists, and then
    the late markets, and then the, what is it, the laggards, something like
    that.

    01:00:34 - Speaker 1: And just in general, like how trend curves work

    definitely come into play in product adoption curves and the Crossing
    the chasm book, which I have not read, but you know, loosely familiar
    with the concepts, I think really applies that general notion of and the
    science on how trends move through society, it applies it in a really
    practical way to product marketing.

    That’s exactly what marked the diagram you’re recalling there kind of

    outlines just like the evangelists that we want to start with, but
    recognizing we need to get beyond them, right? And they’re not going to
    know everything that, you know, your Twitter followers know.

    So how do we expand the way we communicate, keeping our brand intact,

    and I think the work idealist, it kind of sets up this inspirational
    kind of character that we can think about on that path.

    01:01:25 - Speaker 2: Right.

    And certainly part of what I liked about this persona is that it

    describes me, and I think it describes everyone on our team, right,
    which is someone who seeks meaning through their work, and you know,
    maybe a lot of us in creative fields, and especially tech, we’re lucky
    enough to have that we can kind of be a couple rungs up on the Maslow’s
    hierarchy of needs, where our work can be not just a way to put food on
    the table, but a way to, yeah, do something that we think matters in the
    world.

    And so then we’re mindful about, you know, for example, choosing what

    problems we work on, what company you’re gonna go to work for, or maybe
    you start companies yourself, or maybe you’re a freelancer, and you
    have the luxury of choosing projects that you think are more important,
    or speak more to you, or are more likely to do good in the world, for
    example. And then that also connects to, you mentioned, designing your
    day around.

    OK, I know I need focused time, I know if I leave myself to the demands

    of meetings and Zoom calls and notifications on my phone, and whatever
    that I won’t get that time, and so I’ll put the effort into designing
    my day and my work life and my creative process to get the work setting
    that I need. And another piece of that is also the tools.

    And so actually this comes back around something that I think has been

    part of our story, part of the muse story from the beginning, which is,
    OK, you know, there are pen and paper and Apple Notes is on your iPad by
    default and other things, but if you’re someone that really cares about
    the right set of tools for your creative process, and you’re willing to
    invest time in learning those tools while finding them in the first
    place, learning them. Paying for them, you know, maybe they cost more
    certainly than something that’s installed by default on your computer,
    but you care about a setup of a work environment, which is everything
    from how your day is to how your desk is, to something like whether you
    get to do a physical activity in the afternoon as a way to get out of
    your mind, those things matter to you and you’re willing to invest in
    those things and make choices that are outside of structure given to you
    by your employer.

    Right, and so that’s one of the reasons it was always really important

    to us that we uses something in the beginning, we call it sort of a
    personal tool, but that’s not quite right. You’re using it for work,
    probably, but you’re buying it for yourself because you want that
    agency, rather than it’s part of a default package of tools that kind
    of everyone in your company uses.

    01:03:52 - Speaker 1: Yeah, Adam, I love that you see yourself in the

    work idealist and, you know, the hope is that many, many people would.

    I certainly feel that this is like an expression of myself as well and

    strategy work in general actually is like quite a personal experience
    for me. I tend to pick products that are solving problems that I really
    understand and have felt and So in many ways, writing this was personal
    and I think also an attempt to kind of capture how I’ve understood you
    and the team as we’ve worked together.

    And you mentioned, you know, tools and kind of ways of working is part

    of this persona.

    So something that I really enjoyed about this project is the kind of

    work culture with the Muse team and people might find it interesting to
    know just how much of this project was done asynchronously over. notion
    docs and slack updates and we all work in different parts of the world.
    We had very few meetings over this whole project, which is very unusual
    for marketing projects in my experience. Yeah, we got to this amazing
    outcome. So I was curious to ask you actually like how you guys have
    built kind of that culture and just sharing more about how the team
    works asynchronously.

    01:05:13 - Speaker 3: Yeah, so there’s a piece of this that’s

    mechanically necessary. We’ve got people on the US West Coast in
    Europe, and people get up early and later, so.

    Just mechanically speaking, there’s a relatively small amount of

    overlap.

    So we’ve had to develop strategies that allow that, but I think

    there’s something deeper here and something you’ve mentioned, which is
    the idea of creative trust where we’ve designed this company and the
    associated partnership where we would have people who we all had a huge
    amount of creative trust in and didn’t need to be supervising their
    every activity and cross checking everything and things like that. And
    that for me was a huge goal of setting up the company like this, and I
    would want to do that even if we were all in the same place.

    01:05:51 - Speaker 2: Yeah, probably one piece of it is the, what I hope

    will become more of a modern standard. I think we’re seeing that in
    remote work, which certainly is, yeah, asynchronous stuff that, you
    know, works better across time zones, but also gives people more
    flexibility in their lives, right? That’s a Big deal for, you know, I
    mentioned, you know, Julia’s travels and the fact that she really
    values that, but everyone on the team does for different reasons, right?
    Like, for example, a couple of us are parents, and we really value the
    flexibility, meaning we can basically spend more time with our kids or
    be there in those critical moments, like a bedtime or a trip to the
    playground or something like that, that maybe a 9 to 5 job wouldn’t
    allow for. So I agree that sort of thing is both a pragmatic and uh just
    maybe a way the world is shifting a little bit, that people find this
    enough life work balance is quite the right word for it, but you can fit
    things together in a way that is more suitable to exactly what you need
    in your life, rather than the one size fits all box of, you know,
    everyone will be at the office at a certain time of the day, and then
    leave at a certain time.

    But then I think the deeper level, maybe you’re talking about a little

    bit there, Mark, which is There’s the trust in someone new has joined
    the team and we’re going to trust them to do good work as opposed to
    needing to like, I don’t know, count their hours or something like
    that. But I think there’s also the trust that’s more like, I trust
    that we share values, that we understand what the goals of this business
    are, that we all have the context necessary in order to make good
    decisions, maybe someone brand new to the team and certainly even
    integrating. A freelancer like you, Hillary, but even someone who’s
    maybe more of a filling a longer term role, in the beginning, they
    don’t have that context, and I think it takes a little time to build
    that. Hillary.

    I think you’re kind of an expert at immersing yourself in the world of,

    you know, a company and a brand, and it’s so that you can then do the
    work that you do. I almost think of it as like an ethnographic research
    approach. So you’re very skilled with that, but not necessarily
    everyone does. But I think we as a team have spent a lot of time not
    only in being very cautious who we bring into the team, we’re not in
    some hypergrowth, you know, hiring, scaling thing where there’s new
    people all the time needing to get up to speed. We can be very
    deliberate and take a lot of time that each new person that comes onto
    the team can build up the context. And then, hopefully, then we all
    trust each other. We all know what the purpose of this business is, what
    we’re trying to accomplish, both in terms of meaning and impact, but
    also in terms of just pragmatically, we need to sell, you know, we need
    this much revenue to stay in business kind of thing, and then we can all
    kind of make decisions independently within our realms that reflect that
    context. And of course we need to sync up, we need to brainstorm, we
    need to share ideas, we need to share our work for feedback, sometimes
    we collaborate more directly, you know, pairing that sort of thing, pair
    programming or pair designing or whatever you wanna call it. We did
    quite a bit of back and forth on sort of copywriting type stuff, you
    know, you would write a pass with something, I would copy edit it, and
    maybe Leonard would take a pass, that sort of thing. But in order to be
    able to do that work in this more independent way, yeah, that baseline
    of trust is about.

    Values, what are we all here for? What’s the mission? What are we

    trying to do, not only broadly, but in this moment, and then you can
    have this relative independence in how you work, but also be a team,
    right? It’s not about just doing our own thing. We’re all trying to
    like pull together and make a holistic endeavor.

    01:09:23 - Speaker 1: Yeah, that’s so interesting. It was just so clear

    to me as I kind of joined the team for this project that you had such a
    high level of trust, and I felt like that kind of extended to me pretty
    easily actually, as I just kind of came into your way of working and I
    think a lot of it is exactly everything you’re saying, like shared
    values and vision and context, and it’s just interesting how The tools
    that we use to work facilitate that a lot of the time, like coming into
    your Slack channels, getting a lot of the context on the project, and
    Adam, you certainly did a lot to kind of brief me and give me a lot of
    context and structure coming into.

    The project and then kind of as we went through Mark sharing with you

    like in critical moments throughout.

    And so I think it’s interesting going back to that idea of the work

    idealist. I think there’s a lot of like shared culture and values that
    we take from the tools that we use actually, and I think that can play a
    big role into building that like shared creative environment and trust.

    01:10:28 - Speaker 3: Yeah, indeed, and this is a long term interest for

    us at Muse. Right now, Muse is certainly part of this collaborative
    creative process, but we have aspirations for it to be integrated and
    reified in the products or perhaps in a Muse 3 this flow of you work
    together, you work separately, you share, you collaborate, becomes more
    native, so we’ll see.

    01:10:51 - Speaker 2: Well, let’s wrap it there. Thanks everyone for

    listening. If you have feedback, write us on Twitter at MuseAppHQ or via
    email, hello at museapp.com. You can help us out by leaving a review on
    Apple Podcasts. And Hillary, thank you for not only helping us find our
    new message that we hope will resonate with our audience, but also
    helping bring out the work idealist in all of us.

    01:11:15 - Speaker 1: Yeah, thank you. So happy to join you guys on the

    podcast today.

    0 min
  • 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 it just
    wasn’t working, and I realized we need to do a pretty fundamental
    rethink of this whole architecture, which is what we end up doing in the
    research lab and then now with Muse.

    The last thing I’ll mention about my journey here was my background was

    in back in engineering and distributed systems engineering, and so I had
    encountered variants of the sync problem several times, for example, at
    Hiroku, Adam. We had this challenge of we had these routers that were
    directing HTTP requests to a back end that was constantly changing based
    on these dinos coming up and down, and the routers needed to maintain in
    memory router tables based on the control plan that was being adjusted
    by the API.

    And so we had a similar problem if you need to propagate consistently in

    real time state to the in-memory databases of all these router nodes,
    and sure enough that work kind of came full circle and we were applying
    some of the same lessons here with Muse. So it’s a problem I’ve had
    the opportunity, for better or worse, to make a few passes at in my
    career.

    00:15:57 - Speaker 3: Yeah, I think it’s an extremely hard problem that

    comes up so often across so many projects is eventually you need data
    over here in Box A to look the exact same as data over here in Box B.
    and it’s one of those problems that’s just surprisingly hard to get
    right, and there just aren’t that many libraries and existing solutions
    for it to drop in and implement. A lot of other libraries you can just
    go out and find it, and there’s code out there, or you can license it
    or open source, whatever, but for whatever reason, sync is one of those
    things that’s for every project, it needs to be custom baked to that
    project, just about every time.

    00:16:38 - Speaker 2: And that’s part of what blew my mind back 8 years

    ago when I was looking for a sinking layer for clue and realizing that,
    yeah, I just had this feeling like surely everyone has this problem,
    everyone needs it, everyone needs the same thing. It’s really hard, you
    know, an individual company shouldn’t be distracting from their core
    competency of building their app to create the sinking layer, and yet to
    my surprise, there really wasn’t much, and that continues to basically
    be true today.

    00:17:06 - Speaker 1: Yeah, and this gets into our collaboration with

    Martin Klutman on CRDTs.

    So briefly you can think of there being two pieces to this problem. One

    is conveying the physical data around, and the other is, OK, you have
    all this data that synchronize, what do you do with it, because it’s
    all a bunch of conflicting edits and so on.

    And that’s where the CRDT technology came in. I think one of the

    reasons why we haven’t seen widespread standard libraries for this
    stuff is the thinking problem is hard. We’ll talk more about that. But
    another is that we haven’t had the computer science technology to make
    sense of all of these edits. Well, we sort of did. There was like
    operational transforms, but you literally need to hire a. Team of PhD
    computer scientists have any shot at doing stuff like that. And so
    Google Docs basically had it and maybe a few others, but normal humans
    couldn’t do anything with it. But the CRDT technology and automerge,
    which we’ll talk more about, made it much more accessible and possible
    to make sense of all these conflicting edits and merge them into some
    useful application state. So that’s the kind of why now of why now is a
    good time I think to be pursuing this.

    00:18:06 - Speaker 3: Yeah, and I think almost surprisingly to me, the

    solution we came up with at Muse, I think is actually really generic, and
    I think we solve it in a really elegant way that’s even more
    foundational to the technology than solving just for use. I think the
    solution we have. Can certainly solve from use in the future and is
    futureproof in that regard, but is broad enough to be applicable to a
    whole number of different uses and applications, which I think is really
    exciting too.

    00:18:37 - Speaker 2: Maybe it’s worth taking a moment to also mention

    why we think local first in the style of sync is important for you
    specifically. I think certainly Mark and I have had a long time interest
    in it. Well, if you have an interest in it, so it’s just something
    that’s more like we’d like to see more software working in this way
    where the user has a lot more sort of control and literal ownership over
    the data because it’s on their device. In addition to being mirrored in
    the cloud, certainly the performance element is huge for me personally,
    and I think for all of us on the team. But I think Muse, as we go to this
    multi-device world, on one hand, we think that every device has its own
    kind of unique mood. The iPad is this relaxed space for reading and
    annotating, whereas the Mac or a desktop computer is for focus,
    productivity, you know, the phone is for quick capture, the web is good
    for sharing. OK, so really you need your work to be seamlessly across
    all of them.

    But at the same time, you know, we want that sense of intimacy and

    certainly the performance and the feeling that it’s in your control and
    you own it, and it belongs to you.

    I think that maybe matters less for some consumer products, or maybe it

    matters less for more kind of B2B, you know, enterprisey products, but
    for this tool, which is for thinking.

    Which is very personal, which is very kind of needs to be at your

    fingertips and friction free. I think the local first approach would be
    a good fit for a lot of software, but I think Muse needs it even more than
    most. So that’s why I’m really excited to see how this works out in
    practice as people try it out, and we really don’t know yet, right? It
    may be that we’ve made this huge engineering investment and in the end
    customers just say, I’d be happy with the cloud, yeah, it’s fine. I
    have some spinners, I can’t access my work offline. I hope not. But
    that could happen. We could be like falsifying the business hypothesis,
    but I really believe that for our specific type of customer, you’ll go
    to use this product with the sinking layer, you know, once we shake out
    all the bugs and so on and say, you know, this feels really
    fundamentally different from the more cloud-based software that I’m
    used to like an ocean and also fundamentally different from the non
    syncing pure local apps that I might use.

    00:20:51 - Speaker 3: Yeah, I really think that with as connected as

    this world is and is becoming, there’s always going to be places of low
    connectivity, there’s always going to be places of just dodgy internet,
    and having an application that you know just always works, no matter
    what’s going on, and figures itself out later once it has good
    internet, is just so freeing compared to Those times when, you know,
    your device is switching Wi Fi networks or the LTE is just not quite
    what it needs to be to make things happen.

    I think it really does make a really huge difference, especially when

    you’re deep in thought, working on your content in use, the last thing
    you want is to be interrupted for even half of a second with a small
    spinner that says please connect to the internet. And so just being able
    to free the application and free the user from even worrying about the
    internet at all, even if it works 99% of the time, it’s that 1% of the
    time that breaks your train of thought that is just really frustrating.
    And I think that’s what’s exciting about being able to be purely
    offline is it fixes that really huge problem of that really small
    percentage of time that it happens.

    00:22:10 - Speaker 2: Very well said. Now with that, I’ll do a little

    content warning. I think we’re about to get a lot more technical than
    we ever have on this podcast before, but I think this is a topic that
    deserves it. So I’d love to, and me especially as someone who’s not
    deep in the technology and just observing from the sidelines, I’d love
    to hear about what’s the high level architecture, what are all the
    pieces that fit together here that make this syncs when you’re on the
    internet and lets you keep working even when you’re not? What is it
    that makes all that work?

    00:22:41 - Speaker 1: Yeah, I’ll give a really quick overview and then

    we can dive into some of the specific pieces.

    So to start with the logical architecture, the basic model is a user has

    a bag of edits, so you might have 1000 edits or a million edits where
    each edit is something like I put this card here or I edit this picture,
    and over time the user is accumulating all these edits and the job of
    the sync system is to ensure that eventually all of the users’ devices
    have the same bag of edits.

    And it passes those edits around as opaque blobs and different flavors

    of blobs we’ll talk about.

    Basically there’s a bunch of bits of binary data that all devices need

    to have the same, and then it’s the device’s responsibility to make
    sense of those edits in a consistent way.

    So given the same bag, each device needs to come up with the same view

    of the muse corpus of that individual user, what boards are alive and
    what cards are on them and so forth. And then briefly in terms of the
    physical architecture, there’s a small server that’s running on
    Hiokku, data is stored in post grass and S3 and it’s implemented in Go,
    and again the server is just shuffling binary blocks around basically.
    And then there’s different front ends, different clients that implement
    this synchronization protocol and present a use corpus model up to the
    application developers. So the most important of these is the SWF
    client. We also have a JavaScript client and both of these back to SOI
    databases locally.

    00:24:09 - Speaker 3: Yeah, and I think what’s really interesting about

    this architecture is that we actually maintain the entire bag of edits.

    Edits only get added into the bag, but they never really get removed.

    And so the current state of the application is whatever the most recent
    edit is.

    So if I make a card bigger on my Mac, and then I go to my iPad and I

    make that same card smaller. And then we synchronize those two things.
    Well, at the end of the day, either the card is going to be smaller on
    both devices, or the card is gonna be bigger on both devices, and we
    just pick the most recent one. And that strategy of just picking the
    most recent edit actually makes conflicts essentially invisible or so
    small and so easy to fix that the user can just, oh, I want that big,
    let me make it big again. It’s really easy to solve. For the user side
    without showing up one of those really annoying, hello, there’s been an
    edit. There’s a conflict here. Would you like to choose copy A or copy
    B? Just being able to automatically resolve those is more than half of
    the magic, I think, of this architecture.

    00:25:13 - Speaker 2: I also note this is a place where I think the muse

    domain, if you want to call it that, of the cards on a canvas model
    works pretty well with this sort of automated resolution, which is if
    you moved a card in one direction on one device and you moved it
    somewhere else on the other device, it’s not really a huge deal which
    one it picks as long as it’s all kind of like flows pretty logically.

    By comparison, text editing, so what you have in a Google Docs or

    certainly I know auto merge team and the incode switch team has done a
    huge amount of work on this, is a much harder space where you can get
    into very illogical states if you can merge your edits together,
    strangely, but I think a card move, a card resize, add remove, even some
    amount of reparenting within the boards, those things just are pretty
    natural to merge together, I think.

    00:26:02 - Speaker 3: Yeah, I think so, and I think even with the new

    text block feature in Muse, we end up slicing what would be a really
    long form text document into much smaller sentences or paragraphs. And
    so then text edits, even though we’re only picking the kind of the most
    recent one to win, we’re picking that most recent at the granularity of
    the sentence or of the the paragraph, and so. Conflicts between
    documents for us are larger than they would be for automerge or for
    Google Docs, but are small enough that it’s still ignorable for the
    user and easily solvable by the user.

    00:26:42 - Speaker 2: Which incidentally I think is a trick we sort of

    borrowed from FIMA, at least on the tech side, which is in FIGA and also
    in Muse. If one person edits, you know, the red car and someone else
    edits the blue car, you don’t get the red blue car, you just get one or
    the other, and it turns out for this specific domain, that’s just fine.

    00:27:03 - Speaker 3: Yeah, I think we kind of lucked out having such a

    visual model, and we don’t need to worry about intricacies of
    multi-user live document editing.

    00:27:13 - Speaker 1: Yeah, I would point to both Sigma and actual

    budget as two very important inspirations for our work. I would say
    those are two of the products that were most at the forefront of this
    space, and thought about it most similarly to how we did.

    And notably they, as well as us sort of independently arrived at this

    notion of basically having a bunch of last white wins registers. As the
    quote unquote CRDTs.

    So these are very, very small, simple, almost degenerate CRDTs where the

    CRDT itself is just representing one attribute, for example, the X
    coordinate of a given card. But this is an important insight of the
    industrial application of this technology, if you will. That’s a good
    trade-off to make it. It basically covers all the practical cases, but
    it’s still very simple to implement, relatively speaking.

    00:28:03 - Speaker 2: I also mentioned briefly actual budget, great in

    the basically made by one person app and recently open source, so you
    can actually go and read the custom CRDT work there and maybe learn a
    thing or two that you might want to borrow from.

    00:28:17 - Speaker 3: I think one of the really interesting problems for

    me about the CRDT was Deciding which edit is the most recent because it
    just makes logical sense to say, oh well, it’s 3 o’clock, and when I
    make this edit at 3 o’clock and I make a different edit at 3:02,
    obviously the one at 3:02 wins.

    But since computer clocks aren’t necessarily trustworthy, sometimes I

    have games on my iPad that reset every day and so I’ll set my clock
    forward or set my clock backward. Or if I’m on an airplane and there’s
    time zones, and there’s all kinds of reasons the clock might jump
    forward or jump backward or set to different problems, and so using A
    fancier clock that incorporates a wall clock, but also includes a
    counter and some other kind of bits of information, lets us still order
    edits one after the other, even if one of those clocks on the wall is a
    year ahead of schedule compared to the other clocks that are being
    synchronized. I don’t know how in depth we want to get on that, but
    it’s it’s called a hybrid logical clock.

    00:29:23 - Speaker 1: Yeah, I think this is another great example along

    with choosing very simple CRDT structures of industrial style
    architecture where you could go for a full blown vector clock, and that
    gives you perfect logical ordering and a bunch of other nice properties,
    but it’s quite large and it’s expensive to compute and so on. Whereas
    if you choose a simpler fixed size clock, that can give you all the
    benefits that you need in practice, it can be easier to implement, it
    could be faster to run, and so on.

    00:29:52 - Speaker 3: Like everything in life, it’s all about

    trade-offs, and you can get accuracy, but it costs more, or you can get
    a little bit less accuracy, and it costs a lot less, and for us that was
    the better trade-off to have a fixed size clock that gives us Enough of
    the ordering to make sense, but might not be exactly perfect ordering.

    00:30:13 - Speaker 1: And we’ve been alluding to trade-offs and

    different options, so maybe it’s time to address it head on in terms of
    the other options that we considered and why they weren’t necessarily
    as good of a fit for us. So I would include in this list both iCloud and
    what you call like file storage.

    00:30:27 - Speaker 2: It might be like cloud kit or something, but yeah,

    they have one that’s more of a blob, kind of, you know, save files,
    what people will think of with their sort of iCloud drive, almost kind
    of a Dropbox thing, and then they also have a cloud kit. I feel like
    it’s a key value store, but in theory, those two things together would
    give you the things you need for an application like ours.

    00:30:47 - Speaker 1: Yeah, so there’s iCloud as an option, Firebase,

    automerge. CouchDB maybe, then there’s the role you’re on which we
    ended up doing.

    00:30:57 - Speaker 2: Yeah, the general wisdom is, you know, you don’t

    write your own, if there’s a good off the shelf solution, you name some
    there that are commercial, some are built into the operating system
    we’re using, some are indeed research projects that we’ve been a part
    of, what ultimately caused us to follow our own path on that.

    00:31:15 - Speaker 1: Yeah, so there was a set of issues that tended to

    come up with all of these, and it was more or less in different cases,
    but I think it’d be useful to go through the challenge that we ran into
    and talk about how they emerged in different ones of these other
    solutions.

    So one simple one, it would seem it’s just like correctness slash it

    works. And the simple truth is, a lot of the singing systems out there
    just do not work reliably. Hate to pick on Apple and iCloud, but
    honestly, they were the toughest in this respect where sometimes you
    would, you know, admit data to be synchronized and just wouldn’t show
    up, and especially with opaque closed source solutions and third party
    solutions, stuff would not show up and you couldn’t do anything about
    it, like you couldn’t see what went wrong or when it might show up or
    if there was some error.

    And then bizarrely, sometimes the stuff would pop up like 5 or 10

    minutes later. It’s like, oh, it’s actually sort of worked, but it’s
    off by You know, several zeros in terms of performance. So that was a
    really basic one, like the syncing system has to be absolutely rock
    solid and it kind of goes back to the discussion Wulf had around being
    offline sometimes. If there’s any chance that the sync system is not
    reliable, then that becomes a loop in the user’s mind. Am I gonna lose
    this data? Is something not showing up because the sync system is
    broken. Our experience has been that if there’s any lack of reliability
    or lack of visibility into the synchronization layer. It really bubbles
    up into the user’s mind in a destructive way, so we want it to be
    absolutely rock solid. Another important thing for us was supporting the
    right programming model. So we’ve been working on news for several
    years now. We have a pretty good idea of what capabilities the system
    needed to have, and I think there were 4 key pillars. One is the obvious
    transactional data. It’s things like what are the cards and where are
    they on the board. This is data that you would traditionally put in a
    SQL database. Another thing that’s important to have is blob support,
    to a lot of these binary assets in use, and we wanted those to be in the
    same system and not have to have another separate thing that’s out of
    band, and they need to be able to relate to each other correctly.

    00:33:09 - Speaker 2: This is something where a 10 megabyte PDF or a 50

    megabyte video just has very different data storage needs than the tiny
    little record that says this card is at this X and Y position and
    belongs to this board.

    00:33:23 - Speaker 1: Right, very different, and in fact you’re gonna

    want to manage the networking differently.

    Basically you want to prioritize the transactional data and then load

    later, or even lazily, the binary data, which is much larger.

    Yeah, so there was transactional data, blob data, and then real-time

    data slash ephemeral data.

    So this is things like you’re in the middle of an ink stroke or you’re

    in the middle of moving a card around and this is very important to
    convey if you’re gonna have real time and especially multi-user
    collaboration, but again, you can’t treat this the same as certainly
    blob data, but even transactional data, because if you store every
    position a card ever was under your finger for all time, you’re gonna
    blow up the database.

    So you need those 3 different types of data, and they all need to be

    integrated very closely.

    So for example, when you’re moving a card around, that’s real time,

    but basically the last frame becomes a bit of transactional data, and
    those two systems need to be so lined up to each other that it’s as
    simple as changing a flag. If you’re going on a 2nd or a 3rd band for
    real-time data and need to totally change course for saving the
    transactional data, it’s not gonna be good.

    It was quite rare. I don’t know if we found any systems that support

    all three of these coherently.

    00:34:33 - Speaker 2: The ephemeral data element I found especially

    interesting because you do really want that real timey feeling of
    someone wiggles a card with their finger and you can see the wiggling on
    the other side. That just makes the thing feel live and Just responsive
    in a way that it doesn’t otherwise.

    But yeah, at the same time, you also don’t want hundreds of thousands

    of records of the card moved 3 pixels right, and then 3 pixels left.

    And one thing I thought was fascinating, correct me if I misunderstood

    this, but is that because the client even knows how many other devices
    are actively connected to the session, it can choose to not even send
    that ephemeral data at all. It doesn’t even need to tap the network. If
    no one else is listening, why bother sending ephemeral data? All you
    need is the transactions over time.

    00:35:21 - Speaker 1: Right, this is actually a good example of how

    there’s a lot of cases where different parts of the system need to know
    or at least benefit from knowing about other parts.

    So it becomes costly or or maybe just an outright bad idea to separate

    them, especially as we’re still figuring out as industry how they
    should work. I think there’s actually quite a bit of benefits to them
    being integrated.

    Another. that we could talk about eventually is prioritizing which data

    you download and upload, you might choose to first download blobs that
    are closer to you in board space, like it’s in your current room or
    it’s in adjacent rooms, and then later you can download other blobs. So
    that’s something you could do if the application had no notion of the
    networking layer.

    It actually brings us to Another big challenge we saw with existing

    systems, which is multiplexing. So I’ll use an example of automerge
    here, and this is something we’ve seen with a lot of research oriented
    CRDT work. It’s very focused on a single document, so you have a
    document that represents, you know, say a board or whatever, and a lot
    of the work is around how do you synchronize that document, how do you
    maintain correctness, even how do you maintain performance when you’re
    synchronizing that document across devices.

    Well, the challenge with Muse with our model.

    You might have, you know, easily 1000, but, you know, potentially tens

    of thousands up to millions of documents in the system corresponding to
    all your individual cards and so on. And so if you do anything that’s
    order and in the number of documents, it’s already game over. It needs
    to be the case that, here’s a specific challenge that I had in mind for
    the system. You have a corpus, let’s say it’s a million edits across
    10,000 documents or something like that, and it’s 100 megabytes. I
    wanted the time to synchronize a new device that is to download and
    persist that entire corpus, to be roughly proportional to the time it
    would take to just physically download that data. So if you’re on a 10
    megabyte connection, 100 megabyte connection, maybe that’s 10 seconds.
    But the only way to do that is to do a massive amount of like
    multiplexing, coalescing, batching, compression, so that you’re taking
    all these edits and you’re squeezing them into a small number of
    network messages and compressing them and so on. So you’re sort of
    pivoting the data, so it’s better suited to the network transfer and
    the persistence layer. And again, you need to be considering all these
    things at once, like how does the application model relate to the
    logical model, relate to the networking protocol, relate to the
    compression strategy, and we weren’t able to find systems that
    correctly handle that, especially for when you’re talking about
    thousands or millions of documents being synchronized in parallel. And
    the last thing I’ll mention is what I call industrial design
    trade-offs. We’ve been alluding to it in the podcast so far, but things
    like simplicity, understandability, control, these are incredibly
    important when you’re developing an industrial application, and you
    tend not to get these with early stage open source projects and third
    party solutions and third party services. You just don’t have a lot of
    control and it was too likely to my mind that we would just be stuck in
    the cold at some point where system didn’t work or it didn’t have some
    capability that we wanted, and then you’re up a dead end road, and so
    what do you do? Whereas this is a very small, simple system. You could
    print out the entirety of the whole system it would be probably a few
    pages, well it’s a few 1000 lines of code, it’s not a lot of code, and
    it’s across it’s a couple code bases, and so we can load the whole
    thing into our head and therefore understand it and make changes as
    needed to advance the business.

    00:38:38 - Speaker 3: Yeah, I think that last point might honestly be

    the most important, at least for me. I think having a very simple mental
    model of what is happening in sync makes things so much easier to reason
    about. It makes fixing bugs so much easier. It makes preventing bugs so
    much easier. We’ve been talking about how sync is hard and how almost
    nobody gets it right, and that’s because it’s complicated. There’s a
    bajillion little bitty edge cases of if this happens, but then this
    happens after this happens, and then this happens. What do we do? And so
    making something really really simple conceptually, I think was really
    important for the muse sync stability and performance at the end of the
    day.

    00:39:21 - Speaker 2: I’m an old school web developer, so when I think

    of clients and servers, I think of rest APIs, and you maybe make kind of
    a version API spec, and then the back end developer writes the endpoint
    to be called to and the front end developer figures out how to call that
    with the right parameters and what to do with the response. What’s the
    diff between a world that looks like that and how the new sync service
    is implemented?

    00:39:50 - Speaker 1: Yeah, well, a couple things. At the network layer,

    it’s not wildly different. We do use protocol buffers and binary
    encoding, which by the way, I think would actually be the better thing
    for a lot of services to do, and I think services are increasingly
    moving in that direction, but that core model of you have, we call them
    endpoints. You construct messages that you send to the endpoint and the
    server responds with a response message. That basic model is pretty
    similar, even if it’s implemented in a way that’s designed to be more
    efficient, maintainable, and so on than a traditional rest server.

    But a big difference between A traditional rest application and the muse

    sync layer is that there are two completely separate layers, what we
    call the network layer and the app layer. So the network layer is
    responsible for shuffling these binary blobs around the transactional
    data, the ephemeral data, and the big binary assets. And the server
    knows absolutely nothing about what’s inside of them by design, both
    because we don’t want to have to reimplement all of the muse logic
    about boards and cards or whatever in the server, and also because we
    anticipate eventually end to end encrypting this, and at that point, of
    course, the server can’t know anything about it, it’s not gonna be
    possible. So that’s the networking layer and then if you sort of unwrap
    that you get the application layer, and that’s the layer that knows
    about boards and cards and edits and so on. And so it is different, and
    I would say it’s a challenge to think about these two different layers.
    There’s actually some additional pivots that go on in between them,
    versus the traditional model of you would like post V1 slash boards
    directly and you’d put the parameters of the boards and then the surfer
    would write that to the boards table and the database. There’s a few
    different layers that happen with this system.

    00:41:30 - Speaker 2: So if we want to add a new card type, for example,

    or add a new piece of data to an existing card, that’s purely in the
    application layer on the back end, or it doesn’t know anything about
    that or no changes are needed on the back end.

    00:41:44 - Speaker 1: Yeah, no changes are needed.

    In fact, one of the things I’m most proud about with this project is we

    basically haven’t changed the server since last year, December, and
    we’ve been, you know, rigorously iterating on the app, you know, adding
    features, changing features, improving a bunch of stuff, and the
    servers, it’s basically the same thing that was up 4 months ago, just
    chunking along, and that’s a benefit. It’s a huge benefit, I think, of
    this model of separating out the application model and the network
    model, because the network model is eventually gonna move very slowly.
    You basically figure that out once and I can run forever. And the
    application model has more churn, but then when you need to make those
    changes, you only need to make them in the client or the clients that
    maybe you update the application schema so that current and future
    clients can understand that, and then you just start including those
    data in the bag of edits.

    00:42:26 - Speaker 3: Yeah, I think one thing that’s really nice is

    that those protocol buffers that you were talking about are type safe
    and kind of statically defined, so that way it’s when we’re sending
    that message over the wire, we know 100% we’re sending exactly the
    correct messages no matter what, and that guarantee is made at compile
    time, which I think is really nice because it means that a lot of bugs
    that could otherwise easily sneak in if we’re using kind of a generic
    JSON framework, we’re gonna find out about when we hit the please build
    muse button. Instead of the I’m running views and I randomly hit a bug
    button. And that kind of confidence early on in the build process has
    been really important for us as well to find and fix issues before they
    even arise.

    00:43:11 - Speaker 1: Yeah, to my mind this is the correct way to build

    network clients. You have a schema and it generates typesa code in
    whatever language you want to use.

    There’s just enormous benefits to that approach. I think we’re seeing

    it with this on use and again, I think more systems, even more
    traditional B2B type systems are moving in this direction.

    By the way, everyone always made fun of Amazon’s API back in the day. I

    had this crazy XML thing where There’s a zillion endpoints. I actually
    think they were closer to the truth and the traditional, you know, nice
    rest crud stuff because their clients are all auto generate and sure
    enough they have like literally a zillion endpoints, but everything gets
    generated for free to a bunch of different languages.

    Anyways, one challenge that we do have with this approach is, you know,

    one does not simply write a schema when you have these multiple layers.
    So again, if you look at a traditional application, you have a protocol
    buffer definition of, say, a board B board and probuffs. And that would
    have fields like title and width and height or whatever. And when you
    want to update the board, you would populate a memory object and you
    would encode this to a protocol buffer and you would send this off to
    the server. Well, it’s not quite that simple for us because we have
    this model of the small registers that we call atoms.

    So an atom is the entity, say a board, the attributes say the title, the

    value say use podcast, and the time stamp. And your bag of edits is
    comprised of all these different atoms, but the problem is, how do you
    encode both how you’re gonna send an atom, which is as those twopos, as
    well as what a logical board is, you know, what the collection of atoms
    is meant to look like, you know, it’s gonna have a title and the width
    and height and so on. So that’s been honestly a pretty big challenge
    for us where it doesn’t fit into any of the standard schema definition
    approaches, certainly not the regular protocol buffer schema, which
    again we use for the network and for encoding the messages that are
    wrapped up in the network, but you need a separate layer that encodes
    the application model, as we call it, you know, what is a board, what is
    a card, what attributes that they have and so on.

    00:45:06 - Speaker 2: And Wulf, if I recall you have a blog post about

    these atomic attributes. I’ll link that in the show notes for folks.

    00:45:14 - Speaker 3: Yeah, so unfortunately no relation between my name

    and Adam. It’s a TOM.

    00:45:18 - Speaker 2: Yes, we have two Adams on this podcast. The ADAM

    is different from the ATOM.

    00:45:25 - Speaker 1: Yeah. A big inspiration on this, by the way, is

    Tomic, I don’t know if we’ve mentioned that yet on this podcast, but
    Atomic is a database system developed by Rich Hickey and team who is
    also the creator of Closure. And it uses this model in contrast to the
    traditional relational model you have tables and columns and rows.

    The atomic model is more like a bag of time stamped attributes where you

    have an entity, an attribute, a value and a time stamp. And from that,
    it could be more challenging to work with that model, but it’s
    infinitely flexible. You can sort of put whatever model you want on top
    of that, and it works well for creating a generic database system.

    You know, you couldn’t have a generic post graphs, for example, that

    could run any application. You need to first create tables that
    correspond to the actual application you’re trying to build, whereas
    with an atom oriented database, you basically have one huge table which
    is atoms. So it’s useful again for having this slower moving more
    stable synchronization layer that handles moving data around that you
    build the application on top of that moving quickly.

    00:46:27 - Speaker 3: Yeah, and like we talked about earlier, it’s so

    much simpler to reason about. All of the problems of my iPad is on
    version 1, my Mac is on version 2, and my iPad Mini is on version 3.
    They’re sending data back and forth. At the end of the day, every
    single database on all three of those clients is gonna look the same,
    even though they have completely different logic, maybe different
    features. But all the simplicity of that data store makes it much, much
    easier to reason about as the application gets upgraded or as two
    different versions of the client are synchronizing back and forth.

    00:47:03 - Speaker 2: How does that work in practice? So I can certainly

    imagine something where all of the data is sent to every client, but a
    V1 client just doesn’t know what to do with this new field, so just
    quietly stores it and doesn’t worry about it. But in practice, what
    happens if I do have pretty divergent versions between several different
    clients?

    00:47:23 - Speaker 1: Recall some podcasts ago, we suggested that

    everything you emit should have a UU ID and a version. Well sure enough
    that’s advice that we take to heart with this design, where all the
    entities, all the messages, everything has a UU ID and also
    everything’s version, so there’s several layers of versioning.
    There’s the network protocol is versioned and the application schema is
    versioned. So by being sure to thread those versions around everywhere,
    the application can then make decisions about what it’s gonna do and
    Wulf can speak to what the application actually chooses to do here.

    00:47:54 - Speaker 3: Yeah, exactly. If we’re sending maybe a new

    version of a piece of data on the network layer that device A just
    doesn’t physically know how to decode from that work, then it’ll just
    save it off to the side until it eventually upgrades and then it’ll
    actually read it once it knows what that version is.

    00:48:11 - Speaker 2: So is there someone like, can I make a crude

    metaphor here, someone emails me a version of a Word doc from a later
    version that I don’t have yet, I can save that on my hard drive, and
    later on when I get the new version, I’ll be able to open the file.

    00:48:25 - Speaker 3: Yeah, exactly right. It’s very similar to that.

    And then I think there’s a different kind of upgrade where we’re
    actually talking the same language, but I don’t know what one of the
    words is that you said.

    So let’s say we add a completely new content type to muse called the

    coffee cup, and everyone can put coffee cups on their boards, right?
    That coffee cup is gonna have a new type ID attribute that kind of
    labels it as such.

    New clients are gonna know what type 75 means coffee cup, and old

    clients are gonna look at type 75 and say, oh, I don’t know about Type
    75, so I’ll just ignore it.

    And so the data itself is transferred over the network schema and kind

    of the app schema and understands those versions, but it might not
    understand the physical data that arrives in the value of that atom.

    And in that case, it can happily ignore it and will eventually

    understand what it means once the client upgrades.

    And so there’s a number of different kind of safety layers where we

    version something. If we’re unable to even understand kind of the
    language that’s being spoken, it’ll be saved off to the side. If we do
    understand the language that’s spoken, but we don’t understand the
    word, we can just kind of safely ignore it, and then once we are
    upgraded, we can safely understand both the language and the word.

    00:49:47 - Speaker 1: Yeah, so maybe to recap our discussion of the low

    level synchronization protocol before we go on to the developer
    experience and user experience, might be useful to walk through a sort
    of example.

    So suppose you are doing a thinking session in your nice comfy chair on

    your iPad, you’re offline, you’re making a few dozen edits to a series
    of different boards and cards in your corpus. Those are going to write.

    New atoms in your database, and those are essentially gonna be flagged

    as not yet synchronized, and then when you go online, those atoms,
    assuming it’s some plausible number, you know, it’s maybe less than
    1000 or so. Those are all gonna be combined into a single network
    message.

    So this is that multiplexing efficiency where you certainly don’t need

    to check every document in your corpus, and you don’t even need to do
    one network right per every edit or even one network right per document.
    You can just bundle up all of your recent changes into a single protocol
    buffer message and could potentially compress it all with GSIP, and then
    you send that out to the server.

    The server doesn’t know anything about these edits, you know it’s just

    one big binary packet. The server persists that, and then it sends a
    response message back to the client and says, OK, I’ve successfully
    received this. You can now treat this as synchronized and the server
    will take responsibility for broadcasting it out to all the clients.

    And then clients as they come online, if they’re not already online,

    they will immediately receive this new packet of data called a pack. And
    then they can decompress and unpack that into its constituent atoms, and
    once they’ve processed those, tell the server, I have successfully
    saved this on my device and in the background of the server is
    essentially maintaining a high watermark of for each device that’s
    registered for this user, what’s the latest pack or block they
    successfully persisted, and that way as devices come on and offline, the
    server knows. What new data needs to send to each individual device, and
    that works both for essentially conveying these updates in near real
    time as they happen, as well as for doing big bulk downloads if a device
    has been offline for a long time.

    And I know we’ve mentioned a few times, but to my mind this

    multiplexing and batching and compression is so important, so it’s the
    only thing that makes this even remotely feasible with the Muse data
    model of having a huge number of objects. And then I think this leads
    pretty naturally to a discussion of the developer experience. So we’ve
    talked about this sort of sync framework, and that essentially is gonna
    present a developer interface up to the application developer. So Wulf,
    maybe you can speak a little bit to that.

    00:52:19 - Speaker 3: Yeah, we’ve talked some about the simplicity that

    we’re aiming for, just conceptually and how synchronization works.

    I think it’s equally important for this to be extremely simple for the

    end developer to use as we’re building new features in use or as
    we’re, you know, changing the user interface around.

    That developer, whether it’s me or Julia or anybody else working on

    Muse, doesn’t need to be able to think in terms of sync at all. We just
    need to be able to write the application is the ideal world, needs to be
    very, very simple.

    And so keeping that developer experience simple was a really big piece

    of designing what sync looks like inside of Swift for iOS.

    Since we had been built on core data beforehand, a lot of that developer

    interaction ends up looking extremely similar to core data. And so we
    build our models in Swift, it’s a Swift class. We have all of the
    different attributes where there’s position, and size, and related
    document, and things like that, and we just stick what’s called in
    Swift a property wrapper, it’s just a small little attribute. In front
    of that property that says, oh by the way, this thing, this thing
    belongs in the sync database. This property is gonna be merged, and that
    one little piece of code, that one little kind of word in the code
    program is what fires up the sync database and the sync engine behind it
    to make all of this stuff work. And that has been really important both
    for conceptually building new features, but also for migrating from core
    data to sync. Because the code that core data looks like beforehand, and
    the code that sync looks like now, is actually extremely similar.

    Early on in the development process, our very first kind of internal

    beta, internal alpha, pre-alpha, whatever version you want to call it.
    Very early on in the process, we actually ran both core data and the
    sync engine side by side. So some of the data in Muse would load from
    core data and other bits and pieces would load from sync, but both of
    those, because they looked very, very similar from the developer’s
    perspective, from kind of how we use both of those frameworks. It
    allowed us to actually slowly migrate use over from one to the other, by
    replacing bits of core data with bits of sync, and then this little bit
    of core data with this little bit of sync. I mean there’s, you know,
    thousands and 10s of thousands of lines of custom logic to make muse
    muse. And so it was really important to keep all of that logic running,
    and to keep all that logic separate from the physical data that logic
    was manipulating. And so making those appear similar to the developer,
    let us do that. It let us keep all of that logic essentially unchanged
    in use while we kind of swap out that foundation from underneath it.

    00:55:15 - Speaker 2: And I remember when you implemented the first pass

    at this persistence library, and I forget if Yuli was maybe away on
    holiday or maybe she was just working on another project, but then she
    came in to use your kind of first working version and start working on
    the sort of porting it across and she had a very positive reaction on
    the developer experience, you know, you are sort of developing the
    persistence layers so you naturally like it because.

    Here, maybe the way you like it and you’re thinking about the

    internals, she’s coming at it more from the perspective as a consumer
    of it or a client or a user, and the developer experience, and I found
    that to be promising because I mean, she, like most, I think iOS
    developers has spent many, many years in her career using core data.
    Which is a long developed and well thought through and very production
    ready persistence layer that has a lot of edge cases covered and is well
    documented and all that sort of thing.

    So in a way it’s a pretty high bar to come in and replace something

    like that and have someone just have a positive reaction to using it as
    a developer.

    00:56:21 - Speaker 3: Yeah, I was so happy when she said that she kind

    of enjoyed using it and kind of understood how it worked, because of
    course every developer likes their own code, but when a developer can
    use and is comfortable with another developer’s code, that’s really,
    really important. And that was absolutely one of my goals is to make
    sure that it was simple for Julia to use and simple for any other
    developer that comes onto the Muse team that doesn’t have background in
    Muse and in our code base. For them to be able to jump in quickly and
    easily and understand what’s going on, was a really important piece of
    how this framework was built.

    00:56:57 - Speaker 1: Yeah, I think this is a really important

    accomplishment, and Wulf is maybe even underselling himself a little
    bit, so I want to comment on a few things. One is, while there’s just
    this simple annotation of I think it’s at merged is that it Wulf. Yeah,
    that’s right.

    Sometimes when you see that, that annotation instructs the framework to

    do something additionally on the side, on top of the existing standard
    relational database, you know, like basically do your best, try to
    synchronize this data out of band with some third party service or
    whatever.

    But this in fact totally changes how the data is persisted and managed

    in the system, so it’s sort of like a whole new persistent stack for
    the application. And I think that’s important because we constantly see
    that the only way you get good results on sync system, 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, you know, true data synchronization and
    persistence layer. So I think that’s as important though. There’s
    another subtle piece here, which is the constraints that you have with
    the industrial setup. So a lot of the research on CRDTs and
    synchronization basically assumes that you have one or a small number of
    documents in memory, and that if you’re going to be querying these
    documents or managing synchronization of these documents that you have
    access to the full data set in memory. But it’s not practical for our
    use case, both because of the total size of memory and the number of
    documents we’d be talking about. So a lot of critical operations can
    take place directly against the database or the data layer can smartly
    manage bringing stuff in out of memory. It’s not like we have the whole
    new corpus up in memory at any one time, the system has to smartly
    manage what gets pulled up from disk in the memory and what gets flushed
    back, and then that. Introduce a whole bunch of like, basically cash
    coherency and consistency issues. So that’s a very tricky problem to
    manage, some of which are just hard engineering problems, but some of
    which would not even be possible, again, if we didn’t have this
    approach of owning the whole stack, we can control everything from top
    to bottom. So, for example, you might want to be able to query, select
    all boards where the title is Fu, and to be able to do that directly
    against the database with a single SQL query. Well, there’s no hope of
    doing that with a system where the data is stored opaquely to you. You
    need to be able to understand exactly how the data is persisted all the
    way down on disks so you can bring it up to memory efficiently. That’s
    a good example of the type of thing that we’re able to do with the
    system.

    00:59:25 - Speaker 3: Yeah, exactly right.

    And as new changes come over the network, if the object is already

    loaded into memory, then that object can immediately see those changes
    from the network, update its properties, and be immediately live in the
    user interface. And if that object is not loaded into memory, then those
    changes from the network just get saved directly to the database. And so
    the data that the object uses to hydrate its properties and to actually
    use its logic internally is the exact same structure as what’s stored
    in the database and it’s the exact same structure that gets sent to and
    from the network. And that consistency across all three of those places
    is extremely important, as Mark was saying, because it means that
    you’re not. Having to maintain 3 different representations of the same
    data, you’re only maintaining exactly 1 representation of the data, and
    that consistency is extremely important as hundreds or thousands of
    changes are going up to the network, down from the network, loaded from
    the database, and you’re moving all these things around in memory,
    keeping everything consistent in that one data format has been extremely
    important.

    01:00:34 - Speaker 1: One other challenges I’ll mention here, I’m

    actually not even sure how you solve this. Well, so maybe you can
    enlighten me here.

    Most of these systems again in the research setting, they use a

    functional reactive rendering approach, and briefly, this is where you
    give the renderer a complete snapshot of the world, and it renders the
    world, and then For an update, you just give it a complete new snapshot
    and it smartly looks at the discs between the old snapshot and the new
    snapshot and efficiently affects the appropriate updates in the UI.

    This is important because that’s very amenable to the synchronization

    model where you have updates coming in from all over the place. You have
    updates from your local device, you have updates from the network,
    updates from disk. And it’s very convenient to be able to just merge
    those in to a single new view of the world and tell the UI to go figure
    it out. You know, I’m not really sure who edited what here, but
    something changed, please re-rendered the screen so it looks right.
    That’s a very convenient property that you have, for example, in a lot
    of JavaScript based systems that use React. But that’s not how the
    traditional UI stack works in Swift, as far as I understand it, it’s a
    more imperative model if you say, put this thing here, change the color
    to this, make the dimensions this, and that can be very efficient and
    it’s certainly straightforward when you’re getting started, but it’s
    not clear to me how we actually affect the right changes when you have
    these updates coming in from all over the place. So maybe you can speak
    a little bit to that, Wulf.

    01:01:49 - Speaker 3: Yeah, and some of that is actually borrowed from

    core data where in core data you load up a context, you make a bunch of
    changes to the model, and then at the very end of that you say, OK, save
    everything, go, and Core model kind of held everything in memory for a
    little bit, but not until that last save command does it actually
    physically write to the database and kind of ensure that it’s
    permanent.

    And something similar happens for us where if there’s 100 changes that

    come down over the network, we apply all 100 of those changes, but then
    at the very end of that network call, there’s an, oh by the way, I just
    saved a bunch of stuff, call that goes out, and that notification goes
    out to the rest of the code base that says, hey everybody, I just
    changed these object IDs and these attributes inside of these scopes.

    And so, we haven’t quite talked about scopes and object IDs, but scopes

    are basically a bag of objects and objects are a bag of attributes.

    You can think of it that way.

    So when that notification goes out, then the rest of the UI already

    knows, hey, I’m displaying board A with cards B, C and D, and so when
    that notification goes out that says, hey, by the way, everybody, I just
    updated whatever object B is, good luck, then our interface can say, oh,
    I have a card name to B. Great, I’m gonna go update that and make sure
    it’s OK. And so the physical object and memory actually does get
    updated immediately.

    When network requests come in, but the interface updates only after a

    save command or only after some very specific notifications that show
    up. And that has been very important because if there are 100 updates
    coming down from the network, I don’t want to update the user interface
    100 times. I want to update the interface once after all those 100
    updates have been processed, and that makes things a lot quicker for us
    to be able to say. When do I update, why do I update, and which object
    is it that caused this update? All of that information lets us
    efficiently update the interface as changes come in or as changes are
    saved.

    01:03:55 - Speaker 1: So it’s coalescing and batching all the way down,

    you’re saying.

    01:03:58 - Speaker 3: Exactly, yeah, it’s a giant pile of coalescing

    and caching all the way down as turtles all the way down for sure.

    I think one last piece of the developer experience that has been really

    important is we talked about this a bit with the protocol buffers and
    how that uses a lot of code generation. For all of the models in Swift
    are generated from that single protobuff schema, but then once that
    schema is built, we actually do a second round of code generation using
    a program called Sorcery, and we can link that down below as well, but
    that actually reads the SWIFT code that is generated by Protobuff and
    lets us use templates to create even more SWIFT code from that original
    SWIFT code and so, One important thing is type safety, which we’ve
    talked about with Protobuff, and what type safety gives us is compile
    time errors, if there’s anything wrong. And so a big piece of what we
    could generate is that query syntax to say, hey, give me all the boards
    with title Fu, making sure that that returns boards and not cards and
    not URLs or tweets or anything else. All of that code for searching our
    database is. Code generated off of the code that was generated from
    Protobuff. And so that’s been another really, really helpful piece is
    there’s probably hundreds and hundreds of lines of code that are
    guaranteed type safe and generated for us to use, which prevents us from
    making type unsafe bugs in the code.

    01:05:40 - Speaker 2: So the beta has been online for a few months,

    we’ve been using it internally longer than that.

    I think I’ve been using it kind of as my primary use place for about 5

    months, and we’ve had something like 400 beta testers, which is A big
    enough number to give it a real solid run even though it’ll be a small
    fraction of the folks that will be using it after launch.

    Now it would be great to hear both the user experience side of what

    we’ve learned from using a system like this in practice, again, not
    just in the research context, as well as the what has it been like
    debugging problems on the client side and kind of running a production
    server at this scale. Yeah, I’d love to get into the lessons learned
    with you guys a little bit.

    01:06:30 - Speaker 1: I would say that especially from the server and

    protocol side, it’s been going very well so far.

    We spent a lot of time going back to several years of research in the

    lab to try to understand how to correctly architect and design a system
    like this, and I think we were able to bring a lot of those lessons to
    bear.

    I think it’s basically working well, like the model that we have with

    atoms and objects and scopes and a separate network and outplay that’s
    all working great. And like I said, I basically haven’t touched the
    server. And almost half a year now, it’s just chunking along, even as
    we add all these new users, so that’s great. And well, how do you feel
    it’s been going on the client side?

    01:07:04 - Speaker 3: I think the interesting thing for kind of bug

    finding and bug fixing is how the network relates to what’s going on on
    the client. There’s been some either whether it’s performance or
    whether it’s just logic bugs or user interface bugs, where it relies
    on.

    Your iPad is currently in this state and it receives this network

    message at the same time that the user is doing this action, and it
    manifests in this way.

    And so then setting up a reproducible case. To make sure that I get that

    same network message in can sometimes make it a very slow iteration to
    debug, because I need to constantly set up the network to do the right
    thing, then set up the iPad to have the right initial state, watch
    everything happen to reproduce that one bug. But once I’ve found kind
    of what those messages are, then it becomes a lot easier because I can
    set up a unit test locally, where I can actually spin up multiple
    clients locally inside of the unit test and say, OK, device A creates
    this, device B creates this, I synchronize, I see the bug, now I can fix
    it. And so some of the I’m not sure if this is a lesson so much as a a
    war story, but it’s just the difficulty of making sure that the initial
    state and the network state are easily reproducible to find the bug. And
    then once you’ve found it, it’s actually really straightforward to,
    you know, fix it, but just finding the cause of the bug sometimes in
    this kind of distributed system can be a bit tricky because what I see
    on my iPad with the same data that you see on your iPad. Might function
    very differently depending on what we have going on in the network, or
    how big our corpus is, or what else is going on in the background.

    01:08:57 - Speaker 1: Yeah, it actually makes me think that an important

    lesson learned is that the client is actually much harder than the
    server, and the reason is the client is much more multidimensional.

    There’s the data side and the application logic side, and the rendering

    side, and there’s a bunch of third party code in there and there’s,
    you know, batteries and networks. It’s basically a wild environment,
    whereas the server is just very regimented. There’s like a dozen
    messages that come in and out. It’s all. In one single queue, it has a
    single database that it’s talked to, and it’s complex and that the
    whatever, 2000 lines of code are very subtle and you got to get them
    right.

    But once you figure things out, it’s pretty nailed down, whereas, like

    I said, the client side is just wild. And so that’s an important lesson
    that you just got to expect that when you’re shifting a lot of your
    model to the client, you got to invest more there.

    I’m also saying on debugging and debugability investing there always

    pays off, so we mentioned IDs inversions. I’m a huge fan of logging,
    which is log everything everywhere, and our standard model whenever we
    encountered a bug, is whoever saw the bug identifies the request ID that
    corresponds to when that happened, and then we just produce the logs and
    both the client and the server that are tagged with that ID and then you
    can go from there. That’s been very important.

    Another thing is assertions. I’m a huge fan of assertions. I can’t

    tell you how many times I’ve added assertions to this code base. I’m
    like, there’s no way we ever trip this up, you know, how could we ever
    possibly send a blank value here? And then sure enough, two weeks later
    I get this alert on Century, you know, someone submitted a blank string
    for this attribute. What? How did that possibly happen? Oh, it’s well,
    you know, A and B and C and yeah sure enough that’s what happened. So
    it’s really important to add these ratchets, type checks, the
    assertions, the validations, it all pays off.

    01:10:35 - Speaker 3: Yeah, I’m glad you mentioned logging. I think

    having those unified IDs for those network messages back and forth and
    having really verbose logging on both the client and the server, when
    something pops up and we have a problem, we can look through those logs
    and actually trace down exactly kind of what went wrong and reproduce
    that state.

    And that’s another honest benefit of this kind of bag of atoms state is

    that we’re only ever adding items to this bag, we’re never changing
    items that are already in the bag, and we’re never removing items from
    the bag.

    And so we can also just look through the bag and see, OK, I know that I

    got change A, B, and C, did they end up in the bag or not? I have A and
    B, but where did C go? And so being able to have those identifiers and
    have such a simple conception of what the sync database physically looks
    like, really lets us get down to the cause of almost anything we’ve run
    into we’ve been able to solve with logs and identifiers, those two
    things have been able to point us in the right direction.

    01:11:41 - Speaker 1: I’ll also come back to multiplexing one last

    time. It was such an important investment for us to make for the system
    to work, and I actually realized there’s one step of multiplexing that
    I forgot to mention.

    So we talked about how the clients, they all gather up their edits into

    one or a few packs. Those all get sent to the server, by the way, those
    packs can be bunched up into a single message, so that’s another layer
    of packaging and compression, but then the server.

    The server has this challenge of there’s basically a zillion clients in

    the world and one or a few servers and databases and needs to manage all
    of the rights.

    So if the sync server did a post graph database right for every time

    someone did an ink stroke or moved a card, there’s no way that would
    work. The round trip times alone would be prohibitive. And even if the
    server did a database right for every time a pack of changes came in
    from an individual device, it would still probably be prohibitive
    because eventually you’re gonna have a lot of devices online. So the
    server actually does is that again, it does a coalescing and a batching
    and every, I think it’s 5. 100 milliseconds, it takes all of the edits
    that have arrived in that time frame and writes them into the database
    in a huge bulk transaction, and then fans out the responses to all the
    devices. That’s another layer where if we didn’t have that, I don’t
    know if it would fall over immediately, but certainly as we get more
    users, it would become unviable. So I think this idea of multiplexing
    back and forth is really important, and it’s honestly been a huge
    amount of work, but now that we have it, I think it’s gonna be really
    key.

    01:13:09 - Speaker 2: And I’ll weigh in on the lessons learned from the

    user experience side. First, there’s certainly the response we’ve
    gotten from a lot of beta testers, which is, I would actually just call
    it surprise at the speed and responsiveness of the syncing.

    But for me and my heavy use of it, I’m a heavy Muse user always have

    been, but I think especially leading up to this launch, there was a lot
    of strategy work to do and a lot of ideation work to do in terms of all
    the storytelling materials and so on.

    So I found myself using it especially heavily and having the Mac app

    also increases the utility and so on, but it’s almost confusing that on
    one hand, you get this thing that is a native app and everything happens
    instantly, and there’s never a spinner, and it never says now loading,
    and there’s never the stutter that you just come to expect from web SAS
    apps. But at the same time, it has this incredible liveness. So I would
    say that maybe coming back to comparing some of these other types of
    systems like iCloud is a good example where iCloud is quite good in
    terms of never blocking the application while you wait for something,
    but then it might be. 30 seconds till it propagates your other device
    and you’re sort of refreshing or staring at the screen or waiting for
    it to show up and uses between my Mac and iPad has that liveliness that
    I’ve come to associate with the Google Docs or a Figma, but then it
    doesn’t have that flakiness that I’ve come to associate with those
    things, and indeed I have often used more typically my iPad when I’m in
    an offline environment traveling or something like that. And yeah, it’s
    just so use the word freeing early in the discussion here today, Wulf,
    which is freeing you of the worry that you’re gonna hit that hiccup,
    your network’s gonna hit that hiccup, and suddenly you can’t access
    what you’re doing or you’re gonna get stuck. But at the same time, I
    can feel complete confidence or feel completely comfortable that things
    are gonna get synced and I’m not gonna get, for example, a weird merge
    conflict as I do sometimes with Dropbox, much as I love Dropbox and A
    major tool in my tool kit for a lot of years. I have also had things
    sort of disappear or seem to get lost because there’s a merged conflict
    that sticks the conflict off to the side, and I don’t notice that it’s
    there until two weeks later, something like that. So Muse somehow manages
    to really get the best of both of those worlds with the local first
    sink. And in a way that almost feels like getting away with something,
    or you’re cheating somehow, it’s no way, you can’t have both of these
    things together, you have to pick one. So that to me is amazing, a
    little magical really.

    01:15:47 - Speaker 1: And relatedly, I’m also very happy with our

    investment and giving the user visibility into what’s happening with
    sync.

    We learned in our research at the lab on sync that there’s the actual

    performance of sync, then there’s the like consistency and reliability
    of it, and then there’s the layer of being honest with the user about
    what’s happening, and it’s often not the sync is slow or it’s not
    working that gets you, it’s lying to the user about it or not giving
    them any way to understand what’s going on.

    And so we make as an absolute first class citizen in this protocol, the

    ability to understand exactly how many bytes you have left to sync of
    both the transactional blob types.

    So anytime you can always see how much do I have left to sink. Is it

    growing or shrinking, that is, is stuff getting added into my bag faster
    than I’m able to sink it down. And you get a definitive message when
    you have 0 left. Like you can say, OK, I’ve in fact synchronized every
    bite that’s known to my universe of Muse Corpus. And we reflect that in
    the eye, and I think that visibility into the rock style and sinking
    performance is really key.

    01:16:51 - Speaker 2: Yeah, so if you’re getting a chance to try out

    Muse 2.0, uh, I definitely recommend just looking in the lower right
    corner of either your window or your screen where you’ll see a little
    circle, and it can be filled in or not filled in, depending on your
    network status, and it will kind of pulse a little bit, just very gently
    when it’s.

    Working, uploading or downloading, inspired by the old school hard drive

    indicator lights, and then you can tap on it or click on it to open and
    get detailed information about the amount remaining to upload and
    download. It’s very simply done, but it helps give you that visibility
    precisely, as you said, and love to get back some time to talk about the
    design work that went into that because we think that part of things is
    really important.

    Well, with the launch around the corner, I’m really excited to see how

    this scales in practice. I’m sure we’ll have a few server meltdowns
    and difficult bugs and so on, but it is very much the proving out this
    technology in a way to help take it from the lab and take it from the
    world of theory and research.

    And show that it is something that can be done in the real world and is

    valuable and beneficial to customers that they find that their software
    works better and they are able to work better and in the case of M’s
    domain that they are able to think better because they have this fluid
    connection between all their devices.

    So what are some of the things we’ll be building on top of this

    technology foundation in the future?

    01:18:21 - Speaker 3: I would love to see an eventual web version of

    Muse and taking the JavaScript sync client that we’ve written and
    actually flushing out what a browser version of Muse might look like. I
    think that could be really interesting. And then of course there’s
    options for Android or for any of the other tablets that are out there,
    I think would be fun. I think being able to share any board with a link
    over the web and just have a full new experience load up, I think would
    be really fascinating use of sync and collaboration.

    01:18:53 - Speaker 1: Yeah, I think a web client could be very

    interesting.

    There’s also the iPhone, maybe that’s obvious, but we currently have

    this very minimal iPhone app and we’ve long said that the phone is one
    of the three pillars, is one of the three key device types.

    It has its own unique use case.

    So I think to realize that vision will need to have a full blown in its

    own way use client for the iPhone.

    And then looking further afield, the system was designed for day one to

    support not only multiple devices from the same user, but also multiple
    users collaborating on documents and that actually required quite a bit
    of design affordances.

    Sort of inserted into the structure here so that we’d come back in a

    year or two and like, you know, turn this key and be able to enable
    collaboration.

    So looking forward to potentially exploring that and then looking even

    further beyond that, this could be a very important enabler for end user
    programming.

    You think about like how do you program data that you don’t even have

    access to? Do you like just HTP get it all and then change it and then
    HT posts it back and that doesn’t really work in the world of
    traditional rest APIs, whereas if you have the full data set and it’s
    just sort of this live multiple thing where anytime you turn it or Touch
    it, it’s magically reflected through the ether on all the other
    devices.

    I think that could be a really powerful substrate for doing end user

    programming eventually.

    And then conveniently at this time, you’ll have this nice whole corpus

    of data that’s very important and personal to you that you would be
    motivated to manipulate with programs. So that could be a fun thing to
    explore.

    01:20:19 - Speaker 2: All very exciting. So yeah, the multi-device path

    is really just the beginning and also will help us prove out that this
    technology can work and that it can scale and that our team can handle
    it. And speaking of team, we do have jobs related to this, so this sort
    of work sounds interesting to you and you have skill with CRDTs or
    anything we’ve discussed here, you should check out our jobs page,
    perhaps a local first job with the new team is in your future.

    01:20:50 - Speaker 3: Absolutely, and if you’re excited and don’t have

    experience with CRDTs, that’s probably fine too. 2 years ago, I had no
    idea what a CRDT was, and yet here we are.

    01:21:00 - Speaker 2: Now you’re on the forefront of the field.

    01:21:02 - Speaker 3: Yeah, now we’re doing it.

    01:21:03 - Speaker 2: Also at that point, I think you’ll be giving a

    talk at the, as I understand it, is the world’s first local first
    conference, which is happening here in Berlin in June as part of a
    larger academic event. You wanna plug that quickly, Wulf?

    01:21:17 - Speaker 3: Yeah, I’m really excited about it. It’ll be on

    June 7th, will be the piece that I’m doing. There’s gonna be lots of
    talks about where Local First is going and how it’s being used in a
    whole number of different places. And so I’ll be giving a short talk on
    Local first in Muse and doing a little bit more detail about how our
    CRDT works and what some of that back end infrastructure looks like in
    production and making it live and so I’m really excited about it. I
    think it’ll be a lot of fun.

    01:21:47 - Speaker 2: Let’s wrap it there. Thanks everyone for

    listening. If you have feedback, we’re on Twitter at @museapphq and
    we’re on email, hello at museapp.com. It’s always nice if you leave a
    review for us in Apple Podcasts. Mark Wulf, it’s been really a pleasure
    to watch as you two have poured your heart and soul into building the
    system over the last year, and I think it will be incredibly rewarding
    to see it out in the world, and I’m just really looking forward to
    hearing the response from everyone once they get a chance to give it a
    try.

    01:22:20 - Speaker 3: Yeah, thanks for having me on. It’s been a lot of

    fun.

    01:22:23 - Speaker 1: That was great. Thanks everyone.

    0 min
  • 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, for example, I mean, certainly some of my early inspiration
    for wanting to make a sort of open canvas ideation tool came from
    watching how creative people often use Illustrator, where they have this
    just big open space and you can zoom out and you have a lot of
    iterations of one idea up in this corner and some iterations over here.
    So there is, even though we’re not a design tool or an illustration
    tool. Some of the precedents has been set on the open canvas we do
    borrow quite a bit from.

    00:15:55 - Speaker 3: One other I’ll mention, even though that’s maybe

    just a different flavor of the finder, is actually the Mac OS desktop. I
    think that’s one of the areas of the operating system that actually
    comes closest to the experience of use the canvas.

    It’s just kind of an open space where you have items, I think depending

    on how you have it configured, you can arrange them freely, drag them
    around.

    And I was looking to that specifically when implementing multi-cart

    selection behavior, this is something that is also new in Muse2 and in
    use on the Mac specifically. I was surprised to see how we actually have
    quite an intuitive understanding on how selections should behave based
    on how our operating systems behave. So whenever we implemented
    something in the multi-cut selection space that didn’t feel quite
    right, it was usually because it was different from how the Mac OS
    desktop does it. So that was definitely a good inspiration on figuring
    out what kind of behavior users expect and what just feels right.

    00:16:59 - Speaker 1: Yeah, and it’s really fascinating how especially

    sort of this really core part of the desktop experience or even MacOS,
    you know, it’s been around for decades and it really hasn’t changed
    and at least for me like I basically grew up with it, right? I don’t
    know any other way that it could work. And so it’s very ingrained in
    how I think these interactions should work. And that’s quite different
    from the iPad where I kind of know a time before the iPad and I also
    know how Apple started and how it got there very iteratively over just
    the last few years and like it’s still changing things, it’s moving
    things around every year.

    Even app developers haven’t really agreed on a single way to do it and

    probably even Apple itself hasn’t really agreed on one way to do
    certain things on the iPad. And so in that way, I think it’s really
    helpful to just look at what Apple is doing on Mac OS as sort of the
    gold standard, even though they are, I think, especially with sort of
    the catalyst apps that Apple has been doing over the last few years,
    like there are also a few outliers of apps that just aren’t as well
    designed or aren’t as well fitted to the Mac OS system. And so since
    Muse is a catalyst app, you also have to like specifically look at
    Catalyst apps. I think where to me craft stands out as one example of
    just a really well designed catalyst app, and I think we looked to them
    quite a lot for just seeing what’s possible on Catalyst and like
    what’s a reasonable solution in between the Mac and the iPad.

    00:18:30 - Speaker 2: Yeah, definitely. I think we have to give a big

    shout out slash some appreciation to Kraft.

    They’re very good sort of comparable to us because they did start on

    iPad and then came to Mac, and they have sync between those.

    They were an early mover on Catalyst, and I think probably, you know, we

    benefited from starting, you know, a year or two later than they did,
    and I think they faced a lot of the bugs as that technology was still
    pretty early and they wrote a nice long guide that I think we referenced
    quite a bit.

    And on top of that, their team even was nice enough to answer a few

    questions we had, which I think usually came in the form of we go to
    look at how the preferences panel is implemented or the toolbar or
    something, and we go, oh wait, Catalyst doesn’t seem to support that
    API that normally would have elsewhere and then basically we’re able to
    ask their team and they said, oh yeah, you know, here’s how we did it.

    And that was just really, really nice to have uh referencing back to our

    career episode, maybe where the advice is always talk to your elders,
    people who have, you know, forged the path before. And so, yeah, very
    appreciative to their help along the way.

    00:19:35 - Speaker 3: Yeah, definitely, I’ll second that and yeah, for

    sure, Kraft has been a big inspiration for us and kind of the benchmark
    on the kind of quality that you can actually deliver building a catalyst
    app.

    And on many occasions they’ve helped me with some quote level support

    and even just to get confirmation on an issue that I got stuck with to
    figure out is this really not possible? Is this potentially a bug in the
    system.

    There’s just unfortunately quite little documentation out there on

    Catalyst stuff and not so many people are using it. So if you do run
    into some weird unexpected behavior, it’s often kind of hard to find
    materials to solve that and Just talking to the craft team about that
    and hearing that, yeah, we got stuck on the exact same thing. It seems
    to not be possible, what was just a good check for me.

    00:20:28 - Speaker 2: So we mentioned using Finder and also the, I guess

    Finder-ish thing that is your Mac desktop is kind of one of our main
    inspirations or references for selections, and you, you mentioned the
    multiselect is new in use too, which was sort of an interesting fallout.
    We weren’t, I think, necessarily thinking the 2.0 product is going to
    include more powerful selections, but it’s more that once you’re on
    Mac. Where you just expect selections to work a particular way, and
    yeah, you expect them to be more powerful.

    That’s just the nature of the desktop platform and so that pretty

    naturally led to implementing much more there, and then a lot of that
    does indeed benefit the iPad.

    So maybe the starting place there is how do selections actually work in

    Muse.

    00:21:16 - Speaker 1: Yeah, so, so far on the iPad, it really just work

    with the pencil, right? So we rely on the pencil on the iPad a lot and
    we have the selection tool for the pencil and you can use it basically
    to draw with a lesser selection around your content and then you can
    move that.

    But we don’t really visually indicate that much what exactly is

    selected and you don’t really have a way to really One by one select
    cards. And so on the Mac, the selection system kind of requires that.

    So if you select something in the finder or even on the Mac desktop, you

    know, you can very quickly select something just by like opening a
    rectangle with your mouse and everything within that gets highlighted
    and selected. And even from that stage, you could like hold down command
    and deselect things again like called shift and deselect a lot of
    things, move those around and Yeah, it’s like a very. Well thought out
    and established system that kind of really works exactly this way across
    everything on the Mac. Ideally, And yes, I think we really needed to
    follow that from use as well in order for it to feel native in any way
    to the Mac.

    00:22:24 - Speaker 3: Yeah, and then on the Mac, even taking it a step

    further and allowing you to just single click a single card and select
    it this way so you don’t even need to necessarily draw a selection with
    your cursor around it, but the default behavior that happens when you
    click on a card is that it gets selected and if you click again, it gets
    deselected. We actually did have to do. A few compromises here because
    for some card types, you just expect, for example, if it’s a text card,
    you expect that clicking into it will make you able to edit the text,
    and that is in fact the case. So there were a few places where we just
    had to make the decision to sacrifice consistence for user expectation,
    but I think we landed in a pretty good place there.

    00:23:15 - Speaker 1: And I didn’t even realize that consciously

    before, but on the Mac, basically anything you click on is first
    selected, right? Like if you click on an email, it gets selected. If you
    click on something on your desktop, it gets selected.

    And so while on the iPad selection is really about bulk editing, like

    you can press the edit button on the iPad and then you can select
    multiple things if you want to edit multiple things. On the Mac, it’s
    really just used for everything, even if you just want to interact with
    a single item, like if you want to delete something, you first select it
    and then press the delete key or you press enter to rename it or
    something like that. And it even gets automatically selected if you move
    an item from one place to another. By doing so, you also selected. And
    so it’s really such a core interaction on the Mac while being this like
    special case on the iPad. And I think that was just a really big shift
    for us as well even in how we think about it.

    00:24:13 - Speaker 2: Seeing how the selections came together also to me

    really emphasized this difference in Yeah, use case and setting for each
    platform.

    It’s that, you know, with the iPad, you’re doing relaxed thinking,

    you’re reading, maybe annotating brainstorming with Mac, you’re doing
    productivity, heavy research and in particularly this kind of idea of
    bulk editing, which came up a lot, I feel, and you see that with the
    selections, which is that you can, for example, just the simple thing of
    Hitting command A to select everything so I can move it around a little
    bit, or yeah, selecting a whole screen or half a screen full of stuff
    and then you can fine tune the selection with command, click, and then
    you know cut that and move to another board or drag it to another window
    or something like that. You can do all of that stuff on iPad, but it’s
    just you have the smaller screen. You don’t have the same kind of speed
    and precision. You don’t have the keyboard shortcuts. So while it’s
    more intimate and natural and organic to touch things and use your
    pencil and stuff, it’s just not fast to do those big bulk edits. I
    guess intuitively I knew before, OK, the Mac would be better for that
    sort of thing, but I wouldn’t have really been able to say why, and now
    I feel like the selections and powerful selections, it really is the
    core of that.

    00:25:29 - Speaker 1: Yeah, for sure, and it’s in combination with

    keyboard shortcuts as well, right? Like you select something and then
    you want to do something to it quickly and with the Mac, you have sort
    of the guarantee that every user has a way to quickly select something
    and has a keyboard to quickly manipulate those objects. And I feel like
    that is sort of the matric combination that we have and that makes the
    Mac so powerful and the iPad is kind of missing both of those sadly.

    And so just because of that, it kind of becomes a very different

    platform that can’t have speed and efficiency sort of as the target,
    but sort of has to have strength and the direct manipulation and sort of
    the immersiveness you get through touch input.

    00:26:11 - Speaker 2: One area I think is important or I’ve observed.

    In my own just use of uses and others as well as this concept of

    culling, what I usually call culling, which is you probably dump a bunch
    of source material that you think is going to be inspiration or
    reference or as a starting place for your thinking process into a board,
    but often in the process of kind of sorting through it and trying to
    find the patterns and figure out what you want to do with it, there’s
    this element of, oh, you know, this thing doesn’t fit in. I don’t need
    it or I don’t want it or it’s a duplicate of something else. And
    that’s why I think that gesture we have on iPad, which is to throw
    something off the edge of the screen. So 3 of the 4 edges of the screen,
    if you swipe something in that direction, it just disappears. I think
    that’s a really important gesture to be so easy to do and top level
    because of that quick culling.

    You can just dump a bunch of junk in because it’s OK. You can throw out

    the stuff you don’t want. But it’s very good for the kind of one-offs,
    so I’m going to do this one, this one, this one, and that’s pretty
    quick. Whereas, yeah, on desktop, we’re just used to, you select a
    couple of things and you hit the delete key, and that’s a very quick
    way to do it. And of course there the throwing something off the edge of
    the window, I don’t think it would even really make sense. That’s just
    not an interaction that is at all pleasing to try to do with a mouse,
    nor does that really fit with the paradigm at all. Whereas, yes, there
    is something that’s really well established, selected and hit delete,
    and that’s very fast in its own way.

    00:27:37 - Speaker 1: Yeah, there were some tough decisions there, I

    would say of, OK, which elements of the iPad app can we just take over
    and apply on the Mac as well, or which things do we actually have to cut
    or find a different way to do it on the Mac since we don’t want to
    alienate our users or like take things away from them, basically. But we
    also have to be very careful not to just take what’s on the iPad out of
    convenience basically and just say, OK, it’s gonna work the same way on
    the Mac, it’s gonna be fine. And yeah, so weighing these was always, I
    think a difficult choice even for like tiny details.

    00:28:10 - Speaker 2: Another thing that points to the importance of

    selections is kind of where they sit in our gesture space.

    I don’t know if that’s the right terminology when you talk about Mac,

    but that brings me to another section that I’d love to hear you both
    talk a little bit about, which is, I know you put a whole bunch of time
    into questions like, How do you navigate into a board? Is it a single
    click? Is it a double click, or what happens when you click on open
    board space? Does that kind of turn into a little grabby hand and let
    you pan the board, which actually is what it does on iPad. If you just
    put your finger down and open board space and then move your finger, you
    start to pan.

    But I think here we ended up with when you put down your cursor and

    click in open board space and then drag, you start to get a rectangle
    selection.

    So we’re saying the selection is so important we want. That single

    click kind of default to actually be that. So I’d love to hear about
    the process of kind of coming up with the holistic idea for what the Mac
    gesture space is.

    00:29:08 - Speaker 1: Yeah, that was really something that especially in

    the early parts, we really had to just try out a lot of different
    things, like basically for every possible basic interaction, like
    whether it’s double click or single click to open something, to edit
    something, to make a selection, you know, we basically had a list of
    choices to pick and combine those. And yeah, in the end, it’s a lot of
    sort of trying and giving it to a few users and seeing how they react.
    And yeah, then you just have to Sort of consider all the different parts
    of, OK, so you wanna fit into sort of the Macro as well, but you also
    wanna fit into what you’ve established on the iPad. You wanna make sure
    it just feels good to use and feels in line with how we want you to feel
    basically. And then I think we actually also have to think a bit about,
    OK, what other things do we actually want to build on the Mac in the
    future? Like, what do we want the Mac app to become at some point
    because we don’t want to box ourselves in by setting certain
    interactions know that in the future, you know, means we can’t do
    something else.

    00:30:11 - Speaker 3: Yeah, and I think in many cases it’s actually

    trying out these different versions, even though we were unsure in the
    beginning what the right answer is. Once you try out one versus the
    other, you just immediately know because one feels wrong and the other
    one feels right.

    So I think the example of zooming into a board with a single click felt

    wrong. It felt borrowed from the iPad where you tap to zoom into
    something is just a very well established pattern. Whereas on the Mac,
    opening a document is almost always a double click. So putting these two
    side by side, it was just immediately clear that one was much more well
    suited for the Mac.

    And yeah, when it comes to scrolling the canvas. The good thing is that

    you actually, if you use a MacBook that has the trackpad touch input.
    That actually works with the two finger scroll just like you used to
    from almost any other scroll view, your browser or whatever.

    00:31:11 - Speaker 2: As well as the pinch gestures, so you can pinch

    the zoom in on a board, pinch the zoom out. Yeah, you have the two
    finger pan, so I was surprised how natural that stuff was, but then you
    also can’t assume they have a trackpad. They might have a mouse or a
    trackball or something like that, so we couldn’t rely on those
    existing, but it’s nice to have those gestures as a bonus, right?

    00:31:32 - Speaker 3: Yeah, exactly.

    00:31:35 - Speaker 2: So something was notable to me about the creative

    process here was that we started with a debug menu that had a long list
    of everything you could do that was kind of in the command gesture
    space, and then you would have options for each one. You could play a
    video with single click or double click or maybe some other thing. You
    could zoom to a board with this, this, or this.

    And then you go through a very granularly set your whole command space,

    but of course it’s very easy to get things that collided if you said,
    I’m gonna single click to select, but also single click the zoom or
    something like that, maybe weird stuff would happen.

    And then eventually based on those experiments, I think Leonard, you

    boiled it down to like 2 or 3 kind of groups that naturally fit
    together, you know, maybe one. It was more double click oriented around
    actions, and that was more single click oriented, and then you could ask
    folks on the team or users or whatever to try out these different setups
    and say what feels right to you. And I remember testing those out a
    little bit, and the real test of it to me is once you get it and you’re
    really trying to do something, do you get lost in the flow? Does it just
    start to come naturally and you stop thinking about it versus I have to
    stop and think, what do I need to click or press or hold or whatever to
    get what I want to happen to happen here.

    00:32:51 - Speaker 1: Yeah, right, that’s really the key. It’s kind of

    about how everything feels when you use it together, right? You can’t
    really look at any one single thing on its own.

    00:33:01 - Speaker 2: Now did you find that the existence of a cursor

    hovering over the canvas, was that sort of a major change in the sense
    of how the user experiences it, or was it more kind of minor?

    00:33:15 - Speaker 3: To me personally, I regained my appreciation for

    correct cursor, how would you even call it? Correct cursor shapes. I
    think this is something that you don’t notice when it’s working as
    expected, but you definitely do notice when it’s not like if you’re
    trying to resize a card and you actually have the normal arrow pointer.
    It just feels like something’s broken.

    You expect there to be the little reset arrows pointing in different

    direction. I think same with kind of hovering over a card that you can
    click like a link card. You just expect there to be the little pointy
    head that indicates this is a link that you can click. And yeah, it was
    actually a bit of work to get all of that right, but I do appreciate the
    cursor and like the subtle ways in which it cues the user as to what
    would happen if they interacted with this element.

    00:34:07 - Speaker 1: Yeah, and I would say it’s actually quite

    underappreciated how much of another dimension the cursor adds. Like
    it’s not just sort of a translation of the touch input, but to me it’s
    also about the interaction that happens before the touch input like a
    cursor, you can kind of move around before you commit to an interaction.
    And so the cursor shape can change, so you can see what’s about to
    happen. You can even show additional information if you want to unhover.
    But you can also use that to let the user just make more informed and
    precise decisions, I would say.

    00:34:42 - Speaker 2: Queuing what the user can do reminds me of one

    really interesting call it subtree in the interaction space that you
    both went down, which is this, I guess I would call it this sort of
    ghost card that you get when you’re adding content. I’m not sure if
    that’s what you both call it, but I’d love to hear about the decision
    to go that way.

    00:35:02 - Speaker 1: Yeah, I’m not sure what we call it. I, I don’t

    know that it needs a name, but yeah, it’s basically while on the iPad,
    when you add something, it immediately appears in your inbox on the left
    side of the screen and you just drag it to where you want it to be. On
    the Mac, it works quite differently where you add something and then it
    adds this little preview to your cursor and it follows you around and
    you can kind of figure out where you want to place it first and then
    when you click, you place it on the board.

    00:35:28 - Speaker 3: And it even has a little additional hidden

    feature, uh, which is that you can actually click down to place it and
    then move your mouse with the button down to resize it in the same
    gesture.

    So this is, I think one of the little things where we felt like this is

    something that feels news on the iPad like, even though it’s obviously
    like a cursor base and very Mac specific gesture, but A little
    thoughtful touch and you know, what if you want to make this image
    really big, you would have to click and then go to the bottom right
    corner and resize it and we wanted to make it easier to do both in one
    gesture. So this is what you can do on the Mac.

    00:36:10 - Speaker 1: Yeah, and this is something that really isn’t

    possible on the iPad, right? Like the iPad in that way has a very simple
    input system, whereas on the Mac with the cursor, you know, you can very
    quickly, especially in combination with the keyboard, add something, you
    find where you want to place it. Confirm that and then also set the size
    of the content. Whereas on the iPad, that would be multiple steps and
    take quite a bit longer. So in that way, I think it kind of maps to what
    we said earlier about the Mac that it’s just a lot more about speed and
    precision while the iPad is sort of about this direct connection to the
    content, which, yeah, it’s lacking when you use the cursor on the Mac
    to add something.

    00:36:53 - Speaker 2: One thing I think they both have in common,

    whether something goes in the inbox or whether you drag out a new board
    from the left side on iPad with that kind of extra gesture, or whether
    you’re moving the ghost card for the new board or the image or whatever
    it is around to find where you want to place it.

    In all cases, we really try to avoid putting content on the user’s

    boards in a kind of a random place. Basically everything on your boards
    is things you have decided where it goes. I don’t know how much that’s
    a, you know, an intentional core principle that you always try to adhere
    to or something that just naturally came out, but it’s an interesting
    because it feels to me like there is a shared common principle or set of
    values, maybe like you were referencing earlier, but how it is
    implemented per platform is extremely different because the input
    devices are so different.

    00:37:42 - Speaker 1: Yeah, that is quite intentional and that’s a big

    reason for why it works that way on the Mac as well. Yeah, I think since
    new is the spatial canvas and it is really directly about your content,
    it is really important that the user places everything. And, you know,
    Muse is not a linear text editor or something where we can just add new
    things at the bottom and the user will find them there. But since it is
    a special place. We feel it’s important that the user. Always has to
    say about where exactly something is.

    00:38:13 - Speaker 2: And we talked about how a lot of what is in our

    kind of in-app custom UI Chrome on iPad, on Mac, you have the benefit of
    stuff that sits kind of outside the canvas, and that includes the
    toolbar, but then there’s that. Very ever present top menu bar that
    every app has. You just got the little apple in the corner and then the
    name of the app, and then you’ve got file edit, and so forth from
    there.

    Now, those all seem very, I guess standardized to me. They seem pretty

    similar across apps, but I don’t know if there’s really good
    established conventions there or they just seem similar because apps
    borrow from each other or I don’t know, what was our process for coming
    up with the new menus.

    00:38:57 - Speaker 1: Yeah, I would say it’s a bit of all of that. Like

    there are actually a surprising amount of sort of guidelines and just
    Apple documents about how you should structure and order your menus.

    So I also think many apps don’t really follow it that closely or kind

    of make their own decisions. So in that way, it’s, you try to look at
    everything other apps are doing. You try to look at what Apple is doing,
    and then you need to figure out what is the right call for use. And I
    think for us, especially the challenging part was that we also have this
    iPad app which doesn’t have any of those menus and we still need them
    to work similarly and so we can’t rely on only those menus.

    But it did actually mean that the iPad also benefits a lot from what we

    did on the Mac. Like, for example, we introduced a lot of new sort of
    context menus, right click menus for the Mac version where you can click
    on a card, click on the background of your canvas, and you get really a
    lot of useful options which we didn’t have before on the iPad.

    And the interesting part of me was also that there isn’t really like a

    single menu on the Mac, right? Like you have the menu bar, you have the
    context menus in different places, and then you have keyboard shortcuts
    that need to map to those menu entries. And so in that way, you’re kind
    of trying to build up this whole system of different menus that all need
    to make sense and sort of have the same structure and order for
    different content types, but also, you know, the different places, the
    menu appears. And I think the iPad version of news also benefits from
    that a bit, especially in regards to keyboard shortcuts. Like we always
    wanted to do better keyboard shortcuts on the iPad, but it’s never
    really been a focus for us on the, on the iPad. But now on the Mac, it
    really is table stakes to have menu entries and then have keyboard
    shortcuts set for all of them. And so we’re trying to bring the same
    thing to the iPad as well and really try to build up this universe of
    actions that work the same way across iPad and Mac.

    00:40:54 - Speaker 2: Are the keyboard short guts between the two

    exactly the same, or are there places where they’re different?

    00:41:00 - Speaker 1: Yeah, we’re mostly trying to keep them the same.

    I think the difference is more that there are some. iPad specific
    shortcuts and some Mac specific shortcuts, like for one, of course, you
    know, the iPad has like inking or something and maybe you want to do
    special shortcuts for that. But there are also a lot of system shortcuts
    that Mac OS just takes for itself, basically, and there are a lot more
    of those on the Mac than on the iPad. And so we have to be very careful
    on the Mac, not to touch on any of those, but we could use them on the
    iPad if we want to.

    00:41:30 - Speaker 3: One other thing about menus that I realized and I

    think wasn’t quite consciously aware of before is that they actually
    also a great way to teach users what’s actually possible to do in an
    app.

    I think on the iPad we spend a lot of time thinking about how to best

    teach all of these complex gestures to our users.

    We had a few different approaches of onboarding, even popping videos

    into the inbox that will show two hands, you know, zooming into a card
    while also carrying another card with them and Since we don’t have any
    of that on the Mac, I think actually just that’s for me how I often
    learn how to work with an app is to just click through all of the menus
    and see what the options are there and learn about the capabilities and
    how to navigate the app. So it’s basically almost like a little on
    boarding intro for free.

    00:42:22 - Speaker 2: And maybe like a sort of a table of contents of

    what you should be able to expect to do, and not just the verbs, but
    also the nouns in many cases.

    So I think of something like an audio, you know, I use audio editor

    tools as part of podcast audio editing, among other things. And so you
    might go into something like audacity, and you go through the menus and
    you see there’s a whole section on adding and removing marks. OK,
    what’s a mark? Well, it turns out this is a way to put a little marker
    in the audio and possibly give it a label.

    But you might, if you’re new to that, now you know that this is a noun

    within the world of the application and maybe what you should learn
    about or what you should read about in the documentation, or you just
    try adding one and see, you can kind of infer from, you know, the name
    and what happened, what it is. So yeah, there’s a lot of
    discoverability in those standard menus.

    00:43:11 - Speaker 1: Yeah, and even Apple is actually really explicit

    about that being one of the jobs of the menu.

    And so they really encourage you to build your menu in that way that

    users can, when they first start the app, go through the menu and
    basically get an overview of everything that’s possible.

    And yeah, that doesn’t really exist in a system like that on the iPad,

    which I think is partly because, you know, the iPad is not as much a pro
    device, but Yeah, for people that want to make it a pro device, that
    makes it a lot more difficult to sort of do this kind of onboarding
    themselves and come up with another way of teaching users about
    everything that’s in the app.

    00:43:50 - Speaker 2: I also give a quick shout out to the Mac help menu

    which has a default search box.

    Muse has this as well, and so you basically just search menus for what

    you’re looking for and definitely for a lot of apps that I use, for
    example, sophisticated programming editors or video editors where they
    have so many options and the menus are often many layers deep, and I
    can’t necessarily remember the keyboard shortcut for an action I use
    infrequently. But I can go into the little help menu and type in
    something there. It’s almost like a little command line or, you know,
    spotlight quick search kind of thing.

    In addition to being a quick way to execute a command, they can help you

    discover. So I’m thinking now, even just going to use for Mac right now
    and I type in, let’s say I’m looking for the duplicate option or I
    want to remember what the keyboard shortcut is or where that’s located
    in the menu. And if I type in DUP, I see duplicate, but I also see
    duplicate Inc, which maybe I didn’t realize before that there was an
    option just for that, but I discovered that by using the school search.
    Now another huge area from my perspective is drag and drop, and that’s
    also important in the iOS iPad OS world, but way more so in the world
    of, yeah, pro app workflows and big screens with you’ve got multiple
    windows on screen at a time and you’re moving data between them. And
    actually through this process, I think of watching the two of you work
    on this application, I’ve rediscovered some of my love for native apps,
    so I found myself using a lot more, especially maybe smaller, just
    utility apps, something like Transmit for uploading stuff to S3 or
    Optimage or Forecast is a little podcast kind of compression tool. But
    all of these, the drag and drop just works so beautifully. It’s just
    really nice that you can always drag from one tool to the next tool to
    the next tool and just always works the way that you expect, whereas I
    don’t know, with the web and especially like electron apps, you know,
    oh, someone shared an image with me in Slack, I want to grab that and
    put it someplace. Sorry, drag and drop just doesn’t work or it produces
    some unexpected result. I drag the thing out and I get some weird URL,
    not the actual image. So I’d love to hear about the design and
    implementation of drag and drop for Muse, including any challenges we
    might have run into along the way.

    00:46:08 - Speaker 3: Yeah, so the way that drag and drop works on the

    iOS and Mac OS systems as well is that you basically define a set of
    file types that can represent the content that you’re trying to drag
    and that could be one file type, for example, just a piece of text, or
    it could be several. So you could say this text could be represented by
    just the text, but it could also be represented by a file on your in
    your file system with a TXT ending. And depending on the content type,
    there might be a lot more versions in which you can deliver this content
    to other apps.

    And then on the other side, a receiving app can get this packaged item,

    look into it and try to figure out what possible format it might extract
    from it. So if you drag something into a text editor, it probably just
    cares about the text. For example, an app. Like notes on Mac and iOS can
    actually absorb all kinds of different content. You can drag images, you
    can drag files in there, you can drag text, URLs, and it kind of tries
    to be as smart as it can about what’s possibly the format that the user
    would expect in this case. But it also created some challenges for us in
    trying to basically outsmart that system if we feel like what the system
    determines as the desired content type is not actually what we are
    trying to provide. So in the coming back to the example of text, we
    thought it would be really cool if you could just select some text, drag
    it into your finder and have that write a TXT file into your finder. But
    if I then select some text, drag it into the notes app instead of the
    text appearing there, it’s actually a reference to the TXT file
    appearing. So in this case, nodes sees text and a file and it chooses
    the file over the text, unfortunately, which in the end led us to
    abandoning the file type altogether and just serving up pure text and
    Any app that can read text will then extract the text from it, but
    unfortunately, the finder doesn’t have the magic capability of turning
    it into a file by itself.

    00:48:20 - Speaker 2: Yeah, it does feel like an edge case. I feel like

    most of the common situations with text, images, PDFs.

    Those all work, I think pretty much as expected every time I’ve ever

    used them anywhere. Now maybe it gets complicated if I’m dragging 3
    text cards and 2 images and I’m taking it to another place like a craft
    or notion or something that can certainly support those and what order
    should they go in and do all of them come across that sort of thing.

    But for the most part I’ve found that there’s certainly especially

    single items and even on the web. So if I’m, for example, want to
    compose a tweet. With maybe an image attachment, and I do that and muse
    and then I drag that over to my web browser right into Twitter and it
    just does precisely what I expect. The text becomes the text of the
    tweet, the image becomes the image attachment. So I don’t know how much
    that was a huge amount of work on your part to like handle a whole bunch
    of special cases versus that 80% of the common cases actually do work
    pretty well out of the box.

    00:49:17 - Speaker 3: Yeah, it actually wasn’t an unexpected amount of

    work, I would say so. It’s nice to hear that we ended up in a state
    where in most cases it seems to do what you expect, but to even figure
    out what’s expected in each case and kind of weed out all the edge
    cases and make sure that, you know, when you drag two items with a
    different type, they both arrive in the format that you expected. It was
    quite a bit of work to consolidate all of that, but yeah, we got there
    eventually.

    00:49:44 - Speaker 1: Yeah, and I’m seeing now how much magic actually

    happens in the background when you drag and drop something like as a
    user, it always seemed to me as, you know, straightforward logical
    operation of you have the content, you put it somewhere else. But yeah,
    in reality, there’s a lot that the system does in the background to
    figure out what part of the content exactly you’re trying to drag, how
    to display that, and how to transition that and sort of the fact that it
    usually does pretty much what you expect. It’s kind of surprising if
    you look at how it actually works.

    00:50:16 - Speaker 2: Well, I continue to think drag and drop is one of

    the best, is that the word for it, interactions in computing.

    Because it’s something that both power users rely heavily on to do

    their work, but also people who are non-power users I’ve seen this
    directly where they just find it really intuitive, almost surprisingly
    intuitive, like, oh, I can just press and hold on this thing and pull it
    over here, or I can just click and drag this thing over here, and it
    just takes it from one place to another. So I think that’s an
    absolutely fantastic interaction in the computing world and almost
    underused in a way. I think there’s even more that we can do with it.
    So, certainly, I think we’ve really made that a priority in our
    implementation work as we go along, both on iPad as the drag and drop
    capabilities have gotten more sophisticated there with multi-window and
    so forth, but obviously on Mac, there’s, again, much more precedent and
    much more capability to use that. I’m curious to know just kind of what
    happens behind the scenes when I drag, you know, for example, a PDF from
    Muse to my desktop, my Mac OS desktop or Finder or another app.
    Obviously it needs to export that file and that data, but if I drag it
    to another Muse window, I’m kind of within the Muse universe, although
    I suppose there it could just do an export and another import. But I
    think at least if I recall correctly, at least on iPad, if you have two
    different boards open, it is the same as if you had done a move
    operation from one board to the other. How does that kind of work behind
    the scenes?

    00:51:52 - Speaker 3: Yeah, so in our case, it’s actually not quite the

    same because we, at least on the iPad, we’ve decided to forego the
    default IOS level system drag and drop interaction because when we first
    started designing news. We took a really close look at it and since Muse
    basically dragging cards around on the board was kind of one of the most
    primitive core interactions of Muse and we wanted it to feel really good
    and really fast and fluid.

    And the way that the iPad and iOS system drag and drop works is that you

    have to hold your finger down on an item for, you know, half a second or
    something like this, and then it becomes detached from its parent and
    you can drag it around, you can even then navigate to a different app
    potentially and drag it in there.

    But it was precisely this tap and hold before you can actually move it

    that we were really bothered by and you couldn’t actually really
    customize this length. You could in a sort of hacky way in that work,
    you could reduce it to a very, very short delay, but you still needed to
    like set your finger down and hold it still for a fraction of a second
    before you could move something around. And we just felt like that
    wasn’t good enough for our vision.

    So we implemented a completely unique and custom drag and drop system

    for moving stuff within the app.

    And to then actually get stuff out of the app or into a different

    window, you have to engage Apple’s normal drag and drop. So in the way
    that it works on iPad OS news is that you actually hold down on the
    thing for, I think it’s, you know, a little less than a second and it
    plays a little lift animation and you can see that this is something
    happening that’s different from The normal dragging around and it
    becomes detached from the screen and moves beyond windows.

    And in this instance, when you detach this object from the canvas behind

    the scenes, the code is basically asked to provide the representation of
    this item and how other apps can consume this. So we would package it up
    into like a little data objects or you could provide a URL pointing to a
    file on disk. But you can also provide your own local object that is
    unique to your app and only your app knows what to do with it. So this
    way we’re able to drag a card from one window to the next without
    having to convert it into a PDF file, write that onto disk and then on
    the other window, read it again from disk and turn it into a card. We
    can just reference the card object directly and kind of move it around a
    lot more efficiently. Without using any of the new internal data.

    00:54:34 - Speaker 2: If I understand that correctly, it’s sort of

    it’s taking advantage of this multi-part content payload that comes
    with drag and drop. For example, you could provide a rich text version
    of some text, but also a plain text version of whatever app is receiving
    it can decide which format it understands or is more native, and in our
    case, we have like a muse specific bundle object thing that only our app
    is going to recognize plus a more generic export. Is that accurate?

    00:55:01 - Speaker 3: Yeah, pretty much, yeah.

    So in the example of a text card, for example, we bundle the text card

    as just a text thing that any old app will be able to unpack, but then
    also as a muse card that contains a muse text document that maybe has,
    you know, ink information attached to it or all kinds of other
    information that only Muse is able to interpret.

    And the same actually applies to things like when you have a whole

    selection of different cards. This way we’re actually able to maintain
    all of the spatial information. So if you drop it into another window,
    all the cards still have the same spatial relation to each other,
    whereas if you drop it into, say, the finder, they’ll just all be
    written into files or, or if you drop it into notes, they’ll be just
    linearly below each other in the document.

    00:55:54 - Speaker 2: One smaller point in all this is we did a little

    experiment to use test flight to distribute the Mac beta.

    This is a relatively recent addition, test flight being the way you

    distribute kind of beta or pre-release versions of iOS apps, been around
    for a long time.

    I would say it’s the gold standard, but I think it’s the only thing

    you can use. I don’t think there’s really any other way to do it.

    Obviously, desktop computers have a history and tradition of, you know,

    you click on download and you get a. EXE on Windows or a. DMG on Mac.
    And so that, I think continues to be pretty common for a lot of
    productivity software, but we decided to to give that a try for the beta
    here and yeah, what was our takeaway? Was that a good call or do we wish
    we’d done the more direct binary download?

    00:56:41 - Speaker 3: Yeah, I think we did the more direct binary

    downloads in the beginning, which usually resulted in me like posting a
    file into our Slack and then everyone having to download it and open it
    from then. I think that worked well enough then. But as soon as we
    started using test flight, I think everyone was just like, oh, it’s
    amazing, finally I get automatic updates and I don’t have to keep
    downloading your stupid files every time there’s something to look at.

    00:57:06 - Speaker 2: Yeah, well, historically Mac apps, they often do

    auto updating, but I think there’s a library, maybe it’s even like
    third party, trying to remember, I know our colleague Adam Wulf has done
    this before, but you basically need to build in the updating behavior to
    the app, which can be done with third party library, but it’s a whole
    other piece of infrastructure, whereas I guess with test flight, we put
    it in there and then the auto updates just kind of quietly happen behind
    the scenes.

    And in fact, I think from a user perspective it’s even better than what

    you’re used to in those standard Mac apps where you tend to get this
    thing where you run the app. If it’s been a little while and there’s a
    new update, it says, oh, I’m downloading the new update, you know, quit
    and restart, and then there’s this brief disruption of your workflow
    whereas test flight, I guess it’s built into the operating system, so
    it just kind of happens in the background. I got to run Muse and I’m
    just on the new version. Yeah.

    00:57:54 - Speaker 3: And in addition to that, I think test flight is

    also just, you know, it’s basically built for distributing beta
    software and also to collect feedback.

    So once we launched the public beta, we were able to, when we have a new

    update, add a couple of release notes that say, here, this is what
    changed since the last version, this is what we’d like you to test.

    It’s also a tool basically to communicate with your users in a way. So

    that worked really well.

    I’m generally very happy with test flights for the Mac.

    I think it’s only available in the very latest operating system and I

    know that especially with the Macs, people tend to not be updating them
    so often. I think it with iOS, the adoption rate of like a new major
    release is a lot higher than with the Mac right away, but we decided to
    Take that risk and it turns out that most people that we asked to test
    were either already on the new OS or we’re happy to upgrade for this
    purpose.

    00:58:51 - Speaker 2: Yeah, I think I ended up upgrading for this

    reason, which is I think it’s usually what happens to me with Mac,
    which is I don’t tend to update just because when a new thing comes
    out.

    Usually there’s some specific reason, some feature I want, some app

    that won’t run, and I’ll go, OK, well, I’m 2 versions out of date. I
    guess I’ll go ahead and get up to date.

    I know there’s a lot of that with Xcode as well, that if you need the

    newest X code, you need the newest Mac OS and maybe you need the newest
    X code to build apps for the latest iPad OS for example. So Apple stuff
    does tend to have that kind of, everything is connected and you need to
    be on the latest version to take advantage of stuff and test flight here
    is one example of that.

    00:59:31 - Speaker 1: Yeah, and I think it’s also a really important

    step from Apple’s part to kind of try to make developing for the Mac as
    easy as developing for the iPad since, yeah, especially the last few
    years, sort of Apple has focused mostly on iOS and the iPad.

    It’s focused mostly on iOS and the iPhone and developing for that,

    making that experience really easy.

    And so now if they want people to take those apps and put them on the

    Mac as well, you know, they have to make sure that they don’t confront
    developers with 10 other new things they also need to do like worrying
    about beta distribution or how to share updates with their users. And so
    I think that sort of stuff like having test right now just really
    enables us to very quickly get the iPad version onto the Mac without,
    you know, a lot of overhead.

    01:00:17 - Speaker 2: Yeah, that’s always the best case scenario for

    any platform that someone might want to develop for, which is focus on
    your app and the specific things that you’re doing, not the
    infrastructure that goes around it, and certainly how you get builds out
    to people, how they install it, how they update it, how they decide
    they’re done and remove it, all of that is infrastructure that I think
    is basically pretty standard and the same across all apps and not
    really. Something differentiated, so actually it does make a lot of
    sense to have that be part of the operating system. So we’re happy with
    test flight. I think we mentioned earlier that we’re happy with
    Catalyst, but probably there’s some pros and cons. What’s your overall
    reflection, Julia, or either of you after having worked so closely with
    this technology for the last 6 months or whatever it’s been?

    01:01:06 - Speaker 3: Yeah, I mean, I’m sure like all young

    technologies catalysts still has a long way to go, but for the most
    part, I was really quite impressed with how low of an entry barrier it
    was for me as an iOS developer to just get into Mac development.

    First of all, like I said earlier, the app basically worked pretty well

    out of the box just by clicking one check box and building it for the
    Mac. So that was quite encouraging for us.

    Of course, it still took a lot of time to tweak everything and really

    make it feel at home on the platform. But for the most part, Catalyst
    really was the right tool for us to use. There’s a few things that we
    had to work around or we just had to acknowledge that it’s currently
    not possible or it would not be possible without a huge amount of
    effort. So, so there’s some compromises that we had to take. But I
    think if we had actually tried to build news on the Mac, you know, from
    the ground up with AI. First of all, that would have been quite a new
    framework for me to learn and probably would have taken us a year or two
    to get to an app that’s, you know, even close to what we have now. So I
    think in general, Catalyst is a great tool and all it takes is a lot of
    patience, attention to detail to really make an app that feels like it
    belongs on the Mac and of course, be open to compromising on some small
    things that are just not possible with the technology at the moment.

    01:02:35 - Speaker 1: Yeah, I’m also really happy with it. I think

    going in, you know, we had a lot of doubts and open questions just
    because there aren’t that many catalyst apps and most of the apps that
    we really like on the Mac are not catalyst apps.

    And so in that way, like from a design perspective, it was also a bit of

    a challenge because I’ve spent the last two years working on this iPad
    app and now I’m sort of trying to get into the Mac OS world and trying
    to figure out what the conventions there are. And so one of the primary
    resources there are Apple’s guidelines.

    But those are not really written with catalyst in mind. You can look at

    all of those, but you should expect that like half of the stuff that’s
    described there just isn’t going to be implemented at all in Catalyst
    or is implemented like only halfway in like a bad version and then it’s
    sort of an uncanny, really, like if you have a certain menu type that
    Apple has implemented in Catalyst, but it’s not quite the same as the
    fully native one. And then there are like a few tiny details that can be
    quite frustrating if you really care about that stuff. But yeah, so far
    I think we have mostly found ways to sort of work around that and get it
    up to a standard where we are really happy with it.

    01:03:49 - Speaker 3: I hope that we’ll still be able to get the title

    editable in the Mac toolbar. I think that was one of the biggest caveats
    that we had to live with for now is that you can have a title displayed
    there, but you can’t actually have any UI that allows you to edit it in
    place.

    01:04:06 - Speaker 1: Yeah, the toolbar is a good example of something

    that is theoretically implemented in Catalyst, but it just doesn’t give
    you many options at all. And if you really want to have a functional
    toolbar, you kind of need to build your own thing, which then you want
    to, which then you try to make look as close as possible to the MacOS
    one. And yeah, that’s always a frustrating experience if you have to do
    that.

    01:04:29 - Speaker 2: I will echo being generally pleased with the

    results of Catalyst more from the internal test user perspective.

    We talked about this in our native apps podcast episode, but It is very

    often the case that there are cross-platform frameworks or the pitch for
    Catalyst, I guess, has some of the same qualities of something like
    React Native where we say, OK, kind of right once run everywhere or
    right once run in many places, and the downside to that is it’s often
    feels native in only one place or it doesn’t feel native any place, it
    feels sort of off everywhere. And so I was kind of worried for that and
    on the lookout for that, but except for every once in a while where it
    pops up, where there’ll be like a default dialogue styling that just
    looks like iOS and like, where did that come from? For the most part
    from the user perspective in terms of how it feels, I don’t feel like
    I’m running some kind of translation layer. It feels completely like a
    native Mac app to me, which I think is testament to Catalyst, but also
    to the hard work you both put into making sure that it did truly feel
    native.

    01:05:34 - Speaker 3: Yeah, thanks. It’s great to hear.

    01:05:37 - Speaker 2: Well, as we look overall on Muse for Mac and how

    it sits side by side with Muse for iPad and is we hope one unified
    product, not something that’s being ported to multiple platforms, but
    indeed with the sync, it ties it all together, so it feels like a fairly
    unified, and sometimes we talk about the medium for thought idea and
    these different devices are just different.

    Inputs into that system.

    And in practice, I think through the beta we’ve certainly heard that

    that is the case. We hear about lots of interesting use cases like
    certainly not just the case of, OK, I work on my Mac for a bit and then
    I work on my iPad, but people may actually use them simultaneously, you
    know, you might have them use for Mac up so you can use it on a Zoom
    screen share while you’re simultaneously scribbling onto your iPad and
    that kind of syncs across seamlessly. But I think that’s kind of the
    big bet we’re making here and we’re making this big investment, again,
    really big investment for such a small team as ours is to make two apps
    for these two platforms that share this core design language and values
    and concepts that are Adapted to the very different purposes of each of
    these platforms. The iPad, of course, relaxed and kind of free flowing
    and intimate and the Mac for productivity and focus and bulk editing and
    so on. So I guess how do we feel about that bet paying off? Is this idea
    one that we think that, you know, maybe others will adopt and If we
    prove it out, that that could be a new precedent, or are we, as usual,
    kind of doing our own weird thing, and others aren’t necessarily gonna
    wanna follow that path.

    01:07:18 - Speaker 1: Yeah, I’m still really excited about that

    approach, trying to really position the different platforms as something
    that you use together and that each have different functions instead of
    necessarily trying to replace either one or the other.

    And I think that’s something that a lot of apps are kind of inherently

    kind of end up doing, but I think it’s really interesting that we are
    trying to be explicit about it and really trying to focus on that and
    the design of the app for each platform. And so, so one way to look at
    it is that I think often the assumption is that you build an app for
    different platforms like for the Mac, the iPad, and the iPhone just
    because the user will have different devices with them at different
    times, like if they’re at the desk, they’re going to use the app on
    the Mac. If they’re on the go, they’re going to use it on the iPhone.
    But I think what I find for myself is that often actually when I’m on
    my desk and I’m using Muse, I’m thinking, OK, I actually want to use
    Muse on my iPad now. Like what I’m doing right now is actually better
    suited. It’s actually better fitted for the iPad. And so I like stand
    up, take my iPad, go to the couch, and then that’s explicitly a
    different experience that I couldn’t have on the Mac. And so it’s not
    just about which device is available and which device does the user
    have. But it’s really about sort of the flexibility you get to change
    modes depending on what you’re working on. And I think that lends
    itself especially well to use, of course, like we have this approach to
    being a thinking tool that really focuses less on productivity and more
    on sort of the creativity side of it. And I think they are the iPad is
    sort of the perfect device of sort of being able to immerse yourself and
    then, you know, just being able to explore and sort of what I would call
    like a free roam experience. Versus thinking on the Mac is sort of all
    about getting things done and about speed and efficiency. And I think if
    we embrace that we will naturally end up with apps that are quite a bit
    different.

    01:09:29 - Speaker 2: I might also argue that I think there’s a general

    sense that you want to own or carry less devices with you, maybe that’s
    part of the appeal of the phone, especially for newer generations, you
    just try to do everything on your phone and that’s it. It’s super
    mobile and it’s always in your pocket and it’s secure and etc.

    But I think one of the maybe, let’s call it user research insights we

    were starting from here is that creative people, creative professionals
    do tend to own. Not only multiple devices, but maybe a lot of them, you
    know, maybe they’ve got the big monitor and the keyboard and the
    docking station, but they’ll also detach their laptop and take that on
    the go, and they may have the iPad, which may be more aspirational for
    creative work. Sometimes it ends up out of batteries in the drawer as
    more of a consumption device, but they may have it for that purpose as
    well as the phone obviously, but you might also have a Kindle for
    reading and you might have other kinds of specialized devices.

    So that’s on one. And I think there’s maybe a desire in some way to

    see kind of all different devices and platforms kind of merged together
    into one like touch merges together with desktop and desktop becomes
    portable and so on, but it felt to me in researching this and looking at
    how professionals really do live their lives and what the devices on
    their desk look like is we do own a lot of devices. We do want them for
    different purposes in different scenarios. But there I think we tend to
    get this really strong app siloing right where it’s like, OK, well I do
    use the iPad for putting together inspiration with mood boarding, but I
    have a specific app I use for that. It’s only on the iPad when I’m
    done, maybe I take a screenshot and send it someplace else. It’s not a
    very fluid thing. It’s kind of just on this one device and then
    similarly, I have my desktop productivity tools, those live there and
    nowhere else, and that’s it. And so I think part of our idea here is
    that you can Exactly as you were saying there, Leonard, that there’s
    this switching modes that can happen seamlessly and with very low
    friction. You’re not thinking, oh, this would really be better on the
    iPad, but there’s a whole big process to get over there and can I even
    do what I want versus because we have this sinking behind the scenes.
    Because we do have the shared kind of data model and conceptual model,
    it is actually a very light touch or it is a very small step to say I
    actually want to be in a different posture, a different attitude and a
    different kind of interaction paradigm with my work, maybe only for a
    minute, maybe only for 5 or 10 minutes, and then I maybe I switch back
    to the other one, for example. So again, that’s part of the big
    experiment we’re doing here is, is there enough value to that that
    folks will really find used to be an unusual tool in their workflow and
    something that unlocks new creativity.

    01:12:16 - Speaker 1: And a big part of that really lies on Apple,

    right? Like we as developers can only do this single app, but in the
    end, it’s Apple’s sort of messaging and product strategy that decides
    if this sort of approach is successful. And I feel like Apple hasn’t
    been super clear about the messaging, like they’re always saying, OK,
    the iPad and the Mac is not going to merge, but it kind of feels like it
    does over time, just like very slowly.

    01:12:42 - Speaker 2: Or you could argue there’s something like a

    superseding, right? There’s the what’s a computer campaign, which I
    thought was quite clever, which basically points to, you know, younger
    people who grow up with touch devices and they’re able to do so much on
    an iPad, including their homework and creative tasks and things like
    that, that they don’t need one of these clunky old things with a
    keyboard and mouse that’s for old people or whatever, and that’s kind
    of the idea that comes through in that.

    But then at the same time, iPad is not now, and I think certainly I know

    it would be Mark’s position to say not ever going to be in a position
    to supplant the power of a true desktop with files and the ability to
    program it and a keyboard and so forth. So, yeah, what’s the future
    there?

    01:13:26 - Speaker 1: Yeah, I think the trade-off is often painted as

    either the iPad is able to replace the Mac for most users, or the iPad
    has to stay this media consumption device.

    And I feel like there’s another pathway, the iPad can be a pro device.

    It can be very productive and used for work, but it can coexist with the
    Mac. And I think for Apple, that kind of means thinking about the
    interface differently as well. Like what I’m seeing a lot with some the
    new iPad OS features every year is then basically taking Mac OS features
    and trying to adapt them on the iPad. And, you know, they often do a
    really good job with that, like with the new cursor, you know, they kind
    of reinvented the cursor on the iPad and really improved a lot on the
    desktop version. But in the end, like if they’re always just taking
    parts of the Mac and Like 80% adapting them and then making them a bit
    better, you know, that’s not going to lead to a really different device
    or really different workflow. What I would be really interested in is
    seeing cool features that are sort of start from the ground up for the
    iPad and that maybe don’t even have an equivalent on the Mac.

    01:14:32 - Speaker 3: Yeah, I think for me personally, I obviously have

    been working on this app for a long time and the iPad certainly has a
    place in my life, but having grown up with being a laptop user, having
    learned to type really fast, using keyboard shortcuts, like, you know,
    muscle memory style, the iPad has never quite made it. Of the line of
    being like a really productive tool for me.

    So yeah, from being able to use new on the Mac and being able to enjoy

    all of the speed that comes with it, the cursor support, the keyboard
    shortcuts, the much more seamless, uh, interaction with other apps,
    getting content in and out really fast is something that I’m quite
    excited about and that I hope maybe in the future.

    Other apps that I like or love on the iPad will be brought to the Mac

    and log new workflows there.

    01:15:26 - Speaker 1: Yeah, and I think that’s actually also a really

    important perspective that even though we are saying, OK, we have the
    Mac and the iPad app and they fulfill different roles, like those roles
    will look different for different people and some people might use the
    iPad still 90% of the time and only use them. Mac version for very
    specific tasks and others will like start with the Mac and only have the
    iPad sort of there to go version of that. And I think that’s fine as
    long as we are kind of aware of those different use cases and sort of
    try to make each platform reach as far as it needs to.

    01:15:59 - Speaker 2: Certainly, I think a part of this is an experiment

    to discover what indeed will people use.

    Use for Mac for, what will they use, use for iPad 4, to what degree will

    they use them together simultaneously, to what degree will they maybe
    use one almost exclusively and the other very little, and I think that
    will vary a lot by user, but I think it’s also a discovery process.
    Basically, I think our whole industry has been trying for decades to
    figure out how the tablet fits into our productive and creative lives.

    And that’s sort of ongoing, and now I think we can say that uses doing

    our small part to help discover what the future of computing might look
    like in that area.

    01:16:40 - Speaker 3: Strong closing statement.

    01:16:42 - Speaker 1: Yeah, that’s a good ending.

    01:16:44 - Speaker 2: Let’s wrap it there. Thanks everyone for

    listening. If you have feedback, write us on Twitter at @museapphq or
    via email, hello at museApp.com. You can help us out by leaving a review
    on Apple Podcasts. And Leonard Yullia on behalf of myself as a user, but
    I think probably lots of other users and customers out there, thanks for
    the incredibly hard work and attention to detail put into bringing the
    new experience to Mac. We’re all pretty excited to have it be part of
    our ideation workflow.

    01:17:16 - Speaker 3: Yeah, looking forward to see what people say about

    it.

    01:17:20 - Speaker 1: Yeah, I can’t wait to see it actually in the

    hands of users and seeing how they use it.

    0 min
  • 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 an email and it’s
    magically answered by the exact right person to do so directly. And I
    think that’s a property that we can still maintain.

    00:14:17 - Speaker 2: Yeah, the handoff element I’ve certainly run into

    that with maybe like banks or something where I already know because
    I’ve done this exact thing, like I don’t know, an international wire
    transfer or something. I’ve done this 20 times before. I know there’s
    a department that handles it. That department does not or refuses to
    give me the direct phone number. You got to call the main customer
    service, explain what you want to do. Then they say, Oh, we have another
    department that handles that. Would it be all right if I transferred you
    there and trying to head off their playbook, I have found if I say
    hello. I need to make an international wire transfer. Your international
    wires department handles that. Please transfer me. And they say, Oh,
    hello, Mr. Wiggins. OK, you want to make a wire transfer? Well, what
    kind is that inside the United States or international? And I’ll see if
    I can help you with it. And I’m like, yes, can we fast forward, please?
    That sort of handoff experience is not what you want, but rather you
    want your message to get to the right person to read it.

    Since we’re talking about sort of examples of unpleasant support or

    support that we on the say the user experience side don’t like, two of
    the things I think that we, or at least I had in my mind when we were
    designing our support setup is one is where you go to that contact us
    page, and yeah, they’re trying to kind of divert you away from
    contacting them in some ways. But I always find it funny when you’re
    logged into a website where they have your full account information.
    Again, a bank would be a canonical example, but any software is a
    service, and if I click that, get support button, I’m surprised how
    often it takes me to a form where I fill out my contact information
    because it’s like, wait a minute, you know exactly who I am. I’m in my
    account and in fact it’s useful to you, you here being the service that
    I’m trying to write to. That you know you have all my account
    information, that context might be really important. So it feels very
    weird and impersonal. Why am I filling out this form like I’m a
    stranger that you’ve never heard from before.

    And that’s one of the reasons we created the in-app feedback from Muse,

    which actually feeds right into the same channel as if you email hollo
    at museapp.com. So from our perspective answering, there’s no
    difference, but for the user, they can do it right in the app. They
    don’t need to identify themselves. They’re already logged into the
    app, so of course we know who they are. And indeed in front it has some
    pretty good features for surfacing past conversations, and we wrote a
    little plugin that gives us just some information like how long they’ve
    been a new user and stuff like that, because that could be really
    important context. Are they brand new or they’ve been a user for or a
    customer for 2 years? They’re probably looking for a different kind of
    support in that case.

    00:16:45 - Speaker 1: Yeah, there’s a couple points I want to elaborate

    on there.

    One is this ina feedback form.

    So we had the intuition that the amount of feedback that you get is

    mechanically related to how troublesome it is to submit the feedback,
    and places like banks take advantage of this by making it as hard as
    possible to, you know, contact us and therefore they get less calls,
    which is their goal.

    So we wanted to do the opposite of that, which is make it as easy and

    quick as possible with the thinking that that would give us more
    feedback, which, especially at the very beginning of the company and the
    product, we wanted to get as much feedback as possible. So that’s why
    we have this in-app form where it’s literally just a box that you open
    up and you type stuff into and you hit send. And by the way, we got some
    good meta feedback on that. People are like, oh, that’s such a, you
    know, easy and nice and pleasant way to submit feedback. More people
    should do that. The other was this idea of like the whole customer
    experience. So as a customer of a product and company, you have a notion
    of what your entire universe of interactions with that company has been.
    You know, I’ve bought this and this, I’ve said these things, I’ve
    given them this information, this is the nature of my account. And
    whenever you’re talking with someone on the other side who doesn’t
    have that full context, it feels jarring and incompetent. And so another
    thing we’ve tried to do is Make sure that we have all the context that
    you have when we’re giving you support. So that again is why we have
    all that stuff in front.

    00:18:07 - Speaker 2: Yeah, I think that’s especially notable, the

    context stuff when you have, let’s say a kind of an open incident or an
    open thing you’re dealing with.

    I don’t know, I think of like some of the car insurance, you’re filing

    a claim because you’re in an accident or whatever, you need to call
    back several times because there’s several things to do, and the good
    ones. They see right on your file that you have this open case and you
    don’t need to re-explain the whole story again every time you call,
    you’re calling back to say, OK, you know, you told me 3 days ago I
    should call when the repairs were complete, they’re now complete, tell
    me what to do next, for example.

    But very often, yeah, you do get this like, OK, well, Mr. Wiggins, what

    can I help you with today? And, you know, I’m thinking you don’t have
    on your screen in front of you that there’s this thing going on.

    00:18:52 - Speaker 1: This is an aside, but I feel like there’s an

    opportunity in software products to productize this notion more, like,
    give customers the sense that you in fact have a handle on their full
    history. So this is like the Amazon orders page, but for everything, but
    for your support requests and all this other stuff. I think some
    companies sort of do this, and I just feel like there’s something more
    there and if people really leaned into it, there’d be a payoff in terms
    of the customer satisfaction.

    00:19:18 - Speaker 2: Yeah, and hopefully that would be, let’s say the

    pertinent to relevant things. There is a version of that that might feel
    creepy, which often the extreme degree of data that the Google and
    Amazons of the world have about us can be, but they should have the same
    context that me as a user does. Like I’ve placed a lot of orders or my
    account is brand new, or there’s an error with the billing and my, you
    know, it told me to log in because my credit card expired, but then when
    I tried to type it in, I got an error. So maybe they can see that I have
    an expired card and that’s like an open problem that I’m trying to
    solve, for example.

    Yeah, I do wonder if there’s some kind of product opportunity for a

    support help desk that does encode a lot of these ideas, but I think
    it’s tricky because it would need such deep integration with the rest
    of your systems and would be fairly specific to your business. But yeah,
    I wonder if there’s something that could capture some of that.

    Now we’ve been talking about bad support examples kind of from the user

    side, Mark, do you have examples of companies that you think do well or
    where you’ve had good experiences as the end user?

    00:20:23 - Speaker 1: Yeah, well, I definitely had my own Zappos wow

    experience. I forget what the original trigger was. I think they like
    sent me the wrong size shoe or something. I don’t know. Anyways, like,
    I called them up, you know, they answered right away. It was a person
    who spoke perfect English, and I told them my problem, and they’re
    like, oh yeah, no problem. We’re giving you free shoes. You’re now a
    VIP customer for life, you know, we’re shipping it out overnight. It’s
    like, oh, OK, that’s awesome.

    00:20:50 - Speaker 2: And I went on to buy like dozens and dozens of

    shoes from them over the years almost like overreacting to a customer
    problem as at least I’ve heard that that was a strategy that IBM used
    back in their powerhouse days. A customer would call in with a problem,
    and they would send, you know, 12 technicians out to the site, you know,
    ready to not only fix the immediate problem but improve everything in
    its immediate vicinity in a way that the customer was just left thinking
    this is amazing, and they would use that as an opportunity to turn
    someone into a customer for life. That’s exactly right.

    00:21:16 - Speaker 1: Yeah. Another one that I always talk about is

    First Republic Bank.

    So this is the rare example of a bank that actually gives good customer

    service. So when I first moved to San Francisco, I needed a bank in the
    area and I googled banks and stuff and I found First Republic on the
    maps, and so I walked over to the office, and the ratio of service
    people to customers was so high.

    I thought I’d like walked into the corporate office or something, like

    there’s no customers here, there’s no line, there’s no big thick
    glass in front of all the counters, like all the other places that I’ve
    been to. Nope, they’re just very responsive. And again, that’s a
    company where I’ve referred many, many people over the years to.

    00:21:50 - Speaker 2: Mhm. One that I’ll give an honorable mention to,

    but sadly is no longer in existence in a meaningful way as an ISP
    actually based out of the Muse headquarters city of Seattle called
    Speakeasy. Do you know these guys?

    00:22:03 - Speaker 1: It sounds familiar.

    00:22:05 - Speaker 2: I feel like they were kind of late 90s till I

    don’t know, mid 2010s and then got acquired and kind of just
    disappeared in the belly of larger companies, which maybe means that
    their whole approach wasn’t really viable. I don’t know what the story
    was there. But for me, they were so stand out because, I mean, ISPs are
    one of those ones that are like banks just famous for giving you
    miserable customer service like Comcast and the Comcast cares thing is
    almost like an internet meme joke that people have such bad experiences
    with that company, and I think that’s common for these sort of natural
    monopoly, telecom provider thing and driven to keep costs low, but then
    there’s complicated systems that break all the time. I don’t know. But
    in any case, Speakeasy was a rare case of a really good ISP. They
    charged a little bit of a premium, but importantly, they didn’t treat
    Linux and other kind of open source operating systems and software as
    well, they supported them.

    I actually ran into that with ISPs that I had over the years where I’d

    get a cable modem or something and the only one that was available in my
    area, and they basically would just tell me straight up that they
    couldn’t let me use it because I didn’t have a Windows machine. And of
    course, it totally worked fine, and I would just kind of say, oh no,
    I’ve got windows, kind of like hedge a little bit and shoot them out
    the door, and then I would like set it up myself because it of course it
    works fine. But then I was always in a little bit of this fight with
    their their service reps about setup, and if you do call in with a
    problem, you know, there’s a problem in the line, which happened a lot
    back in those. Days, particularly with DSLs, and then they want you to
    click on this and this thing in the Windows whatever, but I don’t have
    that exact thing, so I’m trying to simulate it.

    Anyway, Speakeasy got through all that. They were for more power users

    and people who are a little more knowledgeable about networks and their
    customer service was basically a joy to call into. They would quickly
    assess your level of knowledge about networks and whatever.

    We could really be quickly talking in the form of, I say, look, I’ve

    already tested on the local network, that works fine to the router, but
    it’s the router to the here, you know, the trace route’s breaking, and
    they would say, OK, great, I’m going to run a line test on this and
    that. You push this button on the router. OK, it looks like there is a
    fault in the line. We’ll see if we can reset it from there. OK, yes,
    that did the job, or no, it didn’t, we need to send someone out, but it
    was always this kind of interaction and It’s a weird thing to be
    impressed by, but there were many cases where their line would have a
    status update when you first dialed in, where it would say our service
    is currently operational in all areas except for downtown Redwood City,
    where we are experiencing some outages and we’ll have more information
    at a future time. Now if you want, you can stay on the line and you
    could talk to someone about it.

    For me, more often than not, I’d be like, oh great, they know about it,

    it’s affecting my area. I just hang up. Because that’s all the
    information I wanted to know, versus that it’s just affecting me, they
    don’t know about it, I need to like kind of poke them to get something
    to change. So that was a case where the automated system giving me the
    information I wanted was exactly perfect.

    Maybe that’s an example of the support meets service, which is service

    doesn’t have to be, you talk to a human, it has to be like give me
    information or solve my problem or put me at ease that this problem is
    being handled.

    00:25:22 - Speaker 1: Yeah, it also speaks to the whole specialty

    subfield of support and customer service for like operational
    businesses. So ISPs, Hiroku would go in this bucket, which was an
    application, a hosting company. Airlines also, and there you have all
    the standard support stuff, but there’s also this operational element
    where people need this thing to be able to like get online or run their
    business or travel to see their parents or whatever.

    00:25:47 - Speaker 2: Yeah, and very emotional, right? You’re in this

    moment where you can’t get on the plane, you need the money in your
    bank account.

    I had an experience like that with my very first business, which was a

    payment gateway called Trust commerce. I learned pretty quickly there
    how bugs in your software in the payment world has a, you know, higher
    stakes than other realms that I’ve been involved in before then, but we
    had a case where we essentially kind of double authorized someone’s
    credit card.

    So, you know, now we’re getting into payment industry jargon, but an

    authorization. It is basically a reservation of money on a credit card,
    but by default it just gets released after some number of days unless
    you come and capture the result.

    In this case, it was literally like a race condition or bug in our

    software. We charge someone’s card twice, but it turned out that it was
    a debit card, so it actually holds that money out of their bank account,
    and there isn’t really a good way in the system, at least back then,
    maybe this has changed to free that authorization. You’re just supposed
    to let it expire.

    Eventually, the merchant who was our customer gave our phone number to

    one of their customers who had encountered this bug and basically a
    woman called me on the phone sobbing because she couldn’t buy food and
    turkey for the big Thanksgiving. The meal that she was having at her
    house with her whole family in 2 days and you know, that was like a very
    visceral thing to be exposed to. It wasn’t just this bug and this minor
    inconvenience, it’s something that really had a big emotional impact on
    a person’s life.

    00:27:16 - Speaker 1: Yeah, and we should come back to this topic of

    like customer connection and motivating product development. I think we
    have a lot to say about that. But just quickly on the operational front,
    I think our experience has been that there’s a huge amount of
    appreciation for just clearly communicating to customers what’s going
    on. So you gave the example of the ISP outage. You’re not like calling
    to like complain or be mad, just wanna know what’s going on, and if the
    company is aware of it, and you know the company is aware of it, that
    addresses like 90% of your concerns because yeah, I think they’re gonna
    fix it in a few hours and we’ll be back in business.

    00:27:47 - Speaker 2: Yeah, I’ll go for an early lunch, and it’s too

    bad because I really wanted to get this thing I was working on done and
    but I need an internet connection for that. OK, fine, I’ll take an
    early lunch and I’ll work on it later.

    00:27:57 - Speaker 1: Yeah, I was almost surprised to the extent that

    this was true in a business like Hiroku where, yes, people don’t like
    if there’s something wrong or if the platform is down for a little bit.
    What they really, really, really don’t like is if you don’t
    communicate clearly about it, and they especially double dislike if you
    ever give something that’s like wrong or contradictory. And so to bring
    it back to the airline example, the classic cases where they tell you
    the flight is like right on time, right up until the scheduled
    departure, they’re like oops, it’s 3 hours late. Well, you knew that,
    didn’t you? You were just lying to us. That’s what people really
    don’t like.

    00:28:29 - Speaker 2: And that’s where increasingly because a lot of

    this flight information is public or there’s public APIs or whatever,
    you have apps like Flighty, for example, which gives you the exact
    location of the plane that you’re going to be on at the moment and you
    can see it’s still on the way. Or it’s parked at the gate where it’s
    supposed to have departed or what have you, and yet the airline is
    strongly incentivized to not tell you until the last minute because they
    want you to get there and be ready and not delay because if they do
    manage to get the plane there on time, they want you to be ready for
    that, but then you don’t have the information you need to work with.

    Yeah, I even remember a case where I had a flight straight up canceled.

    I think it was just a weather thing, but they sent me an email. I can’t
    remember what it was like 4 hours before, and I was going to leave for
    the airport 2 hours before. So it was already all packed and everything,
    but I get this email and I go, Well, that’s really inconvenient, and it
    cuts my trip a little short and it’ll make the conference I’m going to
    a little tighter. But hey, at least they told me. I don’t need to leave
    my home. I don’t need to even convenience myself. I’ll just unpack,
    stay home for another day and then fly the next day on the flight they
    offered me. So that was a case where It was a huge inconvenience in some
    ways, but because they communicated clearly and at the right time, in
    the end, I just wasn’t that upset about it.

    You’d certainly imagine cases where you did really need to be there

    that day, but that just didn’t happen to be the case there. Yep.

    Yeah, that’s a really great point. It’s the difference between the

    infrastructure operations aspects and I don’t know what we call this
    other kind of sport. So at Hiroku there was this thing of, I tried to
    load up my app, but I’m getting this error or I would like to be able
    to use this feature or I’d like to upgrade this one, have more scale or
    something like that, you know, they want the problem solved, but it’s
    not an immediate outage. And once we did get into running people’s apps
    which were business dependent on it, that sort of thing really quickly
    we had to get very serious about incident response and designing a
    status page that could try to communicate all the subtleties of what
    things may or may not be working, especially when you have limited
    information in the first place and how our pager rotations worked. There
    was a huge Certainly in the last year or two that I was at Haruku, I
    think way more of my time went into that sort of operational stuff as
    compared to what I would consider like the core product or what someone
    externally might consider the core product, and I think that’s kind of
    the nature of. Structure business, but indeed that was, I think I
    mentioned this in our podcast with Martin, but that was honestly one of
    my motivations for local first was wanting to make software where my
    servers are not in the critical path for basic operation. And certainly
    we’ve tried to set new up that way. We’ll see what happens as time
    goes on, you know, if there’s a serious sync server outage and someone
    can’t sync their devices, you can obviously still work, totally fine,
    you just can’t move between them. Uh that’s an inconvenience, but it
    feels different from, for example, when something like Notion has an
    outage, you just can’t use it or access any of your data at all. All
    right, so, Mark, from the company’s perspective, we started out by
    saying it’s important. Why is that so?

    00:31:40 - Speaker 1: Yeah, well, I think there’s a customer

    perspective on this, and then there’s a company perspective on this,
    and we’ve been getting into the customer side a little bit. For
    example, we said that when a customer is writing in to support, often
    it’s something that’s important to them, it’s high stakes, it’s
    critical. So you’re already in an important situation. What I think
    people don’t realize unless you sort of do the math, is that your
    support function is often where people have the most or indeed the only
    human to human contact with the company. So it has the opportunity to
    leave a huge impression either for good or for worse. And also on the
    customer side, there’s this whole like support to sales process,
    perhaps we can talk more about it, but again, we’re thinking about
    support as part of a longer customer flow, a broader customer life
    cycle, and there it’s basically the first touch point on them
    eventually becoming a happily paying customer down the road. So we could
    talk more about those customer side things and on the company side. I
    think support is very important for getting information and motivation.
    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 in a sense that you’re a person too, you
    need motivation to do hard work and hearing from individual people about
    their desires for the product is quite motivating.

    00:33:08 - Speaker 2: Yeah, that to me is huge.

    The reason I build products is, of course we have ideas we want to

    express.

    We are making products that we want to use ourselves, hopefully, but I

    am doing it to help other people to serve their needs, to help them in
    their creation process, their creative process, and hopefully building a
    tool that fits into their life in some way that improves things for
    them.

    And so that includes both the call it positive or negative feedback.

    Of course you tend to get less of this through your support channels,

    but I do always deeply appreciate it when someone writes in to say, you
    know, I don’t have any complaint. I just think what you’re doing is
    great and it’s really a great tool in my pipeline and you know, keep it
    up, or sometimes it comes along with, hey, I’ve got some small thing I
    wanted to report a bug or something, but also by the way, I just want to
    say I’ve been you know a new customer for a year and a half and You
    know, it’s really made a big difference in, I don’t know, writing my
    master thesis. So of course it’s great to hear the positive stuff and
    that’s very motivating.

    But the negative stuff can also be both motivating in its own way, but

    also focusing, right, which is you kind of always have, here’s your
    backlog of 500 bugs to fix and 200 features that you know you want to
    build and what have you, but having someone write in and say very
    specifically, here’s who I am, what I do, here’s why I need this
    feature, or here’s why this bug is causing me a problem, and that just
    really brings it home in a way that Yeah, just the abstractness of
    here’s a ticket in my ticket tracker and my general, you know, we all
    have the general sense of craftspersonship. We want to make a good
    product and fix bugs and, you know, improve things, but it’s totally
    different to hear someone’s story about how it’s causing friction or
    creating problems for them and the tool they otherwise love to use.

    00:34:53 - Speaker 1: Yeah, it really does have an outsized impact. I

    think people underestimate this, it feels like it shouldn’t, you know,
    we have all these statistics and road maps and metrics and whatever
    about what we should be doing. But then you talk to one human being.
    Ideally you look them in the eyes, but the next best thing would be
    you’re on an individual email exchange with them, and for some reason,
    I guess this is what humans are, you know, it’s so much more motivating
    than any number of stats or declarations from the product manager or
    whatever would be. So I think it’s super valuable.

    00:35:24 - Speaker 2: Another piece of that being in touch with customer

    needs, is the fresh perspective. So, we have been in this world of how
    this product works and all the context that goes around it, greater
    tools for thought history, design thinking, and so on. And then someone
    new comes in, especially if they have very little context, you know,
    maybe Apple featured us under, you know, some productivity category,
    someone just clicked on it or tapped on it and like, yeah, cool, they
    install it, try it for 3 seconds and then they have a question and they
    write support, and they just don’t have a lot of.

    Context and all the context, but in some ways we have almost too much

    context, and I’ll give you a concrete example of where we applied that
    somewhat recently was realizing that we really need to explain the
    concept of nested boards better and that in the kind of news 1.0 era
    website. We talk about it, spatial canvas, and you can nest your boards
    and there’s a little video, but what does that actually mean? because
    you see the zooming thing, but of course a lot of, I don’t know, modern
    mobile software allows you to just zoom in like a map or a photo, and
    it’s really not that, it is really about this nesting. The zoom is an
    interaction that achieves the nesting.

    And so folks write in and they might say something like, my board is

    full, is there a way I can clear it? And then kind of wait, what do you
    mean full? Like, can you make it and you realize, oh, the home board,
    they don’t really realize that you can nest other boards within that.
    And so then you need to explain that. And having run across that a whole
    bunch of times, we realized that we really just need a whole page on our
    website. That basically explains the concept of nested boards, and that
    will seem to a long time user customer pretty basic, but for people who
    are new to it, that actually is a really core concept that it’s
    important to get or you’re not going to be successful at evaluating
    whether the apps are fit for you or not.

    00:37:23 - Speaker 1: Yeah, and speaking of frequent feedback items, my

    experience is that a large chunk of support traffic is assignable to a
    small handful of areas at any given time.

    So, just to pick one example, right now I feel like I’m getting a lot

    of support requests about how can I recover a car that I accidentally
    threw off the edge of a board, cause people weren’t aware yet of the
    undue last deletion feature.

    And what it is kind of varies over time. At one point we were getting a

    lot of requests for discounts from college students, I think because we
    were on some college student YouTube channel, maybe. I don’t know.

    But anyways, at any one time, there’s like 5 or 6 things that are

    basically on top of the collective minds of our users. And a coral area
    of that is that you don’t need to go through that many support tickets
    to understand what the 5 things are.

    If you do 20 or 30 tickets, you basically know what they are and they

    start coming up again and again.

    And it’s really valuable to know those things. It’s actually kind of

    inexcusable not to.

    And so that’s an example of where you can just a little bit of support

    work, get a really important bit of data from our customers.

    00:38:26 - Speaker 2: And this could be a place where the qualitative

    and the quantitative can reinforce each other a bit.

    Another fun story from the early days of Hiroku was one of our early

    team members was a fellow named Orn Teich, who I’d say I learned just
    about everything I know about product management as a call it formal
    discipline, let’s say something like that.

    He was a great teacher for me.

    But his pilot project to potentially join our team, which of course he

    eventually did, was to basically send a survey to all of our customers
    asking them what was important to them, and then present us a bar chart
    of the results. And of course that sounds kind of basic, but we were
    pretty surprised and actually it showed that.

    We kind of compared our roadmap of things we were working on, and then

    we compared that to, you know, there were 2 or 3 things that were far
    and away the most important thing that people were asking for. I’m
    trying to remember what it was, probably back then it was something like
    SSL capability. But we had it on our list, but we kind of thought it was
    like, ah yeah, it’s like number 15, we’ll get to it there. But when
    you looked at this, it was just like most people, you know, the things
    we were working on as our top priority items were way down the list that
    people were interested in.

    And of course support and what customers want now is just one input to

    your product process.

    You have a bigger vision. There’s a lot of reasons why you don’t just

    prioritize exactly what you work on based on that, but I think
    oftentimes product oriented companies with product oriented founders or
    CEOs or whatever do tend to lean so heavily on the vision side that they
    basically forget to listen to customers and.

    Seeing that aggregated, not just the individual requests, which of

    course you start to get a feel for it if you’re doing it every day or
    every week, but actually putting that together whether it’s in a survey
    form or for example, we often tag stuff in our support tool where every
    time someone asks for the Mac app we tag that or every time someone asks
    for a dark mode we tag that, and then you can go and kind of have an
    aggregate sense of that over time.

    Now another piece of the be in touch with customers, look them in the

    eyes, metaphorically speaking, is what I would probably call ad hoc user
    interviews or sort of just understanding who are these folks, right? And
    of course it’s part of our values that we don’t. Ask you to give
    anything, you don’t have to give a name or we don’t record a location
    or anything like that, even something like, I don’t know, FIMA for
    example, when you log in, they ask you what’s your first and last name,
    what’s your title, how many people are at your company?

    00:40:55 - Speaker 1: I don’t know if FIMA does that, but a lot of

    people do it annoys me.

    00:40:59 - Speaker 2: Yeah, it’s annoying, but of course it’s also

    valuable from their side. They can both for sales reasons it’s
    beneficial to the company, but probably also for support reasons as
    well.

    They can understand context about their customers, which is fair enough,

    but yeah, I’m also annoyed.

    Buy it, especially since I usually don’t cleanly fit into any category

    that they’re offering when I’m first trying out a tool, I’m usually
    not doing it for my work anyways. I’m just kicking the tires to have in
    my mind whether I might use it in the future.

    Anyhow, so we basically have no information about you other than your

    email.

    So then when someone writes in and they may either volunteer some

    information about themselves, Hey, I’m a professor of industrial design
    at this such university, or I’m a software engineer and I find that
    your product is useful for me in this way, that’s really nice to have.

    But the other thing we do is essentially turn support interactions into

    customer interviews at times, which can sometimes come from the form of
    someone writes in. I see something in their footer, you know, their
    email signature, and I’m like, oh, that’s interesting, and I just kind
    of end up asking them about it.

    Maybe they email in, Hey, I’ve got a bug, this thing didn’t duplicate,

    and they send a screenshot of their board and I’m looking at this board
    and I’m like, wow, this is awesome. What is this? And they’re like,
    oh, you know, I’m an amateur board game designer and this is like a
    game I’m working on for Kickstarter, blah blah blah. You get into that
    kind of conversation.

    So the chance to draw out. What the context is, what kind of people are

    using this product, what are they using it for, and certainly when it’s
    in the context of a feature request where someone writes in and says,
    hey, I want to be able to do X, and I say, OK, well, that’s
    interesting, you know, it’s kind of a thing we want to do, but not
    really explicitly on a roadmap right now, can you tell me more? And the
    motivation of Why they want it, what they’re trying to do with it,
    what’s interesting about that is another piece of this, I guess, coming
    back to the motivation for the team and for development, having that
    story behind it, here’s how this would help this person is, again, a
    really powerful thing for motivating development work.

    00:42:56 - Speaker 1: For sure, and I think in the same way that you

    want to have a pulse on the top 5 or 6 common like feature level issues,
    I think you want a sense of what are people tending to use the product
    for.

    Now, often it won’t be surprising.

    I would say that the users and the use cases that we have from use

    aren’t super surprising and the whole like the micro of it is really
    interesting, you know, like someone is a board game designer or they’re
    a restaurant consultant or whatever, you know, all kinds of interesting
    stuff, but the sort of Type or class of user isn’t super surprising,
    but my experience is that sometimes you have a customer base and you
    develop this really weird pocket that you need to inquire further about,
    you know, as some niche type of user or someone who’s using the product
    in a sort of surprising way, and you need to kind of look into that
    further.

    00:43:43 - Speaker 2: I like that in the process of talking here, we’ve

    naturally drawn on our experiences, my payment gateway, Hiroku, we
    talked about Muse. I’m sure a lot of folks would love to hear about
    what your experience at Stripe was like, whether you were exposed to
    that and kind of what the company culture was from the inside.

    00:44:02 - Speaker 1: Yeah, I had some exposure to that that I can speak

    to. The first thing I would say is, I think people underestimate the
    extent to which Stripe was initially uh like support slash customer
    service focused business. I think people tend to associate Stripe with
    product and engineering, you know, there’s a lot of good stuff there.
    But the original premise of the company, as I understood it, was fixing
    the support slash customer service problem that people. Had with payment
    processors, which was as follows.

    If you were an online business, and you wanted to get started with

    accepting credit cards, it was basically a complete mess. Like you had
    to fill up this application, you had to wait a bunch of time, and then
    every week with some probability, the company would just confiscate all
    your money, you know, like the classic PayPal move of, you know, sorry,
    you can’t get it anymore. And then you would write in and they want to
    answer and whatever. And Stripe did a lot of product and engineering
    things to address that, but the core premise, again, as I understood it,
    was to fix that experience and frustration that people had from the
    support side on payment processing.

    And I think it’s actually the straight folks where I got this insight

    slash idea that support is often one of if not the most substantial
    point of contact that people have with your company.

    As someone inside the company, support looks like a relatively small

    piece of the business. You have all this product and engineering and
    sales and whatever. But in terms of the time that people spend
    interacting with humans at your company, it’s mostly sales and then
    support. And so if you want people to have a good connotation with your
    company to have a good experience, the support needs to be very good.

    We’re also very lucky at Stripe as we were, I would say at Hiku with

    having just an incredible support team. It’s a really tough job, I
    think, especially at a company like Stripe, because in addition to all
    the standard support challenges, it’s an incredibly adversarial
    environment because basically some portion of the people who are writing
    support tickets are trying to steal an enormous amount of money from
    you, and you don’t know up front who they are, so you’re constantly
    dealing with that.

    I learned, especially at Stripe, it’s a very tough job and one of the

    reasons is because you’re often stuck between a customer who has a very
    valid and legitimate issue or complaint or feature request and not
    having a ton that you can do about that personally to fix it. So
    customer writes in and says, oh man, our business is really stuck. We
    need feature XYZ without it, we’re kind of out in the cold here. And as
    support you guys say like, I hear you, you know, we’re looking into it
    or it’s tough. Whereas if you are an engineer who’s just founded a
    software company, for example, and enough of those customers right in,
    you can just go in and build the feature and fix it. He has a lot more
    ability, I think, and degrees of freedom. It’s one of the reasons why I
    think it’s such a tough job.

    00:46:45 - Speaker 2: Yeah, it’s an interesting sub side of things. The

    far extreme to now gigantic company like Stripe would be something like
    the solo founder kind of company like you see with a lot of these calm
    fund companies or something where an individual or maybe two people are
    building a piece of sass, and they’re selling it. And they’re
    basically doing all their own support and very often, especially because
    their customers, you know, the B2B, so they’re often high ticket value,
    you know, you got your $10,000 a year customer, they write in and say
    this feature would really help us out. You may be willing and able and
    motivated to essentially just build it and deploy. The following week
    and then be able to follow up with like, here it is, check it out. And
    that’s like a really cool experience on both sides of that. I even
    remember doing some of that in the Hiroku days, maybe not features, but
    certainly more like fixes, which is someone write in, kind of see right
    away that they’re having the problem. And yeah, we’re a small team,
    and I don’t know, I was young, so I probably worked too much, but, you
    know, just like make a late night of it and fix their problem and deploy
    that and say, you know, here, go and try it again, maybe it’ll work
    now. Talk about a wow moment, getting that kind of a turnaround. I think
    that’s a way that a small company can differentiate from a larger, more
    impersonal one. Yeah, and speaking of the Peruki support team,
    definitely give a big shout out to those folks. They had a really
    difficult job, maybe less the stripe thing of the the adversarial
    element, but the problem of an incredibly complex product. And people
    write in with a problem, and it’s really hard, or I should say it’s as
    much an art as a science, to differentiate between something that’s
    genuinely a problem or a challenge with the platform, the product, that
    is, say, Hirokyo versus just helping them debug their app. And where to
    draw the line there and where to say, OK, well, you know, now you need
    to go on stack overflow and Google a bit and I really can’t help you
    further, but it can be hard to tell, and it can be hard to tell for
    people on both sides, so that means that the support person And in their
    expertise, which, you know, they may or may not be right, but they know
    what they’re doing, be able to say, look, this is kind of beyond the
    scope of how we can help you. Here’s some resources, good luck, and the
    person on the other end could feel like, no way, you’re blowing me off,
    this is a problem in your product, and that’s just a tough, tough,
    tight rope to walk.

    00:49:09 - Speaker 1: A fun aside here is that for these developer

    focused products like Kuroku and Stripe, it was the case that the people
    who best understood how the product actually works is the senior
    technical support staff. It’s not the founders and it’s not the
    engineers who are building it. It’s the people who have to deal every
    day with customers running into the platform and all the complexities
    that that entails. It was kind of amazing actually the degree of
    encyclopedic knowledge that the senior technical support staff had about
    the platform. They knew every bug, every quirk, you know, every weird
    gated behavior, they had it all down cold it was, it’s pretty
    incredible.

    00:49:51 - Speaker 2: And one thing that comes to mind for me in the

    balancing of the customers’ needs or desires, what’s a good experience
    for them when it comes to support and let’s say what the business needs
    is just cost, right? Like human time is expensive.

    Part of what makes software what it is is that it’s very scalable. You

    write one piece of software that many, many people can use, but that 30
    minutes that the support rep spends on your case, that’s just 30
    minutes of human time that they need to be paid for, and certainly it’s
    skilled work and the more you get into something like a Hiokku or a
    stripe, you know, Hiroku employs developers, pretty skilled developers
    in their support role, they have to, like, that’s the only people who
    can reasonably help you, but then that’s turns out, developers command
    a lot of earning power.

    So here, you know, there’s obviously a relationship between maybe go

    with like uh ARPU, which is the jargon for average revenue per user, but
    basically how much you make for each person that’s a customer or user
    and what kind of support they can reasonably give you and the reason why
    I don’t know, Google search or social media or something like that
    can’t give much support is.

    Each user just isn’t worth very much, right? So if the ARPU for Google

    search is $20 a year per user or something, you can imagine a support
    rep that’s paid $20 an hour, for example, you only have to burn one
    hour of support time and then instantly you’ve essentially are neutral
    or have lost money on that user.

    So and that actually came to mind with your First Republic was the name

    of the. The bank you mentioned with the reps standing around it so like
    I think my first reaction would actually be, oh no, is the bank going to
    go out of business because they’re sort of overstaffed and for all I
    know that could be connected to why Speakeasy failed. They had these
    really skilled people answering the phone at kind of level one support,
    which I loved, but then as it turned out, you know, maybe that cost more
    than people were willing to pay for their DSL. I’m not sure.

    00:51:44 - Speaker 1: Yeah, well, in the case of banks, I think it’s

    that sweet 0% deposit funding that they’re after, but I could see it
    being an issue for something like an ISP for sure.

    Yeah, the cost thing is interesting, by the way, you can look at the

    public financial disclosures of these companies, and I think people
    often don’t realize how much of the cost comes from sales and support,
    especially people who have been around startups and early stage
    companies, we think like all the expenses basically engineering.

    And that is true in the very early days of a company, but if you look at

    matureas companies like engineering or so-called research and
    development is a relatively small piece of the total expense, a lot of
    it is sales, support operations.

    00:52:30 - Speaker 2: Yeah, other challenges that come to mind for me

    here is, especially being in the position of being the one to give
    support, which is, you can’t solve everyone’s problem, at least not
    immediately, maybe in the long run, you hope you can, people write with
    feature requests, and in most cases, you know, we might ask for more
    information or that sort of thing, but in the end it’s sort of, you log
    that in your system, however, you’re tracking those things, and then
    you say thanks, and that’s kind of the end of it.

    Now I do differentiate a bit between someone has a problem like

    something happened and I lost some data or I’m locked out or something
    like that, that we take as a more critical happily we haven’t had a ton
    of those uses, but we have had some. For example, we created safe mode
    precisely in response to the crash loop problem, which is that ends up
    locking you out of your data and we dealt with some pretty frustrated
    and recently Irate customers as a result of that and so we’re building.
    And these safeguards to try to handle that situation a little bit, which
    of course is different from, hey, there’s this bug and it’s really
    annoying me that every time I do this, this panel pops up in the wrong
    way and you know, we’ll try to fix it as soon as we can, but we don’t
    see it necessarily as a critical blocker. It’s an annoyance. We try to
    have bug hunting days or weeks where we crank through as many of them as
    we can.

    00:53:50 - Speaker 1: Yeah, and on the feature requests and product

    suggestions front, I’ve had pretty good results with just taking the
    approach of being honest and transparent.

    Like someone writes in and says, can you add infinity pen colors, and we

    say, yeah, well, you know, we’re probably actually not gonna do that,
    at least in the short term, but my experience has been that you can use
    it as an opportunity to like message test or do some lightweight product
    management.

    So someone will write in and say, you know, I love the boards, but I

    wish there was a way to just kind of put a bunch of stuff together in a
    pile or a box or something. And they often don’t even know exactly what
    they want. They’re just trying to describe an issue that they have. And
    I might take the opportunity to do some lightweight product testing and
    say, oh, yeah, that’s interesting. We’re actually thinking about doing
    collections and they’re gonna have these properties and this is roughly
    how it would work and would that solve your problem. And it might say,
    oh, not really, because of XYZ or like, oh that sounds great actually.
    When’s it gonna be ready? Well, not yet, but you know, keep an eye out.
    And you do that enough over the course of weeks and months, and you
    build up a little reserve of customer knowledge and product testing.

    And I think customers appreciate that. It makes it feel more human and

    that they’re actually being listened to, because if you just reply and
    say your request has been noted, that sounds suspiciously like you just
    put it directly into the shredder. Whereas if you actually engage with
    them, there’s a little bit of proof of work there, and it feels more
    real.

    00:55:06 - Speaker 2: Yeah, to be honest, I do some equivalent of your

    request has been noted usually in a case where it’s obvious what
    they’re asking for because a lot of other folks have asked for it or
    because they did provide a lot of detail. Maybe I’d be more likely to
    do that for someone where we’ve had multiple interactions and so I
    actually know the context already sort of who they are and what they’re
    using it for and that sort of thing.

    But yeah, in the case of a new person that we haven’t seen before in

    our system and they didn’t provide a lot of context, then yeah,
    engaging and asking for more information and yeah, it’s a chance to
    find out what might be a fit.

    And sometimes they say, you know, here’s the problem I have, I’d like

    a feature that does X, and they say, well, actually we have this other
    feature that does Y that maybe is kind of similar. Can you try that? And
    they try that and they go, oh, actually, yeah, that gives me 70% of the
    way there, but I still want these other things. So yeah, that kind of
    back and forth, but then maybe you realize we could actually kind of
    extend or expand this other feature and cover their case rather than
    building the thing they asked for.

    I think it’s considered a truism in product work that you don’t just

    want to directly transcribe user or customers that they want to feature
    X, I build feature X, the more that you feed that into a complex system
    of inputs which includes vision, which includes other kinds of user
    interviews, which includes understanding the market, which includes
    looking at what competing or related products are doing. Which includes
    just the stew of interesting ideas and culture within your team, and you
    just put all that together, and the customer input that largely does
    come through the support is a huge and important part of that, but it’s
    just one ingredient that goes into what is hopefully a holistic idea of
    what your product could be in the future that will solve more problems
    for people, uh, address a wider audience, and just be more useful and
    more valuable in people’s lives.

    All right, let’s wrap it there. Thanks everyone for listening. If you

    have feedback, write us on Twitter at UAHQ or you can write us on email,
    which, as mentioned, arrives in our support queue. hello at musapp.com,
    and you can help us out by leaving a review on Apple Podcasts. And Mark,
    I’m glad we’ve been able to develop a simple but effective support
    system for you that serves our needs but gives the user experience we
    hope people like. I’m really curious to see how that might scale as we
    continue to go forward into the future.

    00:57:29 - Speaker 1: Yeah, and today is actually my sport day, so I’m

    gonna go get at it.

    0 min
  • 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 script, it actually takes pretty much the same amount
    of time because they chop up that audio and farm it out to a dozen
    little API servers. I don’t think I can say what they use, but they do
    that transcription in parallel and they do a lot of reliability checking
    behind the scenes to make sure that they got that accurate.

    I think people take for granted the reliability of these things. But

    like it’s so common for a custom engineered code to forget some use
    cases to have some race conditions where you would have some order go
    through, your system might go down or some things might happen out of
    sequence because you know computers. And you would lose an order. It
    would just disappear, vanish, and you would have no idea where it went.
    And this happened to the scripts, actually, we’re able to quote them
    because they said this in our case study. And I was just so happy to
    hear that because I was like, Oh, I’m not the only one. It’s not that
    I’m a bad engineer, like this is just the way things are, and you need
    a well organized and architecture system to take that problem away from
    you because I’m trying to build my app. I’m not trying to solve this
    weird distributed systems problem. So I’m very grateful that I found
    this, they found me actually, because of my blog posts, which is another
    bringing back to the career topic. I joined this company as employee 17
    before we made our 1st $1 in revenue, and now we’re a unicorn company
    and Unicorn here being the startup slang for a private market valuation
    of at least $1 billion.

    00:15:47 - Speaker 1: Yes, sir. I forget that sometimes I have to

    explain this.

    To some audiences, but this is not the kind of job that you would go on

    a job board and go like, right, out of these like 5 very competitive
    offers, like I would just pick one of them.

    The job doesn’t exist until you talk to them and you create the job

    yourself.

    I named my own job and created my own job because I thought that that’s

    where I would be most valuable to the company. I think a lot of jobs are
    like that in the sense that There’s like the 20% of jobs that are
    listed and then there’s like the 80% of jobs that are like, you know, I
    just hired my friend who knows this stuff really well. So perhaps that
    is a good segue into the career topic. I don’t know quite so.

    00:16:27 - Speaker 1: Like it’s so fresh to me that I’m still reeling

    from how this happened because it’s been the best career move I ever
    made.

    00:16:35 - Speaker 2: Yeah, well, we’d love to expand on that story a

    little bit, but yeah, maybe now is the right time to introduce the
    topic, which clearly we’ve hinted at, so that’s career. And before we
    get into a lot of specifics here again, you’ve written this book titled
    The Coding Career Handbook, and it is focused, I think, on the
    engineering or developer side, but obviously I think a lot of this is
    generalizable or we can talk today about something that certainly
    applies to probably everyone that’s in a design or product or general
    tech world product development job. But as always, I like to start with
    a little definition. I’d love to hear what the word career means to
    both of you.

    00:17:14 - Speaker 3: You know, Adam, I should know better by now that

    whenever we’re doing a podcast on a noun, I should think of my good
    definition ahead of time.

    Yeah, I don’t know. I might call a career that course and consequences

    of your professional endeavors, and the reason I like that is it because
    it talks about both what you end up doing and the implications that it
    has for you personally.

    And to me it also implies something that’s not super linear. Sometimes

    people think about career and it’s like, OK, I decide 18 and I’m gonna
    do this and I do it for 40 years, and this is the latter and boom boom
    boom, and I think the reality of careers is much more diffuse and
    nonlinear and probilistic now. We can talk about how that is, but
    that’s how I think about it.

    00:17:50 - Speaker 1: And definitely echo the fact that it is nonlinear.

    I have a more cynical take, which is like the career is the story that
    you retroactively tell after you do the things that you’ve done and
    you’re trying to spin a narrative that’s what you intended all along.

    But I think it’s very much in the vein of Steve Jobs’s Stanford

    commencement speech when he says like, you can only connect the dots
    looking backwards and that’s definitely how I have experienced life so
    far.

    I definitely think that there are other more air quotes, career oriented

    people who plan everything out. They have their 20 year roadmap for
    their lives.

    Some of them achieve that and many don’t, but their take is valid too.

    I just don’t particularly subscribe to that. I think in this day and
    age, the careers are a lot more mobile and random than they may have
    been in our previous generations.

    00:18:40 - Speaker 2: Yeah, for me, I think that word early in my life,

    I had a negative association with that word that it makes you think of
    maybe corporate ladder climbers and you know, you sort of like trying to
    kiss up to the boss in order to like get that next slot, you know, make
    more money, get the corner office, have a more impressive title, and a
    lot of it turns into just kind of status ladder games and that sort of
    thing. And so I felt kind of repelled from even thinking about actively
    the path of my career.

    But later on, I think I came to feel, OK, well, that is like a negative

    version of that. And maybe there’s also this way you described there,
    Shawna, this is the planned out thing, which is just some fields either
    demand that because they just require a lot of education being a
    surgeon, for example, it’s just you kind of have to have that plan and
    really pursue it. It’s not something you can kind of just dabble in and
    find. if it suits you. And so I think those of us that like a little bit
    more of an exploratory path, you know, the tech world where it is much
    more like an opportunistic and ever changing world, and you just try to
    adapt and find your place in it.

    Maybe that suits us all.

    Yeah, I think for me now, and of course we can also talk about the

    difference between, you know, being kind of an entrepreneur or founder
    type versus going to work at companies that already exist, but I do
    think they share the commonality that It’s a way to think about as a
    first class concern.

    We spend typically a third of our lives at work. How am I gonna make

    sure to spend that time well? And I think again, coming to those of us
    who are in tech, we’re lucky enough, I mean, I think for a lot of
    people, a job is really about putting food on the table. It’s filling a
    very basic need, it’s that almost the lowest rung there on the
    Maslow’s hierarchy of needs. We’re lucky enough, we’re very
    employable in a growth industry, and so we have the option to think more
    in terms of like, oh, I can get several job offers from several good
    companies and sure I can compare how much money I earn from them, but I
    can also think move up that hierarchy of needs and think in terms of
    like what’s the meaning that I want, how do I want to live my life, how
    do I want to spend my work day, and what’s the impact I want to have
    with that work and that’s a great privilege to be able to do that.

    But then I think it’s worthwhile to be a little thoughtful about how

    you spend that in order to make sure that that retroactive story is the
    best one it can be.

    00:21:00 - Speaker 1: Yeah. I think there’s a lot of fit with

    personality types as well.

    So there will be some personality types that crave structure. Tell me

    what to do and I’ll go do it. Whereas others, they refuse to be told
    what to do. They need to find it out for themselves.

    And so the career path for these two different types would be very

    different.

    So I think you have to figure out what you are and no shame in either

    approach really. I will say that career ladders are imposed by companies
    partially to give you a path to career development, to give you some
    kind of fair rubric on like, all right, you’ve reached these
    requirements, you obviously deserve the next level and the next bump in
    compensation.

    But then the, I like to call these barbarians, the people who don’t

    believe in structure, would say, All right, you’re constraining my
    growth. I could go out there and strike out on my own. And do actual
    things that matter in business. And if I deserve that in the
    marketplace, then I’ll get my reward, not some fake artificial internal
    metric that you made up. So I have empathy with both because ultimately,
    even if as an entrepreneur, if you’re someone who starts
    entrepreneuring because you don’t like traditional corporate structures
    and climbing those ladders, if you hire people, you’re going to have to
    establish career ladders for them because they want to know how they
    could grow with you and your company. So can’t really run from it.

    00:22:18 - Speaker 2: Yeah, that’s absolutely true. Different people

    need different amounts of structure and maybe like a rule zero thing
    here and successfully pursuing your career is self-know.

    And of course you can’t necessarily know that prescriptively right out

    the gate, but in your process of having experiences working at
    companies, taking freelance jobs, doing side projects, you start to
    learn what works for me, where do I thrive, where am I energized, where
    do I deliver things that people seem to really like or want to pay me
    for, where do I struggle, where do I not enjoy the work, where do I feel
    my energy drained, and then learn from that.

    And you know, I certainly learned pretty early that I want as little

    structure imposed as possible.

    I’m the frontier person that likes just the wide open space where I can

    go and just find opportunity where it may lie.

    And then there’s maybe some that like heavy amounts of structure, but I

    think most are somewhere in between. And I think one that comes to mind,
    maybe this describes you talking a little bit about not every job
    opportunity in a company is even publicized, which is what I usually
    call the entrepreneurship, right, which is that same concept of looking
    for opportunities, but you can only see when you’re inside the company.
    You’re there working at a more standard role, but then the company is,
    especially at a startup where things are changing all the time and you
    see. Some new need the company has that’s sort of unfulfilled and you
    know, maybe the top level management or leaders of the company should
    spot that and like form a new department or something, but that’s also
    an opportunity for someone who’s at the company, has the context and
    feels drawn, you know, I’d like to solve this problem and I think
    there’s a role here. I want to make that my job, and they take the
    steps to kind of create that structure, create that space for
    themselves.

    00:23:58 - Speaker 1: I’ll be curious to see some research on the

    success rate of entrepreneurship like that, because a lot of times I see
    those ideas get shot down and then they leave and then they do the thing
    anyway, because yeah, it’s not in line with the company management goal
    or whatever.

    00:24:12 - Speaker 2: Yeah, that’s right. I think sometimes being an

    entrepreneur is someone that really should actually be an entrepreneur
    and they’re in the wrong place to pursue that opportunity. I like to
    think sometimes in terms of venues, so you see an opportunity at the
    company that you’re at, maybe kind of carving out a new role for
    yourself at that company is a great opportunity, but maybe that actually
    is a thing that’s not best done there and should be done somewhere else
    at another company, at your own company.

    And then of course sometimes there’s the even more dramatic version of

    that is maybe the thing you want to do isn’t even in your current
    field, and there you actually want to completely switch fields kind of
    like you did. So I think we always have to think about the work we’re
    doing as being inside a nested series of containers and to do great
    work.

    We think of that as being something that’s inside ourselves or

    something maybe individual or maybe this is just my kind of American
    culture by. the kind of you know individualist perspective which is
    thinking, OK, the way I’m going to be successful is having great
    skills, but indeed is the systems you plug into the organizations and
    being in the right place at the right time, and I think for me part of
    career is following the opportunities to try to put yourself in the
    right place at the right time to be able to do something meaningful and
    have a big impact.

    00:25:28 - Speaker 3: Yeah, if I can synthesize and emphasize some of

    the things I’m hearing here, I think it’s really important to take
    agency over one’s career, and that’s about, like you said, Adam,
    understanding oneselves first, and understanding the world and what’s
    out there and making deliberate decisions about how you’re going to
    move forward in that world towards achieving whatever ends you want.

    And I think you got to be aware that you’re probably gonna be facing

    trade-offs among All the different desiderata of one’s career, you
    know, the feel, the flexibility, the size of the company, the
    compensation. And I think importantly, it’s my belief that the world
    doesn’t owe you a living, and it certainly doesn’t owe you your dream
    job doing whatever you want, making as much as you want, wherever you
    want and whatever conditions you want, right? You’re gonna have to go
    out there and find something that works in the same way that an
    entrepreneur can’t just do a company that makes whatever. Sells
    whatever, whatever price and expect the market to accept that.

    You know, you gotta go out there and find what’s desired, what’s

    valued, what fits with your interests, what skills you bring, and make a
    deliberate decision like that.

    And the zero with mistake that I see people making is not understanding

    themselves. And the first mistake that I see them making is not taking
    responsibility for their own career decisions and just kind of
    sleepwalking into something, which sometimes it works out and sometimes
    it doesn’t.

    00:26:40 - Speaker 1: I have a follow up question, Mark, if you think

    about the importance of understanding yourself, where are you on in
    terms of correcting weaknesses versus just betting on strengths?

    00:26:50 - Speaker 3: So one of my big personal philosophies is to be

    honest with oneself, and I think it’s really hard to make yourself
    something that you’re not to kind of fundamentally change your personal
    characteristics and personality type, I think, as you described earlier.
    So I think that kind of stuff. It’s really hard to work against you.
    You’re gonna be going really uphill. I think there are skills that one
    can develop, and that’s probably worth doing, but I think you gotta
    differentiate between those and overall, I would lean towards
    emphasizing your strengths and finding a field and a job that taps into
    that, cause again you’re gonna be going uphill your whole career if
    you’re working against that.

    00:27:27 - Speaker 2: I think the path I took for that was not thinking,

    OK, here’s a weakness, let me see if I can become really great at it,
    but to first of all be aware of it.

    Secondly, to perform maybe some basic mitigation, don’t make it be a

    big blind spot or gap that you just can’t do anything about.

    So one example might be, I know this comes up a lot for engineering and

    design types, which is like salary negotiation or negotiations generally
    around compensation and other things. We like to make things. We don’t
    like to do deal shenanigans or something, and many people feel very,
    very uncomfortable doing that sort of thing, and I probably count myself
    among them.

    But for me, I think fairly early on I realized that that is an important

    part of being in business, about having a career. There’s going to be
    certain critical negotiations and you do need to be able to represent
    yourself and your interests. And for myself at least, it was worth
    taking a little time to shore up that weakness so that I wasn’t just
    either completely awful at it or just that it was a huge blind spot. But
    in no world is there am I ever going to be a great dealmaker, a great
    negotiator, you know, the hostage negotiator guy or whatever, what’s
    that book?

    00:28:38 - Speaker 1: Never split the difference.

    00:28:40 - Speaker 2: Yeah, that’s the one.

    But it’s full of advice for every reason I go, it’s hard to imagine

    myself, you know, doing that or anything like it, but I can know what it
    looks like to be great at that.

    I can look for people that I want to be on the TV, you know, I can

    recognize the value of that skill and think, you know, it’s good to
    have a business partner or a colleague that has that skill and to
    respect that skill and hope that they can deploy it.

    In service of you know our team and then I deploy my skills in service

    of our team, maybe skills they don’t have. So I see it as like kind of
    a protecting from a downside rather than long-term investing. And when
    it comes to investing and learning, it’s your strengths and those
    things where you start investing and you just see those really quick and
    high returns on what you’re doing because it’s something you like to
    do and you’re good at.

    00:29:26 - Speaker 1: As a poker player, I kind of call that a leak in

    your game. Like you should know your strengths and what your sweet spot
    is, but also if you have any leaks or towels, then you probably should
    know about it and do the bare minimum to correct for it. You know,
    you’re not going to be a better player by only plugging leaks in your
    game, but you’re at least going to maximize on your potential value. So
    that’s pretty good.

    One thing I often bring up, which is a wonderful piece of career advice

    from Julia Evans, which is to write a brag document. And this is
    something that is useful in negotiation in promo conversations or just
    in regular annual review conversations, which I think people should do
    more of, which is essentially don’t expect your manager to know
    everything you’ve done. You think it’s their job. But they have like 8
    other people that they’re managing. They have their own stuff going on.
    They have your interests at heart. It’s not their top priority of the
    day, even though they might say it is. It’s for sure in your best
    interest to represent yourself really well, even though you feel
    uncomfortable about it.

    But you’re also not going to represent yourself really well because you

    can have recency bias in all the human cognitive issues of memory and
    self-deprecation or being humble. So Julia Evans’s advice is to keep a
    fresh document that you maintain.

    Of the things you’ve done and the outcomes, the quotes, the measurable

    numbers, preferably some, some idea of chronological order that fairly
    represents the kind of work that you’ve done over the year. And I think
    that’s a wonderful thing that you can just take to the bank or just
    bring up because you’ll be asked for these things at the most
    inconvenient times.

    There’s official performance reviews, but then it’s actually

    oftentimes the unofficial vibe checks, I’ll call them. When you’re
    asked like, Leo, how’s it going? And then you know you’d have like a
    really crappy answer, but if you came prepared, you’d actually have a
    really amazing answer and that person will walk away with a much better
    impression of the things that you’ve done for the company and that’s
    just positive for you in literally every situation. So my version of
    this, because I’m too disorganized to keep a rag document is I keep a
    brag Slack channel. I have a Slack channel to myself where I just pop in
    stuff as they happen that I would like to brag about in the future, and
    Slack just keeps a reverse chronological order of things that I can look
    back on.

    00:31:46 - Speaker 2: I love that, and the word brag is actually really

    interesting because, you know, when I have been in the position of
    offering career advice to friends or colleagues in the field or
    whatever, representing yourself well and honestly is something that I
    think is really important, and it’s one reason I like, for example,
    having a personal website or some kind of online profile, I guess a
    resume or CV. Serves some of this purpose, but people don’t tend to
    update it other than when they’re job hunting and it’s a very
    particular format and that sort of thing, having some way that you can
    say kind of here’s who I am, what I’ve accomplished and what I’m
    about, what I value, what I’m passionate about, what you should know
    about me if we’re going to work together in some way or I’m going to
    come work at your company or whatever. And I often find many folks are
    very uncomfortable about this, and I think there is sometimes a cultural
    thing. I heard from a few German folks when I moved out here and I
    basically just wrote a little document that was just, you know, one of
    these GitHub sort of short scratch pad things where I basically said,
    hey, I’m looking for companies to work with. This is what I’ve
    accomplished, this is what I’m good at, this is what I’m not good at,
    this is my ideal profile of company, and here’s the kinds of problems I
    can help you with. you think this is interesting, let’s talk. And I
    shared this with a number of folks, and a few folks expressed surprise
    and one said, well, you know, I love the American swagger that comes
    across in this and what does that mean? And they said, well, you know,
    at least where I grew up and maybe it’s especially with East Germany,
    it’s very much about don’t ever state your accomplishments or what you
    think you’re good at. Keep your head down, stay quiet, let the work
    speak for itself, and that any kind of accounting in that form is a kind
    of bragging. And even beyond the cultural thing, I think there’s a
    personality thing. Some folks just don’t feel very comfortable talking
    about themselves, but I think it’s really hard coming back to Mark’s
    point about agency and taking responsibility for your career. I think
    it’s very hard to accomplish what you want to accomplish and get the
    best possible outcome if someone is not taking an accounting of the
    things you’re good at and the things you’ve accomplished, and who’s
    that someone gonna be if it’s not you.

    00:33:48 - Speaker 1: Exactly. One way I like to point people out to not

    brag, to not think about it as bragging, is to essentially show proof of
    work or essentially show things that you cannot fake. So if you say
    you’re award winning, show me the award. Is it some made up award or
    some award that actually matters? If you say you’re a thought leader,
    well, you automatically disqualified from being a thought leader. This
    is very common, by the way, a lot of people would say like there’s some
    kind of thought leader and they don’t show evidence because they don’t
    have any. But if you do, if you do have substance to back up your
    claims, and show it, then no one really can dispute with you on what the
    quality of your accomplishments have done.

    I think honestly it’s a way to just make it easier for people to get to

    know you. To shortcut the awkward dance that you do when you meet people
    for the first time and you don’t really know what they’ve done in your
    life and how you should be addressing that person. So yeah, I just think
    basically get over it and do it interesting stuff enough that you’d be
    comfortable putting it on your resume, because if you’re not
    comfortable with that also probably show something about the scope of
    your ambitions and maybe you should push yourself a little bit more.

    One thing I’ll mention as well, which is another anecdote that I have,

    because I think you mentioned a little bit about negotiation. Which is
    another piece of career advice that I had with a friend. So a friend of
    mine who I’ve been advising because he recently graduated from college
    and got a job at a well-known tech company, he found out that his
    coworker was getting twice the equity that he got.

    He was really pissed. He only started a job for like 34 months and he

    was like, I don’t know, like. We have to save him amount of experience,
    like I’m doing more than him at my current job and he’s getting twice
    the equity and the way the equity systems work in the US like, this is
    locked in for 4 years. It’s kind of unfair, of course. But I told them,
    the problem is that you’re getting half the equity of your peers and
    you’re trying to renegotiate for better equity relative to your peers.
    I think for you, the better angle for your career is to get new peers.
    It’s kind of like when life gives you lemons, make lemonade. When
    people give you peers that you don’t compare that well to, for whatever
    reason, you didn’t negotiate with that well, they looked at you wrong,
    whatever. Don’t care, just get new peers. Just make yourself in a
    completely different category that the next time this conversation comes
    around in 2 years or 4 years, it just doesn’t happen because they want
    you so badly for the things that you’ve done. And I think his anxiety
    went away when he realized that it’s not about the short term gain and
    keeping up with the Joneses. It’s about being in a different
    neighborhood.

    00:36:18 - Speaker 3: I’ll point out that a lot of the queer stuff

    we’ve been talking about here so far is call it human stuff around the
    edges. It’s not OK, you should study algorithms and then react and then
    whatever post crass, right? I mean, I’m sure we have lots of
    suggestions on that front we could give them on this podcast perhaps,
    but I think people underestimate how important this stuff is.

    It’s really important. It’s really valuable. It’s easy to form your

    mind, especially coming out of undergraduate where everything is like
    formalized tests and classes and grades.

    A lot of the important career work does not look like that. It’s just

    dark matter that exists between people and to your experience, Sean, I
    think it’s really critical to speak with people who are 5, 10 years
    ahead of you.

    In a similar journey because they’re gonna have all kinds of weird

    stuff that they see and all kinds of interesting tricks that they know
    of, and they can give you those heads up.

    It sounds almost too good to be true, but you can just like email a

    handful of, for example, engineering, hiring managers and your career
    earnings go up by 6 figures easily. So I encourage people to take
    advantage of just speaking to people and having a conversation and get
    advice.

    00:37:21 - Speaker 2: Maybe that advice is to kind of pay attention to

    the basic human dynamics is also especially valuable in a field where
    maybe a lot of us were drawn to it because we’re not that good at
    humans or, you know, we’re young introverted kids that learn to play
    with computers and we’re more comfortable there maybe than we were in
    social settings, for example, that’s obviously not true for everyone in
    the field, but lots of people are in that position.

    But then it turns out that products are made by companies and companies

    are groups of people who are working together, and groups of people
    working together always have social dynamics, and of course the
    individual humans involved have their own thoughts and feelings and
    emotions, and you have your own thoughts and feelings and emotions and
    just knowing a little bit about how to navigate all that can make a very
    big difference for you to be able to integrate to the organization and
    again have the work you want to have and have the impact you want to
    have.

    00:38:13 - Speaker 1: I have one more point to bring up in terms of sort

    of general career advice.

    I think, yes, we want to be intentional or try to point ourselves at

    worthwhile problems that we think that we can solve and grow together
    with the industry and, but then there’s a lot of randomness and
    serendipity and I think being able to square the intentionality and the
    randomness, I think the best way that I’ve heard about it is to create
    luck. And it’s like, how can luck be created, it just happens to you.
    And I think this is one of the biggest mental model shifts that I’ve
    had in my career so far that I received as advice from people that were
    ahead of me.

    I’ll bring you through sort of like a four stage mental model if

    you’re ready to do that. So like the first stage of thinking about luck
    is that people are either lucky or unlucky. There’s people that you
    know, like things just happened for them. I don’t know what happened,
    but they’re lucky and I’m not like that, so I just kind of treat them
    as different than myself. And I think that’s a very static view of how
    luck is distributed in the world.

    The second stage of this mental model is progressing from that to having

    some agency in the matter, which is Selina Mark you brought up. And the
    term that is very popular for this is having a lux surface area, which
    is that people who are lucky have a larger lux surface area for
    capturing the random luck that happens in the universe as opposed to
    people who are not lucky.

    What kind of lux surface area are we talking about? The two typical axes

    that people give a combination of doing and telling. Like, have you done
    enough that is noteworthy for people to take notice of your work and
    then have you told people about it? A lot of people, particularly on
    this podcast, are doers. And they’re maybe not so comfortable with the
    telling, but you have to kind of do both in equal amounts to get your
    message out there, to get your work out there, so that you get
    opportunities for future work that compounds and compounds and
    compounds. But you have to sort of think about it in terms of that two
    dimensional graphic of like surface area rather than a one dimensional
    lucky or non-lucky binary metric. Then the third progression in this
    line of thinking is that there are 4 kinds of locks, so you sort of
    split that two dimensional chart into like a 2 by 2.

    So I kind of turn, if you imagine like a 2 by 2 diagram, the y axis, you

    could sort of split into active versus passive, and the x-axis, you can
    split into general versus individual. So, for example, general and
    passive luck is luck that just happens to you. It’s the same luck that
    a plant would have just being born where it is. A lot of this comes from
    privilege, but a lot of this just comes from just sheer randomness in
    the universe.

    But active luck, for example, that in general is from you just doing

    random things, trying all sorts of things and seeing what sticks, kind
    of throwing stuff at the wall and seeing what sticks, right? And you can
    sort of think about career analogies for that as well. But where things
    become really individual is that, for example, you sort of primed
    yourself throughout your career to notice certain opportunities and when
    it happens, you are one of maybe 5 individuals in the world that can
    take advantage of it because you’ve just spent all your life preparing
    for this. And when it happens, you really capitalize on that and that
    really works out for career progression as well.

    And then finally, the fourth category, which is active luck, that is

    also individual focused is what I call magnetic luck, which is that
    you’ve done so much in your life and you’ve built such a strong
    network that you draw people to you in the sense that people come your
    way because they know to seek you out. And I really like this as a
    mental model because Obviously it’s an aspirational thing, but I do
    really like the fact that you don’t do as much work, but people are
    drawn to you for your specific skill set that only you can fill. Like
    there’s a sort of U-shaped hole in the universe and you’ve created
    that sort of suction energy or 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, right? And so finally, throughout
    all of that, I think there’s a lot of focus on Being in the right place
    at the right time.

    The final stage of this model that I developed for myself is the concept

    and the place of strategy. Instead of being in the right place at the
    right time, try to think actively about where the puck is going. A lot
    of times I call this the meta game behind the game, so a lot of times
    you’re playing two games at once, you’re playing the game with the
    rules as they are written right now, and then you’re also looking out
    for how the rules are changing. And going towards that and hopefully
    being in a position to change those rules to benefit yourself. But to
    me, that’s strategy, right, to being able to say like, OK, the status
    quo is this. I can play by the system, but at the same time, the system
    is probably going to change in a certain way. If you have an active
    opinion on that, you can just leave behind the whole system and just go
    straight for the new one because that’s ultimately where you want to
    go. I’ll stop there. I feel like I’ve been rambling for a bit. I
    wanted to just drop this because I think luck plays a huge role in
    careers, but often people don’t really have a system to think about
    luck.

    00:43:02 - Speaker 2: I like the framework. I think that knowing that,

    of course, there’s always this huge amount of, as you described a
    randomness or privilege or just, yeah, the, everyone has a very unique
    and different circumstances, time and place you were born, particular
    capabilities, you have just people you just randomly happen to meet that
    may have opportunities for you, but being alert for those.

    Opportunities and doing what you can to maximize your opportunities.

    Well, that is something you can actively do, and I think it’s probably
    a recipe for happiness and life in general to focus on the things you
    can affect and work on those things and then try not to lose too much
    sleep over the things that are circumstances that are essentially forced
    upon you by the universe.

    Exactly. Do you have any good personal stories about sort of using some

    elements of this framework or essentially creating that lock to find
    your way to, especially the role you’re in now that I’ve heard you
    speak with great pleasure about? Was there some of this framework that
    fed into you being able to find this? Yeah.

    00:44:03 - Speaker 1: So the blog post that I wrote directly led to me

    getting hired for the role, and in fact, the full story is a little bit
    more complicated than that. The blog post that I wrote generated some
    comments and one of the commenters on that blog post. Got hired as head
    of product for Temporo and that guy turned around to hire me because
    obviously I wrote that blog post. So out of that blog post, two jobs
    came out.

    But I think the more general meta thing is to write about the most

    interesting problem in your domain. And just to work towards that,
    because I think problems are inherently more attractive than solutions,
    they’re inherently more timeless than solutions.

    A lot of people are like very focused on solutions like what’s the best

    tool for personal knowledge management? What’s the best tool for
    thought? But really, like, OK, sure, like every solution out there is
    just one instantiation of one team’s current way of thinking of how to
    solve this, but if you study the problem in the infinite depths of the
    nuances to what people really want out of that problem. You have a more
    general and timeless model for evaluating solutions to aligning your
    career with those solutions and to see what’s missing, to kind of look
    for the negative space and if that’s valuable enough to pursue it.

    And it’s kind of what I did with the whole long running job thing. I

    was like, OK, service is a really well, very competitive space, but hey,
    the long running job thing is not really being done. And so you just
    write about it and I think when the opportunity comes up, it looks like
    nothing happened for like a year. When the opportunity comes up, you’re
    in a place to have thought through at least the arguments for it so that
    when they came calling, I picked up the phone, where in a lot of
    situations, you would ignore an email like that.

    And that’s also you know something I talked about with the passive

    individual luck, which I call sort of prepared luck. There’s some
    situations where you have to kind of prime yourselves because these
    opportunities happen at random to people and they’re ignored all the
    time because you’ve just trained yourself to say, like, this is just
    one of many opportunities, and I haven’t really thought about it. But
    if you do work hard to understand like what could be missing. Then you
    prime yourself a little bit better to write it.

    So yeah, I definitely say that I’ve unintentionally aligned myself

    towards this framework, just again, this is retroactively breaking it
    down for myself.

    00:46:15 - Speaker 3: Yeah, that’s a great story.

    And another thing I think it illustrates well is how unknowable the

    payoffs are for your discrete investment in one’s career capital, if
    you will.

    You won’t know and you can’t know if, how and when these investments

    are going to pay off in practice what we see is it takes a very winding
    course, you know, it’s a year later someone read a comment and then you
    know emails or whatever, you know, many such cases.

    And I think that’s one of the things that makes it so hard to do. You

    have to, you know, sit down and write a blog post, which everyone knows
    is a huge amount of work and you’re dealing with people commenting
    about you on the internet and blah blah blah, but you have to kind of
    believe that probabilistically at some point in the future, this will
    pay off.

    I think it’s just important to be aware of that, because otherwise

    one’s gonna be frustrated.

    It’s not something that you can pick an outcome and say I want to

    achieve that. Therefore, I’m going to do this investment. It’s much
    more probilistic and random. The flip side of that is that it becomes
    optionality, you know, if one has career capital, you can, if you will
    call on that in different ways throughout your career and you don’t
    need to know the time of creating it, how you will make that call.

    00:47:19 - Speaker 1: I think that’s very well put. My personal

    reflection on this, by the way, is uh, this becomes a problem when your
    job involves the industrial production of these kinds of things, the
    industrial production of luck.

    Like I just told you, like the feedback cycle is over a year for me

    about publishing a blog post to me getting the job. That doesn’t fit in
    any OKR or performance review cycle. And when your job is kind of
    creating content or creating luck in different ways, whether it is sort
    of laying the seeds.

    So for example, I have some customers now who I think are potential

    investments, but they won’t pay off for another 23 years. So they’re
    viewed as dead weight by some people, but in 2 or 3 years from now,
    again, like, there’ll be a whole different team taking credit for the
    groundwork that we laid today. And I think you just kind of had to take
    a very long term view for that.

    And I wonder how to measure this because people ask me like, How do you

    measure your like output or how do you justify the time that you spend
    on all this personal content? And I’m like, I don’t know, but I just
    generally believe that doing good things leads to good outcomes. Like
    there’s a bit of mystic karma that you have to kind of have to suspend
    your disbelief for, but hopefully it kind of works out. It is an open
    question, how do you measure this?

    00:48:32 - Speaker 3: Yeah, it’s a tough matter of judgment, which by

    the way, kind of seems isomorphic with the startup investing problem,
    and I think that the state of the art solution is similar, which is you
    find people who have good demonstrated ability to. Evaluate these things
    and you get their advice and opinion. So it circles back to my
    suggestion earlier I was speaking with people who are a little bit
    further ahead in their journey. They can’t give you a closed form
    solution for how to evaluate your personal capital investments, but they
    can give you their appraisal. I like that.

    00:48:59 - Speaker 2: Yeah, hearing you describe it that way, it made me

    think of investing. It also makes me think of the sales, for example,
    especially enterprise sales, it can be a very long cycle as an element
    of this, and research, right? The work Mark and I were doing, and I can
    switch, and the work that team continues to do, where, you know, you can
    have KPIs around papers published and citations and things, and that is
    what tends to kind of drive the academic world, but the reality is, it
    is very long term investment.

    Most of it won’t pay off, but the things that do pay off, you know,

    occasionally you invent calculus or split the atom or whatever, and
    those payoffs are so big that it’s worth having a big portfolio of
    these things, and so it’s probably the same for career investments,
    whether it’s finding opportunities through blog posts, through
    attending events where you’re likely to meet other like-minded people.
    And so on. It’s a long and steady portfolio of investments and over
    time, you can post hoc show how it paid off, but it’s really hard to
    measure it in a week by week or month by month metric.

    00:50:00 - Speaker 1: Yeah, totally. I will say that there is a

    noticeable difference between people who engage in these luck creation
    activities, let’s just call it LCAs, as a general category of like
    blogging, speaking, whatever, right, putting yourself out there.

    There’s some people who just do it because they are told that it’s a

    good thing to do and then they do that, and others who do it because
    they’re genuinely interested in the thing that they’re working on.

    And every time it’s super obvious which is which, and one is just

    completely not that valuable and I wish I could tell them without
    offending them.

    And the other is I wish they would do more of and a lot of them don’t

    because they don’t know that they have it, whatever it is.

    And Basically, what I’m saying is like the outcomes are almost

    secondary to you loving the process, just falling in love with the
    process, making the best thing you could possibly make like for its own
    sake, not because you think some benefit will flow back to you
    eventually, because it will, but if you’re motivated by the benefit
    first, you’ll make a worser product.

    00:51:00 - Speaker 2: That to me also circles back to something I

    realized at some point in my career, which is I care very much about the
    mission, the impact, you know, the thing you’re making, right? I want
    to go to work for this company because they make this product or I want
    to get involved with this group that’s working on this open source
    project or whatever because I love the product or the problem they’re
    solving or whatever, and that remains incredibly important to me, but it
    has become of equal importance to me, the Exactly as you said, loving
    the process, loving the act of what I’m doing when I sit down every
    day, and whether or not this particular product I’m working on a
    particular project I’m involved in right now has kind of the impact I
    wanted to have because again, some do, some don’t. That’s part of the
    business, but I want to know that I’ve enjoyed the day to day, the week
    to week, and a lot of that is the people I’m working with, the
    specifics of what kind of work I’m doing. And maybe the vibe of the
    team, the culture, even something like the tools we use, right, that if
    the tools make the creative process and my daily work kind of enjoyable
    and fun versus they’re sort of clunky and feel like they’re holding me
    back.

    It’s those collection of things really matter a lot.

    And in fact, I’ve told the story on the podcast before, but I, similar

    to you made a transition, career transition from video games early in my
    life, and that was something I was passionate about making games and I
    still think games are an incredible form of art. But the process, at
    least at the time I was involved in it, the way the teams worked and the
    tools and all that sort of thing were very punishing. I would describe
    it as, it wasn’t worth that to me. It wasn’t worth hating the day to
    day in exchange for producing a thing I’m proud of at the end, or an
    art form that I wanted to be involved in.

    00:52:43 - Speaker 1: You kind of have to go through that journey to

    appreciate what you have today, don’t you?

    00:52:47 - Speaker 2: Quite so, yeah, I never would have thought, you

    know, as a younger person that business and productivity software would
    make me a lot happier than writing video games for a living, but you
    know, sometimes you got to maybe achieve your dream to realize it’s not
    what you want after all.

    00:53:02 - Speaker 1: So, a lot of people come to me actually, they’re

    inspired by games. A lot of us got into programming because of games and
    design because of games. But then, I immediately tell them to avoid the
    AAA game industry like play, right? And I wonder how to fix that because
    like that cannot be a sustainable way of things. And I don’t know, like
    GameDev just seems like such a dead end career because it takes such
    talented developers, pays them nothing, and they all come up burned out.
    And I feel like we should talk about this more because like, how do we
    fix this?

    00:53:32 - Speaker 2: Yeah, well, I feel the indie game revolution, you

    might call it, when that sort of started to happen, I think it was kind
    of in the late aughts, is that what we’re calling that decade now, but
    things like Braid, for example, was, I think one of the first kind of
    like, what seemed to be successful relative mainstream success made by a
    relatively small team, partially enabled by these new platforms like the
    Xbox, Marketplace, and Steam and so on.

    So to me, I could imagine myself getting back into games now, I

    wouldn’t do that cause I love what I’m doing, but there is a coming
    back to this venue idea or container, you know, the AAA in game industry
    was not the right venue for me to express my ideas and do my work with
    something like the indie games world, where a couple of people can make
    a successful game that has a lot of art and makes a unique statement,
    and can be played by a lot of people, and, well, you can make a living
    from it.

    And the style and approach and you know, just add a work life balance of

    the indie games industry is quite a different beast from the AAA world.

    00:54:34 - Speaker 3: Yeah, for me, this also moves back to the agency

    discussion and this idea of actively understanding the world.

    I’m not sure because I don’t know a lot of people who entered and

    exited the AAA space, but my suspicion is that there’s a few fields
    where people really significantly misestimate the nature of the work in
    totality, including the conditions and the career implications and
    compensation and hours and things like this, and I think that’s one of
    them, and I think they get a little bit blinded by what they see on the
    outside, and I think if one. took more time to see what’s on the
    inside, they might come to a different conclusion.

    Now I think there’s also an element of people, they know that’s there

    and they still want to do it, you know, cause people are different, you
    know, fair enough, but this is a case where it’s worth it to really go
    in and understand what it’s actually like, you know, do an internship
    or speak to several people who have done it for a decade and go on with
    eyes open.

    00:55:22 - Speaker 1: Talk to the others. It’s a good piece of general

    advice.

    00:55:27 - Speaker 2: Yeah, absolutely. lots of eye-opening things in

    this conversation here already.

    The last one I’m going to make sure we talk about, because I think Sean

    you’ve mentioned it a few times, is what I would call specialization.

    That idea was the U-shaped hole in the universe, which is sort of how

    much your skills are very particular.

    And it seems, I guess, kind of counterintuitive that having a very

    general skill set being a jack of all trades or being a generalist
    engineer, I don’t know, full stack engineer or generalist designer or
    something, you would think that would make you more employable because
    you can fit more potential jobs, but it seems to be the opposite of that
    when you have some very high degree of specialization both in your
    skills, but also that you’re known for.

    You’re that one person that has that very particular skill set and

    people know that and your phone rings when someone needs that specific
    thing, maybe to your earlier point about your blog post on the
    asynchronous world of services. How should, especially younger folks who
    are just getting started, how should they think about the benefits or
    downsides of specialization and how to find their specialty.

    00:56:38 - Speaker 1: Oh, OK. My approach to this, which is a topic I

    cover in the book actually, is you should specialize in peacetime and
    generalize in wartime, mostly because specialization, yes, is very
    valuable. And a lot of people will be seduced away from it because they
    want to have an approximate knowledge of all things. They want to sort
    of view themselves as pluripotent, to be capable of a lot of things.

    But I think you only understand what it’s like to master something if

    you just spend a lot of time.

    Digging into it. And learning how to master things is a skill in itself.

    And you don’t get there by being a journalist at a bunch of different
    things.

    You get there by breaking through the basic things that everybody knows

    and then understanding which part of that is not true and really getting
    to the nuance of that, and then getting to know all your peers who are
    masters and understanding, instead of looking at them as heroes, they
    actually all have flaws too and they coming of their own theories.

    Like that whole journey of mastery of a domain. is something that we

    systematically underrate.

    And being able to specialize and get to a mastery in the field, that you

    know all these things that you both know the things that everyone thinks
    that they know, you both know the underlying lies to that, but then you
    also know what could be improved and you have an opinion on the other
    experts in the fields. I think that’s super valuable and can be only
    developed when a company or a problem domain gives you the space to do
    that.

    But you will be forced to generalize when you basically don’t have a

    choice, when there’s no one else doing that task and it needs to be
    done, and surprise, surprise, you’re it. And so that’s how I feel
    about it.

    Like when you can specialize, especially if the company gives you the

    space to do it, because you’ll be learning so much that other people
    just don’t have access to, and you can trade that specialty in with
    other specialists, right? You don’t have that much to offer if you’re
    just a journalist, you know the average of what most people who spent
    some time at didn’t know. But if you’re a specialist in something and
    you can sort of deal with other specialists and other things and have
    some kind of equal value to exchange there.

    So I do view that as valuable career capital keyword to offer. This is

    obviously a concept from County Newport, an author that we both like,
    but I actually haven’t read the book that it comes from, so I don’t
    actually know what the career capital concept comes from. It’s just
    what I intuit as the value of building up reputation and skills in a
    specific career.

    00:59:05 - Speaker 2: Yeah, the book you’re referencing, I believe

    it’s called So Good They Can’t Ignore you. I read it quite some time
    back. I think it was one of the things that helped influence me to think
    more of my own career as a first class concern to invest in.

    And I should have pulled up my highlights from the book to refresh

    myself before we talked here, but briefly I would summarize that
    basically a career capital is this accumulation of, it’s certainly
    specialization and skills, but it’s also reputation, it’s network, you
    know, people that you’ve worked with in the past or know who you are,
    people that trust the work you do or that you trust them or you have a
    good established lines of communication.

    It’s all of these things together and one of the things that was

    powerful for me about that concept is that career capital, yes, can be
    directly translated to earning potential.

    You can make more money if you have, you know, bigger skills and a

    better network and whatever, but actually the more valuable thing I
    think for a lot of folks that I know in this kind of modern world is one
    of flexibility and being able to kind of make maybe lifestyle design is
    the slightly hackneyed term for this, but the idea that When your skills
    are relatively undifferentiated or you don’t have a ton of career
    capital, you kind of have to fit into the box that’s offered you.

    You know, here’s this job, it’s 9 to 5, you go to this office, you

    dress this way, you sit in this cubicle kind of thing, and the more you
    have great career capital, the more you are able to, for example, going
    to become a freelancer, for example, is much easier to do when you have
    that list of. Connections that you’ve made in the past and people that
    know you for being really great at a particular thing and are likely to
    want to hire you in the future and pay you on an hourly basis, for
    example, and then of course, that is a way to get more flexibility and
    freedom and agency in your life. So, yeah, like the career capital
    concept is a thing to work towards in your career, not just for how do I
    get the bigger title or the corner off. sort of the money, but as a way
    to lead the kind of life I want to lead, which for a lot of people may
    have to do with spending more time with family or getting to work in the
    evening hours because that’s where they’re more productive or take,
    you know, 3 months off in the summertime to go pursue their weird sport
    or whatever. And so that’s a powerful thing if you invest and work
    towards that goal.

    01:01:28 - Speaker 1: There is a finance analogy that I really like from

    Kevin Kwok. I highly recommend following him as a tech investor slash
    thinker, because he talks about PE ratios on your substance.

    So what is the PE ratio? It’s like the ratio of your price in the stock

    market to earnings.

    And he cites Elon Musk as someone who has a very high PE ratio on

    anything that he does, he’ll do one thing and then He’ll tell everyone
    about it and everyone suddenly thinks he’s the world expert on it. And
    he may or may not be, but it becomes that way.

    And it’s very useful currency to trade in for the things he actually

    wants to do, right, giving that to his engineers to work on. And it’s
    in some way that is financial analogy to career capital, which I never
    thought about until I heard Kenny Kwok talk about it.

    01:02:11 - Speaker 2: Well, that’s a great advice here. The closing

    question, I think that, you know, anyone on the engineering side is
    going to have, Sean, please tell us, how does one become a 10X
    developer?

    01:02:21 - Speaker 1: So, depending on who you talk to, 10X developers

    either do or do not exist, essentially they are developers that have 10
    times the impact of the average developer, however you measure it,
    whether it’s by business impact or naively by lines of code, there’s
    all sorts of ways that you could sort of think about that.

    My humble opinion, at least this is how it works out in the capital

    markets or in capitalism, is T0X developers do exist. And one example of
    a 10X developer that I bring up in the book is Jeff Dean and Sanjay
    Gammaat, who are in the rankings of Google software engineers. They have
    sort of software engineer 1 to 10. They’re the only ones at 11, kind of
    very spinal tap way to rank engineers. And one of the comments that
    I’ve seen about their work, because Google Code commits are publicly
    available within Google, is that they actually could commit just about
    the same amount of code as an entry level software engineer. Just about
    the same, like they’re not particularly prolific, but their choice of
    problem in what they work on has enabled them to create Google Brain,
    MapReduce, to do whatever. And I think that’s my insight, which is that
    being a tennis developer is not about the cleanliness of your code, not
    about your knowledge of the intricacies of a framework, it’s about
    knowing which problem to work on. And I think that’s a good analogy for
    anyone who not just developers on your career choice, it’s not about
    how well you practice your craft, like let’s just assume that you’re
    competent in your craft from that based assumption of competency, then
    you should also spend probably equal or more amount of time on what
    you’re working on, because that’s. more likely determinant of your
    career outcomes. Like I think of you as a better designer if you came
    from FIMA, not knowing anything else about you just because FigMA turned
    out to be a much more impactful company than some other company that has
    not had such an impactful name. So that’s my pitch for having some form
    of strategy in your career planning.

    01:04:13 - Speaker 2: Let’s wrap it there. Thanks everyone for

    listening. If you have feedback, write us on Twitter at @museapphq or via
    email, hello at museapp.com, and we love it when you leave a review for
    us on Apple Podcasts. And Sean, thanks for helping guide us all as you
    first learn in public and then help us think about career as a first
    class concern and make our own luck.

    01:04:37 - Speaker 1: Thanks so much.

    0 min
  • Discuss this episode in the Muse community

    Follow @MuseAppHQ on Twitter

    Show notes

    00:00:00 - Speaker 1: A product launch needs to prepare and calibrate

    the potential user for how much the world is going to get shaken up by
    this thing. So Muse 2, it’s still muse, but it’s a major version
    change, so prepare for a moderate amount of novelty in your life.

    00:00:21 - Speaker 2: Hello and welcome to Meta Muse.

    Muse is a tool for thought on iPad and Mac.

    This podcast isn’t about Muse the product, it’s about the company and

    the small team behind it. I’m Adam Wiggins here as ever with my
    colleague Mark McGranaghan. Hey, Adam. And there’s a little bit of
    excitement in the air here. Uh, those who’ve been following the Muse
    story know we’ve been in a pretty deep maker cave for a while working
    on our 2.0 product. And I think we’ve talked a little bit before about
    the sort of big releases versus incremental, and I think there’s much
    to be said for both.

    Incremental has a certain momentum, velocity, you feel more in touch

    with the people that you’re serving, your users and customers, but of
    course the big releases are where you can really kind of reinvent the
    universe and there’s the feeling that anything’s possible, something
    like that.

    And of course we’re undertaking something pretty ambitious here, at

    least for our small team with Basically adding a whole new platform,
    which is the Mac, in addition to iPad, and then on top of that is this
    local first syncing technology that we’re trying to take from the
    research lab and bring it into our product is a pretty big bet here.

    So we’ve been grinding away at that for a few months, but very happy to

    say that the Beta is now available to prom members, so we think it’s,
    we’ve been using it internally for a little while, you and I both have
    used it quite a bit as our kind of daily driver in our work, and it is
    nowhere near bug-free or glitch-free or even total feature parity with
    Muse one, but it all does work, and it’s quite a thing to see, I think,
    but I’m really excited to share it with everyone and see the reaction.

    00:02:02 - Speaker 1: Yeah, very exciting times for me, actually, the

    multi-device and local first sync capability was perhaps the thing I was
    most excited about with the original Muse vision, and it’s taken a few
    years to get up to that point, so I’m really excited to be releasing
    this capability into beta.

    00:02:20 - Speaker 2: And I’ll link the memo in the show notes for

    those that are interested, we do a little bit of a, a walkthrough,
    particularly on the Mac side, but also take a little look at the sync
    side of things, although that will certainly bear much more explanation
    in the future.

    But with that be kind of out the door and baking, as we sometimes say,

    so folks will be trying it out and sending us bug reports and feedback
    of all kinds, and while we let that sit for a while, we can start to
    think forward to the product launch, the Muse 2.0 release.

    Which is very exciting for me. I get excitement from shipping things in

    general, even something like a beta, but doing a full product launch is
    quite its own wild ride, I think, and we haven’t done one for a year
    and a half since Ms 1.0 came out, so I’m kind of looking forward to
    that, and indeed, that will be our topic today, which is launching
    products.

    00:03:11 - Speaker 1: Nice. And now Adam, I’m gonna turn the tables on

    you. You usually ask me to define these nouns that we talk about, so
    I’m gonna ask you what does a product launch mean?

    00:03:22 - Speaker 2: Yeah, I see now being the other see why that’s

    difficult, because it seems like everyone knows, right? And you go to
    kind of actually define it and realize you don’t have a real good crisp
    definition. And I probably like you, have been involved in product
    releases of many different kinds over the course of my career, and I
    think it was really only the Muse 1.0 launch where I really sat down to
    try to more deeply understand what is the anatomy of a product launch
    and what even is it, because if you’re sort of iteratively releasing
    improvements and features all the time, what is it that makes kind of a
    launch? And I think one of the descriptions that I saw someplace is the
    idea that you’re creating a moment. You’re creating kind of a feeling
    of an event, and you can think, of course, of the really dramatic
    examples like Apple, right, they do these just completely huge events,
    you know, back when they were in person, but even now with the kind of
    virtual stuff, hugely produced, all these, you know, press are lined up,
    you know, all the product review people had their stuff ready to go, and
    so it’s this big event, big moment. But I think you can equally as well
    do that on a much smaller scale, right? Even if you’re just like, for
    example, making a little app to share with your 10 friends, if there’s
    a moment where you release that and everyone feels excited about it and
    they’re kind of talking about it with each other or sharing the link
    with each other or something like that, I think that serves it just as
    well. And then the other part of it is just like, what actually are you
    launching? So the moment of the event is an announcement, something
    exists, something that is truly new. And I think here we get into a more
    subjective definition for sure and product hunt, which is an interesting
    piece of this puzzle, we’ll come back to a little later, but they
    actually do have some rules around. They don’t want you to launch just
    new features, but new products. Of course, that begs the question, well,
    what actually is a product launch was a feature launch? It’s not really
    that clear and there’s a few guidelines there. Being on a new platform,
    having a totally redesigned interface if you’re covering some new use
    case, but I think there is just an implicit feeling or sort of
    subjective feeling just like we’re talking about here with Muse 2. This
    is something that feels really new and different, even if it shares a
    lot of the fundamental qualities of what we’ve been building all along.

    00:05:40 - Speaker 1: Yeah, I actually quite like this definition of

    product launch is creating a moment cause it’s user centered. It
    describes it from their perspective. When we’re talking about product
    management, we often say that you should describe the benefit or the
    capability and not the functionality, like at least think in terms of
    what the user is getting. And when I was thinking of launches, I was
    thinking of like a marketing push or you turn the thing on, right? It’s
    these things that we’re doing versus the moment that the user is
    experiencing, so it’s a great lens.

    00:06:09 - Speaker 2: I may have gotten that from uh there’s a series

    of posts on the site, launch notes. They have one that I’ll link to in
    the show notes that I quite liked about a launch Mailchimp did a couple
    of years back, and they’re obviously a huge company, so what a launch
    for them means is quite different than what it means, for example, us,
    but I think again, those concepts.

    Your channels are different, the scale is different, the quantity and

    quality of the materials you can create are different, but the basic
    idea I think is in there. And by the way, you can also launch a product
    that has yet to be built.

    So I think the landing page with a waitlist is absolutely a thing you

    can launch. And in fact, we did this, that was basically the first Muse
    launch. We kind of call it the soft. internally, but, you know, we had
    come to the point where the team was working on it. We had made a Slack
    channel named Muse, we’d registered a domain, you know, we had
    incorporated new software, Inc. and we said, you know, we should tell
    people we’re working on this. So we made a little one pager landing
    page with just a little place you can sign up and it would just kind of
    store the email, and we weren’t sure what we were going to do with it
    quite yet. And our launch was just, we all tweeted it, and maybe the
    incode Switch account tweeted it. But that actually got us, I don’t
    know, first few 100 signups and some energy on the team in the sense
    that like, OK, something exists now that didn’t exist before, when
    it’s just a one-page website with an email sign up, but that indeed is
    a launch.

    00:07:33 - Speaker 1: Yeah, indeed, one of the first lessons that I

    learned about product launches from you and from Hiroku was that you can
    and should separate delivering the product, turning it on from doing the
    launch. You can do the launch before you ship the product, you can do it
    afterwards, you can do multiple launches, you know, you have all kinds
    of flexibility and you should take advantage of that.

    00:07:52 - Speaker 2: Yeah, I think that’s key in thinking about the

    when part of things. I am big on decoupling a product release from a
    launch, a marketing launch or a storytelling launch, whatever you want
    to call that.

    And so, the Muse 1.0 launch was a good example. We went live in the App

    Store, I don’t know what, 5 or 6 months before we launched, and we had
    turned on payments, and we had migrated our beta, a good portion of our
    beta users over from test flight, but we had a new website, and we had A
    chance to say, hey, everybody, we exist now. And so the MS 1.0 release
    wasn’t necessarily something that you couldn’t get before. It was just
    something you didn’t know about because we hadn’t really publicized it
    beyond our little internal circles.

    And we may have pushed some kind of release that had something or other

    in it, you know, maybe a 1.0 version on it. But really there was no big
    change to the product, and I think that becomes even more important, you
    know, there’s obviously things like getting through app review, but if
    you’re doing infrastructure, you don’t want to be doing big changes to
    your systems exactly the moment you’re getting hit by a bunch of new
    traffic and a bunch of new people.

    I think it’s very tempting to feel like you need to do that, that wait

    a minute, you know, if I could have tried this product a week ago, what
    am I actually launching? And again, I think it’s really about you’re
    telling people that didn’t know about it before, or that maybe had
    heard about it, but you’re saying, hey, this is ready, it’s reached
    some new milestone. It’s 1.0, it’s 2.0, whatever that is.

    00:09:23 - Speaker 1: Right. And this is a good example of where the

    user lens is so helpful from our internal lens, it’s this product
    that’s been released for a while and hasn’t undergone a big change in
    the past few weeks. This is at the time of the 1.0 launch, but the
    reality is, approximately everyone in the world has never heard of it.
    So you can’t think of this thing.

    Already existed or people already know about. In fact, people are

    hearing about it from the first time. And this is part of why creating a
    moment is important and valuable because you’re signaling to the market
    that there’s something important happening here. They can’t read every
    app store update to decipher when you’ve undergone a big step change in
    capability. You need to signal that to the market with your marketing.
    As an aside, this separation of product release from marketing launch
    reminds me of what we do in infrastructure engineering with gradual
    rollouts, so that the obvious thing to do with shipping code is you code
    up the feature and then you deploy the code and then the code is active
    and the feature is active. In fact, what you do with infrastructure
    engineering, once you get beyond any small scale, is you completely
    separate the coding and the shipping of the code from activating the
    code. So you’ll have a new code path behind a feature flag and you’ll
    ship that code up to production dark where it’s not running, and
    you’re very slowly in the case of infrastru. you do it slowly, you turn
    the knob to activate this code 1%, 2%, 10%, eventually up to 100%. And
    of course you can also flip it back without deploying the old version of
    the code. So it’s sort of isomorphic with this idea of separating
    product releases from marketing launches.

    00:10:53 - Speaker 2: Gradual and iterative is essentially always

    better, but in the sense of doing a thing or making changes and being in
    the business of software and technology is essentially a change business
    first and foremost, but the point of a good launch is to make a little
    bit of a splash, and to do that, it should feel like there’s kind of a
    lot coming all at once, rather than being dripped out. But again, you
    can do that exactly like the feature flagging on the infrastructure
    side. One trick that we used on the 1.0 launch that hopefully I’ll get
    the chance to use here is we actually had our new website on a
    subdomain, like some preview URL, and then we can share it, for example,
    with press. So someone that has, for example, reviewed news in the past
    and we say, hey, you know, we got this new product coming, we’d like to
    give you early access. Here’s what our new website is going to look
    like. And that’s really important because if they’re trying your new
    product but reading your old website and then they’re trying to make
    sense of that for some review video, they might make, it will be a
    little bit incoherent. But on the other hand, you want to push out that
    website again, feel like there’s something big and new the day you’re
    announcing something. And so that’s kind of a way to do it again
    incrementally and a little bit iteratively. And I think that gets harder
    to do is for a small team like ours, it’s easier to do, certainly our
    1.0 launch where, as you said, approximately every in the world had
    never heard of us. Um, as you get bigger, it gets harder, people
    actually want to, but that’s a nice, that’s a whole other set of
    problems to have, which is that like you worry about leaks and people
    getting early access. But when you’re at that size, in a way it’s a
    nice problem to have, but it’s sort of a whole other domain that I’m
    talking less about here, and then you need new techniques to kind of
    keep your secrecy or the press embargoes and all that stuff, but even
    so, I think that iterative and doing things in a gradual way, so that
    you’re not just flipping a bunch of switches and then everything
    collapses right in the moment you most need it to really be stable.

    00:12:49 - Speaker 1: Right. I think there’s a theme here where if you

    execute a product launch, well, it should mostly be not surprising to
    you. It’s going to be news and therefore sort of surprising to a lot of
    the broad market, but you can basically understand what’s going to
    happen along a lot of these dimensions. So for example, you’ve already
    released. the product, you know, that it works. You should, by the way,
    be observing the rate that new bugs are coming in and that should be
    hopefully decreasing and reaching some acceptable moderate level,
    because the bugs aren’t gonna suddenly stop coming the day you release,
    right? So you got to anticipate that.

    Also, you were alluding to this, you can Basically beta test a lot of

    the marketing and messaging with the press. You can also do this with
    the users. You can say, here’s how we’re proposing to talk about the
    products and see if that resonates, if they’re nodding their head up
    and down, and if so, you can anticipate that will catch it will stick
    when you eventually do your marketing launch. I think people have in
    this mind as users of products that marketing is like big like basically
    frenzy where everything’s super uncertain and everyone’s figuring
    stuff out and who knows if it’s gonna work or not. That should be only
    the perspective from the outside, from the inside, you should have a lot
    of data about how this is going to unfold.

    Now that also speaks a little bit to, I think our bias, which is like

    B2B that is business to business and prosumer software and those
    domains, like especially with B2B, you have like 1000 customers, you
    just call up Amy, hey Amy, you know, you paid us $100,000 last year for
    a B2B software. What do you think about, you know, B2? Of course
    they’re gonna give you their take and we can sort of do that also with
    Prosumer because it’s something that the user has made a bit of an
    investment in. As you get into consumer, it’s harder because each
    consumer is worth whatever 7 cents or something, but that’s one of the
    reasons why I like B2B and prosumer software.

    00:14:27 - Speaker 2: Yeah, that certainly comes to each individual

    represents a larger share of your revenue, so you can care about them
    more if that’s the right way to put it. But then you’re actually much
    more likely to have a relationship with them, you know, there’s folks
    that we’ve had as customers stretching all the way back to those early
    days, and they’ve written them with lots of great feedback and we’ve
    had our back and forth. And so then, you know, it’s pretty natural to
    go and say, hey, check out our new website, what do you think? And also
    that usually they’re comfortable with saying, I hate it, here’s why,
    which is important. And of course you can do that with consumer stuff,
    but I think it’s harder. The scale is bigger, the individuals matter
    less, and it’s more of these like gross trends, yeah.

    Speaking about numbers a little bit, I think another question that I’d

    like to make sure to ask on teams is, why are we doing this? Hopefully
    that should go with anything you ever do in a company, but I think you
    can take it, especially folks who have been in marketing a long time,
    take it as just a given that you need to launch. And I actually do kind
    of agree with that. You can’t expect people to know about your product
    if you haven’t launched it, sort of how I’d put it, unless you have
    some viral growth loop thing that’s really, you know, quite remarkable.
    For the most part, you’ve got to get some real effort into getting out
    there and both one packaging your message in a way that people will be
    able to understand it who are not part of your inner circle, and then 2,
    make sure that message gets into channels for people who care about what
    you’re doing or you want to serve her listening. So I think that is
    reasonable.

    But in the why thing or going a layer deeper there, I think it’s

    important to try to define success upfront. And one place I think it’s
    easy to get a little bit diverted here is the what I’ve called the
    press launch. So, especially if you’re in, as you said, B2B software as
    I have for most of my career, there’s tech press, Silicon Valley Press,
    so here I’m talking about TechCrunch or Gigaom, maybe the Verge,
    there’s a variety of sites like this, and at least back in the rogu
    days, you know, we got pressed pretty early on, we were just a couple
    people working on a thing, you know, barely worked. We were in my
    combinator, so that helped, but it’s nice to see those stories or a lot
    of folks maybe take it as a sort of ego boost to see those stories, but
    they actually don’t help that much with getting you users. And what
    they do help a lot with is getting you investors and helping you recruit
    people both in the moment, you know, you’re in conversations with
    investors, they see your TechCrunch article come out and that kind of
    adds some heat to, you know, bringing the deal to a close, for example,
    but also the Googling later on, which is you’re trying to recruit
    someone, they want to learn about your company, they type the name of
    your product into their search engine, and if some articles come up
    where there’s some, you know, headshots of the founders looking fancy.
    It just kind of confers legitimacy. OK, these folks are really in it.
    And so that’s part of your goal is to set yourself up for fundraising
    and recruiting, then that kind of press launch is excellent. If your
    goal is actually to get new users or new customers, particularly if
    you’re in a specific and narrow demographic, which many companies are
    in their early days or forever, then it’s actually probably just gonna
    be kind of a sort of an ego exercise and actually doesn’t serve you
    that well.

    00:17:40 - Speaker 1: Yeah, I also tend to think that people over rotate

    on classic press outlets.

    I don’t have a whole lot of hard data on this. I just have an intuition

    that a lot of people’s media is now basically socially oriented, and
    it’s coming less through these hierarchical media outlets.

    So to the extent that that is true, I think of a launch as more about

    planting a new memetic seed out in the social networks about what your
    product is. OK, the Muse 1.0 seed is a flexible canvas for not taking in
    the iPad, for example. And then that propagates, people tell their
    friends they post about it on Twitter, it goes in the Discords or
    whatever. I guess there’s some media coverage of it as well, perhaps.

    00:18:25 - Speaker 2: And if I can interject there, incidentally, that

    helps, and I think one of our goals for the Muse 1.0 launch was be in
    people’s minds around, yeah, fluid iPad apps for thinking and
    productivity.

    And one of the, I forget if we have this exact metric in here, but I

    think, you know, just in writing out what did I want from the.

    Launch some of it was new users, but one of them was, can I put it

    exactly, but if you see someone mention.

    Muse or especially tag us on Twitter in a thread where someone asks,

    hey, I just got a new iPad with a pencil, what sweet apps should I try?
    And it’s someone who’s sort of in the sphere that we’re in, I don’t
    know what you want to call that tools for thought or thoughtful people
    who are interested in sort of doing productive work. And if you see a
    couple of folks jump into the thread and say, hey, you should check this
    one out, you know, that means that the launch was successful in the
    sense that we’re sort of in people’s minds under that.

    Whereas if we don’t get mentioned, then it means, OK, we didn’t quite

    plant that hermetic seed, as you said, and that’s not what’s in
    people’s minds.

    They may think, I like this team, they may think they have a sweet

    podcast, they may think, I don’t know what they like the interface
    design, but for some reason, we didn’t come to mind when they saw that
    thread, and that meant that our launch. If that were to be the case,
    that would mean the launch wasn’t very successful. And so I was really
    pleased to see there was a significant difference, you know, this was
    mostly just anecdotally me just like spotting people tagging us, but
    after the launch versus before in terms of, yeah, people responding to
    those kinds of questions with, you should check out UA HQ.

    00:20:03 - Speaker 1: Yeah, I think we did a pretty good success with

    our 1.0 meme seed.

    And I think if we have a successful 2.0 launch, we’re basically telling

    the world, you know, hey, memetic DNA update here, uh, we got a new and
    updated things that we’re saying about Muse, it has new capabilities.

    We have new ways of describing it. We have new words and phrases, and

    because we are the memetic source in a way, you know, obviously through
    the product itself, but also through our website and how we talk about
    it on our Twitter and so forth, that will then tend to propagate through
    the social networks, which is where people get most of their information
    these days. That’s kind of my intuition about how this works now.

    00:20:39 - Speaker 2: Now other sorts of success metrics, of course, can

    be things like new users or, you know, putting a 1.0 on a product
    convinces people who are already using it that it’s sort of stable and
    trustable, that kind of stuff.

    But earlier you mentioned, you not being too external facing in your

    description of what a launch is, but actually I do think there is an
    excellent internal reason that exists for almost any launch, which is
    basically energizing the team, really something about seeing.

    Again, it’s that moment, but a conversation, and again, it can be in a

    small circle, it can be a hacker news thread, it could be a couple of
    Twitter threads, it could be comments on product hunt, it can be
    comments on the YouTube video for some person that decided to review
    your product, whatever it is, but seeing that what you’ve made is out
    in the world, part of the conversation, and they usually have this push
    leading up to it, which the push can be uncomfortable at times. Yeah,
    certainly, I experienced this a lot in the game industry.

    But you make this hard push, and then you see it out there, and then

    there’s just something really energizing to that and trying to explain
    yourself to the world, I think strengthens your own internal culture and
    sense of identity and why are we all doing this, and what’s our mission
    and what are we here for? We’re not just pushing pixels around on the
    screen, we’re here to X where X is, whatever your company’s and your
    product’s mission is.

    00:22:00 - Speaker 1: Yeah, I think this is huge in terms of

    strengthening the team identity and sensible accomplishment.

    I have very fond memories of our initial launch of Hiroku Postgress,

    which you and I were a part of, along with Peter Van Hartenberg, and I
    think a few others, or Ryan Henry, and we were grinding on this thing
    for so long, and we felt that we had infinite work in front of us.

    And in fact, we did, we probably at that point had accomplished 1% of

    the engineer year’s worth of work that have since been accomplished on
    Haruka postgras if that. But I think if I recall correctly, you were in
    there saying, guys, we gotta basically pick a point and launch it. And
    again, we felt like we had so much more to do, but it ended up being
    great just to put a stamp on it and to go out as a team for a night and
    celebrate that we had accomplished this release.

    00:22:45 - Speaker 2: Yeah, the milestone aspect of it. I’m a huge fan

    of kind of milestones in general as a life hack, that’s not quite a
    technique one can use in your personal life, in your company, in your
    family, which is, you know, it’s very easy that the day passed day by
    day by day and you’re doing all the things you’re doing and you’re
    very heads down and focused on the details, and I like Milestones that
    cause us to zoom out and look at the bigger picture, maybe birthdays
    and, I don’t know, holidays serve that in personal life, but in
    companies and products, I think that shipping a product is one of the
    most important milestones. It’s something you make happen, and then you
    get this results that you see of what you put into the world, which is
    sometimes bigger and smaller. Every launch goes differently, you can’t
    totally predict it. There’s certainly a big element of, call it luck or
    randomness, in terms of how it will be received, but the fact that you
    did this together, you pulled together, you had this singular purpose,
    it all comes down to kind of a date, you know, one day or a couple of
    days, and then afterwards you can have that shared celebration, that’s
    a really powerful thing.

    00:23:53 - Speaker 1: And I think sometimes you gotta basically

    manufacture it a little bit, to the extent that you’re artificially
    manufacturing, it’s not gonna be an external product launch
    necessarily, but I think humans, creators, they have this natural rhythm
    where every, you know, I don’t know, maybe every 4 to 6 years you want
    a big change, like you start a company, you join a new company,
    something like that, and every 246 months you need to kind of win like a
    feature level win, and every week or two you need to get commit level
    win or whatever.

    And if for whatever reason, you’re not getting that, which can happen

    if you’re working on, especially these big enterprise products that
    basically go on forever, like you’re never done. You got to manufacture
    and say, all right, this is version 7.2, stamp, celebrate, take a day
    off, that sort of thing. I think it’s important.

    00:24:34 - Speaker 2: I think we talked in an earlier episode about the

    Ubuntu release cycle, and I know you’re a big fan of using time boxing
    or limiting time rather than scope to figure out products.

    Now you do still have to package things up in a way that’s coherent.

    And in this venture where I’m in the role of, for example, writing a
    memo to describe what actually is in this product launch, it needs to be
    something good and exciting.

    We actually had this debate in the team quite a bit, because honestly,

    the Mac app plus this local first sync is a huge chunk of work for our 5
    person team, like really big. Actually, it’s quite a big risk.

    I think we’re taking with the business that we essentially have been

    doing no changes to our core product, the one that people are actually
    paying us for. Other than critical bug fixes for quite a while to work
    on this, and we’ve been working on the look for sync technology for
    over a year, not even counting the research time, so it’s a big risk,
    but we really talked through, OK, can we do just a Mac app or just sync
    between iPads and, you know, it just didn’t feel like 2.0, it didn’t
    feel exciting enough, it didn’t feel And maybe we could have done a
    sync between iPads as kind of a smaller feature and then we kind of
    don’t make a lot of noise about it and then go work on them. I don’t
    know, something like that, but it just didn’t feel like a good package.
    And that’s why we kind of decided to go to put all this together.

    And again, I feel this when I’m writing a memo or in some other way

    trying to describe, here’s what the team did and why you should find it
    interesting. And when I struggled to do that, I struggle to find that
    narrative, then I go, hmm. We don’t have the right package here.

    00:26:12 - Speaker 1: Right. And I think having a good compelling

    package is important because again, you’re asking people to sort of
    break their frame.

    You take 30 minutes out of their busy professional lives to read our new

    memo or whatever and digest it, and our side of the bargain is obviously
    you need to have good features as part of that, but you also need to
    have some way for it to make sense to be able to do the memetic transfer
    over and for a product that’s the size and shape of music, I think it
    needs to be a story size package.

    It could be a feature if it’s smaller or use 2.0 complex of features if

    it’s larger, whereas Another example we could look at is something like
    an operating system, so they’re Ubuntu or Mac.

    They don’t really have, I would say themes. It’s more like it’s

    better as 13 is better than 12 sort of thing, although even there, at
    least with Mac, I know, I should try to find the source of this story,
    but My understanding is that they try to shape the release such that it
    has good like optics in the sense of it’s not all bug fixes, it’s not
    all workhorse features, it’s this combination of like big shiny kind of
    showstopper type features that are very visual and understandable. You
    got a bunch of workhorse features that people have just been asking for
    and then you got a bunch of bug fixes and you got to kind of balance
    that for it to be a compelling release.

    00:27:33 - Speaker 2: Now you told a little story there about theoka

    Postgress launch. Those were good days for sure. And now, after Hiroki,
    you went on to work at Stripe for quite a while. Now obviously they’re
    a highly respected and also much larger company. I wonder if you can
    compare to how they went about launching things or at least your view
    from the time when you were there.

    00:27:55 - Speaker 1: Yeah, so at Stripe, I worked a lot more on what I

    would call horizontal systems, so shared infrastructure, developer APIs
    and tooling and risk and compliance infrastructure.

    This is stuff that’s sort of cut across all of our products. So whereas

    at Roku, for example, I was more involved with launching discrete
    products and doing the the core product development of that at Stripe I
    ended up doing more of supporting in my own small way, a bunch of
    individual product launches over the years.

    And so the view I got there was really focused around how do you

    coordinate and deliver across all these different functions in this very
    complex enterprise, these product launches, and we could talk about it
    if it’s interesting, but the short version is one does not simply
    launch financial services products.

    00:28:42 - Speaker 2: Well, that’s true, that’s a highly regulated

    industry and also one where, you know, my very first business venture
    was a payment gateway, and I do remember bugs in my code causing, for
    example, people’s credit cards to be double charged.

    And you know, sometimes that’s a problem when you, it’s a debit cards,

    it’s actually reserving money, that’s actually real money sitting in
    their bank accounts and now they can’t buy other stuff that they need,
    etc. It’s a higher stakes situation, not to say that productivity
    software, people are using that to do their work, they’re relying on
    it, it’s important that it not lose your data and that you’d be able
    to do your work and all that sort of thing, but there is something
    about, yeah, financial products, i.e. money and medical products. I, I
    don’t know, life force, those two have a particular high stakes
    element.

    00:29:31 - Speaker 1: Yeah, and with financial services software it

    really strengthened my sense of working across teams to launch products.
    So with a typical like a SAS product, for example, obviously you have
    engineering, you have product management, you have design. And hopefully
    you involve marketing with launch, although a lot of product development
    people, you know, kind of forget or omit that step, it’s very
    important. But with financial services, you got like, you know, legal
    compliance, risk, support, and you really got to bring the whole company
    along across whatever 8, 10 functions. So there’s a lot of product
    management work that goes into that.

    00:30:05 - Speaker 2: And did you find being in that horizontal role and

    part of a much bigger team was that more or less or the same in terms of
    satisfaction for getting your work into the hands of end users. I mean,
    in some ways maybe your customers, so to speak, or internal ones, right,
    like building internal tools, you could still I guess you do releases,
    you’re not going to do a big press launch necessarily, but if you have
    100 people in the company using your internal tool, you might need to do
    some kind of announcement, try to get people excited and get them to
    bridge the gap from the old world to the new.

    00:30:39 - Speaker 1: Yeah, that’s an interesting angle.

    I’m actually a big fan of doing internal product releases for internal

    tools. That’s something you don’t get to until you’re a medium size
    or larger, where you have dedicated internal tools teams, but I don’t
    know you probably hit this around 50 or 100 people or so.

    I think a lot of the ideas and lessons and movements from doing.

    External product launches can be applied internally.

    For example, this feeling of accomplishment and team identity can

    absolutely be magnified by doing an internal product launch, which can
    be as simple as sending an email to the whole company.

    Stripe actually had this really cool thing called Ship at ship at

    stripe.com and email alias, where people would write. When they had
    released a new capability. Now it was used both for external and
    internal releases, but it was especially useful for internal releases
    because there was no, you know, blog or Twitter that they could post to,
    and I always found that very focusing and rewarding to articulate to the
    company, what you’ve done, why, and what benefits they’re gonna get
    from it.

    00:31:41 - Speaker 2: Yeah, you have a bunch of people who are

    incredibly busy, focused on the things that they need to do in their
    day, and you need to kind of get a little piece of their attention and
    convince them that you have something that will make their life better
    or easier. And that’s quite hard to do. And yeah, high energy, big
    company, there’s a million things to keep track of, a million projects,
    a million people, and you need to somehow edge in, or you need to
    somehow. be heard for the people that you genuinely believe you could
    serve, and say, hey, there’s this new thing and it will make your life
    better, and here’s exactly how and help them bridge that gap. And some
    of that is just having them be excited because they see, oh wow, this is
    actually is going to make my life a lot easier. Great, because there’s
    inevitably going to be some transition pain. And so that excitement of
    glimpsing what, how their life will be better on the other side, helps
    them get over that hump.

    And so it’s the same thing with launching a product there, it’s

    obviously less direct because you’re not inside the same company, but
    you’re trying to get someone’s attention in this extremely saturated
    media environment, someone who is in your target demographic that you
    believe you can help with your product. And help them understand if, and
    if so, why and how your product is going to help them, because once they
    get in there, they’re going to have to do some things to transition
    over to getting that value and so if they come into it sort of excited
    and with a vision in their mind of how their life will be better,
    they’re far more likely to be successful or try it all.

    And maybe that brings us to another important question to ask oneself in

    launching, which is who are you launching to? And I think that is again
    a challenge with some of the press launches, particularly if you think,
    oh boy, it would sure be great to be covered by some really mainstream
    outlet, I don’t know, USA Today, The New York Times, something like
    that. And actually it probably wouldn’t in a lot of cases, like I
    don’t think it would help Muse very much if for some hard to understand
    reason. Someone wanted to cover us there, right? We exist in a niche,
    that’s a very broad channel, and what we want to do is find where the
    people are who are right in our demographic that we can best help.

    And even talk about channels actually in a minute, but when you think

    about the who and trying to, you know, be a little crisp about that, I
    think even once you describe your demographic, you know, here’s exactly
    who we, you know, our target customer, you also can think in terms of
    where they are in their cycle of awareness of your product. So I think
    naturally you tend to think of brand new people. And those are always
    interesting because.

    The gap may be between, especially when you’ve been at it a while,

    we’ve been doing this, you know, coming up on 3 years now, we have a
    very strong mental model for cards and open canvases and Gestures and
    all these things that we’ve been thinking about, as does people who’ve
    been following our work or using our product. So when we launch a
    product, it might be inclined to say, wow, this is great, now you can
    have nested boards and cards on an open canvas, but also on your Mac,
    and to folks who’ve been following our work, they might think, oh yeah,
    that sounds good. And then to a brand new person who may well be in our
    target demographic in terms of they would need or want the tool if they
    can understand it, but they hear that’s a nested boards, cards can’t.
    What are you talking about? And you know, they just don’t even
    understand it. And so thinking in terms of how do I explain not just
    this release, but you’re really launching everything you’re doing from
    scratch, right? You’re basically explaining from the ground up for that
    set of people, here’s everything that Muse is and represents and how it
    might help you in your life.

    But you also definitely need to think about your current users and

    customers, right, letting them know first of all there’s new
    capabilities, which is both to get them excited, so maybe they’ll use
    those things, but also so that they’re not surprised, right, because
    inevitably, and this is certainly going to happen with News 2.0, but
    I’ve seen it happen in other, for example, we worked together on
    launching Hiroku Cedar, and that had, I think it was overall a vast
    expansion of capabilities and improvement of the platform, but it did
    change things in a way that There were some small set of users and
    customers that maybe they didn’t like the new thing as much. What was
    there already was serving them well, or just they were used to it. And
    new stuff comes along and I got to learn some new things, and that’s
    annoying, why are you bothering me with this? And so again, creating
    that excitement or just helping them understand, here’s why we’ve made
    this big change to a product you already use, like and pay for. We think
    it will overall make your life better, but here’s some things, you
    know, you should know to be prepared for.

    And then there’s a third category which is people who are in between

    those, which I think will be quite important for us on this launch, but
    I can see also similarities there with, say, Hiroki Cedar, which is
    people who may have tried the product before but dropped off, or maybe
    they kind of been following you because they’re sort of like, I don’t
    know, for example, they think our demo videos on Twitter are neat or
    whatever they like us personally or something like that, but they just
    weren’t in our demographic before because they say, well, you know, I
    just don’t use my iPad that much. Oh, there’s a Mac app now. Now I’m
    interested. Now I want to try it again. Or it might not be that crisp,
    but maybe they tried the product before, and yeah, it didn’t quite
    stick for them, whatever, but now there’s this big new release. People
    seem to be excited. They’re like, oh yeah, that was pretty cool. I’m
    trying to remember, what did I think of it before, I should check it out
    again, and then you go check it out again, and of course, a lot’s
    changed, it’s more approachable, it’s more usable, maybe it looks
    cooler, whatever it is, and so you have a chance to kind of reactivate
    or reconnect with those folks.

    And so I think It is a challenge in the messaging that you want to speak

    to all of them. You don’t want it to be boring as you re-explain all
    the fundamentals of what you’re doing to your base. I think as they
    sometimes call it in politics, the folks who are already your users and
    customers, but you also want to make sure you’re not alienating the new
    people. A big part of the reason you’re doing this is to reach a new
    audience. And so you do need to explain that whole thing. And then
    there’s the folks in the middle as well. So I think there’s quite a
    bit of nuance in that, but I think it’s an interesting storytelling
    challenge.

    00:37:44 - Speaker 1: Yeah, and I think there’s an important marketing

    fact embedded in that, which is people generally don’t buy and use
    software because they’ve heard about it once.

    Usually people will need to hear about it multiple times from different

    people on different channels before it really sticks.

    And we’ve talked about how we went through this with notion, for

    example, where you and I heard about it from several different people,
    you know, here and there, it took several passes for it to stick for us
    and for our company. I think it’s the same way with any other software.
    And so part of what you’re doing with the launch then to kind of
    reframe what you just said is you’re making another pass over everyone
    and hopefully for some people that’s the critical, you know, end pass
    where they get it or you’ve planted the seed that will eventually
    propagate to someone, you know, some YouTube reviewer learns about Muse
    and they do a video and then that is the end pass for a new customer.
    You’re always building this reservoir, if you will, of familiarity with
    the products.

    00:38:45 - Speaker 2: So I mentioned channels, and that’s I guess a

    piece of jargon or marketing terminology that describes how people might
    hear what you have to say.

    And once you are an existing product or company, you do have the benefit

    or luxury perhaps of an existing audience, so all your Twitter
    followers, your email list, if you’re on other social media, and I
    think that’s a really important one to speak to right from the start.

    If those folks get excited, They will help and support you.

    And by the way, I’ll mention that one of the things that made our 1.0

    product launch really rewarding for me was just how much support we did
    get from all folks out here, folks who listen to the podcast, colleagues
    that you and I have worked with, folks who were early beta testers in
    the product, and just others that just liked to see more innovation and
    cool stuff happening in the tools for Thought space.

    And so we had quite a lot of folks coming out and showing us. Really

    lovely support in comments on product hunt, comments on hacker news,
    retweets, all that kind of stuff. So I think your existing audience, now
    at the very beginning, you don’t have an existing audience, that’s
    where you bootstrapped it, maybe a little bit with that landing page,
    but we do have that luxury this time around.

    But then you go to more traditional channels, now it would be, yeah,

    aggregator sites, Reddit, Hacker News, it could be events. Certainly
    there’s, well, companies put on their own big kind of marketing events.
    We talked about Apple, but there’s also more conference style events.
    Hiroku got a lot of value from using basically the kind of rails comp
    and other developer community events, either to launch products or to
    make connections with the community.

    I press that we’ve talked about a little bit before, which includes

    classic press, but also, I don’t know, YouTube influencers, product
    reviewers, that kind of stuff, and even something like paid media.

    You know, I don’t think too many folks are big fans of advertisements.

    We dabbled with it a little bit from use and didn’t get great results,
    but I have been part of a lot of businesses where paid media was a huge
    part of how they managed to get started and get their early audience or
    how they managed to scale something they had that was working, so it
    shouldn’t be ignored.

    And I think you can think of all of these together, you have a single

    message, a single thing you want to say, that’s probably mostly
    conveyed through your website. And then you think, how do I repackage
    these things for all of my channels? It also includes even something
    like marketplaces.

    So you know, if you’re a game company, probably something like Steam or

    Xbox Marketplace or Switch Marketplace or whatever is probably a really
    important channel for you. Obviously for us, the App Store and being in
    the Mac App Store will be a big one for us and then there’s editors,
    you know, human editors who work in that and look through the deluge of
    new apps that come out all the time and try to pick out ones they think
    are interesting to kind of bump up to the top of the pile. And so, The
    challenge is each one of these channels has its own shape, right? You
    know, Twitter has, well, now 280 characters, and you can attach media.
    Instagram is very media oriented, not so much on the text, but you
    actually can’t put links. How you post something on Reddit, for
    example, just looks completely different from how you post it somewhere
    else. And yeah, paid media, it’s just a whole gamut of different
    things, right? Like every single ad, whether it’s banner ad or Google
    AdWords or whatever, they just all have very different formats. So you
    want to make sure you have the same message, but adapting that message
    to all these different formats and what’s right for the channel.

    She’s a huge amount of work. When I think I frequently underestimate.

    And as a reason why I think it’s good to to kind of focus in on a small
    number of channels that you think are really likely to get a good result
    for you and try to make those channels, try to invest in them in a way
    to make the message really strong there.

    00:42:28 - Speaker 1: Yeah, honestly, it’s been especially challenging

    from you because it’s such a rich multimedia visual app to create
    assets for that for all these different channels can be tough. It’s one
    of the reasons, by the way, that I’m so bullish on trying to facilitate
    and encourage social distribution, cause then people adapt and use their
    own visual content and they’re perhaps more expert at the particular
    channel format, whether that’s YouTube videos or whatever.

    00:42:56 - Speaker 2: Now, one that’s in this list that I think is sort

    of special in a way is Product Hunt, and I had never used them much or I
    guess I knew it had become a big deal in the sense of a lot of people
    use it and certainly use it to launch their products, but also find out
    about new products. And so it was just kind of an experiment with the
    Muse 1.0 launch to do product hunt. We did pretty well there, we
    weren’t the number one, but we were the top few and The comments were
    really good and so on.

    But actually, part of what I think is interesting about it is it is a

    channel incredibly specific to product launches. And so in a way, just
    trying to fit into that channel, I think helped me crisp up how I was
    thinking about launches, and Product Hunt has a how-to guide called how
    to launch on Product Hunt that’s quite comprehensive, really well
    written. And the process of reading that and learning about it as I did
    a year and a half ago, I think it helped me think more crisply about
    launching generally. So I think I would get value from that even if I
    wasn’t launching on product hunt. But maybe we’re coming back to this
    kind of event or moment. Part of what makes it work so well is your
    product page will basically last 24 hours. And so your website and even
    something like a blog post or, you know, a memo that you might do on
    your website, that’s something that’s obviously supposed to be long
    term. The website.

    And the core message and whatever is there, you may adjust it and adapt

    it, but probably it’s going to be pretty similar for the next, you
    know, 6 months, year, year and a half. You might have a blog post or
    something like that, but with any luck that’s getting shared around for
    a week or two, maybe people are still reading it, even, you know, they
    put it in the relay or tool or whatever, but product hunt is really
    specifically time limited. It goes live at I think midnight, I don’t
    know, it’s GMT or something like that, or maybe it’s midnight US East
    time, I can’t remember. And then you have one day where people can
    upvote and post comments and you’re there as the creator engaging and
    responding.

    And yeah, it’s a powerful thing because directing people to that link

    is a way to say, here’s our long term stuff, you know, go read that or
    watch this video or whatever, but here’s the event. Here’s the moment,
    here’s the place we’re gathering, and it’s a place for people to come
    show you support, but also people who are new to come and just like,
    feel part of that energy, maybe in a way that you couldn’t just with
    Twitter that has a very kind of fragmented social graph.

    00:45:20 - Speaker 1: Yeah, now I’m thinking of Salesforce’s

    Dreamforce, which also had this property of being a known launch shaped
    container, although obviously it was a very different one. It was a very
    cool structure where my understanding was basically Salesforce said
    every year at this date, you can come to San Francisco and we’ll tell
    you everything that’s happening this year. And then people over a
    decade, they became accustomed to that and Salesforce was very
    successfully able to use that container to launch products. It’s going
    to show there’s value in having a place where both sides know they can
    go to get launch shaped things.

    00:45:58 - Speaker 2: Yeah, that points to another reason why something

    like Dreamforce or Apple events work is you have to be kind of in a
    certain mindset to be interested in a new product, which is, for
    example, I remember at the start of the pandemic, we heard feedback from
    a few users and customers.

    Of course, we were pretty early on at that point, but they basically

    said, oh, I’ve been, you know, forced out of my office for a little
    while and I’m just using that as an opportunity to kind of rethink my
    tool stack before I I had a whiteboard on my wall, and that’s where I
    would kind of go to pace and think. I thought, OK, what other options
    are there for that in my home office that is more constrained in space
    as one example.

    But there a person’s in the mindset of changing stuff and I’m looking

    for new tools and I’m In that state of mind. And I think most of us,
    most of the time, rightly so, we’re living our lives, we’re working
    our jobs. We don’t want to change things. We don’t want to hear about
    new things. We wanna continue what we’re already doing.

    Necessarily introduction of new tools to anywhere in your life and your

    work is going to be a little bit disruptive, and that disruption can be
    well worth it, but you kind of have to be in the mood for it. So maybe
    when someone goes to, yeah, Dreamforce, Google IO, an Apple event,
    something like that or watches it, they’re in the, they’re getting
    their set themselves kind of in the mindset of, OK, there’s going to be
    something fun and exciting here, and let me open myself to the
    possibility that I might get exposed to a product, be able to think in
    terms of how does this fit into my life.

    00:47:28 - Speaker 1: Yeah, totally, and perhaps there’s a

    generalization of this which is that a product launch needs to prepare
    and calibrate the potential user for like how much the world is going to
    get shaken up by this thing. So Muse too, it’s still muse, but it’s a,
    you know, major version change, so prepare for a moderate amount of
    novelty in your life, whereas a little update would be smaller and
    sometimes companies introduce whole new named products, which is a way
    to signal to the user, OK, like, you know, buckle in, we’re doing
    something pretty different here.

    00:47:58 - Speaker 2: And we’ll wrap it there. Thanks everyone for

    listening. If you have feedback, write us on Twitter at MuseAppHQ or via
    email, hello at museApp.com, and you can help us out by leaving a review
    for the podcast on Apple Podcasts. And Mark, I’m excited to come out of
    our micro cave here a little bit first with the beta, but with the full
    launch share and share not just the 2.0 product message with the world,
    but also the larger message that we want to see folks be more
    thoughtful. We think that the right software could help accomplish that,
    and we hope that the software we’ve made could help accomplish that for
    you.

    00:48:36 - Speaker 1: Right on, looking forward to it, Adam.

    0 min
  • 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 website and a
    lot comes across, because almost anything I think you would want to get
    to know someone online for, again, whether it’s Hiring them, applying
    for a job at their company, asking them on your podcast, meeting them in
    some professional context, kind of a lot of what you want to know is
    just like, are we in the same tribe or do we vibe together or do we have
    the same interests or the same values because often that’s the thing
    that matters a lot for those kinds of connections.

    00:15:12 - Speaker 1: I think that’s amazing, especially in the

    designer developer space. I don’t know about you both, but when I find
    somebody on Twitter and they have a link in their profile that is
    firstname lastname.com, that’s an instant click for me, right? That
    already says something about this person that they’ve gone out and
    bought that and invested in that.

    Then you click and you get the aesthetic. I like to go just a tiny bit

    deeper and like, did they build this or was this a template, and that
    distinction also tells you a lot about that person, you know, maybe it
    only makes sense for designers, developers, but I find that developers
    often don’t care as much about having built it themselves.

    Like I think you encounter a lot more stock WordPress themes or

    something like that, but designers, I think there’s perhaps this.

    Community pressure to represent yourself in a unique and special way, so

    there’s a lot more playfulness with color or imagery or, you know,
    drawing your own custom icons or things like that.

    And I suppose maybe I’m like squarely in the middle, like my site is

    pretty boring, like you mentioned minimal, but I see it as fairly
    boring. There’s not actually much color or visual interest on the
    page.

    But that can be its own tone, right, and people can read into that, how

    they will and maybe be surprised if they meet me and, well, maybe I am a
    boring person actually. I don’t know, but I guess that’s up to other
    people to decide.

    00:16:44 - Speaker 3: I don’t know if I would call this boring. I mean,

    it’s minimally styled, but it’s like it’s a whole app. I mean,
    there’s a whole sidebar with all kinds of different categories and
    everything. It’s a whole thing.

    00:16:52 - Speaker 2: And maybe that sort of begs the next question,

    which is if representing yourself online, it is to someone. And that
    someone is again someone that maybe you want to connect with or they
    want to connect with you and you’re trying to find the like-minded
    people to connect with, and that maybe leads into a question of what you
    might call your, how available you are. To outreach. So, for example, I
    have my email address on my home page. Some folks maybe have their
    Twitter handle, but they have DMs turned off. There’s many pros and
    cons to making yourself more or less accessible and be curious to hear
    how you think about that.

    00:17:31 - Speaker 1: Yeah, I think that’s an interesting question

    because my perspective is maybe changing a little bit over time. Which
    is, I’ve always just tried to be accessible because I’ve always been
    so thankful to other people who made themselves accessible. For example,
    I started the Design Details podcast because I wanted to meet other
    people and what we did is we created a spreadsheet of 100 people who we
    wanted to meet and just started going down the list and emailing them.
    And everyone was super kind and most people were open to being on this
    brand new podcast with these young 20 something designers trying to
    figure out what they were doing in the industry, and that
    approachability was magical, and it really opened a lot of doors and
    helped, I don’t know, get me into the room, so to speak.

    And so I always wanted to have that same feeling that people could reach

    out to me, especially. Younger designers or people just getting into the
    industry who might want to learn about, I don’t know what it’s like
    working at GitHub, they might want to apply there or work there someday,
    like having that approachability has all sorts of benefits.

    But when I said I think I’m starting to maybe change that over time,

    I’ve just noticed, I don’t know if you both have your DMs open, but
    like when you have your DMs open, surprising stuff comes through and a
    lot of it increasingly is noise. Or even if it’s not noise, I feel bad
    not responding to people. And so there is this trade off of like being
    approachable and accessible, and then all of a sudden having a 3rd or
    4th to do list, you know, you have your work to do list, you have your
    emails to go through, and now it’s your direct messages and you want to
    come across as a friendly person who responds quickly and thoughtfully
    and carefully. But then there is a little bit of a burden there, I
    suppose. I mean a good burden to have. It’s awesome that people want to
    reach out and chat, but sometimes that’s overwhelming. I’m curious if
    you both have experiences cause you both are also quite public and put
    yourselves out there.

    00:19:33 - Speaker 3: In general, I’m very bullish on this channel that

    is cold contact over the public internet in both directions. I think
    people underestimate the opportunities that you can create by sending a
    good cold email or cold DM as it may be. And I think there’s also a lot
    of value potentially in being open, and I’ve always been open for a
    similar reason I think to you is I was incredibly fortunate to have
    people help me out as I was entering Silicon Valley, basically on the
    basis of cold emails.

    00:19:59 - Speaker 2: Mark, I feel you gotta tell your story here about

    how you came to San Francisco.

    00:20:04 - Speaker 3: Oh, the full story will not be told, but I will

    give the abbreviate story.

    The abbreviate story is someone posted on the internet that they were

    looking to help people who were we help people in San Francisco or early
    in their career, something to that effect, and I emailed this
    individual, and we ended up meeting at a bar in San Francisco, see if he
    can help me out, and he introduced me to someone there who worked at
    Hiroku and one thing led to another and I ended up working there for
    about 4 years, and the career went on from there. So there’s a classic
    example of Silicon Valley and cold emails and Just being willing to just
    reach out. Yeah, so I’m very bullish on the channel, and I think
    furthermore, there’s not too much downside to being open. I found quite
    a bit of value in receiving communications and my experience is that
    very few people actually write in. I get a few emails, mostly about go
    by example, and I get a few DMs, but the volume isn’t an issue for me,
    and if anything, I’m surprised at how little it is.

    00:21:04 - Speaker 1: I wonder if email is a good filter there versus

    DMs, like the act of cold emailing something requires a little bit more
    activation, probably because there’s a subject field, right, and
    you’re forced to consider what do I actually want to get out of this
    interaction, whereas the DM it’s just a chat, right?

    00:21:23 - Speaker 3: Yeah, exactly, and on my personal site where I

    have a contact page, my line is that I respond to every thoughtful
    note.

    And that eludes this activation energy, which, by the way, is just one

    special case of this overall dance that we’re doing as strangers on the
    internet, because again, the base case is that You’re a random person
    on the internet, you don’t know what you’re doing, you’re probably
    malicious, you know, whatever, but if you’re able to provide just a
    little bit of signal, which can be a first name last name.com website
    that’s well done, it can be a simple thoughtful email, either of those,
    and especially if you do both, it’s like, OK, you’re already in the
    99th percentile of random internet people, and I’d be happy to chat
    with you.

    00:22:01 - Speaker 1: Yeah, yeah. The bar is low in that world, right?

    00:22:05 - Speaker 3: You would think, but then most people fall blow

    it, but most people don’t, yeah, yeah.

    00:22:11 - Speaker 2: And my experience is that, yeah, maybe through

    your podcast and Twitter and other things and all the writing you do
    maybe you end up being higher profile, Brian, but yeah, I would say the
    amount of inbound kind of both DMs and emails that I get are certainly
    manageable, but yes, it does create a new to do list. I do like to, even
    though I don’t say this explicitly, have kind of a similar policy to
    Mark, but I think it’s easy for me to sort out. There’s ones that sort
    of obvious good signal where it’s like an interesting person and they
    have a clear request that’s something I can fulfill in not too much
    time.

    Or there’s the case that’s clear spam or something close to spam,

    let’s say, not classic spam necessarily, but something where I don’t
    know, you know, the recruiter, the classic recruiter thing. Oh, I see
    you have a Ruby on Rails project. I’m working with a company that, you
    know, they clearly just didn’t look at my profile for more than 5
    seconds.

    The middle ground, I think, is the harder thing where someone does know

    me personally in my work, they are writing to me saying, hey, you know,
    I’ve enjoyed what you’ve done at, I don’t know what I can switch,
    Muse, whatever, and here’s the thing I’m doing, you know, I’m a
    student, I’m an entrepreneur, I’m something else. But then if that
    doesn’t lead into like a real clear request, it’s more just a general
    like, I’d like to get to know you or it’s just unclear what they’re
    asking for, and then maybe it’s a long email, and then it’s like, It
    is thoughtful and it’s in this middle ground that’s tricky and it’s
    hard to know 100% what to do with it.

    I still try to like find a good reply if I can, but it’s often ends up

    being more of a thanks for the nice words. I think you’re doing
    something interesting. You know, if there’s some specific thing you’re
    looking for, let me know, but this kind of comes to the rules for
    emailing busy people thing, right? Like make it short, have a crisp and
    clear request. Maybe they’ll say no, but just make it easy for them.

    00:24:06 - Speaker 1: Just to add on to that, you know, speaking of what

    the bar is to stand out as like a non-random person on the internet,
    like have a domain, have a clear ask. I’ve found. If that puts you in
    the 1%, well then the 1% of that is people who actually follow up.

    And what I’ve been really surprised by is, you know, people will email

    you and they’ll ask a question and it’ll be very thoughtful and
    you’ll maybe send a reply and say, hey, I think this, or I’m not sure,
    but I read an article about this, or here’s a person that might know
    better than I would, and you send out this information, you’re
    connecting people and ideas.

    Nobody ever responds to those, but the 1% of people who do are really

    special and I feel like that’s where you build really cool
    relationships is, you know, somebody asks, hey, I’m weighing these two
    offers at a job. What do you think I should do? I’ll tell you what I
    think. And then they respond, and they say, hey, by the way, I ended up
    doing this, and even better is they say, oh, I did this, and I learned
    this, right? And so one thing that I’ve started doing now recently with
    sort of these kinds of engagements with people I don’t know, where it
    feels a little bit transactional is I try and explicitly request a
    follow up, and the way I frame it is. Hey, by the way, if you end up
    making a decision, I would love to hear how you made that decision if
    you learned anything. So a lot of times this will end up being like job
    hunting or negotiation. A lot of people have been asking me how much to
    charge for freelance service, and I love to say just let me know what
    you end up doing. Like, no matter how much you decide to charge as a
    freelancer, please just tell me because I’m trying to populate my own
    data library so that I can be more helpful or more fine tuned in future
    interactions.

    And most people don’t, but the people who do, it builds a cool, cool

    relationship there and it feels like it keeps the door open for back and
    forth, right?

    00:25:55 - Speaker 2: Nice. Now another topic related here maybe is what

    some folks call audience, and audience is pretty clear, I guess if
    you’re a YouTube influencer and your audiences your subscribers, people
    who are, you know, following your work and you want to grow that because
    the whole point of your business is, or I should say the business is
    built on attention and the more kind of attention engagement you have,
    then the stronger your business is, and it also reflects your impact.
    You’re sharing ideas, maybe you’re creating some kind of
    entertainment, and you want to get that out to as many people as you
    can. That’s kind of what you’re in the business for. Now, all of us,
    we’re in the business of making products. We want to get our products
    to a lot of people. That’s kind of our main goal, but if personal brand
    is sort of a helper, contributes to Your career, but also just your
    ability to meet interesting people, maybe your ability to hire or be
    hired. Uh how important or how much do you, Brian, and Mark, I’d love
    to hear your answer as well. Think about audience as a thing you want to
    grow, Twitter followers, podcast subscribers, or is that a thing you
    think about at all or do you think that’s not important to you?

    00:27:09 - Speaker 1: I’d love to hear your answer first, Mark, I’m

    curious how you think about followers specifically. I think first of
    all, the term, but yeah, how do you think about this?

    00:27:18 - Speaker 3: This goes back to the answer that I gave to

    Adam’s original question, which by the way, I was getting some
    quizzical looks from you also maybe I can elaborate a little bit.

    I think there are some people who purposely build a brand as a first

    class goal and want to have a lot of followers, either because they just
    enjoy playing that. Game or because they’re in some type of role where
    having access to that marketing channel is valuable if they’re
    developer advocate or they write a newsletter, someone like that. And
    that again is that sort of classical brand that you would think of if
    you compare it to something like a Coca-Cola. I think of it more as an
    asset that I can draw on when needed, so I don’t particularly need any
    followers. I need the ability to point to something and say, hey, I’m
    reaching out to you. You can refer to this artifact and see that I’m a
    clueful person, and that’s really all that I personally, and I think
    that covers most people. Now there’s a bit of a spectrum there, but I
    think it’s important to differentiate between Having this big standing
    audience and that being a first class value versus having some signal
    that you’re able to draw upon.

    00:28:22 - Speaker 1: Hm, so maybe more clearly, do you care about how

    many followers you have? Like if you had 10,000 or 100,000 or a million,
    like are these break points interesting for you at all as far as
    Communicating ideas, marketing for use, the product and company hiring,
    like, those things matter, right? But how much do you care about how
    much that matters?

    00:28:47 - Speaker 3: Yeah, so mostly not because I don’t need to do a

    lot of this called outbound. Now there are a few exceptions including
    marketing, use the product, and recruiting, and so they’re having a
    little bit of a follower base helps, but there’s also liabilities that
    come with a larger following base, especially from a personal
    perspective. And there’s this joke that as you approach Infinity
    followers, your tweets become like fortune cookies, and I think there’s
    a lot of truth to that. And so I think there’s kind of a sweet spot in
    1 to 10,000 or whatever, but people have different takes.

    00:29:15 - Speaker 1: What do you think, Adam? Do you care about this

    stuff?

    00:29:18 - Speaker 2: Yeah, I think it is good to look at the difference

    between company and personal in this case. I do care about the followers
    for, say, the Muse Twitter account because that reflects our ability to
    get our message out of the world, right, or our newsletter subscribers
    or whatever.

    In the beginning, when you’re brand new and no one knows who you are or

    cares what you have to say, if you Built something good or you believe
    you built something good, it’s hard to get that out into the world and
    you compare that to working for an established company, you know, I was
    part of the Salesforce empire for a little while and I saw the value of
    this huge megaphone, these events they did, just the reach of their
    voice, and so you could make a product and you didn’t need to worry too
    much about whether people would see it. You would worry just about
    making the product good.

    I think obviously GitHub having such a far reach and being part of

    Microsoft empire probably only enhances that as well. It’s not to say
    that you don’t need to worry about marketing, but it’s more, you
    don’t need to worry about crickets or people not seeing something good
    you’ve made. If anything, it’s almost, you tell me what you think, but
    it’s almost the opposite, which is when your things still early on and
    you need to just get a few people to test it and not get everyone piling
    on to it, then, you know, it’s almost you have to work hard to sort of
    keep it under wraps.

    So I do care about kind of the followers and the audience and the kind

    of the reach for my companies because that’s part of their existence.

    For me personally, yeah, like Mark, I would say that’s not something I

    care about in the sense that it is occasionally useful recruiting is one
    of the main ones there, or being able to support and promote things my
    friends and colleagues are doing. So when a friend launches a new
    Product or you can switch, puts out a new essay or whatever, and I can
    retweet that or just, you know, do a quote tweet and say this is awesome
    and get them a little bit more attention than they might have had
    otherwise, you know, help contribute to that. That feels really good.
    That’s a nice use of that power. But yeah, it’s not something I want
    to make go up.

    00:31:05 - Speaker 3: I think it’s also the case that as the technology

    around these social networks advances, the reputational capital becomes
    more atomized down to the individual, say, tweet. So it used to be back
    in the day, if you wanted to publish something you need to go to a big
    newspaper or whatever, a big radio station, and then it was that you
    need to have a big Facebook page or maybe a big Twitter account, but now
    you just need the one right TikTok video or the one tweet and it can
    blow up by itself, and so there’s more weight placed on having
    something good and valuable to say versus having a stock of reputational
    capital in the form of a bunch of followers.

    00:31:42 - Speaker 2: Hm. Although being known for saying things that

    people want to hear definitely is a huge amplifier on anything you might
    say, which is maybe to that fortune cookie point, you can say basically
    pretty generic platitudes, but if your audience is big enough or you
    have this reputation where people just care about what you have to say,
    then, yeah, they’re excited about what would otherwise be a pretty
    bland statement.

    Now the other piece of this on the followers though is I would say that

    the quality is not the right word. It’s people who are following me for
    the right reason, and I especially like the mutual follows and maybe the
    mutual followers thing just kind of takes you back to a little more of
    the classic social network where you have people who sort of all know
    each other rather than a publishing form, but I guess I like this thing
    where you can start to follow someone.

    Without necessarily needing that to be two way, but the really high

    value relationships to me are ones where we follow each other because
    we’re interested in each other’s work or we share work values or
    we’ve worked together in the past or we might want to work together in
    the future, and you can have those little interactions, those little
    conversations, etc.

    But for me, a much smaller number of followers who are people that I

    really vibe with or have a lot in common with or we just have similar
    interests and passions.

    And I think I saw one effect of this when I transitioned, kind of did a

    bit of a career pivot, still in creative tools, but you know, went from
    the kind of developer tools, cloud space to the research world and more
    of kind of like personal productivity software. And so quite a lot of
    people who had followed me because I don’t know, they saw me speak at a
    developer conference and now they’re, why is this guy tweeting about
    tools for thought? What the hell is that? You know, not that interested.
    Maybe they don’t unfollow, but they just become kind of a dark. The
    point of our connection is no longer there, and so maybe the newer
    fresher followers who are here because of things I’m doing now, and
    then maybe in turn I follow them because they’re doing similar things,
    that’s to me where the value is.

    00:33:34 - Speaker 1: Yeah, I love that you both have pointed out two

    things that I think are interesting challenges as you like start
    engaging online.

    The first is the cookie cutter problem, and the second is how do you

    actually allow yourself to evolve? Fortune cookie, not cookie cutter,
    maybe the same thing. I think the fortune cookie problem is a really
    interesting one because I think there’s a point where you have a
    certain amount of reach on Twitter where the algorithm becomes very
    apparent. You can watch it in real time take hold, and you very subtly
    understand or maybe subconsciously understand what is going to get likes
    and what will probably not get likes, and it just breaks your brain, at
    least I’ll say it breaks my brain because it puts you in this position
    where You are tempted and also rewarded for oversimplifying, polarizing.
    Tweeting the hot take, criticizing. Those kinds of things. I think a
    good example that I learned and in many ways has for me discredited the
    value of like having a large following in some ways is, I remember when
    I launched a side project last year, I think. When I tweeted about the
    staff design project, which was an interview series I did. Maybe 100
    people liked the tweet, which is awesome. 100 people checking out my
    project, fantastic. And then I think the next week I tweeted a
    screenshot of framer.com, and I said something like, Framer clearly
    reveres visual design or something like that, and that tweet got 1000
    likes. And so that I felt this really deep disconnect between What I
    thought was valuable and what people seemed to resonate with versus this
    throwaway screenshot of somebody else’s work that everybody sort of
    glommed onto and followed me for and all of a sudden I’m like, oh,
    people are following me because I tweeted a screenshot of somebody
    else’s work. That doesn’t feel super good. And then to your point,
    Adam, this idea of almost being locked into a thing you’re supposed to
    tweet about, I feel is I don’t think I’ve really encountered this yet,
    but you see other people encounter this where they are the design
    systems person, they are the accessibility person, and when they try and
    branch out, it feels particularly hard. Like you can watch them struggle
    with it. You can watch them try and find their voice because all of a
    sudden the thing that they’ve become well known for and recognized for
    and respected for. They’re trying to branch out and are met with
    crickets, right? Like the design systems person who becomes interested
    in web 3, that’s a painful transition, like that is an entirely
    different disconnected audience. And so I think, you know, these ideas
    connect because You start tweeting things that are your more current
    modern interests, they’re met with crickets, and you feel the algorithm
    pushing back against your own personal development, and you think to
    yourself, well, I like getting likes, I like getting followers. I like
    that notification dot. Maybe I’ll just keep tweeting about design
    systems and then you end up with people creating alts, and then you have
    all these multiple Twitter accounts you’re balancing, and then your
    life is just These different threads of interests and nothing feels
    authentic or complete anymore. Maybe that’s OK, maybe that’s how the
    internet should work. Maybe we should have different accounts for
    different interests, right? Like we have different networks for
    different types of communities. Facebook has a different type of
    connection than a Twitter. Maybe you should have a different Twitter for
    every kind of interest you have. I don’t know. But yeah, I’ve noticed
    those sort of tensions in my life, like figuring out what to tweet about
    and wanting to be real and authentic and true to yourself, while also
    recognizing as you’re typing, you’re like, uh, I bet if I reworded
    this to be slightly spicier, more people would like it, and I don’t
    think that’s a good thing.

    00:37:53 - Speaker 2: That’s incredibly interesting.

    I mean, those pressures, social pressures have always existed, of

    course.

    I think of if you want to like reinvent yourself a little bit, maybe

    like your personal style or something about how you present yourself to
    the world, the best time to do that is when you move to a new town. No
    one knows the old you and so you can just kind of, you know, change it
    overnight and not deal with the I know it’s quite pressure, but maybe
    even if people are not necessarily trying to push you back into what
    they know you for, but yeah, I think we always feel a sort of pressure
    to be what we’re known to be rather than what we want to evolve into,
    and that comes from our environment, friends and family, peer groups,
    and so on, and that makes personal change even harder than maybe it
    already is. Now obviously you digitize these natural tendencies which
    are maybe not great to begin with and make them maybe even more amped
    up, particularly when the algorithm makes it so visible to you. So
    that’s very interesting. Actually this is a nice connection back to a
    concept we talked about in the company brand episode which is there’s
    what’s known as brand extension. And the general thing is that brand
    extension is uh basically a pretty bad idea and almost never works. So,
    you know, for example, Kleenex is known for making facial tissue. If
    Kleenex makes printer paper, which perhaps is a similar product in the
    sense of how it’s manufactured, not only is it confusing what the hell
    is Kleenex printer paper, but you’ve actually destroyed the brand
    equity of what Kleenex is in the mind of your customer. And the
    recommendation there is generally make a new brand if you’re truly
    transitioning to a different market. So maybe that does beg the question
    of should I have just started a new Twitter account when I was
    transitioning my career. And again, to me it feels I’m the same person.
    It feels like a continuous journey that I went through, and I do think
    there’s this uniting thing that ties togetheroku I can switch and Muse,
    which is creative tools and helping people, you know, making things to
    help other people make things. So to me it’s perfectly, perfectly
    logical and obvious, but maybe there is places where that ends up being
    sort of a brand extension.

    00:40:03 - Speaker 1: I feel like crypto is just the most obvious

    example to point to where like everybody has their separate crypto brand
    now, or I mean we could talk about pseudonymity, which is this
    interesting trend that’s taking shape right now where people want to
    have.

    This alt profile where they can feel safe to talk about this other

    interest they have, but they know is incredibly polarizing and they
    don’t want to sort of poison the well of their existing brand by
    introducing these new topics, right? What do you both think of
    pseudonymity in this space, maybe even going back to Mark’s point
    about, I think he called it reputational capital, I think is a really
    interesting concept that gets associated with, you know, a name, a face,
    a person, and we’re sort of breaking that a little bit.

    00:40:51 - Speaker 2: I think the ability to make multiple profiles and

    isolate them from each other, have some be private, some more public,
    maybe one that’s career oriented, one that’s personal, something like
    that is one of the incredible strengths of the internet, and I pretty
    strongly, I think Mark Zuckerberg at some point in the early Facebook
    days said that everyone should have just one personal account, your one
    person, it should have your real first and last name. And I think that
    really removes a lot of what makes the internet a pretty special place.

    I think it’s a place, particularly, for example, teenagers or younger

    people who are still figuring things out, they can explore parts of
    their identity that they’re not sure about yet in this sort of safe but
    still out in the world way. I think it’s an incredible thing. Now, of
    course, the ability to make anonymous accounts or relatively little tie
    to your real world identity is also part of what creates so many
    problems on the internet. Spam and fraud and abuse and different things
    like that, but I feel that’s a price worth paying.

    00:41:48 - Speaker 1: It feels like there’s this tension, you know, in

    the old world of forums, every forum you went to, you would sign up and
    have a separate account and you could kind of build your own identity
    there that wasn’t linked to your other forum accounts, but now we live
    in the world of Discord where you are.

    Your account, no matter what server you’re accessing. Mark, I’m

    curious because I know you’re deep in Discord. I’ve always wondered
    why Discord doesn’t have this concept of bringing a separate identity
    to every server, even though it’s all wrapped under one login.

    And maybe even Twitter has an opportunity to innovate here cause

    they’re experimenting with a feature called Communities where, you
    know, your design persona or your development persona or tools for
    thought persona is just different and as you switch contexts, it should
    feel very natural to do that and you shouldn’t have to log out of one
    persona and log back in. It should just be, oh, I’m switching into this
    space, this mode.

    00:42:49 - Speaker 3: Yeah, well, in general I’m very bullish on

    pseudonymity. I think it’s super important to individuals, to people,
    to citizens, and I think it’s honestly fairly threatening and sometimes
    problematic to like managers and governors, you know, that kind of
    group, and so that’s why there’s this constant tension of should you
    be able to make a synonymous account and generally individuals say yes
    and people running stuff say no.

    Discord is interesting that you mentioned that because I think it is

    unfortunate that they don’t natively support multiple. Identities, for
    what it’s worth. I do have multiple disco identities. I think one is
    for like personal and gaming and one is for work. I forget how exactly
    it’s split, but I definitely have several. Yeah it’s too bad they
    don’t support natively.

    00:43:31 - Speaker 2: Identity is also a huge topic of interest for me.

    It’s something I think that the computing slash internet world is
    basically serving users really, really poorly on from a security
    perspective, from a mental model perspective and all that sort of thing,
    but it is obviously a very thorny problem and here we’re talking about
    personal brand which is about a public identity or how you’re
    representing yourself to some.

    Group, whereas identity could be in the kind of foundational sense,

    could just be an account with the system or how I represent myself to a
    computer somewhere that’s relatively private activity.

    But I do think that, do you have one account that is in multiple things

    versus sort of many totally segregated accounts is an interesting one on
    that side because for example, one thing I think GitHub got really right
    from my perspective is you only have one GitHub account and you belong
    to different organizations.

    I don’t get a new GitHub login when I join a new company. And maybe

    some people choose to do that separate their open source work from
    personal work or whatever.

    But at least for me, I find that works very well, maybe because coding

    related things are not something I feel particularly desirous of
    separating, but on the other side of it, you can look at something like
    Google, which has increasingly just rolled up more and more and more and
    more services into one giant Uber identity, and I basically have tried
    to stop using Google services for the sole reason that I just cannot
    stand in their identity system.

    Because it seems to get the worst of all worlds.

    On one hand, I do have different accounts, you know, I have the

    different ventures I’m involved in, each have their own thing, and I
    have to switch between that. I go to a Google doc, I can’t access it. I
    got to switch to the right account, but on the other hand, they roll
    together all this stuff like my search history with other things that I
    just don’t want connected at all and I’m really annoyed by.

    It’s sort of like the worst of all worlds. I think we’re very much

    still figuring this out as an industry.

    00:45:30 - Speaker 1: Yeah, I feel like the YouTube connection is

    particularly painful. At least for me, I’m like, the things I care
    about on YouTube are very different than the things I’m typically
    googling for. I don’t know if that’s the same for you both, but no,
    yeah, for sure.

    00:45:42 - Speaker 3: We’ve talked a lot on this podcast about

    understanding and aligning with how things actually work in their
    underlying basis, mostly in terms of knowledge work and tools for
    thought and Workflows and stuff like that. We can have a whole
    discussion about this with respect to identity. I think a lot of the
    troubles that we have with identity and therefore developing personal
    brands comes from an impedance mismatch between how identity actually
    works and how it works on these platforms.

    The way identity actually works, it’s a much more distributed networked

    mesh concept. The identity is something you Have with respect to another
    individual or with respect to another group, and it’s the sum or the
    intersection of all the interactions and labels and information that
    that subset of the universe has about you and it can vary depending on
    which subset you’re talking about.

    So my identity with respect to this group is different than my identity

    with respect to my family. You know, those two groups are different
    things there’s some overlap but they’re not the same. Whereas identity
    in the technical sense tends to be modeled as a single row in a database
    that again, they tend to want to match 1 to 1 with like a human body,
    and I think basically that’s wrong and that’s why you get all this
    impedance mismatch, something that the in which the lab has done a
    little bit of work on. I’m curious to see them do more on that too.

    00:46:58 - Speaker 1: Have either of you encountered a tension between

    the fact that you Follow people you work with and people you work with
    follow you, and then this interest graph, right, like you behave
    differently around your close friends and you behave differently around
    your family, and then you behave differently when you’re in a work
    meeting, but all of that stuff gets scrambled up on Twitter and I found
    this very odd sensation of, I don’t know, like personal brand
    conflicting with, oh, these are also people that I have professional
    relationships with day to day and I’m in meetings with them. And my
    shit post on Twitter kind of shows up alongside, hey, we gotta hop on a
    Zoom call to make a decision about Q3 strategy. It’s a very odd sort of
    sensation to bounce between those kinds of things. Have you experienced
    that or do you feel that in any way?

    00:47:50 - Speaker 2: I do think it’s a good thing that they talk about

    the like concept of bringing your whole self to work, which I’m not
    sure I quite fully agree with. When I got started in the business world,
    and there was a sense of professionalism which to me felt really
    inauthentic, things like you’re expected to dress in a certain way that
    was just not the way I wanted to dress and That was quote unquote
    professional and there’s many ways in which I felt it was very sterile
    and very just kind of restricting of, you know, we’re people here and I
    think it doesn’t hurt to get to know each other as people a little
    bit.

    And the flip side of that, I do believe in professionalism as a kind of

    siloing of we’re all here to serve a particular mission, the mission of
    the company that we’re involved in, and we should mostly build our
    interactions about that sort of thing.

    So I think there’s a balance to be struck there, and I think it’s

    maybe not bad that people see your tweet and, you know, thought it was
    funny and they can reference it and you can make a connection on that
    level.

    I don’t know if you feel like it undercuts your serious tone and

    authority because you like to be a little goofy on Twitter, but I don’t
    know. I feel like, you know, people just have a little more fun in the
    workplace than they used to and being taken seriously as an authority or
    as a boss or as a designer delivering a piece of work that folks are
    going to needed to sort of take as the golden path for what they’re
    working on, shouldn’t be undercut by that you like to have fun
    sometimes.

    00:49:11 - Speaker 1: Well, here, maybe this gets back into like

    personal brand building, like there is this strategy or way to go about
    building an audience or increasing your online cloud, which is, you just
    learn things and talk about it, like you build something, you learn
    something, and then you share that with the world.

    And the thing is you learn, at least in my case, I learned the most

    about designing and building products through my engagements at work at
    GitHub at Spectrum and Facebook. And it does feel like there’s some
    tension between, oh, I learned this thing from this interaction at work,
    but now I don’t want to tweet it because it feels like I’m subtweeting
    a co-worker. And so then I end up only really tweeting about side
    project stuff.

    So while it’s great that I work at GitHub and I can like Tweet big

    product announcements. The things that I am actually learning day to
    day, I feel very self-conscious posting about that online. It feels
    almost like betraying the bubble of the workspace where like we’re
    learning internally at work together, yet there’s still, I believe,
    something valuable about people sharing that stuff externally.

    Hey, I learned this thing, I overcame this hard problem. So I don’t

    know, this might just be like a classic case of overthinking and being
    too self-conscious about what other people think of me, but that feels
    like the more gray area boundary of, I don’t want it to feel like I’m
    ever subtweeting someone at work where we had a particular interaction
    that I learned from and it was good, but now it’s going public, right?

    00:50:47 - Speaker 2: Yeah, and I can see why that would be especially

    tough for you because you do have a pretty big audience, you do have a
    lot of Twitter followers, quite a few more than.

    Mark and I and through your other means as well. And so yeah, maybe if

    you had 50 followers, then it would be OK to share that, but you know,
    you have to be conscious of you do have a pretty big megaphone and if
    you get up there and say, you know, I really realized that a meeting
    without an agenda is always a waste of time, and you tweeted that right.
    After meeting without an agenda, and so whoever like organized that
    meeting, and maybe it’s a good learning and so on, and maybe you even
    had that conversation with them, but it feels a little bit airing dirty
    laundry or you know, it’s the way you trust your colleagues as you’re
    able to be a little vulnerable around each other and going blasting
    through your megaphone about it is maybe not that nice.

    00:51:35 - Speaker 3: I think this is a great point and a very real

    dynamic, and I think it’s appropriate and reasonable to be mindful of
    this when you’re tweeting or not tweeting about stuff at your work, but
    I think there’s a big macro implication of this, which is that there’s
    a lot of professional dark matter in social media, you know, in
    astronomy there’s this idea of dark matter, which is All the mass or
    whatever out in the universe that for some reason we can’t directly
    observe, but we know indirectly that it’s there.

    And if you only look at stuff that you can easily and obviously see

    you’re sort of missing a lot of the universe, I think the same thing
    happens with professional experiences or takes on social media where
    there’s actually a pretty narrow subset of stuff that tends to get out
    of the filter and on the social media, and especially the social media
    that you look at. So if you turn that around and say, The stuff that
    I’m seeing on Twitter is representative of what happens in my industry.
    That’s a very serious mistake, especially in terms of best practices,
    or what should I do, or how should I approach this problem, because a
    lot of the, the most effective and experienced people, they just like go
    and tight for 10 hours and they go back home to their families or
    whatever, and that’s that. They never post anything on Twitter in their
    entire life. So I think you got to be really aware of this dynamic.

    00:52:45 - Speaker 1: I’m so glad you brought that up, cause this is

    another topic that I’m really interested in, because I feel like I wish
    the world worked a different way, that it just doesn’t work, which is
    that, how do I tee this up? Maybe you’ve seen people say something
    like, The talkers are on Twitter and the builders are off doing the real
    work, or people will frequently say the best designers or developers I
    know don’t have a presence on Twitter, and these things are quite often
    true. I mean, I have these people in my life, you do too, I’m sure of
    you just know a fantastic person who is good at their craft, and they
    don’t care at all about Twitter.

    And I think that’s great. I think that it’s amazing that there are

    people out there doing great work and Unfortunately, we never hear from
    them. We never get to learn from them.

    So as a result, the stuff that does get posted to social media ends up

    skewing like not as good or maybe lowest common denominator kind of
    content, and I understand why this happens, you know, if you imagine
    even someone inclined to share the things that they’re learning and the
    skills that they’ve developed, they buy a house. They have kids, they
    get married. They don’t care about impressing people on the internet.
    They just don’t care anymore, and those are the people that I want to
    learn from the most.

    So yeah, when I said I wish the world worked a different way. I wish the

    world worked where people who are really good at their craft and felt
    like they didn’t have to be on Twitter, would still go on Twitter and
    share what they know with the world. I wish those would be the people
    whose blog. we read whose Twitter accounts get the most likes, not this
    other hot take spicy repost screenshot of framer.com stuff that isn’t
    substantive and quite shallow, but people seem to like, you know,
    there’s just I don’t know, I complaining about reality, but How do we
    get more people who are really good at their craft, the person who we
    say, yeah, you know, the best people are off building, they’re not
    tweeting. How do we get them to tweet and actually feel comfortable and
    safe and rewarded for sharing what they know?

    00:55:03 - Speaker 3: I have a couple thoughts here. One is, I do think

    it helps if you take a broader and more networked approach.

    So my experience with infrastructure engineering, for example, which is

    the space that I used to work in, uh, and really focus in, my experience
    was that very few of those people were like online, but they were quite
    accessible if you just knew who to ask. So you just ask for an
    introduction and then you tell me your war stories about my sequel or
    whatever, and you can get access to a lot of information that way.

    So it might not be online and public social media, but You can access

    them directly.

    The other thought I have here is that I think that the edited interview

    is a great way to surface this information, and I wish people did more
    of it.

    That it is you identify someone who might have a lot of insight and

    experience, but for whatever reason, they just don’t have time or they
    don’t want to do it, and they haven’t got. The activation energy to go
    post about it.

    You just go interview them because people love to talk about themselves,

    right? And you can usually get people to talk for an hour about their
    work or what they learned. And if you do all the hard work of editing it
    and writing it up and publishing it, and so forth, you can get a lot of
    stuff out that way.

    And I’ve seen a few people attempt this. Like I think Will Larson, for

    example, has done the staff engineering series, you know, the podcasts
    end up being something like that sometimes. But I think that’s a really
    valuable and underutilized form.

    00:56:18 - Speaker 1: Yeah, I agree, and that’s why I actually think

    the Meta Muse podcast is so special in the space of whatever we call
    this design engineering technology podcast, which is that the two of you
    have experience, you’ve walked the walk and you also know how to talk
    the talk, and you have the ability to ask questions that go beyond the
    surface level.

    I remember when I started the Design Details podcast, when we would

    interview people. We were brand new to design and it’s like we could
    ask them questions, but we didn’t know the best questions to ask or
    even if they gave us a response, we wouldn’t have a nuanced follow up
    of, oh, I’ve also experienced that, like, how did you solve it and we
    can compare paths, right? It was very much newbie interviewing expert.

    So how do we get, I guess, to that point, Mark, like, what does it take

    to get more experts interviewing experts and it comes back to the same
    problem of they just don’t have time, they don’t care enough.

    00:57:16 - Speaker 3: Yeah, I think we need more information

    entrepreneurs, and by the way, it’s a great opportunity to build a
    little bit of a personal brand.

    00:57:22 - Speaker 1: Oh, interesting phrase, information entrepreneur.

    Hmm.

    Do you ever think about how there’s this path, it seems like where

    people get traction for doing something, and so they talk about it.

    I think this is quite common in the building and public movement which

    you all talked about on last week’s episode, which was You know, you
    build something you share it out with the world, you talk about what you
    learned, and quite often that gets engagement, but then it quickly
    becomes like a meta-analysis of, here’s what I learned about tweeting
    about what I learned.

    And then you get to the next level, which is, I made money tweeting

    about what I learned about what I learned, and then you inevitably have
    somebody selling a course about how to tweet about making money from
    learning about things that you learned about. And you just get stuck.

    I feel like that’s, I don’t know, the logical conclusion for all of

    this is you just release a course, have a newsletter, and talk about how
    to make money from tweeting about stuff. Yeah. Do you have the same
    perception that this problem exists and how do we avoid it? How do we
    help people not get stuck in that trap of doing the meta creation?

    00:58:35 - Speaker 3: I think it’s a very powerful and unfortunate

    attractor. I definitely see that a lot. I think a lot of this comes back
    to the individual participant in the information landscape and the
    social capital landscape. You gotta be aware that there’s a huge
    attractor there, so you got to heavily discount people who are selling
    courses about stuff, honestly. It’s not to say there aren’t any good
    ones, but you need to be aware that there’s much more incentive for
    someone to post about it if they’re doing that versus if they’re a
    very experienced practitioner who’s just scraping some time together
    outside their family to write one blog post.

    00:59:04 - Speaker 1: I agree with that. I would be curious to hear if

    you’ve experienced this, which is The people who are the best at that,
    who are very productive and good at their craft, they’re unwilling to
    take the reputational risk to talk about that publicly.

    One thing that I encountered when I did a series of interviews about

    staff design, which is really about the IC career ladder for product
    designers, and some people that I asked to interview didn’t have an
    incentive to be interviewed about that.

    They had made it at their company, they had the job where they were

    doing the best work of their life. There’s no reason to rock the boat.
    They’re making as much money as they want to make. They don’t care
    about being famous, they just want to do good work, and there’s no
    reason to be interviewed for that.

    Like, the downside of a misspoken phrase in today’s environment is

    pretty consequential from a reputation point of view to the point of,
    you know, you could actually get fired for saying something wrong or I
    don’t know, counter to the flow of online discourse.

    So I had people reject participating in that, who sadly are the people

    who I most wanted to learn from and have the most to share with the
    world. So, I guess selfishly, you could have that conversation one on
    one, unrecorded. But then we lose this opportunity for everyone else in
    the world to understand how the actually great people think and get work
    done and stay productive or whatever it might be.

    01:00:33 - Speaker 2: Well, before we go, Brian, one of the questions

    that I think your listeners sent in to ask Mark and I kind of a bonus
    question was basically advice to young designers getting started. So
    maybe I’ll repurpose that a little bit, turn it back around to you,
    which is if there’s someone early in their career that thinks, all
    right, this personal brand thing seems useful, will get me in touch with
    people I want to meet or maybe help me get a job or something, what
    would you advise for sort of how to get started and then Not only in
    terms of where to start, but even channels, right? We’ve talked a lot
    about Twitter, but like newsletters are really interesting one as well,
    building a personal website. There’s obviously lots of other ways to
    kind of speak to the world. What would you advise is the right place to
    start and are there even pros and cons, right? Like just coming in and
    thinking, oh, it would be cool to be like mildly internet famous, it’s
    probably the wrong motivation. There’s probably you even talked about
    some of the downsides. How does a young person know? If or how much to
    invest in a personal brand, and then how would you suggest they go about
    doing that?

    01:01:36 - Speaker 1: This is a really interesting question cause as

    you’re asking it, I’m like, damn, I wish I’d written about this to
    think more clearly about it before answering it live here with my voice
    captured for all of eternity on the internet, but let me try my best.

    I think maybe there’s 3 points I’d want to make. The first is what I

    look for when I’m hiring designers or even going back to original
    points like, 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 actually 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, you read a book, here’s my review. Other ways are you went ahead
    and bought a domain of your personal first name last name.com, then you
    built your own website. And in building your website, you got stuck on
    this gnarly JavaScript problem. So then you went in this way, right? So
    that’s one thing. Others are people who get frustrated with the way
    FIMA works, so they build the FigMA plugin, or it can be even just you
    take photos of the world and publish them. There’s just something about
    being curious about the way the world works, or more specifically about
    the way software works, and following some thread of that and sharing
    that online. I find that to be the number one signal I look for, like, a
    lot of people can design apps, a lot of people can design websites, and
    I’m sure are great at it, but it’s more enjoyable and interesting to
    work with people who are curious about how it all works, how it all fits
    together, and they have some activation to pursue that. So that’s the
    first thing is maybe it’s less about building a personal brand or
    building an audience and rather just like, how do I actually make sure
    that I’m still curious about the world after many years and don’t get
    jaded about everything and cynical and pessimistic about the future of
    software.

    01:03:42 - Speaker 2: I wonder if one piece of that, you know, curiosity

    is something I personally value and is one of our company values at
    Muse. So it’s interesting to hear you say you look for that in hires,
    but it’s also notable, I think that there is a connection really to
    creative and knowledge work, which is you are doing something well
    creation oriented and it has to be inspired somehow. It has to have a
    unique angle, you’re doing something and so curiosity is the start of
    that pipeline of making something interesting, making something unique,
    having a voice, doing some interesting work that isn’t just kind of Put
    something in the start of the pipeline and something obvious pops out at
    the back end.

    01:04:23 - Speaker 1: Yeah, 100%. And of course, you know, exceptions

    abound. I think a common push back against this idea is like people have
    families and work a second job or they might just be trying to break
    into the industry and they don’t have time to go make their personal
    website. I think that’s fine. It doesn’t have to be some big thing. I
    think it can be small proof of curiosity that grows over time. I think
    it’s OK, don’t need to overthink the size of that artifact, which
    maybe leads into my second point, which is I think it’s so easy to
    overthink. It’s gotta be perfect. If I’m gonna write a blog post,
    it’s gotta be a world shaking essay. If I could make a YouTube video,
    it’s gotta have, you know, 4K perfect sound quality, perfectly color
    graded. And I think this over optimization or this pursuit of perfection
    causes a lot of people to get stuck one step short of shipping, where
    they are way too invested in the polish of the thing they’re building
    and not concerned enough about just actually making sure the world sees
    it and can enjoy it. And I don’t know exactly how to battle that except
    What I’ve been doing a lot more lately is trying to publish right at
    the moment where I’m a little bit scared that it’s not quite ready.
    And there are definitely downsides to doing that cause you end up making
    many mistakes. A good recent example is I tweeted this idea that, hey, I
    will critique the visuals of your website or app. Would anyone pay for
    that? And I just tweeted this out into the world, and it’s taken me
    down this really random side project rabbit hole. Where now I’m doing
    these like product design critique breakdowns for people. But that
    initial tweet, I tweeted it when I was maybe a little bit scared to
    tweet that, like, is this too shallow? Does anybody care? Is this
    useful? I don’t know. Maybe I should just delete this draft. But I hit
    publish and there were mistakes in doing that. Like, the framing of it
    was incorrect. I put a price on it that was incorrect. I gated it like,
    oh, I’ll do this for 2 hours. That was a mistake. It ended up taking
    way longer. So I mean there’s this tension of being thoughtful about
    what you put into the world, but also not overthinking it. And so I’m
    trying to actually push back to not being unthoughtful, but being a
    little bit more daring, I suppose, and like, let’s just get it out
    there and it can develop over time. And then perhaps that leads into
    this third point, which is maybe even echoing what you said earlier,
    Mark, about. For younger designers, I look back at the stuff that I
    published and wrote when I was getting started, and it is just eye rolly
    cringy, embarrassing stuff, and that is on the internet. And I think
    that’s OK. I think it’s good to have some of those artifacts that you
    can look back on and laugh at yourself for. But if you’re particularly
    nervous about that, about being wrong, about having your early ideas
    published for the world and archived, I think a useful workaround for
    that is to ask the experts, you know, this was the way I started with
    design details, is we just interviewed better designers than us. In
    fact, even the precursor to design details was a series of blog posts
    that I wrote. They’re now called app dissections, where what I would do
    is I would screen record really interesting software on my phone. Oh,
    that interaction was cool. I would take a screen recording and annotate
    it. There’s no stakes in that. I’m commenting on other people’s work,
    but in doing so, I felt like I was You know, preserving some artifact of
    design in time, adding a little bit of commentary, forcing myself into a
    mode where I was thinking about design, trying to reverse engineer a
    decision. But I didn’t actually have to put my work out there, right?
    So it’s a little bit more of a safe way to wade into those waters. So I
    think podcasting is great, interviewing people is great. Use existing
    resources and extract information and knowledge from those before you
    necessarily feel like you have to publish your own groundbreaking essay.
    There’s an on-ramp here. So maybe those three ideas in combination, the
    proof of curiosity, don’t overthink and don’t put this pressure on
    yourself of having to have some magnificent idea when you’re early in
    your career. Maybe that all comes together into some concoction or soup
    of ways to feel comfortable talking about the stuff you’re interested
    in on the internet.

    01:09:00 - Speaker 2: I think that’s a great point to wrap on. Thanks

    everyone for listening. If you have feedback, write us on Twitter at
    MAHQ or on email, [email protected], and you can help us out by leaving a
    review on Apple Podcasts. Brian, thank you for inspiring us all with
    your decades-long accumulation of side projects that you’re willing to
    put on the internet for everyone to see and for educating us about maybe
    some of the pros and cons of having a lot of followers and how that
    might lock you in, but I look forward to continuing to follow all of
    your writing and podcasting and thanks so much for being on.

    01:09:36 - Speaker 1: Thank you for inviting me. I guess I have to be

    candid. It was a little self-conscious about being interviewed for this
    subject. There is this, I guess, chip on my shoulder of being known for
    being known, and that doesn’t feel super great. It’s like.

    01:09:52 - Speaker 2: Watch out, pretty soon you’re going to be selling

    a course.

    01:09:55 - Speaker 1: How about this? I’ll look forward to take to

    where we get to talk about design or product building. But this was
    really fun in the meantime and thanks for having me.

    0 min
  • Discuss this episode in the Muse community

    Follow @MuseAppHQ on Twitter

    Show notes

    00:00:00 - Speaker 1: When I think of real world analogies to this, like

    supporting a painter or a ceramicist or like glass making that’s kind
    of handmade, usually those things are more expensive than the Walmart
    equivalent. But in software, it’s kind of inverse, where the
    subscription to Microsoft 365 is going to cost you a lot more than your
    indie text editor.

    00:00:24 - Speaker 2: Hello and welcome to Meta Muse. Us is a tool for

    thought on iPad and Mac. This podcast isn’t about Muse product, it’s
    about muse the company and the small team behind it. I’m Adam Wiggins
    here today with my colleague Mark Grannigan. Hey Adam, and joined today
    by Perjean of Kinopio. Howdy. And Peron as knowledge workers and people
    who sit in front of computers all day long, I think it’s really
    important to have something physical, get out, move around, do exercise.
    What do you like to do for that?

    00:00:54 - Speaker 1: Well, these days I run, but before COVID, I used

    to box. We used to go to Gleeson’s boxing gym, which if you ever seen
    like a cameo or clip of like a boxing gym on TV or movies, you’ve
    probably seen it. It was a pretty great place to let out steam, but
    mostly it was a cardio workout where you train and occasionally you’d
    spar, which was kind of like a very high stress situation, which makes
    other situations seem less high stress, which is kind of good in its own
    way.

    00:01:21 - Speaker 2: That’s interesting. I remember seeing, maybe it

    was in the classic surfer documentary that they said one of the reasons
    surfers are known for being so kind of chill and low key is that when
    you go up against these incredible primal forces of nature. Than regular
    human stuff, the volume seems very turned down by comparison. Would you
    compare the, yeah, I guess, sparring with other humans, even though
    it’s not like a real fight in the sense that you’re going to get hurt
    is having some of that quality.

    00:01:48 - Speaker 1: Yeah, I forget who said it. Maybe it was Mike

    Tyson or something, but there’s this like really famous boxing quote,
    which is like, everybody has a plan until they get punched in the face.
    It’s a life lesson in a way, and I think it applies to a lot more than
    just boxing.

    00:02:02 - Speaker 2: Yeah, absolutely. Actually, I had a colleague who

    was doing that for a little while, but his wrist got sore enough. Maybe
    he was doing it wrong or something, but he ended up basically not being
    able to type for a week. Ouch. Obviously, as a creator, your hands are
    second only maybe to your eyes and your brain as being key tools. Do you
    worry about that at all or do you have any sense of like I’m sort of
    taking my delicate crafting tools? Using them to pummel a bag of sand or
    another person.

    00:02:30 - Speaker 1: I think there’s something to be said for making

    your delicate tools a little more durable, but I think for me, actually,
    like things like yoga stress my wrist a lot more than boxing did. And I
    think it’s just like different things might stress out different people
    in different places. And I think like trying all the different types of
    physical activity and going with what works for you is, it kind of makes
    sense to do, even though it’s kind of a slog to figure it out.

    00:02:55 - Speaker 2: Yeah, when it comes to fitness, and I definitely

    became a huge believer in the importance of doing something physical,
    both for the change of pace, but also really because it’s so important
    for maintaining our health earlier in my life as a kind of tech person.

    And I think one of the things that’s important is just to find

    something you enjoy.

    Some people love running, I do. Many people just cannot stand it.

    Others like lifting weights, others like riding their bike, others like

    boxing, climbing, but whatever it is, if the activity itself is
    enjoyable, not just the result of enhancing your strength and
    flexibility and endurance and general health and well-being, metabolic
    well-being maybe, then you’re likely to do it.

    And if you’re likely to do it, then that’s sustainable over the long

    term.

    00:03:39 - Speaker 1: Yeah, totally. If you don’t enjoy it, you’re not

    gonna stick with it, right?

    00:03:43 - Speaker 2: And so maybe you could tell us a little about your

    background. You’ve worked at some pretty interesting companies.

    00:03:48 - Speaker 1: Sure, so most recently, before working on Canopio,

    I was working at Fog Creek, which eventually became Glitch, which is a
    web development tool similar to Hiroku’s web development tool once upon
    a time, and I was the co-creator of Glitch and did its original design
    and the editor and stuff like that. I think nowadays things are very
    different, so the glitch you see now is very different than the glitch
    of 3 years ago.

    00:04:12 - Speaker 2: When you first mentioned that to me, it made

    perfect sense. The visual style of Glitch, at least as I remember it
    from a few years back, very much matches what you’re doing now, and I
    wouldn’t have made that connection, but then you mentioned it, and it
    instantly made sense.

    00:04:26 - Speaker 1: I feel like, yeah, Canopo is kind of an evolution

    of some of the ideas that I had when I built that interface.

    00:04:31 - Speaker 2: And Fog Creek also is interesting to note for

    maybe some of the younger folks in the audience.

    I always like to pull my technology graybeard card here, but one of

    their principals, Joel Sppoolsky, was really the one who I think defined
    modern blogging, and we’d probably find His style to be nothing special
    today, but this idea of a software engineer or a company founder who
    writes pretty humanistic blog posts about ways of doing things and you
    know, experiences and whether it’s technology or hiring or something
    like that. I think he really kicked all that off, and that’s in
    addition to, I don’t know exactly what the structure is there, but
    somehow the fog Creek nexus of people produced trello, stack overflow,
    later stack exchange, and Glitch, which is quite a run. So, yeah, it
    must have been interesting to be part of that little sphere.

    00:05:23 - Speaker 1: Yeah, Fog Creek was interesting cause like it was

    this kind of technology innovator and it was wild working so close to
    that.

    So for the first two years of me working at Fog Creek, we shared an

    office with Trello, so like, I got to see how that sausage was made as
    well.

    But also like Fog Creek had a lot of failures too. There was like a

    thing that was called. I think it was co-pilot where like you could do
    screen taking over and this was way before other solutions existed. It
    had kiln, which is like GitHub before GitHub, but based on materials,
    nobody used it. And yeah, it was just like wild seeing like so many
    ideas come from this place and Glitch was one of those ideas that just
    happened to be successful and how those things got incubated, you know,
    it was pretty unique experience.

    00:06:04 - Speaker 3: And didn’t they write a whole programming

    language? Is that still a thing over there?

    00:06:09 - Speaker 1: Well, yeah, so before I started, I don’t remember

    the details, but basically they couldn’t get what they wanted with like
    the existing .NET compiler or whatever the Microsoft stack was at the
    time. So they wrote their own programming language called Wasabi, I want
    to say it was called. That’s right. And they pulled it away while I was
    there, a really talented developer basically was part of writing it and
    then also part of migrating the code base away from it and it was like a
    really Contentious idea at the time, cause they were trying to do
    something they couldn’t do conventionally.

    00:06:44 - Speaker 2: Well, that is key to being a technology innovator

    though is you have to take a lot of swings, you got to try a lot of
    things, and that also implies a lot of failures, and the failures will
    be more or less forgotten to time and then you’re known for your
    successes. So, yeah, very interesting firm. And I also understand your
    educational background is a little different from the conventional
    computer science path that a lot of folks in the technology world took.

    00:07:08 - Speaker 1: Right, yeah, my degrees are in technically biology

    and urban planning, so I think I might approach things from a slightly
    different place.

    00:07:17 - Speaker 2: And if you’re interested in urban planning,

    certainly check out our episode with Devon Zugle about cities. We
    haven’t done a biology episode yet, but I’m not ruling that out.

    00:07:27 - Speaker 1: I’m definitely not the one for that. I was really

    bad at school.

    00:07:31 - Speaker 2: And did you find that that different kind of

    education has fed into the work that you do now, or did you feel that
    that was more like something you were interested in, but didn’t end up
    leading to your career or feeding into how you approach your work today?

    00:07:45 - Speaker 1: Yeah, I would say like kind of the inverse of what

    you’d expect, doing a grad degree and urban planning in general.

    The main thing I learned was like how to spot bullshit because like you

    read a lot of academic papers, you have a lot of professors, I don’t
    really do anything.

    There’s a lot of like authority gained by being a professor and How can

    I put this, didn’t really match the reality of what they were capable
    of.

    And also urban planning was really interesting.

    This might be really, really hot take, but the urban planning department

    was always kind of like mad at or like kind of had an inferiority
    complex with the architecture department. And I took a lot of
    architecture courses and like the professors in urban planning like
    really got on my case about that a lot.

    And so that kind of disillusioned me on the whole profession and the

    whole idea of graduate studies as like this kind of I don’t know, I
    think I held it in some sort of reverence, and I definitely don’t do
    that anymore.

    I respect speaking plainly more than like, saying a lot, I guess.

    00:08:49 - Speaker 2: So I guess the big takeaway there was the academic

    world didn’t seem like a good fit for you less because of the specific
    fields, but more because of all of the petty rivalries or status games
    that frankly exist everywhere, but maybe they take on a different
    character in the academic world.

    00:09:07 - Speaker 1: Yeah, a lot of pettiness. That was not something I

    expected.

    00:09:12 - Speaker 2: And then why don’t you tell us about Canopyo.

    00:09:15 - Speaker 1: Sure, so Canopo is, well, it’s kind of hard to

    describe, but it’s like a thinking tool, you know, you could do mind
    mapping, whiteboarding, note taking, all that sort of thing, but it’s a
    spatial canvas where the core interaction is clicking, writing down a
    thought, clicking somewhere else, writing a new thought, and eventually
    connecting ideas together with lines and with groupings and kind of
    getting to new ideas or solving problems both personally or
    professionally or like together with a group collaboratively. So it’s
    like a thinking canvas.

    00:09:45 - Speaker 2: Yeah, and certainly folks in the audience will

    probably immediately recognize that description as being very similar in
    a lot of ways to Muse.

    You could potentially describe our tools as competitors, although I feel

    like when you’re so early in a space trying to I guess convince the
    world that it’s worth thinking with computers in the first place and
    that we need new kinds of tools to do that, and that the spatial canvas
    is one that’s kind of under explored at the moment.

    From that perspective, I consider us very much allies in the sense that

    we’re trying to Bring people on board with this model or prove that it
    can work. But part of what I like is on one hand, what you’re doing is
    incredibly similar in terms of the core aim and this very basic idea of
    kind of the spatial canvas, but at the same time, stylistically, it’s
    completely different. You’re on the web. You’ve got collaboration as a
    core interaction, less about the tablet, the inking, I don’t know, PDFs
    are necessarily a big part of it. So there’s the core idea is the same,
    but you’re exploring a very different branch in the tree, so that makes
    us, I think, have a natural affinity.

    00:10:49 - Speaker 1: Yeah, I also think, correct me if I’m wrong, but

    the way we kind of arrived at the very different takes that Muse and
    Canopo have are very different in the sense of, I started with like a
    core interaction, just trying to make it fun, and that came from an
    observation that when I was working as I worked as a designer and a
    developer, but when I was working as a designer, I’d often like write
    out notes or little thoughts inside of a larger sketch document to
    myself.

    00:11:13 - Speaker 2: And here by sketch you mean uppercase S sketch the

    sketch the app.

    00:11:16 - Speaker 1: OK. Yeah, just kind of trying to like make ideas

    and mockups make sense to me or like write down the goals and rationale
    for things and kind of after leaving Glitch thinking about like, how can
    I kind of make that a thing that other people could do cause like you’d
    have to know sketch, which is kind of a weird design tool to take
    advantage of that kind of thinking and something built around that idea
    just kind of turned into Canopio.

    Canopo kind of started from me experimenting based on my own experiences

    using Sketch, the app. And writing with the text tool notes to myself
    while doing mockups and kind of trying to bring that experience with the
    advantages of being able to write anywhere on a page in a more
    approachable way to more people, as opposed to my impression of Muse is
    that it started a little bit more academically or rigorously.

    I don’t know what the right term is, but it feels pre-planned or well

    thought out and well fleshed out before, at least from the outside
    looking in.

    00:12:12 - Speaker 2: Well, I’m glad we’ve got you fooled. Joking a

    little bit there.

    Obviously it did come from pretty deep research, but yeah, you’re

    right, our origin story was more about tablet, tablet and stylus form
    factor, where do we do our best thinking as well as kind of gestures and
    the touch screen as being something more intimate and trying to think
    about what it would take to get a sketchbook or a whiteboard into a
    digital space, and then maybe one of the missing things is, yeah, being
    able to use your hands or more directly interact with the ideas.

    But I think in a way we have arrived at something similar.

    Text has become a bigger and bigger focus for us. We have these text

    blocks in beta now we have sort of big plans for that. And so we’ll see
    where that goes. But I think that idea of text and visual thinking
    together or written thinking and visual thinking together has become
    sort of core to our idea. So in the end I think we all organically
    develop towards a vision, right?

    00:13:06 - Speaker 1: Totally. I mean, I think it’s interesting that we

    both kind of met in the middle, as you say, but you started more as like
    image oriented and I started more as text oriented. And then I guess
    people want all the things. I think that’s kind of the story that also
    guides the evolution of both these products.

    00:13:25 - Speaker 2: Probably the way I’d put it is symbolic

    representation of thought and visual representation of thought both have
    their place.

    Computers have always been great at the former, but not at the latter,

    but then often you do have these more visual oriented environments,
    something like sketch or Photoshop or whatever, but then text is a
    trying experience to bring in there. And one thing that always struck me
    when you look at as part of our user research a few years back, we went
    through a bunch of photos of whiteboards, just to kind of get a sense of
    like, OK, when people are using this analog tool, how are they
    expressing themselves visually? And I was always struck by, like, how
    much text is up there. It really is at least 50% text in the sense of
    handwritten text or occasionally a printout that’s been like magneted
    to it, even though it’s combined with, OK, you wrote the text in
    columns or you color coded one, or you have a little annotation on the
    side, so there’s a lot of information that’s contained in the spatial
    positioning or how things are color coded or where they’re placed on
    the board, but in the end, the core atoms are often snippets of text.

    00:14:31 - Speaker 1: So I used to write a lot of specs and you know,

    documents and stuff as you do in a large company, and I noticed, I think
    one of the things that kind of defines like, is it a pleasant experience
    to work for or with someone versus not is can they kind of share their
    ideas? Can they get their thoughts out? And I think learning to write is
    like learning to think and Traditionally we have like linear writing
    tools and they kind of require a high level of like practice and skill
    to write well, but the great thing about whiteboarding and spatial
    writing in general is, I think it takes a lot of that pressure away.
    Like I don’t have to necessarily have a lead in sentence. I don’t
    necessarily have to think about how prose flows, it just, here’s an
    idea, here’s another idea, maybe like lines or some other visual
    connects some, and yeah, I think it just sort of lowers the bar to
    communication.

    00:15:22 - Speaker 2: Yeah, absolutely. The free form, just get it out,

    get started, approach versus the dreaded blanking cursor on the start of
    the blank page and where do I begin? I think that’s a big part of what
    you can offer with these more sketchy and certainly more spatial tools.
    So today’s topic is building in public, and I think this is something,
    another similarity in our approaches, again, not maybe purposeful, but
    sort of people with similar mindsets working on similar problems often
    arrive at similar solutions.

    And so I think I became aware of your work through these short demo

    videos you post Twitter, here is some new feature, and here’s how it
    works, and you can watch this little 5 or 12th interaction and even
    without having the full context for what the tool is, you see this and
    it’s, you know, videos are fun, but it doesn’t demand too much of your
    Time, Canopia certainly has a very interesting visual style, and you see
    that and you see a few of these and you start to get a sense for what
    it’s about and it’s quite fun. So tell me what you do there and how
    you arrived at that, I guess, approach to kind of sharing what you’re
    working on.

    00:16:29 - Speaker 1: Sure, so the way I share things online kind of

    evolved organically.

    I was thinking about it for a while and the great thing about Canopo and

    drawing tools and spatial tools in general is that they’re very
    visceral.

    They kind of video really well because there’s animation, there’s

    movement, and a lot of the features I was building kind of also involved
    movement, which meant conveying what something does easier with video.

    The cadence I got into was like build a feature and then make a short

    video and kind of talk about it, like short tweet length blurb and share
    it and kind of do that in small iterations and that kind of paralleled
    how I shipped updates to the product.

    My priority was sort of, I wanted to integrate marketing into my

    process. I’m just one person building the tools, so I don’t really
    have like a separate marketing department. And so just do the work or do
    the programming work and then do the marketing work or the
    communications work of here’s what I built, here’s what I did, and
    then keep that cycle going and hopefully end up somewhere good is
    basically my plan. And so the tweets are a reflection of that, like,
    every tweet usually coincides with a push to master to production.

    00:17:42 - Speaker 2: Yeah, that makes sense.

    And yeah, we’ve arrived at a similar thing as well, which is the short

    demos, which are pretty informal.

    We did find that for the tablet, it’s pretty important to show the

    hands, and so we film kind of external to the device that works well,
    but yeah, being short, having some kind of little textual description of
    what it is.

    But not trying to explain everything. It’s not a product manual. It’s

    not a full top down. It’s just some little snippet of interaction in
    this product and for existing users there’s a chance to find out about
    something that’s coming out soon or has come out that they can try
    maybe a feature they’ve been waiting for they would like to try because
    it looks useful or interesting.

    But then also for the folks who are not current users of the product, if

    they do come across it through a retweet or Twitter’s algorithm,
    somehow organically or magically surfacing it to them, and then maybe
    they see that a few times and they start to get intrigued, and they
    think, what is this weird looking out? Maybe I want to check it out.

    00:18:41 - Speaker 1: Yeah. Oh yeah, I guess I should have also

    mentioned this before, look my process. Maybe I’ll take this again or
    maybe this will be fine, but The process for me making these videos is I
    used the inbuilt Mac screenshot video tool Command shift 5. I record
    myself doing the things, and then I’ll trim the back and the front
    edges in quick time, also already on the Mac, and then convert it with
    handbrake to MP4 format and then throw it on the web. It’s a very like
    quick streamlined kind of system I’ve got going. I’ve gotten really
    good at command shift fiving.

    00:19:13 - Speaker 2: Indeed, and certainly being a one person shop,

    it’s important that you not get too hung up on the production, but I
    also think even for, you know, our team who has a few more people than
    that, we’re still small, but I find that if it’s sort of quick and low
    ceremony to do this, then you’re much more likely to do it often and
    even be able to show, sometimes we show some work in progress and we
    update a week later and you can see that stuff has changed, even just,
    you know, minor visual design details.

    If you can make it more just fun and quick and low ceremony, then you

    get these steady stream of it, which I think fits better with the
    building in public thing, right? I guess we should stop and define that
    a little bit, cause I think there are some different definitions, but to
    briefly like kind of look at the far extreme, you could take something
    like Apple, who does these huge product releases, all this fanfare, and
    they keep everything totally secret up until the moment when it comes
    out.

    And you know, that obviously works for them. There’s lots of companies

    that do things that way, but I think of the building in public approach
    you’re using and that we do and plenty of other folks as well as being
    more of a bite size, taking folks along on the journey, and there’s
    plenty of products, even games and things that I follow, largely through
    Twitter that I actually probably will never use the product to play the
    game or whatever, but I just like their little videos. I like their
    sharing their work, cause I like creative process, I like seeing makers
    do their thing, and if they have an interesting visual flair or what
    have you, it can be like a source of inspiration, I guess.

    00:20:43 - Speaker 1: My theory slash hot take is that the kind of

    classic way of doing big product releases very much tied to a time where
    when you really software was on a box, so you kind of had to make sure
    people knew about this was a new hot box to buy because there’s only
    like one a year or something. In our case, we’re not necessarily
    constrained by that old world. I think with social media and stuff, I
    think there’s just more of an emphasis on frequency and having that
    ongoing conversation with people. Cause we can like a release for us is
    relatively easy compared to shipping a box with a CD in it.

    00:21:19 - Speaker 2: Yeah, now I guess if we were to define building in

    public, we sort of already talked about sharing work in progress, short
    product demo videos, kind of bite size micro videos, but taking a step
    back from that, Mark, I’d be curious to hear for you what that term
    evokes.

    00:21:36 - Speaker 3: Yeah, well, certainly the core is sharing what

    you’re doing along the way.

    Often there’s this element of engagement with the community where

    you’re getting feedback, you’re getting ideas, you’re getting
    reactions and using that to influence more or less how you’re
    proceeding with the project.

    I also think there’s something to sort of priming the social

    distribution mechanism, to build on your point earlier about a box
    versus a continuous release. It’s not just a matter of the release
    mechanism. It’s about how people find out about software.

    It used to be whatever PC magazine who had 12 issues a year or

    something. You need to punch through the editorial calendar so you get
    on there, whereas now will find out about it through their friends and
    through influencers on YouTube and stuff. And it takes a long time to
    get that flywheel going, because you need to have several revolutions of
    it before people find out from people who find out from people, and you
    get the exponential growth to go up. I think that’s a big aspect of it
    as well.

    00:22:31 - Speaker 2: One term sometimes used by marketers that I’ve

    worked with is a drumbeat, a marketing drumbeat, and I think what they
    mean by that, if I can decode it, is sort of similar to a rhythm in a
    song.

    In general, what makes music pleasing for humans, I think, and engaging

    is essentially sort of it’s repetition. It’s not just one pleasing
    note or a few pleasing notes and then it’s over, it’s that it has this
    kind of repeating, but then with variations thing and then you can be
    drawn into that almost, yeah, like a story or a journey or something
    like that.

    And so yeah, I think increasingly it’s not that you find out about a

    product through, yeah, that big review in PC Magazine like you said, and
    then you decide to buy it and you go to the store and you buy it, or you
    don’t decide to do that and you never think about it again, and instead
    it’s more it comes on your awareness through all these aggregators. And
    social media networks that we operate in nowadays, and you think, oh,
    that’s kind of cool, and you start to follow it just out of curiosity,
    and then maybe it builds some kind of mindshare with you, and then
    either you come across a problem that you think, oh, I need a solution
    to this. Oh, actually that weird little indie company I’ve been
    following on Twitter, actually that might be just the thing for this, or
    just at some point you just get curious enough, you’re like, yeah, I
    got a little time, I want to check this thing out. It seems cool.

    00:23:46 - Speaker 1: Yeah, I mean, you mentioned the phrase marketing

    drumbeat. When I heard you say that, I was picturing like, you know, the
    Viking person kind of drumming the beat and everybody’s like rowing the
    or in unison to it. And to me, I think like from the point of view of a
    marketer, it’s sort of like we’re rowing every day, you know, this
    constant rhythm. And it’s like a lot of hard work because the seas are
    choppy, but if we row enough, long enough to the beat, we’ll arrive on
    the shore or something, but it’s kind of part of that, like the journey
    is part of it. Yeah that’s my interpretation.

    00:24:20 - Speaker 2: Another interesting thing here is you mentioned

    that sort of the sharing of work in progress, let’s call it marketing,
    maybe storytelling is a term I like a little better since it doesn’t
    have some of that historic baggage, but explaining and sharing what
    you’re doing, particularly if you do this build in public approach
    where it’s not about the big bang but rather a continuous stream of
    here’s what I’m up to kind of updates.

    Now, for you as a solo creator, you have the full called vision of any

    particular feature or thing you’re doing in your mind. And so then you
    need to translate it to kind of speak to the outside world through a
    little video or something like that. We’re in a position where
    sometimes the person kind of making a little demo video is also the same
    person that worked on the feature or kind of was the driver for it, but
    other times it’s quite different.

    So I’ve often been in the position where I’m the one to make a

    screenshot or a demo video or add a handbook entry, but I actually
    don’t, you know, I was working on other things and I wasn’t following
    closely the feature development, and I need to really sit down and kind
    of mind meld with the person who had that, so I can understand what’s
    special about this, why do we do it? Why is this here, why now, that
    sort of thing.

    And I wonder, there’s probably a big benefit to not having to do that

    mental handoff in the sense of, you know, you don’t have to take the
    time. But I think there’s also pros to it sometimes, which is the
    process of getting the product owner, let’s say, to explain what
    they’re doing to me, and then I try to make a demo about it and I say,
    well, what I really want to show is X and Y, but that doesn’t work
    because of this missing feature or this bug or this strange behavior,
    and then that actually can feed back into how the product is made, or we
    just get CRISper in our thinking because of that handoff.

    00:26:02 - Speaker 1: Yeah, in my case, it kind of definitely requires

    some diligence. Actually, sometimes while making the screencast, I’ll
    notice that something’s off or like my explanation of the feature is
    kind of hard to convey, and I’ll actually just like, hold on a second,
    maybe I’ll go back and update the thing that I just built. So I can
    explain it better or that it kind of makes more sense. So I feel like
    the process kind of does have like a little mini cycle unto itself,
    where if something isn’t easy to explain, then maybe that means the
    thing that I built just doesn’t make sense or needs a bit of refinement
    to get it to that last 10th.

    00:26:37 - Speaker 3: Yeah, a few reactions here. One is I really agree

    about this idea of the importance of the mental model.

    Often when you can’t explain something, it’s because you don’t

    understand it or you’ve basically misconceived the world and therefore
    you’re having this impedance mismatch when you go to try to explain
    it.

    So that’s very viable. Also, there’s this idea of how do you convince

    a lot of people of a new idea? Well, the answer is one person at a time,
    so you might as well start with your business partner first, or, you
    know. rubber duck or whatever, because you’re going to work out some of
    the kinks that way. And relatedly, I think building public has this
    element of sharpening the tool. I come back to this example of teaching
    hospitals a lot where when you’re in this environment of teaching and
    critique and different levels of expertise and familiarity, it brings
    out the best in you and it forces you to step up your game. And I think
    working in public has that same dynamic.

    00:27:27 - Speaker 1: Yeah, I also noticed from having a joby job back

    in the day that one of the main reasons that like a feature would suck
    when it was built is because the brief or the spec was like just flawed
    fundamentally, like maybe there’s an assumption that was wrong or
    whatever.

    And the great thing about building in public is if you’re doing it like

    really on the bleeding edge where you’re saying, I’m thinking of doing
    X, where I might not tweet that it might be in the forums or on the
    Canopbio discourse, but That kind of has like a correcting mechanism or
    it kind of forces me to be clear, and which also kind of chops off scope
    in a lot of cases.

    So I totally agree with you on that.

    00:28:05 - Speaker 2: So basically explaining things is another kind of

    tool for thought.

    00:28:09 - Speaker 1: Yeah, exactly, totally. It’s the tool for

    thought.

    00:28:13 - Speaker 3: Yeah, and another variant here is doing residence

    testing with the community where you emit a bunch of different
    frequencies, each frequency, it’s a different way to think about or
    explain your product and a subset of those resonate back and then you
    know that you can iterate towards those ideas and phrases in your future
    marketing.

    00:28:30 - Speaker 1: Yeah, I’m not sure if it’s similar to, like, I

    don’t know if you’ve heard the term paving the cow paths, which is
    like a landscape architecture term where you know, if people are walking
    weirdly through your park, then you just kind of pave that as the path,
    because that’s where people want to go and using words that people are
    using to describe your own thing back at them, I think it’s really
    effective.

    00:28:51 - Speaker 2: And the other elements of building in public, you

    know, here we’re talking about demoing product features.

    I think when I first encountered the term, it’s in the bootstrapper in

    the hacker communities, it seems to be a lot of sharing your revenue
    growth, and I think some of that is a pushback to the conventional
    wisdom of business is you don’t really share numbers unless they’re
    really impressive.

    If you’re a public company that’s reporting your $100 million in

    quarter 3, that’s one thing, but if you’re a a developer or two people
    and you’re making a moderately successful product, you don’t share
    that you’re making 5000, 10,000 a month or whatever the number is.

    You have end users or end customers, and so a lot of the folks, I think

    even the indie hackers site has some capabilities built in where you can
    even connect to the stripe API and it builds a dashboard for you where
    you can see the exact numbers.

    And there’s some interesting debate about that in the community because

    there are people who are maybe less scrupulous would be the right way to
    put it, but when they see revenue growth of a particular product,
    that’s motivation to basically create a clone and try to grab some of
    that revenue for themselves, so that’s not great.

    But it does seem to be this culture of we share this as a chance to have

    your own milestones and sort of accountability from an outside
    community.

    I think is also especially helpful when you’re just one person, you

    don’t have investors or whatever, but then also it’s a chance to
    support others when people do reach their milestone that they set out.

    Oh, I’ve reached 100 customers, that was my goal for the year and

    everyone can cheer them on and be supportive, and it’s sort of a small
    business culture. I think that’s quite interesting.

    It’s different from the building public we’re talking about here, but

    I still think it’s an interesting one.

    00:30:27 - Speaker 3: I actually think they’re more related than you

    might initially think.

    I think a lot of the impetus is signaling. So if you go back to when we

    first started to see this with small software businesses at a time it
    wasn’t really understood that an individual person can make a lot of
    money online with a really niche weird software business. And so being
    able to do that and share it was a very interesting signal. It had a lot
    of novelty value and it showed that you were a surprisingly accomplished
    software entrepreneur.

    Well, now we know that’s much more feasible and there’s tons of these

    businesses, and it’s still hard to do, but it’s not novel or unique.
    And I think in many ways it has become outweighed by this clone risk
    that you mentioned.

    But I also think a lot of the product building in public is about

    signaling to your community and your potential community that you have
    good taste and you get it, because this is not the case with most pieces
    of software and software firms, you know, that’s just the reality.

    But if you can do the hard work of putting together not only a really

    good product, but a piece of media that concisely shows that, that
    causes people to correctly adjust their priors a lot on the quality of
    your work. I think as software people were often uncomfortable with this
    idea of signaling and marketing and information uncertainty, but the
    reality is there it’s a huge place, most of it isn’t very good, and so
    you have to do a lot of work towards helping people understand that your
    product and your company is in fact good and this is gonna be one way to
    do it.

    00:31:51 - Speaker 1: Yeah, this is something I think about a lot. I

    don’t share numbers personally yet, but my thinking is more along the
    lines of How can I put this? Well, there’s two things, I guess. The
    first is that I kind of feel weird that people are like analyzing
    whether a thing is good by how much money it makes when they can just
    like look at it and like, is it good? But I guess I could see how that
    would be like human nature.

    The other side to it is like, If the number is too low, does it have the

    reverse effect? And if the number is too high, are you seeing a sort of
    like sell out or like, oh, you’re not like an indie hacker anymore, now
    you’ve like made it, you’re not one of us. So maybe I’m a pessimist,
    but I only kind of see the negatives in that case.

    00:32:35 - Speaker 3: I tend to agree on the financial numbers side, and

    I think most people have, which is why we don’t see them very much
    anymore. But yeah, and I think there’s still interesting signaling
    value on the product itself.

    00:32:45 - Speaker 2: Another spin on that that I like for individuals

    is just talking about their transition from either being full-time
    employed or a contractor and then the kind of percentage of their sort
    of life earning needs which are covered by their product or their
    business that they’re trying to get started versus a more conventional
    source of income. And I think we’ve all made that.

    Transition or anyone that’s tried to go off and do their own thing,

    whether it’s being indie or even as a freelancer or starting a
    business, you know, I certainly went through that lots of kind of, you
    know, moonlighting, I guess is the the term for it, because you end up
    working on it at night.

    But yeah, when I started my first business, there was a good long period

    of kind of working on it on the side while I worked my day job, and then
    trying to do the calculation of, OK, do I have enough saved up? I’m not
    quite earning enough from my side gig yet, but I know if I can focus on
    that, I think I can get it across the line in 6 months or a year.

    If I cut down the basics in life, can I make it there? It’s this really

    huge and important life transition and honestly a pretty intimidating,
    even scary one for a lot of people. I think that approach of sharing. Of
    I’ve reached personal break even where I’ve made the full transition,
    you know, I’ve basically like finished my last client project and from
    here forward I can be full time on this product that I’m working on.

    That sort of thing I think is really good. Pure, I don’t know what the

    word for it is not quite role modeling, but a chance to exactly said
    mark show that you can do it, and it’s not about the number and whether
    it’s low or high, it’s about. Starting something from scratch, and
    being able to take that very hard road that takes you to that basic
    sustainability.

    00:34:25 - Speaker 1: Would you be more interested in like that hearing

    that story from the perspective of, I’ve made it, here’s the things
    that I did, or I’m in the struggle right now and it sucks. It doesn’t
    end on a happy note cause it’s pending, right?

    00:34:41 - Speaker 2: Yeah, that’s interesting. I think that hearing

    from inside the struggle, and this I think does connect to the build in
    public, you’re not getting the finished and polished story where you
    can go back and kind of like adjust the little details probably
    subconsciously to make it all add up and end in that happy ending.

    But instead that you get the raw unfinished thoughts that may be even

    conflicting day to day.

    I think of a good example of this, an incredible log of sort of creative

    process is the book The Making of Prince of Persia, where the author of
    this absolutely now iconic and classic video game, the Prince of Persia,
    had been keeping personal daily journals the whole time, and it’s a
    wild roller coaster, and he is questioning every month, is this worth my
    Time is the video game industry a dead end? Should I even be doing this?
    And in hindsight, you look back and you go, not only did this make this
    person’s career, but you know, if you’re someone that grew up with
    gaming in that era, you think of this as just a seminal thing. How could
    he have been questioning that he was doing something worthwhile? But of
    course any artist, any creator, you got your struggles, anything worth
    doing has its struggles, and being able to see that kind of in real
    time, if that’s the right word for it, is a really powerful thing.

    00:35:52 - Speaker 1: Yeah, Jordan Meckner, right?

    00:35:54 - Speaker 3: That sounds right, yeah.

    00:35:55 - Speaker 2: That’s the 10 wow, what a legend.

    00:35:57 - Speaker 3: Yeah, folks, if you haven’t read this book, you

    have to, it’s absolutely incredible, and it’s almost totally unique as
    far as I know in terms of having the actual day to day source materials,
    just incredibly valuable.

    To your original question, I think there’s two dimensions here.

    One is, do you see all the details day to day, which could be either

    because you have basically a journal, which is quite rare, or because
    you’re just talking about on Twitter as it happens, which is more
    common, and then there’s the question of who do you hear from, and you
    can get all kinds of weird selection bias depending on if you only hear
    the success stories. So for both of those reasons, I think it’s
    interesting to hear it as it happens, which of course is congruent with
    our choice of building a public podcast episode.

    00:36:36 - Speaker 1: Yeah, it’s definitely rare, which I also agree

    kind of makes it more valuable.

    00:36:41 - Speaker 2: Yeah, certainly that’s part of what we do here in

    this podcast.

    I wanted to document our thinking almost as a sort of journal for my own

    purposes later on.

    And I think in maybe in some of the early episodes, I’m thinking of

    where we talked about like our partnership model, which is a bit unique
    and you know has certain risks to it, and I think we basically left it
    with, well, we’re hopeful this is going to work, but it’s got all
    these risks, no one really knows. Let’s check back in 3 years, maybe we
    did that episode a year and a half ago, so, you know, we’re not too far
    away from, you know, checking in and being able to. retrospect, and I
    can only imagine that some of the things that we talked about early on
    later on, I’ll be able to look back either years from now or even
    sooner than that and go, ah, this whole idea we had, it sounded nice at
    the time, it made sense, but it actually didn’t work, you know, in the
    laboratory of the world where you put your ideas to the test, not all of
    them are going to stand up.

    00:37:35 - Speaker 1: Yeah, I mean, I want to check out that book. The

    part of it that really kind of sounds like it resonates with me is a
    sort of emotional struggle. I’m kind of an emo guy. Like you don’t
    necessarily hear that side of it. I think there’s numbers and if the
    numbers are good, then there’s posturing, but you’re in the middle and
    I’m not so sure in real time is very interesting to me.

    00:37:55 - Speaker 2: Yeah, posturing is one thing that I have sort of a

    personal cringe from and when I have been inside companies where it
    seems like maybe this is more old school business advice, maybe this is
    changing now and being more honest and human and authentic and
    vulnerable is hopefully becoming more in fashion because those are
    things I’m more interested in, but I don’t know, man, posturing,
    life’s too short, you know.

    00:38:22 - Speaker 3: Yeah, well, this does remind me of the issue of

    individuals versus small companies versus large companies.

    I think we’ve mostly been talking realistically about individual

    creators and entrepreneurs and very small ventures like Muse in terms of
    number of staff. I think actually a big advantage for these people,
    these individuals and small firms, I think it becomes much harder to
    have a really open, transparent working in public process when you’re a
    large company.

    It’s not impossible, but there are all kinds of dynamics working

    against you, and we need to go into all the reasons, but basically.
    It’s because a firm has this incredibly valuable capital, you know,
    goodwill that you’re potentially playing with. And so you could burn
    that down, or people could be very jealous of it, or it could be hard to
    get access to it, to basically be able to publish under the company’s
    name and so on and so forth. So for all these reasons, it’s potentially
    a unique advantage that small ventures have.

    00:39:12 - Speaker 1: I think the bigger the company, the more it’s

    seen as like this is a high risk thing with low reward and like nobody
    wants to be the first mover on that kind of initiative.

    00:39:22 - Speaker 2: Yeah, do you think the personality element of it

    is really important. We do talk about brands as having personalities.

    Yeah, there’s certainly big brands that are playful and fun, and

    there’s others that are sleek and futuristic, and there’s others that
    are maybe emotional and rustic, for example, but those are pretty I
    don’t wanna say manufactured exactly, but they don’t really come from
    any one human or small set of humans other than maybe the founders.

    The founders had a particular set of personality traits and that created

    the beginning of the brand, culture or the brand personality, but then
    you go on 10 years, 20 years, the company is big, and all of that gets,
    I don’t know, homogenized or more distant.

    Yeah, and maybe that’s as it should be actually, as you get bigger, you

    should be kind of more accessible, less.

    Peculiar, maybe one way to put it, whereas when you’re at a small

    scale, yeah, bringing your own personality into the brand, the business,
    you are the company, right? And that’s true even at uses company size,
    but certainly for a one person shop like you have, that is there, how do
    you think about personality as being part of the work you’re doing?

    00:40:32 - Speaker 1: I think it’s a big part of it. I think it’s one

    of those things that set us apart from other companies that kind of have
    to compete on these are featured checklists, these are like, you know,
    enterprise ready things.

    There are more choices in software, it’s becoming less of a commodity

    and like, There are markets that are already kind of evolved in this
    direction, like to do lists and stuff where you’re not choosing the
    thing that has all the features because you don’t need the features,
    you’re choosing the tool that resonates with you, and it’s kind of
    like buying a camera or buying like a good where there’s a low end
    version, a high-end version, and lots of variations in between choosing
    based on vibes.

    00:41:09 - Speaker 1: Exactly. I think there’s like a floor of

    capabilities you need, but beyond that, it’s sort of like which tool
    makes me feel the best. To use and, you know, to tell people about and
    all the rest of that.

    00:41:21 - Speaker 3: Yeah, totally, we’ve talked about this on the

    podcast before on how creative work is this incredibly difficult,
    emotional, highly unnatural endeavor, and you need the right
    encouragement and inducement, and environment, and if you’re working
    with a tool that makes you feel, you know, inspired and motivated,
    that’s a huge deal. It’s actually worth something. It’s not just
    cosmetic in the negative sense, right? It’s really valuable.

    00:41:43 - Speaker 2: I think we usually cite the substance of style.

    A classic Virginia Postrell book talking about that, and I think it came

    out around the time of Steve Jobs had taken over Apple, and she was
    arguing why the new IMAX coming in colors you could choose rather than
    just having the one beige box, which is what computers have basically
    always been up until that point, was actually a pretty big deal.

    The whole thesis of the book boils down to We want to say that aesthetic

    doesn’t matter and it’s about function, but the thing that’s missing
    there is we’re humans and we care about how things feel and how they
    look and how they smell and sound, and we actually are more productive
    and more effective at whatever it is we’re trying to do if we just like
    the vibe of the thing itself.

    00:42:25 - Speaker 1: I think that’s really connected to the idea of

    we’re selling consumer software more than we’re selling for business
    software in that when you’re selling to people, the same people giving
    you money are the people using the product. With corporate or enterprise
    software, you have a corporate buyer buying it on behalf of other people
    and they’ll never use it for themselves. So there’s a different
    calculus that goes on there where it’s like, I don’t really care how
    Jira is to use because it checks all the boxes and I won’t get fired
    for buying it.

    00:42:54 - Speaker 2: And that’s certainly why we wanted to stay

    focused on the individual buyer in the early days of the company, and
    there may be a future, you know, business team product or something like
    that, but I wanted to make sure we were so far along that the core
    product could be very personal and emotive, and it serves the user’s
    needs and the user and the person that’s parting with the money or the
    same person, which is a really good way to make sure those things stay
    completely in sync or it gets much harder when the buyer and the user
    are different people.

    00:43:23 - Speaker 1: Yeah, I think there’s this metal layer where

    you’re designing a company and if you do a really good job, you’ve
    kind of designed everyone’s incentives and motivations to take you to
    the same direction, same place.

    00:43:35 - Speaker 2: There’s also some software industry dynamics here

    when you talk about the bigger you get, the more kind of generic it
    needs to be or should be, and the smaller anicier you are, the more you
    can be sort of weird, and then you’ll be a beacon for the people that
    also like that same kind of weird and that if there’s a lot of
    different choice out there from different weird things that have
    different angles and you can find the one that really suits you.

    But I think a lot of folks still think of software as being kind of the

    world that say Microsoft. Built, which is a single player who’s going
    to dominate and consolidate an entire market. So there can only be one
    word processor. Basically there can only be one spreadsheet, there can
    only be one photo editing tool because one sort of the file format, I
    call it network effects, but switching costs, probably a better word for
    it, and then that implies several other things, which is you need really
    huge scale. That your R&D cost becomes kind of a footnote or much
    smaller compared to because it’s split among such a large audience,
    essentially the whole world.

    And then you get into this niche indie software and there can be way

    more variety. It’s OK if there’s 50 spatial canvases because they all
    serve a unique niche, uh have a unique vibe or are made by different
    creators with just different kind of basic aims and in different
    communities.

    But that also means that the R&D cost is not averaged among so many

    people, so that may affect kind of pricing elements, but it also means
    that maybe there’s this element of almost the patronage, we’ve talked
    about this a bit before, Kickstarter or Patreon, or something like Steam
    Early Access, which is in many cases, you want to see the work of this
    creator come to fruition. You want to see this product exist in the
    world because you want to use it, but coming back. To that vibe thing,
    you just want more stuff in the world that is like this and almost
    implies, you know, in the same way you would through patronage support
    an artist, a painter or a musician or something you want more of their
    stuff in the world. It’s less of a practical calculus and more of a,
    hey, I’m willing to part with a little money to have this thing exist.

    00:45:47 - Speaker 1: Yeah, it’s actually also interesting because when

    I think of real world analogies to this, like supporting a painter or
    ceramicist or like glass making that’s kind of handmade, usually those
    things are more expensive than the Walmart equivalent, but in software
    it’s kind of inverse where the subscription to Microsoft 365 is going
    to cost you a lot more than your indie text editor or something like
    that.

    I’m not entirely sure why that is, but I think part of it is like the

    way we perceive how much things should cost with software, just it being
    like this thing that’s floating out in the ether, measured only in
    kilobytes and megabytes, if that, yeah, it’s kind of hard to put your
    hands around it in a way where you can value it the same way you value
    physical good.

    00:46:32 - Speaker 3: Speaking of purchasing software, if you think

    about what you might be buying, the bundle is probably bigger than you
    would originally think.

    So, yes, you’re buying something to move numbers around in a

    spreadsheet, OK? You’re buying the sense of putting your thumb on the
    scale in favor of this creator and the way you see the world existing in
    the future.

    Another thing I think you’re buying is sort of an aesthetic tool to

    signal to your friends and your community. I’ve seen this a lot with
    things like notion and other supposedly personal productivity tools.
    There’s a whole ecosystem around basically sharing what you’re doing
    in this very aesthetic and outward facing way of just like to do lists
    and calendars and things that seem very mundane and personal, but being
    able to show that you have a sense of taste and aesthetic is actually
    very valued by people. And so I think that’s an emerging and important
    aspect of the bucket of things that you’re buying.

    00:47:26 - Speaker 2: I wonder if that point is almost the buyer or the

    other side of the building public for the creator, which is they’re
    showing how they use a tool, but they’re really showing how they live
    their life, and I think we’re all much more curious than maybe we
    realize or we want to admit about Yeah, how do people juggle their
    calendars? I don’t know.

    I spent probably 15 years in my adult life trying to find the right

    combination of managing my time and not say that I have it perfectly
    sorted out, but I had a lot of false starts and made a lot of mistakes
    and so on. Like, what do other people do? Same thing for to do this, the
    same thing for personal retrospectives or how to think about big
    decisions or all that sort of thing, just a screenshot of someone’s
    Maybe color coded to do this doesn’t necessarily give you the whole
    picture, but it gives you a surprising glimpse into it, maybe like
    seeing their living room behind them in zoom or something like that, and
    you just get some little snippets, you know, the guitar there, the book
    on the shelf, the cat going by, you have a little insight into their
    life and maybe we’re all curious for that.

    00:48:31 - Speaker 3: And critically, you’re not going to share that to

    do list if it’s really ugly in the same way that you’re not going to
    do a YouTube video by your living room, it’s terrible, right? And I
    love the idea of building public as well as buying public or live in
    public, you know, it’s a great mirror image.

    00:48:47 - Speaker 1: Especially when it feels like there’s a default

    option for everything, like you buy your iPhone, you have your standard
    issue calendar and your standard issue, you know, notes app and
    whatever, and I think showing that you use other things or that you’ve
    thought through or thought hard about, maybe I’m different, maybe I
    don’t fit into this one box that Apple incorporated or Google
    Incorporated has kind of ordained for all of us to be in.

    00:49:12 - Speaker 3: Yeah, that makes perfect sense to me in the same

    way that people, you know, they don’t want to just wear, I don’t know,
    Levi’s jeans every day or something, right? They want to show that they
    have some other aesthetic taste.

    00:49:21 - Speaker 2: I’m actually reminded of people sharing their

    phone home screenshots, and then, you know, that’s going to be defined
    by almost the diff against the standard thing, and that includes the
    operating system default installed apps, but also maybe things that just
    kind of everyone has.

    OK, your, I don’t know, WhatsApp, for example, is basically the de

    facto messaging app here in Europe, and so you see a screenshot of a
    European’s home screen and WhatsApp being on there, there’s not much
    to comment on.

    But you see some new encrypted messaging app, or you see some, yeah,

    weird to do list thing, or you see something else that has an unusual
    icon and you don’t recognize, and then you wanna, again, what is that?
    Why did you come to that? Why did you choose that over all these other
    choices? That exists in the market, and then that in turn can be a point
    of pride, maybe for the person sharing. They’ve spent some time
    curating a set of software tools that serve them in their lives, and
    maybe they found some that have interesting vibe, interesting aesthetic,
    a unique take on the problem. And then it’s also for the person that’s
    inquiring, it’s a glimpse into their life again, and I think we’re all
    curious for that.

    00:50:27 - Speaker 3: Yeah, and I think this critically circles back to

    the idea of social distribution. So the original idea of social media
    was you’re following your small group of friends and you’re finding
    out whatever what Adam had for dinner or something.

    But the modern reality of social media is that a huge amount of the

    traffic is professionals, basically people whose essentially full-time
    job is having and demonstrating good taste on YouTube and Instagram and
    TikTok or whatever, and it’s a critical marketing channel for anything
    consumer, which I think increasingly is going to include consumer
    software, and if your products can’t participate in that, it’s a huge
    problem and conversely, if your product is very well suited for that,
    it’s potentially hugely helpful.

    And yeah, I feel like people are still really under rotated on how

    important things like YouTube channels and subreddits are for marketing
    and distributing consumer software, and the software, I think really
    needs to support that and be natives to those mediums if it’s gonna
    have a good chance.

    00:51:24 - Speaker 1: That’s a good tip for me. I don’t do enough for

    Redditing just cause I hate the interface, but I’ve definitely feel a
    lot of great success stories from that.

    00:51:32 - Speaker 3: OK, so there’s a little bit of cety here because

    I think very early on, as certainly you are in mostly still muses, you
    have to push up it yourself. You have to be the one to go and post on
    Twitter and Reddit, but the end game is you have people who’s like
    literal full-time job it is to make amazing videos about your software.
    Now this exists for things like Notion or Rome or whatever, right? But
    your software has to be amenable to that and worthy of such third party
    distribution.

    00:52:01 - Speaker 1: What do you think makes software amenable to that?

    Because this is something I’ve been curious about myself where like a
    couple people have done YouTube videos on Canopio, but like compared to
    the avalanche of notion hacks and Rome hacks and the rest, yeah, it’s
    like a drop in the bucket.

    00:52:17 - Speaker 2: Well, for sure, there is a bootstrapping effect

    happening there, which is that if your job is, you’re a content
    creator, you’re an independent content creator, you post product tips
    and reviews on YouTube, things that other people are already interested
    in are what are going to get you the views and the views ultimately
    translate into your financial results.

    So once something is already popular on people’s mind, and so yeah, the

    notion tips and tricks, for example, and I can almost tell when
    something has tipped over that.

    Line, maybe obsidian did that in this last 6 or 12 months, where you

    start seeing fewer of the, for example, what Muse has had plenty of,
    which is basically a review, assuming the audience has not seen this
    product before. Hey, I found this awesome product, let me show it to
    you.

    But then when you tip over into a certain level of, I don’t know what,

    renowned or just enough people have it or have heard of it or use it,
    then it’s to their benefit to essentially Give you tips or tricks or do
    things, and that’s the ultimate position to be in, right, is if other
    people are marketing your products for you because it benefits them,
    they’re not doing it for you, they’re doing it for their own brand.

    I think of like the ultimate in this is when the social media companies

    got their little icons to appear on every single billboard and flyer and
    you know, the little. Twitter icon, the Instagram icon, the Facebook
    icon, when those started to show up, I don’t know, 12 or 15 years ago,
    and I thought, wow, that’s amazing. They’re having every other company
    do their marketing for them.

    Apple, of course, is amazing for that. We are square in that. You go to

    our homepage and there’s a giant picture of an iPad, you know, we’re
    basically constantly doing beautiful product shots of their products for
    them.

    That’s because when it’s a thing that people already have and use,

    then, you know, it’s to our benefit. I mean, obviously we’re on that
    platform, which is a little different, but it’s to our benefit to talk
    about or be associated with something that people are already connected
    to.

    00:54:16 - Speaker 3: Perhaps I can synthesize a little bit here and

    answer your original question. I think there are 3 things that really
    helped this dynamic kick off, aside from the obvious one, like if
    you’re already big, people are more inclined to do it.

    One is this aesthetic sense, which I think is really important. A second

    is end user customizability and extensibility, because if the things
    that you can do in your app are limited to what the 5 people working at
    the company had already preconceived, it’s just not that much to talk
    about on YouTube videos, right? Whereas with something like Notion,
    it’s incredibly configurable and extensible. You can turn it into
    whatever you want, even within the world of calendars, there’s all
    kinds of different calendars you can make.

    And the third is having a way to make a living on the product. So an

    example of something that combines all three is something like Shopify,
    right? It’s very extensible. Obviously you can make a living, has a
    great aesthetic sense, and sure enough, there’s an incredible
    ecosystem. There’s many big businesses that are just like Shopify
    extensions, and you’re probably not gonna be like at that third pillar
    in a consumer app, but I think you can and do need to have the first two
    to really hit a big and again something like Notion or Rome has both of
    those.

    00:55:22 - Speaker 2: I also point out that software companies getting

    this kind of called influencer marketing or something like that is
    pretty new. I think that the hardware devices, what I usually think of
    as gadget lust, is way further along than that.

    So for example, I think of some of these really big channels like MK BHD

    who’s a YouTuber, does these amazingly well produced videos, many, many
    millions of subscribers, but essentially all of his videos are kind of
    commercials for the products.

    I mean, he’s giving an honest review for sure, it’s not like he’s.

    Just kind of shilling for the products, but he has a genuine enthusiasm
    for gadgets, so he reviews the new iPhone, he reviews the new Android
    phone, he reviews the new laptop, he reviews, I don’t know, Teslas, he
    reviews game consoles and does this incredible product photography and
    all this sort of thing.

    And of course, I’m sure as influencers like that have got to be a huge

    part of the marketing strategies to these companies, and I think for
    some reason gadgets. have had that or maybe I don’t know if it’s
    something you hold in your hand or I don’t know if it’s a more mature
    industry or something. I think software is only just starting to tap
    into that a little bit.

    00:56:32 - Speaker 1: Yes, I think video games have that too, that

    distinction is definitely there, but I don’t know what caused it. Yeah,
    I think maturity in a market may definitely have a part to play.

    00:56:42 - Speaker 3: Yeah, it is an interesting question what causes

    like it could be something like the hardware was more expensive, so not
    everyone can have a $1000 phone to like try out and post about.

    But I think this idea of video games is super important.

    Longtime listeners will know that we constantly say the future is

    predicted by the video game market, and here’s what’s happening in
    this market just in the last year or so, the companies are developing
    and releasing games, basically exclusively through influencers.

    So they set up a Discord channel where they have all the big YouTubers

    basically who play in Twitch streamers who play the game, and they do
    the initial phases of building in public there, you know, getting. Back
    on the balance and the art and the direction and everything.

    And then when they go to release like a a big release, a big update to

    the game, they don’t even post it. They don’t even have their own
    YouTube channel that anyone watches. They just tell these influencers,
    you know, here’s the release, you get it if you talk about it, you
    know, go and tell it to your audience, which is already huge. And I
    think we’re gonna see more and more of that.

    You’re already seeing it in consumer stuff like, you know, clothes and

    cosmetics and stuff. That’s how that stuff is all going, and I think
    we’re eventually gonna see a lot more of that direction in software.

    00:57:44 - Speaker 1: Yeah, I’d like to see that. That sounds really

    interesting, cool new world.

    00:57:48 - Speaker 2: Did you wonder if games or games have this quality

    that You don’t just pick one and play it for a super long time.

    You pick one and play it for a while, and then when you’re bored of it

    or you’ve finished it or you moved on or whatever, you always want to
    get a new game, basically, and so that makes a lot of sense for both
    reviewers but also purchasers to want to stay up to date, whereas I
    think productivity software, maybe this is starting to change, and I’m
    not necessarily saying that lots of churn in the tools that we use is a
    good idea, but maybe once upon a time you became an Excel expert.

    And Excel was your one and only tool of choice for a decade, 2 decades.

    Maybe now there’s a little more fluidity, people are looking for

    interesting new stuff, and not just early adopters seeking novelty, but
    folks who just genuinely want to try out the latest thing and see how
    that fits into their workflow and may indeed use multiple tools
    together, you may have 2 different to do apps and 3 writing apps, and 2
    spatial canvases, and 4 photos. Editors, and you tend to pull out
    different ones at different times.

    For example, I tend to use a different video editing software for

    desktop screen recordings than I do for live action video, just because
    I have different needs for each of those, and there’s one that’s
    optimized for each one.

    And there is the overhead of needing to learn and remember the controls

    for each one, as well as the cost, but assuming you’re OK with those
    things, it’s nice to have the specialized tools. I don’t know if we
    will be a kind of a video games or fashion level with productivity
    software, but maybe it could be a little bit more of something where,
    yeah, there’s a lot of folks out there who are genuinely always looking
    for new tools in their creative workflow, and they’re excited to see
    new interesting stuff come along and are enthusiastic about the
    increasing diversity of tools with interesting vibes.

    00:59:34 - Speaker 1: Do you think because of the high cost of like

    learning a tool, we might actually see more videos trying to like
    proactively look at what’s new in the world of software just because
    you want to make the right choice, or there’s a perception that you
    have to make the right choice in the same way that people review phones
    because you’re going to buy one in theory every 2 to 4 years.

    00:59:57 - Speaker 3: Honestly, my immediate reaction is, yes, cause

    everything is going to be video. I mean, already video is by far the
    most important medium for social communication, and I think it’s only
    going to become more so as it becomes more accessible and there are more
    tools that support it, so I would certainly bet on it, but we’ll see.

    01:00:15 - Speaker 1: Yeah, I could see it going both ways, cause I mean

    there aren’t a lot of videos about, actually there are, right? Like how
    to use Final Cut or like I’m thinking of like software that people
    dedicate a lot of time into. There’s videos on how to use Final Cut,
    but there’s also like, check out this new avid thing or whatever, in
    those niches.

    01:00:33 - Speaker 3: So, I think realistically, I think if most people

    want to learn Photoshop, what they’re gonna do is open up YouTube and
    type how to Photoshop. They’re not even gonna look in Google, right?
    And I think that’s just gonna become more and more common.

    01:00:44 - Speaker 1: Yeah, which makes it interesting cause we spent,

    especially you guys have spent a long time or a lot of effort making the
    Muse help website, which just has like a lot of videos in it and
    whatever, and you do have a YouTube channel. I’d love to know how
    making your own YouTube content has been going for you.

    01:01:03 - Speaker 2: Yeah, YouTube and longer form video isn’t

    something we’re investing in right now. I think, as Mark says, it’s
    incredibly important. It is also its own.

    Area of expertise, quite different from making software.

    It can be costly, you know, in comparison to writing, audio only, still

    images, or even short screencast recordings for social media, creating
    it just can be an incredibly laborious thing, but it can also tell
    stories, I think, in a way that no other medium can.

    This is the power of Hollywood and movies and the magic movies, and what

    that kind of visual storytelling can bring into our lives.

    So, I want to do a lot more with video and our YouTube channel, and we

    started this little biopic series that’s on hold for now, and we’ve
    done also, you know, more extensive product demos, and I’d love to just
    like do a channel myself that’s like how to muse and it’s just me like
    sitting there for 10 minutes and showing exactly how I do one
    particular. Thing, product strategy or plan out a marketing road map or
    some kind of life thing. But yeah, I think the skills to just do the
    production side of that is something that remains. I think I have a good
    sense of what you need to do, but I know just enough to know that it’s
    a whole giant world of things that I’m not good at yet, but I certainly
    hope to tackle that in the future.

    01:02:23 - Speaker 1: Yeah, from this chat, maybe this will help kind of

    wrap things up, but the kind of theme that goes through my mind is that
    even though software has been around for forever, and it’s on
    computers, which have also been around for forever, the place we find
    ourselves now is very like different from how software was sold and
    marketed or communicated about in the past. And being so different now,
    like it sounds like in the future it’s going to change even more. So
    yeah, it’s just like these are some wild times.

    01:02:52 - Speaker 2: I think that’s a great note to end on. Thanks

    everyone for listening. If you have feedback, you can write us on
    Twitter at @museapphq or on email, [email protected], and you can help
    us out by leaving a review on Apple Podcasts. And Prajean, I want to
    thank you for helping to push forward the idea of a spatial canvas for
    thinking. I think it’s something that is an idea with a lot of legs,
    but also for creating software with vibe, for showing what an
    independent creator can do, and for the frequent delight that you’re
    building in public demos on Twitter bring to my timeline.

    01:03:29 - Speaker 1: Glad to help. Thanks, Adam. Thanks, Mark.

    0 min
  • Discuss this episode in the Muse community

    Follow @MuseAppHQ on Twitter

    Show notes

    00:00:00 - Speaker 1: Also something that makes it very unique is this

    like you’re you’re basically floating through space and you’re
    zooming deeper into your hierarchy and all of this is like a perfect
    illusion of seamlessness when it’s actually not seamless at all.

    00:00:22 - Speaker 2: Hello and welcome to Meta Muse. Use a software for

    your iPad that helps you with ideation and problem solving. But this
    podcast isn’t about Muse, the product, it’s about Muse, the company and
    the small team behind it. My name’s Adam Wiggins. I’m here today with
    my colleague Mark McGranaghan. Hey Adam, and my colleague, Julia Rogats.
    Hi, Adam. And Julia, you have now made 2 have 2 years in a row to spend
    the entire winter in a sunny location away from your home in Germany.
    How’s that working out for you? You can repeat that again next year?

    00:00:56 - Speaker 1: Oh yeah, I mean, I guess we’ll see about next

    year and what traveling is going to be like in the future.

    Um, but at least for the past 2 years, I’ve really enjoyed that. I

    think, I mean, I love my hometown, Berlin, um.

    And I love being here in the summer, but in the winter it can get quite

    gloomy and dark and cold, uh, and I’m very much a sun person, so, um,
    yeah, I’ve really been making good use of this remote company set up
    and you know, make your own work hours for the most part.

    So spending lots of time in Adventurous places, kind of splitting my

    workdays in half, which is something that I really like to do, get some
    work done in the morning and then do something nice outdoors and then
    work some more hours in the night.

    Um, it’s been really been a really nice balance for me throughout the

    winter time.

    00:01:42 - Speaker 2: You have a very impressive ability to get stuff

    done while also interleaving it with adventure. You’ll, you’ll ship
    some major new feature and then go whale watching.

    00:01:57 - Speaker 1: And then fix a bunch of bugs and then go kayaking

    or I’d be like, guys, I’m going to be 20 minutes late from the
    meeting. I’ve just got back from a scuba dive.

    00:02:04 - Speaker 2: That’s yeah, absolutely. But it’s also a

    reflection of the kind of work environment we built. Mark and I talked
    about this on a previous episode of trying to make a space that is
    flexible. For all of the the people on the team to live the kind of life
    they want to live. And for you apparently scuba diving and uh whale
    watching and kayaking is is the life you want to live.

    00:02:23 - Speaker 1: Yeah, it’s definitely been amazing to not have to

    separate your life so much between like work and traveling. Like usually
    traveling for me always happened on vacation, um. And I actually find
    the mindset that I’m in uh when I travel, when I’m in a different
    country to be extremely stimulating in many ways and actually that to
    make me more productive. So being able to mix that has been quite a
    blessing.

    00:02:47 - Speaker 2: So our topic today is iOS development, and then

    from you specifically, kind of our gesturerer system and why that’s so
    challenging to implement.

    But I thought maybe for contexts for people that don’t know how IS

    development works either because they know about software development
    generally, but not necessarily kind of mobile development, or even
    people who aren’t necessarily that familiar with how software gets
    built. They might like to know, what does it look like for you? You sit
    down in the morning or maybe the afternoon to work on some features or
    fix some bugs, you’re going to start crafting muse out of artisanal
    ones and zeros. What does that actually physically look like? What
    devices are you using? What software are you using?

    00:03:31 - Speaker 1: Yeah, so in terms of devices, I use a MacBook

    first and foremost, as far as I know, you still can’t develop iOS or
    Mac software on any other platform. So that’s where everything starts
    and it comes with the with the IDE basically to develop for the iPad or
    iPhone, which is called X code.

    00:03:51 - Speaker 2: IDE being integrated development environment.

    00:03:54 - Speaker 1: Yes, correct. Uh, so basically it’s kind of the

    entire tool kit that you need to write software for the iPad or the
    iPhone. You write all your code there, you compile it there, you debug
    it there.

    So what I usually do um is that I plug in the actual physical iPad.

    The XO also comes with a simulator and you can run all of your um iOS

    apps in the simulator itself. So basically just brings up a little
    screen on your computer that looks like an iPad or an iPhone and you can
    do most things there.

    But for an app like ours, which is extremely gesture driven and we use

    the pencil for many things, it’s a bit tedious to actually um work with
    the simulator and some things aren’t possible at all. So I work with
    the physical device plugged in.

    You can actually also build to it wirelessly as of a couple of years

    ago, but it is a little bit unstable, so I try to just depend on the
    cable there. Um, and yeah, then I just write some code, like click one
    button and then it runs on the device and then I can test everything
    there.

    00:04:59 - Speaker 2: And this is the SWIFT programming language. Uh,

    we’re storing our data, or sort of the persistence layer is core core
    data. Do we use any other fancy libraries or APIs or is it mostly just
    kind of the Apple gives you a pretty complete kit for development,
    everything from the editor through to the language and all that stuff,
    the simulator like you said. Uh, whereas like I come from Mark and I
    actually both come from more of a web development background, there
    you’re putting together more mix and match, uh, the tools, the
    language, and the different pieces. But here you get this one kind of,
    it’s the Apple style thing, you get this one pretty complete kit.

    00:05:33 - Speaker 1: Yeah, pretty much. Um, so I think.

    It’s fairly rare for an IOS project to have no like zero dependencies

    to any sort of third party libraries, but ours are actually quite
    minimal. I think we have something in there, for example, for like
    zipping and unzipping files. That’s something that as far as I know is
    not built into the IRS kind of standard library.

    But for the most part, really like the IOS SDK is extremely

    comprehensible. You can do all kinds of things with it. They over the
    years they’ve added um much more stuff, especially from kind of open
    source third party frameworks that were very successful, have often been
    integrated in one way or another into the um IOS ecosystem or they’ve
    basically rolled their own, their own version of it. So our dependencies
    on on external frameworks is actually quite small.

    00:06:28 - Speaker 2: And at one point we were doing the, maybe this is

    back when Muse was still a lab project or a persistence layer was
    Firebase, which is this kind of mobile back end data service from
    Google. Um, what was our, I think you like we like that pretty well,
    developer experience wise, but what, what led to us kind of replacing
    that with the Apple standard on device storage?

    00:06:49 - Speaker 1: Well, I think the main motivation here was that we

    basically didn’t want to be dependent on Google and kind of giving
    giving our users data um to be stored on Google servers. So I think that
    was that was the main motivation.

    00:07:02 - Speaker 3: Yes, speaking of Sending or not sending user data

    to Google. I’m really proud that we don’t have any third party
    analytics libraries integrated into Muse because these are notorious for
    scraping all kinds of data and sending it to a bunch of third parties.
    You saw this recently with Zoom, for example, where they had, I think it
    was the Facebook SDK integrated and apparently unbeknownst to them was
    sending all kinds of user data to Facebook, presumably for advertising
    purposes. Um, so I think that’s a really healthy thing that we have
    with our current minimal dependencies.

    00:07:30 - Speaker 2: We do have analytics, but this is a, a system

    built by you or, or it’s sort of a roll our own type thing.

    00:07:37 - Speaker 3: Yeah, and it’s it’s extremely minimal and

    deliberate. So every single field, which is like basically like 3 or 4
    that we send this analytic service, are handpicked by us. It’s in our
    code, it’s it’s explicit versus a dependency that’s updating every
    week and it’s scraping new random things from the OS and sending it to
    third party servers where you have no control over it.

    00:07:58 - Speaker 2: Mark, you end up building the back side of things.

    Ya, you do the client side of things. How do you coordinate around that
    API? How do you, how do you figure out how to make those two ends meet?

    00:08:08 - Speaker 1: I think um for the most part, it’s been pretty

    lightweight. We chat on Slack about what’s needed for a certain thing.
    Um, often Mark ends up kind of drafting a notion document or something
    that like API docs or design specification kind of thing.

    00:08:24 - Speaker 3: Yeah, exactly. So, so typically these notion docs

    will have first the mental model, which I think is really important,
    like what’s the shape of the domain here, what are the key objects and
    key verbs, and then a sketch of the HDP API which again is usually very
    simple, and then a discussion of the behaviors that are behind that.

    00:08:41 - Speaker 1: And then as soon as we get into implementing that,

    um, it’s usually we end up being online around the same time and I’m
    telling him, OK, I’ve just implemented this API. Uh, is it deployed
    yet? Can I, can I start hitting it and then I’ve just, you know,
    depending on what it is, I send some sort of event and mark checks in
    the logs if you see if he’s seen the right thing and you know, often
    there’s a few things from there that we need to fix like something is
    not encoded in the right way, but we basically just tackle that together
    via Slack or a video call.

    00:09:12 - Speaker 2: Be just to round out the tech stack discussion

    since we referred to the front end there with, you know, SWIFT and core
    data on the back end we’re basically doing Ruby postgrass and Hiroku,
    which for Mark and I is kind of our very standard tool kit.

    I think they say, you know, we came out of this research lab where our

    goal was to push the boundaries of technology and what what we can do
    there and try lots of Weird and interesting cutting edge things. But
    once you have, once you’re moving into the realm of production and
    commercial products, they say, choose boring technology. Choose the
    boring things that are workhorses that have worked really well.

    I’ve used Postgrass, for example, for, I don’t know, now 15 or 20

    years, um, and there’s always a shiny new thing, but the stuff that’s
    really reliably and the stuff that is performed reliably for you for a
    long time is often just the thing to do.

    00:10:02 - Speaker 3: Yeah, I’m really happy with our back end stack,

    and of course, Hiroku, but also Postgrass in particular, such a great
    database, super rock solid, super flexible, and now we can use it for
    both our sort of online um data as well as our analytics data.

    00:10:16 - Speaker 2: Yeah, and a quick shout out on that kind of from

    the product perspective to data clips, which is a little way to bundle
    up a SQL query in a form that you can share it as a, um, as a web page.
    We use that quite a bit as our kind of our ad hoc analytics sharing
    system.

    Right, well, let’s get into the media part. I hopefully that gives some

    good context for um technical or um less technical folks about exactly
    what the pieces are here.

    Now getting into something that is pretty, and all of that I think is

    fairly sort of standard stuff that you might see in a in an iOS app or
    an iOS app that has a small back end. But getting into Muse, which is
    trying to really push the boundaries on what you can do with a tablet
    app, with these unique gestures, the different treating, treating the
    pencil differently from the the hands, that there’s multi-handed
    gestures and all this. So we have quite a bit of both design and
    engineering effort that has gone into our, our gesture system. But maybe
    we can start at the very beginning. Julia, what is a gesture?

    00:11:20 - Speaker 1: A gesture is uh it’s a good question actually. I

    don’t think I’ve ever defined that for someone. Um, in terms of IOS
    development, there’s actually a whole system around gestures and
    gestures can be of one or more categories. So there is a pen gesture
    which would be just setting your finger down on a screen and moving it
    somewhere. You might be actually touching an item that you want to drag
    along, but you can also, you know, pen for any other reason, for
    example, to draw something. Then there are things like swipe gestures,
    which are also a pen in a way, but they’re like distinct here like just
    flipping through pages. Then there’s scrawling, which is a more of a
    continuous leaving your finger and scrawling something. There’s a
    scrawl gesture, um, there’s pinching, which is sort of you’re zooming
    in and out of of things and there’s a whole bunch of uh other gestures
    that you can. You can combine in your app to achieve different things,
    but they usually triggered with your finger or in our case or in some
    other apps cases also with a pencil.

    00:12:22 - Speaker 2: Yeah, probably from a user perspective, you don’t

    even think that much about something like a tap, a double tap, a swipe,
    a pinch.

    These all part of the magic and the beauty, I think of multi-touch

    screens and why they’ve um Sort of taken over the the world in terms of
    interfaces, is that they do seem so natural, and it seems so obvious,
    the difference between, for example, a swipe, a scroll, and a pinch.

    But in fact, it’s quite a bit of logic to um make sense of that stuff.

    And I have experience with sort of mouse, um, wouldn’t call them

    gestures, but basically interpreting what the user does on a desktop
    computer with a mouse, um, in my past life as game developer, and There
    things are actually a lot simple because you’re a lot simpler because
    you generally have the X and Y position of the cursor and whether the
    buttons are down. And there is a time element for some things like
    double clicking, but it’s pretty minor. Most things are really
    discrete.

    Uh, the thing that I think really opened my eyes on this was, um, we

    both were at UIO last year where you gave a talk. And another talk there
    was, uh, Shannon Hughes, who worked for Omni Group. They make the some
    great productivity tools like Omnigraphle and Omnifocus. And she had
    worked on, I think the iPad app for one of these, and had done gone
    pretty far on these um these gestures and even has written an open
    source library for basically making a diagram. And she showed this,
    these kind of these gesture disambiguation diagrams, uh, in real time
    and you could see that actually this, there’s this huge time component
    where what makes a gesture a gesture is not a discrete moment in time.
    It’s a collection of positions and You know, touches in different
    places and movements of those touches over time and the accumulation of
    those things eventually resolves itself into the system deciding, OK, I
    just saw a pinch.

    00:14:17 - Speaker 1: Yeah, exactly. And gladly we’re getting pretty

    much.

    All of that for free from the iOS SDK.

    So you could, if you wanted to and you, you know, you had the time or

    which is an interesting experiment for you. You could actually write all
    that yourself, so you can get just very raw touch input events from the
    system. If you have a screen. You can basically just implement a couple
    of methods that will fire whenever a finger goes down and moves
    somewhere just with a position and nothing else. And you could go from
    there and build your own, you know, this now. I think these fingers
    moved apart from each other, so it must be a pinch out. But um gladly
    the folks at Apple have gone through all of that work for us and uh
    developed this concept of a gesturerer that you can just attach to any
    view and that will make that view respond to specific gestures, for
    example, a pinch and just notify you when when that gesture first starts
    and then when it changes and also give you for a pinch, for example,
    it’ll give you the scale. So it starts out with a low scale and then As
    you pin, as you move your fingers further apart, the scale value will
    change and it will just notify your callbacks and uh then you can zoom
    or do whatever, whatever else you want to do with that pinch.

    00:15:33 - Speaker 2: Now, if I was to look at the raw data, and I think

    I’ve seen test programs that do this, the screen or the the system
    that’s reading these touches, of course, doesn’t know which finger
    I’m setting down.

    So the difference between, you know, for me, where I can see my hand,

    it’s pretty obvious that if I, if I put down, for example, my thumb and
    my index finger near each other and move out, you know, that looks like
    a pinch gesture or put them down further apart and move in, that looks
    like a pinch. But the difference between doing that with my thumb and my
    uh pointer finger versus doing it with each thumb on each hand, which
    you could totally do. But the system can’t tell any difference. It just
    to text touches in certain locations and then those touches start
    moving.

    00:16:17 - Speaker 1: Yeah, exactly. And that’s actually what makes

    everything so complicated that we’re trying to do.

    In fact, a pinch is even recognized when fingers only move. By only a

    very few pixels.

    So one example that I can give from from our app where this was a bit of

    a puzzle that we had to solve is we want to allow two fingers scrolling
    on a board. That means you sat down two fingers and you move them in,
    you know, either to the left or right to scroll the board. But we also
    have this sort of global pinch gesturerer that listens to you pinching
    out to zoom out back to the parent board. And that gesture is triggered
    by, or at least in the past has been triggered by even the most minimal
    movement. So we wanted to build the app in a way that is, that it’s
    super fluid so that it responds to your touches right away. That means
    that even if you set two fingers down on the screen and they converge by
    maybe 5 pixels towards each other, the system will consider that a pinch
    and will immediately start the zooming transition. So when you’re
    actually just using two fingers to try to scrawl, there’s basically no
    way that you can, you know, you’re not a robot, you’re not gonna be
    able to keep them completely parallel to each other. So we had to add a
    bit of custom disambiguation logic where. Pinche is only triggered after
    the fingers moved, you know, maybe by. a scale of 1.1, um, so by, you
    know, more than 10 or 20 pixels depending on, on where you started with
    your fingers, and that adds a little bit of delay to the system, you
    know, actually responding to your actions when you do want to pinch,
    which is a trade off, obviously, but it’s basically the only way that
    you can make these two gestures work together, um, and dis disambiguate
    them in some way.

    00:18:13 - Speaker 3: Yeah, this delay issue is really interesting.

    One of our top level design goals for you is that it’s super fast and

    responsive.

    So the idea is, as soon as you touch the screen and do something, the

    app should respond. So you always feel like you’re directly
    manipulating your content. And as Julie was saying that’s really hard
    with these gestures that are potentially ambiguous. And in some cases
    we’ve taken this approach where you Uh, just try to have a very small
    delay, basically imperceptible delay that allows you to disambiguate. I
    mean, that seems to work pretty well. Another approach that I’m excited
    about trying is actually doing both optimistically, and then
    retroactively picking one once the disambiguation becomes more clear and
    rolling forward with that and unwinding the other one. So you can
    imagine with this pinch of You start doing a pinch last scroll. It’s
    ambiguous and it basically starts zooming imperceptibly and scrolling
    imperceptibly. And then once it becomes clear that you’ve done one or
    the other, it unwinds the thing that it wasn’t, you know, zooms out
    slightly, for example, and then keeps doing the thing that you were
    doing, scrolling, for example.

    00:19:15 - Speaker 1: Yeah, we’re actually already doing some of that

    um in a similar, in a similar problem.

    So the same way that I was just talking about you can two fingers scroll

    anywhere on a board. Um, you can also drag any card on any board with
    one finger, and we deliberately, as you just pointed out, we
    deliberately wanted to make that instant. So most apps work in a way
    where you hold your finger down on something and then it sort of enters
    like maybe slightly lifts and enters into a movable state and then you
    can drag it around.

    Um, and that’s exactly the thing that we didn’t want, and I think one

    thing that makes news very unique that is like ultra responsive.

    So as soon as you set your finger down a card and you start moving it,

    you can even have your finger do a movement as you set it down. The the
    cart will start moving with you.

    And so the problem with then the two fingers scrawling here is that when

    you do want a two finger, you do want to use two fingers to scrawl, and
    in that case, we don’t want to move that cart as you sat down your two
    fingers, inevitably one of the two will set down first because again
    we’re humans, not robots. So even if it’s just a fraction of a second,
    that first finger that comes down and moves by one pixel will trigger
    the car movement.

    But then the other finger comes down and then the system actually

    recognizes, oh, it’s a scroll, and it actually cancels the car
    movement. So you might sometimes if you do it very fast and if your,
    your first finger goes down noticeably earlier than the other one, you
    will see your your card start dragging and then jumping, kind of
    animating back into place where you picked it up from and then the
    scrolling kicks in. So we’re using that trick already a little bit in
    the app, but it’s quite cumbersome to implement that. So I hope, I hope
    eventually we’ll have more of a unified approach for this kind of
    thing.

    00:21:07 - Speaker 2: Can you talk a little bit about what the overall

    framework here is? Um, is it essentially a giant case statement or a
    series of statements or is it more of a state machine or what does that
    what does that look like?

    00:21:20 - Speaker 1: Yeah, it currently isn’t really. Uh, very

    cohesive system, um, because of how some of the components interact. So
    you still want to be able to kind of give individual components the the
    ability to control themselves basically without writing this this global
    gesture handler.

    00:21:41 - Speaker 2: By component to control itself, here you’re

    talking about. That there’s not one entry point for someone to touch
    the screen. It’s more you want to attach a, a snippet of code or a
    piece of functionality to say a card, and it, it sort of knows, so to
    speak, how to, um, how to manage touches that it it receives, and that
    can be somewhat dependent from what another card does.

    00:22:04 - Speaker 1: Yeah, exactly. So for the cards, actually, um, we

    do have a bit more of a global approach because of how much the card
    dragging interacts with other things like zooming in and out of boards
    while you’re dragging a cart along.

    00:22:16 - Speaker 2: So is this the maneuver?

    00:22:19 - Speaker 1: Yeah, this is the maneuver that made everything so

    difficult for us.

    00:22:23 - Speaker 2: OK. Well, in the backstory here is it’s pretty

    critical, right? There’s, you know, if you’re inside a board and you
    have one or more cards you want to take elsewhere.

    You can, um, you can stick it in the inbox. There’s kind of, you know,

    maybe you can use copy paste, but that’s kind of a hassle. Really, what
    you want to do is grab it and then navigate to your new location. And in
    fact, that’s how it works. Sometimes we call it the two-handed card
    carry. So you can put your finger down, you’ve kind of picked up, so to
    speak, that one, and then if I pinch out with the other hand, I’m
    essentially now I can freely navigate around and I kind of keep this
    other card in this floating state. Um, but that’s the thing that
    doesn’t work if the gesture handlers attached to the card itself.

    00:23:04 - Speaker 1: Yeah, exactly, because the gesture, uh, in, in

    order to be able to carry the card into a different space, we basically
    have to detach it from its parent.

    So before I was living on this board, and then if you had a gesture

    recognizer attached directly to the card, you can move it around the
    board, but as soon as you put it uh to a different parent, The gesture
    uh recognizer actually cancels and you basically lose that gesture. And
    so in our case, in order to be able to carry it to a different board, we
    basically have to put it um on the top level hierarchy, basically attach
    it to your window. So that you can zoom potentially many levels deep or
    or further up your hierarchy um until you find the board where you want
    to put that card and let go.

    00:23:52 - Speaker 2: So many of these things that are challenging is

    because Muse does come from a a different set of product design
    principles.

    And one of them is this certainly the spatial zooming um interface, but

    also that we want to maintain this illusion of a continuous fluid
    space.

    Um, I think with many other kinds of applications, you have this sense

    of going to different screens or different pages, and you know that when
    you go to, when you, when you navigate to that new screen or page, all
    of the kind of stuff that was on the previous screen just goes away or
    isn’t relevant in this new place.

    And I think that’s fine for a music player or something like that, but

    what we’ve tried to create this space where you have this big workspace
    and you can move stuff around freely between it. But then the kind of
    libraries and the APIs that come with, certainly the iOS system or I
    think any kind of UI system is just not built, uh, assuming that,
    assuming you want to do something like that.

    00:24:47 - Speaker 3: Yeah, this is, this is an aside, but I really like

    that there’s no loading screens in Muses. You don’t open documents or
    load them, they’re just there when you look at them, and that seems
    obvious, but when you go back and use an app where you’re constantly
    loading documents, waiting for them to open, it’s just a totally
    different experience. So I think it’s worth the effort that we go
    through on the technical side.

    00:25:07 - Speaker 1: Yeah, and uh you know, not, not least of that um

    the the sort of challenging model that we chose for Muse, which is also
    something that makes it very unique is this like you’re you’re
    basically floating through space and you’re zooming deeper into your
    hierarchy and all of this is like a perfect illusion of seamlessness
    when it’s actually not seamless at all. Basically every new board that
    you load has to be rendered by the system. It has to be, you know,
    loaded into memory. And we, there’s some tricks we’re using there, but
    it’s uh it’s certainly not, not easy to keep up that illusion all the
    time.

    00:25:43 - Speaker 2: Mark, I think you’ve made the comparison to video

    game development at various points, and this does actually remind me of,
    you mentioned loading screens. Video games with big continuous worlds,
    which is, I think, pretty common in today’s um kind of open world
    games.

    This actually has a similar technical challenge that you don’t want to

    interrupt the players’ movement and and give them a now loading screen
    that really kind of is a kink in the experience or or removes that
    illusion of being one continuous world.

    But in fact, when you have this huge world that can’t possibly fit in

    memory, uh, you do need some way to handle that. I think there are
    similar, I think, I feel like a lot of the tricks that we’ve landed on
    to make this work, uh, for Muse actually would be quite right at home in
    the video game world.

    00:26:29 - Speaker 3: Absolutely. Circling back to gestures, then

    perhaps we can talk about gesture spaces. So this is the idea of the A
    kind of set of gestures that is possible in the app and the the actions
    that you can do with that, we found that to be a really interesting
    challenge with Muse. the set of things that you could do with your hands
    or the pencil and the actions in the app that that maps to. And one of
    the reasons this is so challenging is it tends to be much more
    constrained than a desktop app. So on desktop, you have the mouse, you
    have the two buttons, you have the mouse scroll wheel, you have the
    whole keyboard, and then you typically have the menus and the pattern of
    a right click menu or a press and hold menu. Whereas on mobile, you
    know, traditionally you just have like basically one finger, and with
    uhm we’re trying to extend it to, you have 10 fingers and uh the
    pencil, but it’s still quite limited. You don’t have, for example, a
    menu where you can just add a bunch of stuff as you have more
    functionality in the app. So whenever you add a new feature, you need to
    find a way to invoke that with your hands, which isn’t easy because
    there’s a quite limited uh space um to draw from. So, so that that that
    results in a few concrete challenges.

    One is, you need to come up with particular gestures. So an example for

    us is we need to find a way to um pick the color of ink you’re using,
    and for that we have the swipe from the edge of the screen. Gesture,
    which is I think pretty novel, and I guess that’s something that’s
    built into iOS.

    00:27:55 - Speaker 1: Yeah, the, the swipe from the screen with your

    pencil gesture is actually quite a harrowing thing that’s still an
    ongoing problem for us.

    So IOS actually does have a deliberate, I think it’s called UIH swipe

    gesturerer or something like that. So that there’s a way that you can
    attach a gesture listener to only swipes that happen from outside the
    device into the screen and I think iOS uses that for all of their
    system-wide thing like you can summon the dock from the bottom or you
    can.

    Gate back by swiping from the left.

    Um, and I was when I was initially implementing this menu, I was like,

    oh great, we’ll just use swipe gesture recognizer like that and we make
    it fire only for the pencil because notably those gestures, the
    system-wide gestures and IOS don’t work with the pencil.

    You can’t summon the dog with the pencil or you can’t pull in the

    Control center with your pencil from the top. So I thought they would
    just be up for grabs, those gestures, but unfortunately that edge swipe
    gesture recognizer does not work with the pencil.

    00:29:05 - Speaker 3: Surprisingly often, we’ve run into the sort of

    edge of the map on the iOS APIs uh because we’re doing things that are
    quite unusual in Muse.

    00:29:16 - Speaker 2: And what do you do for testing and debugging this

    stuff? You, you’ve talked about the simulator, but that’s pretty poor
    for uh for this kind of thing. There’s obviously you have the physical
    device there. How do you test this stuff?

    00:29:28 - Speaker 1: Yeah, so testing gestures um is, is, you know,

    obviously a little bit harder than than other debugging in some cases
    because you can’t just put a breakpoint in the middle of a gesture to
    see exactly what’s going on.

    I mean you can but then you basically, when you then focus your

    attention back to the screen. And to try to see what’s going on, you
    have to lift your finger from the device that you were just testing on
    and then once you, once you continue execution, that that gesture will
    have ended.

    So what I usually do is I put a lot of logs. So if I’m trying to

    disambiguate some gestures and often it’s like very finicky, like which
    one fires first and then what what like what finger went down first and
    was it on a card or on the board um and then I just go manually through
    those locks and try to try to figure out um the the sequence in which
    things are happening and where I can where I can intervene and uh tweak
    things.

    Another thing that we uh that we use internally for debugging is that we

    have a little system that actually visualizes your touches on the screen
    that often helps to kind of explain to other people in the team, look,
    when I’m doing this gesture, um, something happens that shouldn’t be
    happening and there’s a way that we can activate um basically little
    blue circles showing up around where your fingers are and little um and
    different colored circle for your pencil. And then it’s really easy to
    kind of record a video or do a screen share where you show your um your
    peers what exactly you’re trying to do and what where where exactly
    your fingers are when certain things happen. So that’s, that’s kind of
    been a useful team, team. I would say.

    00:31:11 - Speaker 2: Yeah, by sharing a video, you’re showing a not

    only a reproducible case, but then you can even kind of slow.

    I find it useful sometimes to slow down the video or pause it to to

    figure out exactly what’s happening there, where and can, can make it
    more reproducible.

    I’m sure we can get more sophisticated with those tools over time, but

    yeah, those colored circles have proved, combined with the screen
    recordings have proved, uh, remarkably useful for us in testing.

    Uh, you mentioned earlier the uh the operating system gestures like

    summoning a doc from the edge, uh, talking about the stylus from the
    edge reminded me of the, uh, take a screenshot by going uh stylus in
    from the um one of the corners. I wonder what happens in the case when
    we end up colliding with OS system gestures. For example, we had some
    some capabilities in the app when I was more in kind of beta prototype
    phase that did involve dragging up from below, and those would get in
    the often interfered or or had a bad interaction with the. Uh, with the
    OS summit a dock, and notably, I think when we started working on the
    app, it was before the dock had been introduced, so that gesture to
    summon the dock didn’t exist, but later it became totally foundational.
    Hall, now iPads and iPhones don’t have home buttons to take you. Home
    button you swipe up from the bottom. But then we basically had a swipe
    from the edge of the screen and specifically the bottom gesture, and
    that was colliding with that in a pretty bad way. And we, we basically
    had to make a make a change there.

    00:32:43 - Speaker 1: Yeah, well, I think the general rule is here um

    that the operating systems. So this this has been a trend over the past
    couple of years where where um DOS is actually has been taking over more
    and more. gestures, particularly around the edges of the screen, and in
    many cases for apps that means they’ll just have to change their
    gesture system.

    There is a way that you can, you can basically override these gestures

    once and tell them that you know, I actually want to get this swipe
    first. So this is something that we we tried out when we had the the
    thing that you were able to pull in from the bottom. Um, you can tell
    the system to defer its system gesture to let your Uh, your own app, get
    that gesture first and what that does is that it, um, it makes your app
    execute the gesture, but then also brings up this like little arrow
    thing. Um, and if the user actually if the user’s intent was actually
    to pull up the dock, then they have to basically do the gesture again on
    the arrow and then pull up the dog. But that makes a lot of users very
    angry and I think rightfully so if you, yeah, if you, if you learn how
    to how to use your device and you kind of have muscle memory about
    around certain things and certainly Uh, such fundamental things as, you
    know, switching an app and pulling up the dock, then you don’t really
    want apps to interfere with that or kind of override it with their own
    default behavior. So you basically just have to cave in.

    00:34:11 - Speaker 3: Yeah, and there’s a risk here of major gesture

    space reflow.

    So I mentioned how we’re using basically all the gesture space that we

    know of for the app. It’s all packed with our different features and
    functionality, and so, if the OS takes away just one. You could have
    this musical chair situation where one of the features of the app
    doesn’t have anywhere to sit. And so then you need to, you know, figure
    something totally different out for your gesture space, you know, open
    up a whole new room, for example. Um and we’ve gone through that a few
    times where we were just short of the degrees of freedom that we needed,
    so we need to basically rethink how all of our gestures work.

    00:34:47 - Speaker 2: Just recently, a friend of mine was learning the

    terminal, the Unix terminal, and in the process of doing this, this was
    on a Windows computer, I was surprised to learn that the copy command
    does not work, so they’re used to pressing control C.

    But it turns out the Control C has a long history well predating the

    existence of copy paste buffers to break out of a program in the Unix
    command line. So typically these terminals on the Linux and and uh uh
    Windows will basically take over that control C because they need it for
    the sort of for the historical compatibility.

    And in fact, users are quite used to that as a way to break out of a

    program.

    But then if you’re expecting that that’s a copy, which is an

    absolutely crucial uh capability that people rely on all the time, uh,
    it’s quite confusing, distracting, annoying that that gets blocked and
    you need to use essentially another key command or another way of doing
    copy.

    So that sort of thing has existed since time immemorial, but maybe iOS

    and the iPad in particular, such of a quickly evolving. Uh, new space.
    And so we’re trying to push the frontier, but then the operating system
    maker is also trying to push the frontier and then simultaneously, of
    course, as we explore the space, the likelihood of collisions is
    reasonably high.

    00:36:05 - Speaker 1: And I think we’re already trying to do a lot of

    things differently, um, but we can’t possibly overload the user with
    too many weird things. So in some cases just doing the standard thing is
    probably also a good idea.

    00:36:17 - Speaker 2: We’re definitely pushing right up against the

    ceiling of a number of weird things for the for the user to learn.

    00:36:23 - Speaker 3: So, Julia, looking forward, what are you excited

    to try in the gesture system?

    00:36:28 - Speaker 1: So I’m actually still kind of flirting with this

    idea of um something that you you referenced earlier um talking about
    this uh this new icon talk by Shannon Hughes where she introduced this
    idea of actually building an entire state machine that manages all the
    gestures in your app.

    So that way you you have one centralized place that always knows about

    what’s going on and what’s possible to go from one state to the next.
    So if you One if you set down a finger on the screen.

    From there it might be possible to go into a pinch or into a drag cart

    and the state machine would handle all of the valid states and state
    transitions and that way you you have a more deterministic and
    consistent approach to things and you don’t have to. scatter different
    different um dependencies across different components of your app that I
    have to check, am I currently dragging a card? Do I need to cancel that
    drag in order to start the scroll.

    Um, so I think a bit more centralized approach there could actually be

    interesting, but it would also be a lot of work, um, so currently we
    haven’t. We haven’t made that a focus yet because what we have is
    working pretty well, but if, if, if we ever get bored or if this ever
    becomes a huge issue, I think that would be something that I would be
    excited to try.

    00:37:50 - Speaker 2: While there’s way more to talk about here since

    we’ve invested a huge amount of time into uh this gesture system and
    certainly will going forward, uh, perhaps we’ll leave it there. So if
    any of our listeners out there have feedback, feel free to reach out to
    us at UAHQ on Twitter or hello at musesApp.com by email. Love to hear
    your comments and ideas for future episodes. You very glad that you’re
    uh working hard to make it possible for Muse users to have this fluid
    and powerful interface for interacting with their ideas.

    00:38:25 - Speaker 1: Thanks. Yeah, it’s been uh obviously a lot of

    fighting but also a lot of fun.

    0 min

About Metamuse

From the publisher's feed

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